ERPをクラウドへ移しても業務プロセスの問題は消えない

ERP移行の会議では、決まって同じ約束が繰り返される。「クラウドに移れば、全部もっとシンプルになる」。ならない。クラウドが変えるのはソフトウェアが動く場所であって、会社の働き方ではない。

今の購買申請が、メールでの三段階の承認と、並行して回る別のExcelシート、そして一本の電話で動いているなら、移行後も同じ流れをたどる。違いは、地下室のマシンの代わりにフランクフルトのサーバーで動く、それだけだ。

クラウドは場所であって、プロセスの決断ではない

クラウド移行は本物の問題を解く。ハードウェアの管理から解放される。マネージドなバックアップ、伸縮するスケール、業務を止めない更新が手に入る。これは投資に見合う。だがこれはインフラの問題だ。

あなたの問題は、ほぼ必ず別のところにある。勘で与信を通す営業担当。返品をその場で記録しないせいでシステムと食い違う在庫。仕訳の半分がバラバラのシートに散っていて、二週間かかる月次決算。

どれもサーバーを替えただけでは良くならない。ERPは、オンプレでもクラウドでも、業務プロセスを映す鏡だ。プロセスが混乱していれば、鏡は稼働率だけ高い混乱を返してくる。

手抜きの「現状(as-is)」調査という落とし穴

典型的な移行は、現状プロセスの棚卸しから始まる。掲げる目標は「今あるものをそのまま再現する」。ここでプロジェクトは始まる前に死ぬ。

今あるものを再現するとは、数十年分の例外、抜け道、「昔からこうやってきた」を、新しくて高価なシステムに焼き込むことだ。出来上がるのは、後から誰も更新できないカスタマイズだらけの怪物になる。

最もよく引かれる公開事例がLidlだ。この小売チェーンは、SAPを基盤とする新しい在庫管理システムに何年も取り組んだ。プロジェクトは数億ユーロを投じた末、2018年に中止された。報じられた原因のひとつは、Lidlが業務を標準に合わせる代わりに、取得原価ベースの自社の在庫モデルにソフトを合わせ続けたことだ。ソフトは折れるまで曲げられた。

その二十年前、Hersheyは逆の道を選び、急ぎすぎて失敗した。ERP、CRM、サプライチェーン管理を、ハロウィン直前に同時に本番投入し、プロセスを安定させる時間を取らなかった。倉庫に在庫があるのに、注文を出荷できなかった。移行は技術的には完了していた。それでも操業は止まった。

クラウドに触れる前にやるべきこと

正しい順番は、序盤が遅く感じるので居心地が悪い。まずプロセスを理解する。次に、どれを残す価値があるか、どれを切るか、どれをソフトの標準に合わせるかを決める。移行はそのあとだ。

• マニュアルにあるプロセスではなく、実際のプロセスを描く。実際のプロセスとは、金曜の17時に怒った顧客が電話口にいる状況で、人が本当にやっていることだ。
• カスタマイズした例外ひとつひとつに、なぜかと問う。半分は、もう誰も必要としていないルールが答えだ。
• 何を標準に合わせるかを決める。今日の高価なカスタマイズは、明日あなたをベンダーに縛りつける技術的負債になる。
• 移行前にデータを掃除する。汚いデータは新しいシステムでも汚いデータのまま、それだけだ。
• 各プロセスの責任者を決める。責任者がいなければ、現場が抵抗したとき誰も変化を守らない。

本当のプロジェクトは社内の抵抗だ

移行の技術的な部分は、最も予測しやすい。API、連携、カットオーバーの時間枠。どれにもマニュアルがある。マニュアルがないのは、十五年間その古いプロセスを回してきて、どんなコンサルよりそれを知っている人たちだ。

変革マネジメントの古典的な研究は、この点で一貫している。変革プログラムの多くは、技術が理由で失敗するのではない。実行、足並み、そして人の納得で失敗する。HBRに載ったSirkin、Keenan、Jacksonによる「変革の硬い側面(ハードファクター)」の論考が、これをよく要約している。

よくある場面を思い浮かべてほしい。倉庫の責任者が新システムを渡される。終業時にまとめてではなく、動きのたびに記録しろと迫られる。彼にとって新システムは、楽になるどころか手間が増える。なぜそうするのかを示さず、現場の実態にプロセスを合わせなければ、彼は並行して回す別のExcelに戻る。そしてクラウドのERPは、高くつくだけの死蔵された倉庫になる。

で、クラウドは見合うのか?

見合う。ただし正しい理由で。インフラ管理から手を引くため、伸縮性を得るため、そしてデジタル基盤の残りと連携しやすくするためにクラウドへ移る。サーバーを替えれば業務が勝手に整理されると期待して移ってはいけない。

うまくいく手順は、言うのは簡単で、やるのはつらい。プロセスを整える。データを掃除する。人の足並みを揃える。そのうえでクラウドにつなぐ。この順番をひっくり返した者は二度払う。移行で一度、そして移行を巻き戻すのにもう一度。

良いソフトは悪い業務を直さない。壊れるのを速くするだけだ。問うべきは「クラウドかオンプレか」では一度もなかった。「うちのプロセスは、今のまま自動化される価値があるのか」だ。たいていの場合、正直な答えはノーだ。そして、そこからプロジェクトは本当に始まる。