見出し画像

SAP導入ではコンサルとユーザー企業は同床異夢の場合が多いみたいです

 先日、江崎グリコさんのシステム障害の記事を投稿しました。
 ありがたいことに、都築さんのnoteで私の記事を引用していただきました。(さらに、私の記事も褒めてもらいました。素直にうれしいです!!)

 この記事を読んで、「やっぱり業界ではSAPは炎上確率が高いのかー」「20年前からSAPは燃えていたのかー」「カスタマイズで儲けるのかー、ユーザー企業にとって良いとこないなー」と感じました。
 ユーザー企業の立場でも薄々は気づいていましたが、これだけ明確に言っていただけると、とても有難いです。(隠居したので、実務には役立ちませんが・・・)
 今回は都築さんの記事を読んで感じたことを記事にしました。

 余談ですが、システムを更新する企業の担当者の方は、(株)ディーエックスフォーさんみたいなコンサルをセカンドオピニオン的に契約すると、各大手コンサル(たぶんSAP推し、非SAP推し等あるでしょう)の総合比較の確度が上がりそうな気がします。


同床異夢を感じます

 コンサルとユーザー企業のゴールと課題が合っていない、同床異夢でプロジェクトが進むことが問題の要因のひとつだと感じました。
 簡単な図を作ってみました。


コンサルとユーザー企業のゴールの違い

コンサルのゴールは売上獲得

 コンサルは「売上獲得」することが第1ゴールで、「売上増加」が第2ゴールになるでしょう。
 そのため、まずは「売上獲得」するために自社の強み(例えばSAP推し)で他社よりも優れていることをアピールします。
 なのでSAP推しのコンサルは、SAPの良いところ(例えばデータドリブン)は盛んに説明してくれますが、SAPのデメリットは具体的な説明が無いです。特にSAPで炎上した例などはSAP推しのコンサルからは積極的に説明されないでしょう。コンサルの方々は頭良いので、わざわざ地雷を踏みに行くことはしないです。
 さらに、地雷のひとつであるカスタマイズも、コンサルとしては第2ゴールの「売上増加」に繋がるので、逆に積極的に導入するモチベーションが働きます。
 だって、リスクは大きくなりますが、売り上げが膨大に膨らみます。その後もメンテナンスで売上が期待出来たりしそうです。

ユーザー企業のゴールはデータドリブン経営(たぶん・・・)

 ユーザー企業は「SAP導入」もしくは「ERP導入」がゴールに設定される感じです。しかし、どちらも「手段」であって、最終ゴールでは無い気がします。
 最終ゴールは「データドリブン経営」になるでしょう。生産データや物流データや財務データを一元管理して、素早い経営判断につなげるイメージです。
 しかし、普通の企業の場合は現在のシステムだと以下の課題があって一元化は出来ないことが多いです。
・システムが工程ごとだったり、機能ごと(生産、購買、経理、・・・)でバラバラ
・データ形式がシステムごとにバラバラでデータ統合も難しい
 さらに、古いシステムの場合、すでにメンテナンスが出来ないこともあります。俗に言う2025年の崖です。ただ、これは2025年あたりに寿命が来る可能性があるだけで、2025年を境に使えなくなるわけでは無いと思います。
 もし、古いシステムが延命できれば、データレイクを噛ませることでもそれなりのデータ活用は可能です。苦労はしますが、各システム自体は独立しているので、仕事が止まる危険性は低くなります。
 ただ、古いシステムの更新は必要なので、この際SAPで統一しようと考えてしまう可能性は高いと思います。

コンサルに丸投げするとコストが膨らむだけのような気が・・・

 これだけコンサルとユーザー企業のゴールと課題が乖離していると、コンサルに丸投げすると危険です。
 高価なSAPが選択されてどんどんカスタマイズ項目が増えて行き、コストは膨らみ、複雑性が増していきます。カスタマイズのお守りだけでも、結構な手間とお金が必要だと思います。
 さらに、最終目的が「SAP導入」にすり替わって、本来の目的の「データドリブン経営」ができなかったりします。
 コンサルやベンダーは「SAPが稼働すること」が最終目的なので、システムが要件定義通りに動けばOK(検収してもらいお金が貰える)です。
 ところがユーザー企業は「データドリブン経営」ができる必要がありますが、「SAPが稼働」しても目的のデータが取れない可能性があります。
 例えば、生産ロットの粒度が粗すぎて細かい情報を確認できなかったり、経理情報と生産情報とのリンクが上手く行っていなかったりします。
 この辺りは要件定義の際に検討しておく必要があるのですが、ユーザー企業がデータドリブンの意味が分かっていないと、コンサルやベンダーの言うとおりに要件定義してしまう可能性があります。(そんな現場に限って不要な要件に固執したりする・・・)
 なので、ユーザー企業が自社の最終ゴールを明確に定義することが重要だと感じます。

まとめ

 江崎グリコさんのシステム障害が、コンサルのゴールとユーザー企業のゴールが異なっていて、同床異夢でプロジェクトが進行していた可能性について述べました。
 実は、SAPに限らず、関係者の間でゴールが異なった状態、すなわち同床異夢でプロジェクトが進むことは多いです。
 そんなときは、
・彼らのゴールは何か
・そのゴールと自分のゴールは一致するか
を確認して、ゴールが異なる場合は
・彼らのゴールをどう設定すれば、自分のゴールと結びつくか
を考えるのが良いと思います。
 ただ、こんな苦労をしても評価されないことが多い(普通仕事は上手く行って当たり前なので)ですが・・・。

この記事が気に入ったらサポートをしてみませんか?