DX化のジレンマがシステム連携を阻む
具体的に、「連携されていないシステム」とは何かをお話しします。
例として、PSI（Production：生産、Sales：販売、Inventory：在庫）計画で考えます。売上データに応じて生産データが作られる時、データの連携を電話やExcelで行っているケースが多いのではないでしょうか。購買部門との連携についても、厳しい現状があると考えています。
また、実際の生産データや販売データを入力するときに、その粒度が合っているのかどうかも難しいポイントです。このような問題が重なり、業務システムがバッチ連携に近い状態になっているケースが多く見受けられます。
では、「シームレスにシステム連携している状態」というのはどういうことでしょうか。簡単に申し上げると、購買・生産・在庫・品質・販売の各分野のデータが同じ粒度で上がってきて、原価・管理会計・財務会計につながる状態。そして、経営者が見る経営管理のデータにつながっていく状態を指します。
理想は、仕入先から顧客までのデータが一元化されていることです。しかしながら、ここまでできているお客様はなかなかいません。これを阻む要因である「DX化のジレンマ」を3つお話しさせていただきます。
1つ目は、小規模なDX化の範囲にとどまり、サイロを打破できないこと。経営者が「DXをしよう」とは言うものの、部門ごとに動くのが通常となっている日本企業では、現状の組織のままシステムを作ろうとしてしまいます。そうするとサイロのままとどまってしまう。その上からまた何かしよう、ということでいろいろやる。つまり、企業全体として何をすべきかを検討する機会がないまま過ぎてしまう。「DXに投資しました」という企業も、部分で終わっていることが多いのです。
2つ目は、経営層の方が“Fit to Standard”にこだわりすぎてしまうことです。パッケージに合わせればいいという思考は、スピードの時代には、大局的には正しいのですが、対象をしっかり見極める必要があります。ここを間違えると、業務革新で経営改革をしなくてはいけない部分を忘れてシステム導入が目的になってしまい、うまくいきません。Fit to Standardについて我々は、どこの部分が合うか、ある程度の切り分けが必要だと考えています。
3つ目は、「“ものさし”がない構想策定」です。Fit to Standardと真逆の発想で、ものさしを持たずに進んでしまったら本末転倒です。パッケージの良さは、ベストプラクティスがあるということ。それに合わせる必要があるのかないのか、というものさしを持ち、エリアごとに分けて見ていくことが重要です。
３つの機能を適所に配置し、ジレンマを解消
続いて、当社が考える構想策定に話を移します。
DX時代に必要なことは、「ECOシステムの最大活用するための機能配置」です。我々は「機能配置」というコンセプトを用いて、ジレンマを解消します。機能配置とは、機能ごとにグルーピングをして、システムのランドスケープをデザインする手法です。
機能は、「基幹系内部システム機能」「周辺システム内でのシステム機能」「基幹系と周辺システム間のデータ連携」という3つに大別されます。
「基幹系内部システム機能」は、原価計算・材料倉庫・出荷関連などのデータを扱います。先ほどお話ししたとおり、まずここでデータがつながっていないケースも多いと思います。
原価計算一つとっても、SAP製品を使ったお客様でも、まだ標準原価の域を出ていないことはあります。生産データと絡んでくるところでもあり、入力が面倒だからデータが作れない、といったことも多く起きるエリアです。
材料倉庫のエリアでいえば、伝統的にオフラインでやるところが多いようです。リアルタイムでのデータが取れず、各担当者が探す必要も出てきています。さらに、データもバラバラに入っていて、ロット単位にすぐに引き出せない、といったことも起こっています。
「周辺システム内でのシステム機能」は、PSI連携や管理連結を扱います。PSI連携は、部門ごとの縦串でデータを取り、そこから電話等でやりとりしていることが多いため、うまくつながっていません。管理連結としても、各拠点とのデータのやりとりをExcelで行っているケースが多いのではないでしょうか。
2つをつなぐシステムとしての、「基幹系と周辺システム間のデータ連携」は、E-BOM・M-BOM連携が1つの例となります。データ連携が取れていないことで、手作業がたくさん発生します。これらをなくし、データをつなぐ設計をしていくことが「機能配置」です。
こういった機能配置は、プロジェクトの序盤にあたる「構想策定フェーズ」で取り組ませていただいています。ここで基幹系システム、ECOシステムでの役割分担を明確化しておくことで、その後の要件定義・実現化・稼働準備・稼働につなげていくのです。
お客様が既存の仕組みを持っている場合には、切り替える必要があるところとないところを分け、柔軟に対応していきます。データの連携を妨げない範囲で、周辺の仕組みをいかに使いこなしていくか。こうしたことが重要だと考えています。
