なぜ、基幹システムのリプレースは大失敗するのか 日本企業に足りない「ある役割」

　レギュレーション変更や役割変革などの新たなチャレンジに向けて余力を創出するためには、自動化・効率化は必要である。しかしながら、法制度や経営環境は断続的に変化する。足元の要件に応える自動化・効率化のみではワンショットの対応ができても、環境変化に強い真にレジリエントなファイナンス・オペレーションを構築、メンテナンスすることは難しく、巨額のシステム投資も正当化できない。レジリエント・ファイナンスの実現、ひいてはCFOの3つのジレンマの解消に向けて、デジタルをどう活用すべきか再考が必要だ。

　そこで本稿では、

・なぜ基幹システムのリプレースが失敗に終わるのか

・着目すべきプロセスオーナーとは何者なのか

・ダウンサイジングERPの可能性

・生成AI活用の可能性

の4つの論点をメインに、論述を進めたい。

●日本企業が基幹システムのリプレースに失敗する訳

　1990年代の半ばごろまで、企業の基幹システムはメインフレームをベースとしたスクラッチ開発型のシステムが主流であった。

　図2に示す通り、スクラッチ開発のアプローチは、まず事業ごとに個別最適化された業務プロセスフローがあり、その中の一つ一つの業務機能に対して業務機能要件を整理し、業務機能と対になるシステム機能の要件を定義した上で、設計・開発・テストに進むものであった。

　その後、1990年代半ばから日本企業にERPシステムが採用され始めた黎（れい）明期においても、スクラッチ開発型のアプローチが踏襲された。すなわち、現行の業務機能要件とERPの標準システム機能を比較（Fit＆Gap分析）することから、ERPの導入プロジェクトがスタートした。

　企業固有の業務機能とERPの汎用的なシステム機能には、当然ながらギャップも多く、結果として多数のアドオン開発が発生した。ERP導入は高コストかつ、屋上屋を積み重ねた柔軟性・拡張性が低い姿に決着するケースが多かった。

　こうした反省を踏まえ、2000年代のERP導入「2巡目」以降では、「Fit to Standard」という名のもとに、ERPが持つ標準プロセスや汎用機能を組み合わせて、あるべき業務プロセスをデザインするアプローチが採用された。

　しかしながら多くの日本企業では、ユーザー側のプロジェクトチームとして機能組織別のサイロ化されたチームが組成される。このため、エンドツーエンドでプロセス全体を俯瞰してデザインする視座が欠落してしまう。