プロジェクト推進側の意識

プロジェクト推進側の企業が「ERP刷新プロジェクト立ち上げ時」に最も意識していることは、ROI（投資利益率）だ。システム導入がビジネスの目的達成に資するかどうかといった効果や、導入に係る費用・期間等を重要視する。そして次に気に懸けるのはプロジェクト範囲やデータ移行／体制とITトレンドに対応しているかという点だ。これらが達成出来るかは、ベンダーに判断を仰ぐケースがほとんどである。よって提案依頼書（RFP）を作成していくつかのベンダーに提案を依頼し、企業が意識している内容の達成度が高いベンダーが選択される場合が多い。品質や納期の担保といったプロジェクトの実効性も評価はするものの、特にベンダーのプロジェクトマネジメント実績や、提案依頼書に記載した機能要求を満たしているか、という所に焦点があたることが多い。プロジェクトリスクについても、ベンダー側に移転すれば良いという意識もまだまだ根強くある。
そして「ERP刷新プロジェクト実行中」に最も意識していることは、「現行業務がERPで対応できるか」という部分と「スケジュールが問題なく進捗していて、予算内に実施できるか」である。またこの時に、特にプロジェクト推進側の業務状況を是として進行することを望む。
ベンダーが示したリスクを回避する為の前提条件や先送り事項、契約事項については、ベンダー側から予め強く指摘を受けない限りは、あまり意識せずにプロジェクトを推進し、後になってスケジュール遅延やコスト超過化等の重大な問題が表面化するケースも多い。

導入ベンダー側の意識

導入ベンダー側が「ERP刷新プロジェクト受注前」に最も意識していることは、企業の期待に応えることだ。企業からの提案依頼書にあった予算や期間などの条件を満たしながら、プロジェクト範囲や体制を定め、データ移行に加えてITトレンドにも対応することで、企業のビジネスの目的達成や効果導出を目指す。導入ベンダーにとってリスクと考えられる部分がある場合、前提条件・契約条件などによって受注内容から回避する、あるいは先送りにして受注前にあまり強調しないといった方法で、まずは“受注できること”を最優先にする。
導入ベンダー側が「ERP刷新プロジェクト実行中」に最も意識しているのは、「スケジュール」と「コスト」だ。スケジュールを守りつつ、予算内でプロジェクトを進める。前提条件や契約条件、先送り事項の内容についても意識はしているが、スケジュールやコストに課題が発生しない限り、たとえそれらの条件と異なっていても、企業の状況に合わせて対応する。また、進捗で遅れが発生しそうになるとタスクを入れ替えて対応が容易なものを優先するなど、なるべくスケジュールの維持に努める。
そしてスケジュール遅延が発生すると挽回策を考える。フェーズ内で挽回出来る可能性がかなり低いと分かっていても、可能性がゼロでない限りは「挽回可能」と企業に説明して進行する。この時も、コストが増える要員増強などはなるべく行わない。そしてこの時点でようやく前提条件・契約条件で異なる部分や、検討を先送りした内容について企業側に説明し、理解を求める。

意識の違いから発生する問題点

ここまでは、プロジェクト推進側の意識と導入ベンダー側の意識について見てきた。プロジェクト推進側／導入ベンダー側の双方が、相手にプロジェクトリスクを移転したつもりでいる——この両者の意識の違いが、問題の本質となっているケースは多い。リスクについての検討を放置・先送りにした結果、プロジェクト進捗とともに課題として表出し、後になって重要な問題を引き起こす。特に大規模なプロジェクトになるほど、この傾向が多い。スケジュールは最低でも半年～年単位で遅延し、コストは予算の1.5倍から2倍以上に膨らむ。いくつかの達成目標も諦めることになり、場合によってはプロジェクトの見直しや中止に至ることもある。
 
以下、リスクの発生につながる要因となる考え方の例をいくつか紹介する。

■「プロジェクト推進側」のリスクの放置・先送り例

• そもそもERP導入で提案依頼書に無理がないかの確認が不十分。
• プロジェクトリスクを導入ベンダーに移転させれば良いという考え方を持っている。
• 導入ベンダーから提示された前提条件や契約条件が自社として受け入れられる内容なのかの確認が不十分（ビジネス目的や効果、期間、費用にばかり焦点を当てている）。
• 導入ベンダーからリスク回避された部分の検討をしない。
• 提案依頼内容が内包するリスクについて理解し、導入ベンダー側にも適切なリスク対応を依頼していない。
• 提示された前提条件やプロジェクト実施条件を守る意識が低い。
• プロジェクト実施中の進捗資料から状況を見抜き、このままプロジェクトを進行するとこの先どうなるかの想定をしていない、またはできない。

 
■「導入ベンダー側」のリスクの放置・先送り例

• ERPでの実現性が低いと認識しつつも、出来るかのような提案をする。
• 提示した前提条件やプロジェクト実施条件を企業が受け入れられるかの確認を十分にしない。または、提案期間に余裕がなく、手が回らない。
• 「確実に回避すべきリスク」と、「許容範囲のリスク」についての検討が足りない。
• 提示した前提条件やプロジェクト実施条件を満たさない事象が発生しても、直ぐにアラートを出さない。
• 明らかに遅延するという状況になるまで、遅延を挽回出来るという姿勢を示す。

これらの問題はプロジェクト推進側、導入ベンダー側双方の立場から、リスクについて都合良く判断することから発生している。加えて以下のような考え方の違いから、それぞれの当事者が適切な対処を取れないケースも多い。
 
■「プロジェクト推進側」の立場からの考え方
プロジェクト立ち上げ時は、プロジェクトを推進することに集中しており、ベンダー側が懸念点を伝えても、場合によってはプロジェクト推進に対する反対意見と捉えてしまい、意見をプロジェクトに反映することができない。また、納期・予算内に収めることだけに集中し、導入ベンダー側から提示された条件の実現性を吟味しないままプロジェクトを開始する傾向が強い。プロジェクト開始後は、導入ベンダーが自社側の事情を十分に考慮し、うまくやってくれることを期待して、ベンダーからの提案内容とプロジェクトの実態に乖離が生じていくことに違和感を持たない。

■「導入ベンダー側」の立場からの考え方
受注したい、受注しなければならないといったプレッシャーから、提案時に適切な対応をとれなくなってしまうことが多い。誰もが知る有名なベンダーでさえも「とりあえず受注してから考える」という思考が働くことがあり、これを否定することは容易でない。プロジェクト実施中も、プロジェクト推進側からの納期維持のプレッシャーから、プロジェクト遅延についてはなるべく言いたくないという心理が働く。また、コスト超過については社内から利益維持のプレッシャーがかかるため、要員追加はなるべく避けたいという思いが強くなる。

リスクとなりうる前提条件やプロジェクト実施条件／先送り事項の具体例

実際に、筆者がコンサルティングを行っていく中で、問題となった前提条件や契約条件、先送り事項の具体例をいくつか紹介する。
 

• 業務標準化プロジェクトにおいて、期間が十分でなかったため、時間短縮も兼ねてプロジェクト推進側にプロセスリーダーをたて、そのプロセスリーダーがすべての事業の要件をとりまとめて確定承認する体制としたが、実際にはそのような人材がいなかった。
• ベンダー側の知見に基づきインターフェースの改修工数や期間を算出し、実効性の検証はせずにプロジェクトを開始した結果、実態と大きく乖離してしまった。
• 抜本的に業務を標準化する前提方針でプロジェクトを開始した。プロジェクト開始前に標準化可能な業務領域を確認せずに進めた結果、要件定義フェーズに入ってから顧客・仕入れ先からの要求など標準化が難しい業務の多さ、関連システムとの影響で開発が避けられない事などが発覚し、開発工数や期間が想定より大幅に増えてしまった。
• 急遽ある業務領域をプロジェクトスコープに入れた。採用予定の製品について、事前に業務適用の可能性を確認する必要があったが、時間が無かったため後のフェーズで確認をすることにした。その結果、要件定義フェーズに入ってから当該製品の業務適用範囲の狭さが発覚し、多くのアドオン開発および期間延長が必要になった。

対策

このように、それぞれの事情から当事者自身で解決するのは厳しい状況に陥ることもある。対策としては、これらの違いをあらかじめ認識してリスクの放置・先送りを避けることだ。プロジェクトの進行を導入ベンダー側に一任せず、プロジェクト推進側でも進捗を確認しながら、状況に応じた適切な対応をとることが大切だ。リスクを低減するために、プロジェクト推進側が計画段階で検討しておくべき事柄の例を以下に挙げる。
 

• 実効性がある計画に整理する。
• 導入ベンダーへのリスク移転を前提とせず、計画時にリスク低減の方法を検討する。
• 導入ベンダーからの提案内容についてはスケジュールやコストだけでなく、前提条件、プロジェクト実施条件、先送り事項が受け入れられる内容であるかを確認する。
• 避けられないリスクへの対応をプロジェクト推進側と導入ベンダー側で事前に決めておく。
• プロジェクト推進側もしっかりと進捗管理を行い、導入ベンダーと合意した各種条件を満たさないときには、適切にアラートを上げて対処する。
• 現在の遅延が次のフェーズにどういう影響をもたらすかを適時判断し、早い段階で対応を検討する。

 
プロジェクト推進側と導入ベンダー側の意識をそれぞれ理解している人材がリスク低減を主要タスクにPMOとして参画し、プロジェクト成功に向けて中立の立場で対処することが問題解決に有効だ。特に、導入ベンダーとは構想策定／要求定義／概要設計フェーズまでは準委任契約で進行することが多く、進捗やリスクは発注側（プロジェクト推進側）の責任となる。このためプロジェクトを成功に導くためには、プロジェクト推進側で予め起こり得るリスクを把握したうえで、適切な対処をとることが必要不可欠だ。

おわりに

本稿では大規模ERP導入プロジェクトにおいて、プロジェクト推進側と導入ベンダー側の意識の違いから発生しがちなリスクについて説明した。また、これらの問題を当事者間で解決することが難しいケースもあることから、計画段階からERPに精通した第三者PMOを投入することも有効だ。
 
本稿が、皆さまのERP導入プロジェクト成功の一助となれば幸甚である。