前回の記事「SaaSタイプのERPにおけるプロジェクト品質-要求管理編-」では、要求管理のアプローチにより、現行システムの単なる焼き直しとなる「As-Is」要求を抑制する方法について述べました。しかし、想定外の要求は依然として発生する可能性があります。本稿では、これらの要求の発生を軽減し、発生した場合の対処方法に焦点を当てます。
ERPプロジェクトのような大規模なプロジェクトでは、リスク管理は不可欠です。しかし、実際にはこのリスク管理が形骸化することも珍しくありません。その原因は主に三つです。先ず、目の前の課題に集中し過ぎることで、まだ発生していないリスクが後回しにされるケースです。次に、既存のリスク項目リストをそのまま用いることですが、これが何百ものリスクを含んでいるため、実際にはこれらをすべて高頻度で管理することが難しくなります。最後に、扱うリスク数を減らしても、チームメンバーがその価値を感じられず、結果的に形骸化してしまうことです。
では、リスク管理の本来の目的は何でしょうか。Bifコンサルティングでは、リスク管理の目的を二つに捉えています。
一つは、他のプロジェクトで発生した問題が、このプロジェクトでも発生する可能性があるという認識です。例えば、コロナ禍で多くのプロジェクトがリモートワークに移行し、製品トレーニングの難しさが顕在化しました。通常時は講師の画面をスクリーンに表示して、受講者はそれを見ながら自身のPCで操作します。しかし、リモートワークでは一台のPCで対応しなければならなくなりました。現在は、タブレットや2台目のPCを準備することで対応しています。これは、過去のプロジェクトでの問題を踏まえたリスク対応の一例です。
リスク管理のもう一つの重要な目的は、それをツールとして活用し、お客様を成功に導くことです。例えば、「経営層の参画不足」というリスクを識別し、これに対処することで、経営層の積極的な関与を促し、結果としてプロジェクトメンバーのモチベーションを向上させることができます。ERP導入において経営層の参画は不可欠であり、これは契約書に記載され、体制図にも反映されます。
プロジェクトが開始すると、経営層はキックオフミーティングでシステム刷新の重要性を強調し、毎月行われるステータスコミュニケーションミーティングにも積極的に参加します。これにより、経営層はプロジェクトへの関心を表明し、必要に応じてチームを支援し、進行状況を評価することができます。このアプローチは、「経営層の関与不足」というリスクを軽減し、プロジェクトチームのモチベーションを向上させるための鍵となります。同時に、この取り組みはプロジェクトメンバーにリスク管理の重要性を認識させ、その価値を理解させる効果もあります。
プロジェクトリスクの例をもう一つ挙げます。
「SaaSタイプのERPにおけるプロジェクト品質-要求管理編-」で要求管理の重要性について説明しました。しかし、要求管理を効果的にリードするためには、「アドオン開発の増大」というプロジェクトリスクを考慮に入れる必要があります。
ERP導入プロジェクトでは、想定外の要求が生じることがあり、これがプロジェクトコストやスケジュールに影響を及ぼすこともあります。これらの要求は多くの場合、現行システムの維持に関連するもので、ERPのコンセプトに沿わないものが多く、結果として将来のビジネス環境の変化に対応できないシステムが生まれるリスクがあります。これらのリスクを軽減し、発生時に適切に対応するためのリスク管理が重要です。
なお、As-Is要求が起票される根本的な原因は「現状維持バイアス」です。人々は変化を避ける傾向があり、ERP導入が意味する業務プロセスの変更に抵抗を示すことがあります。
例えば、プロジェクトにおいて「在庫がマイナスになっても引当および出荷できるようにしてください」という要求が出されることがあります。これは、業界標準としてマイナス在庫が許容されているという前提に基づいています。しかし、マイナス在庫の原因を深掘りすることで、ERPを利用してこれらの問題を解決し、マイナス在庫機能の必要性を排除することができます。これについては、「要求管理 – マイナス在庫の真因と解決方法 -」で詳しく説明します。
「アドオン開発増大」の軽減計画は次のようにまとめられます。「FTS: Fit to Standardの目的を理解し徹底する」「現状の仕事の延長で考えない」「要求の原因を深掘りする」「ソリューション要求は、ERPの原理原則を理解した後に行う」「他部門と連携し、要求事項を再考する」
リスクが発生した場合の対応として、「プロジェクト予算およびスケジュールへの影響分析」「アドオン審査委員会の評価」「フェージング」「定量化と代替策」などがあります。これにより、多くのAs-Is要求が抑制されるか、発生してもプロジェクトへの影響を最小限に抑えることができます。
本稿では、「経営層の関与不足」や「アドオン開発の増大」といった具体的なリスク管理の例を挙げています。実際のプロジェクトでは、開始前や開始時にリスク管理ワークショップを実施し、「マスター統合および統一化の複雑さ」「ユーザーのERP習熟度の低さ」「業務適応の難易度」「業務の標準化に関する複雑性」といった15から20件のリスクを特定します。この程度の件数であれば、管理は容易で、リスク管理の効果も顕著です。
これまでに多くの点を述べてきましたが、結局のところ、すべては人の行動に帰結すると言えます。適切なプロジェクトメンバーの選定はもちろんのこと、選ばれたメンバーへの部門や上司からの適切なサポートと関与が極めて重要です。次回の記事では、この点を「顧客変容」のパートでさらに詳しく解説します。