前回記事「SAP ERPプロジェクトの成否を分ける7つの原則」では、システム導入前に考えるべき7つの基本方針について解説した。本稿では、この基本方針の欠如が、どのような課題を引き起こしたかを実際の事例から見てみたい。

事例1：アドオン開発方針が欠如

　A社は5年前に企業合併を行ったが社内システムの多くが合併前のまま手付かずに残っていた。そのため両方のシステムに対して改修が毎年発生し、運用コストがかさんでいた。情報システム部門は運用コストを抑えるためにSAP ERPを活用したシステム統合を行うことにした。A社の業界ではSAP ERPを採用している企業が多く、SAP ERPによる業務の機能的充足度は高かった。また、SAPの技術者も十分な業界知識を備えており、プロジェクトは容易に進むものと期待された。

　要件定義の工程で、ユーザー参加の下、SAP ERPの標準機能の確認と不足機能の洗い出しを始めたが、アドオン開発の規模が当初の想定の2倍以上になってしまった。情報システム部門でアドオン開発の要求一覧を調べたところ、ユーザーは合併前の両方のシステムで実現されていた機能を、そのままアドオン開発として要求していることが分かった。

　情報システム部門は予算内、期日内で対応できるように、アドオン開発の数を半分にするよう説得を試みた。結果、数自体はほぼ半分になったものの、ユーザー部門は異なる2つの要件を1本のプログラムで実現できるような設計を依頼したため、アドオン開発の複雑性は増し、開発規模はさらに大きくなった。

　情報システム部門は、アドオン開発する一部の機能リリースについて先延ばしすることを経営層に認めてもらうことで、どうにか稼働にこぎ着けた。しかし、当初想定の1.5倍以上の予算を費やしてしまった。さらに対応できなかった機能に対して、ユーザー部門からの突き上げが厳しく、期待していた効果を創出するための取り組みが後回しになった。

事例2：システム統合方針が欠如

　B社では事業部ごとに別々のシステムが構築されていた。社長交代を機に各事業部が持つシステムの棚卸しをし、B社内には1000以上のシステムが存在することが分かった。これを問題視した経営層からの指示で、経営のスピード向上を目的に情報システム部門主導でシステム統合のプロジェクトが開始された。

　プロジェクト開始後にシステムをさらに詳しく調べたところ、欧州を中心にビジネス展開する事業部はSAP ERPをベースにシステムを構築したタイミングであり、このシステムを拡張できれば他の事業部で必要とされる多くの要件が満たせることが分かった。一方で、統合方針については、既存システムを参考にはするが、新たに構築して全社システムを統合すべきとするグループもあり、SAP ERPを拡張して全社のシステムを統合すべきとするグループとで意見が分かれた。

　結局、意見はまとまらず、SAP ERPは存続させるものの、その他の事業部については新たにシステムを構築して統合を進めることになった。システムを1つにするという本来の目的を貫徹することはできなかった。

事例3：複数言語・複数通貨の開発対応方針が欠如

　C社はアジアを中心に生産拠点を展開していたが、各国がそれぞれ販売計画と生産計画を立案していたために、需給調整がうまく機能していなかった。そこで生産管理システムの統合を行い、需給調整の高度化を図ることを目的にSAP ERPの導入を軸としたプロジェクトが開始された。

　プロジェクト開始から1年で本社の生産管理本部および本社所在国の生産拠点へのシステム導入を終えた。残りの生産拠点へのシステム展開に向け具体的な検討に着手したが、言語や通貨の違いにより、アドオン開発した帳票や画面のプログラムの多くに修正が必要なことが判明した。また原価管理方式の違いなどから会計システムへのインタフェースも新たに開発が必要なことも分かった。これらの追加開発で各国の生産拠点への展開は、当初の計画よりも6カ月遅れた。

何が問題だったのか？

　3つの事例では何が問題だったのだろうか。事例1では7つの原則のうち、「開発方針」においてアドオン開発への対応方針を明確にしておけば失敗を避けられたと考えられる。例えば「アドオンは、法規制や顧客要求への対応で必須のもの、あるいはROI（投資対効果）が明確なもの以外は開発しない」といった方針だ。事例2では「今回のプロジェクトではシステム統合によるコスト削減を最優先に進める」といった対応方針が明確であれば、ユーザーを二分した議論で時間と費用を浪費する必要はなかっただろう。

　事例3ではどうだろう。事例3を7つの原則に照らした場合、まず「開発方針」として、各国の通貨や言語に対応するための追加開発を行う際の判断基準が明確にされていなかったことが問題の要因といえよう。その他にも、「テスト方針」「パイロット方針」でも、検討が不足していたといえるだろう。では、なぜ多くの方針からこの観点が抜けて落ちてしまったのだろうか。

　そもそも、事例3のプロジェクトの目的は「生産拠点がある多くの国の間で、需給調整の高度化を図ること」であったはずだ。この目的に照らしてプロジェクトが推進されていれば「開発方針」には需給調整の高度化の観点が盛り込まれていただろう。また、本社の生産管理部と最初の生産拠点にシステムを導入した時点で、多国間での需給調整の高度化が達成されるかどうかの検証が、「テスト方針」と「パイロット方針」から抜け落ちていることに気付いたはずだ。

　プロジェクトが6カ月遅延したことで、関係者はその原因となった開発の手戻りに目を向けがちだった。だが、重要なのは各種の方針がプロジェクトの目的に沿って策定されていなかったということだ。システム開発のプロジェクトが始まってしまうと、関係者はみな「システムが無事に稼働すること」だけに注視してしまい、そもそもの導入目的を見失うことが多い。筆者は7つの原則を定義することを推奨しているが、その前段階として「プロジェクトの目的」を定義・文書化し、それを関係者全員に周知するとともに、プロジェクトの終了まで関係者にそれを意識させるように情報共有を繰り返すことも、基本方針と同様に重要であると考えている。

　ここまで見てきたように、プロジェクトの目的を見失わないこと、そして7つの原則を定義し共有することは、日々のプロジェクト管理や要件定義の品質と同じかそれ以上にプロジェクトの成否を大きく左右する重要なものである。