複合企業グループの「神経系」となるデータ統合への決断【第1回】

ERP統合は15年も動かなかった

　神経系を通す取り組みがなかったわけではない。むしろ逆である。基幹システムであるERP（Enterprise Resource Planning：企業資源計画）の統合プロジェクトは、私の入社より15年も前から続いていた。歴代の担当者が真剣に取り組み、多大な労力を注いできた。それでも、完了していなかった。

　現場を見て回るうちに、終わらない理由がはっきりした。「カスタマイズ」である。

　グループに新しい会社が加わるたびに、その会社固有の業務のやり方に合わせてシステム側に手を入れる。現場の要望は、どれも正当なものばかりだ。長年その手順で業務を回してきたのだから、変えれば混乱を招く。こうして一つひとつを見れば合理的な改修でも、それが積み上がり、改修が終わるころには、また次の会社がグループに加わっている。「完成」という状態が原理的に訪れない構造になっていた。

　だから当時、処方箋は冒頭で触れたFit to Standardだとはっきりしていた。業務をシステムの標準に合わせ、カスタマイズはしないと決める。この診断自体は正しいと、私も考えていた。

ゴールを「システム統合」から「データ統合」へ

　ただし、私はFit to Standardにすべてを賭けなかった。

　Fit to Standardは、現場の業務に相応の痛みを強いるアプローチだ。各社が長年積み上げてきた手順を捨て、標準に合わせていく作業になる。やる価値はあるが、完了までに何年かかるかは誰にも分からない。その間ずっと、経営は視界を欠いたまま進むことになる。

　2023年、プロジェクトの最初のフェーズで私が下した判断は、ゴールの定義を変えることだった。目指すべきは「システムの統合」ではなく「データの統合」である。

　全社でシステムを1つにまとめることを当面のゴールから外した。代わりに、各社のシステムはバラバラのまま生かし、そこから出てくるデータだけをつないで、全社共通のデータ・マスタ基盤に集める。会計、販売、人員、在庫など、経営が見たい単位でデータ側をそろえにいく方針だ。

　これは決して妥協ではない。システムを1つにすることは手段であって、目的ではないからだ。真の目的は、経営が的確に意思決定を下せる状態をつくることだ。ならば手段の完成を待たず、目的の実現へ先回りすればいい。私が徹底して守ろうとしたのは、その一点だった。

　このとき並行して進めたのが（1）データ要求、（2）ガバナンスルール、の2つの整理だった。

　データ要求では、従来の発想の順序を逆にした。以前の主流は「ERPに業務を合わせれば、必要なデータが自ずと集まり、ガバナンスも機能する。だからまずERPを入れる」という考え方だった。

　これに対して「経営が何を知りたいのか（マネジメント要求）」を先に固め、それを知るために逆算して「必要なデータをどう定義するか（データ要求）」を考えた。続いて、そのデータを生むために「業務をどう組むか（業務要求）」を決め、最後にそれを支える「システムに何が必要か（システム要求）」を固める。ERPが姿を現すのは、この最後の段階だ。

　順序を入れ替えると、見える範囲も変わる。ERPを起点に考えれば、視野は自ずとERPの守備範囲に閉じてしまう。だが「経営が何を知りたいのか」から発想すれば、顧客情報を扱うSFA（Sales Force Automation：営業支援システム）も、資金の動きを見るCMS（Cash Management System）も、当然その射程に入ってくる。

　私たちが最終的に管理したいのは、特定のITシステムではない。ヒト・モノ・カネという経営資源そのものだからだ。それがデジタル化の本来の目的に他ならない。

　一方のガバナンスルールは、その情報を誰がどう扱ってよいかを定めるものだ。閲覧や更新だけではない。「いくらまでなら誰が承認してよいか」という業務上の統制も、システムの中では「誰が、どの取引を、どこまで扱ってよいか」というアクセス権として表現される。

　ERPはそもそも、こうしたガバナンスが効くように設計されている。承認権限はもちろん、業務が正しく行われるために必要な要求が、権限設定や機能としてあらかじめ組み込まれている場合がほとんどだ。

　要求を固める順序の上で、ERPは最後に来る。だが最後に来るからこそ、そこに何を託すかが効いてくる。この順序で考えたことが後にどんな意味を持ったかは、本稿の最後で述べたい。