現場の“勝手な機能追加”でERP予算が崩壊 情シスが押さえるスコープ防衛7カ条:現場の要望を制御するガバナンス
現場の善意による機能追加が、ERP導入の予算超過を招く。プロジェクトを破綻させる「スコープクリープ」を防ぎ、納期を守るための要件定義や優先順位付け、次フェーズへの切り出しといった現実的な防衛策を解説する。
COO(最高執行責任者)を始め、ERP導入のエグゼクティブスポンサーを務める経営陣は、さまざまな潜在的リスクを警戒しなければならない。具体的には、コスト超過や導入チームの主要メンバーの離脱、スケジュール遅延のリスクなどだが、もう1つ見逃せない危険が「スコープクリープ」だ。これはチームメンバーが過剰な機能を追加することで発生し、ERP導入に悪影響を及ぼすというものだ。
スコープクリープは、費用の増大や納期遅延を招く。最悪の場合、承認済みの要件を満たさない製品が納品される恐れもあるため、要件の検証や主要機能の追跡といった予防策を講じ、導入の失敗を回避しなければならない。本記事では、スコープクリープを防ぐ7つの対策を解説する。
スコープクリープとは何か
「ERP導入」に関連する編集部お薦め記事
スコープクリープとは、プロジェクトのスコープが承認された後に、チームメンバーが勝手に追加の機能や仕様を盛り込んでしまう現象を指す。
通常のERP導入プロジェクトには、構成する機能を概説した「承認済み要件リスト」がある。スコープクリープが起きる主な理由は、メンバーが「最終製品をより良くしたい」と考えたり、新しい機能を試したいと思ったりすることにある。その結果、大半のケースでコストが膨らみ、リスクは増大し、スケジュールも長期化する。
導入が進み、チームが新しい情報を得る中で、ある程度のスコープ変更が必要になることもある。しかし、エグゼクティブスポンサーは、導入を確実に前進させるために追加スコープを厳格に管理しなければならない。
スコープクリープを防ぐ7つの対策
プロジェクトチームがスコープクリープを回避するために取るべき手順は以下の通りだ。
1.導入前に要件を検証する
主要なステークホルダーは、承認前に要件を徹底的に確認すべきである。プロジェクトリーダーは、承認済みの要件リストが全てのニーズをカバーしているか確認する。この際、導入パートナーにも要件を確認させるのがよい。彼らの経験は、不足している要素の特定に役立つ。
2.機能追加のプロセスを定義する
新しい機能を追加する際は、関連する全てのデータを収集できる申請フォームを用意する。正式な審査の前に、詳細な分析と実装に必要な工数を見積もる「中間ステップ」を設けると効果的だ。ただし、詳細な分析には時間と労力がかかる。このステップは、現行フェーズでの導入を検討している機能にのみ適用すべきだ。
その後、チームは機能の重要性、追加コスト、スケジュールへの影響、プロジェクトリスクを評価する。その機能を実装しない場合のリスクと、導入の途中で機能を追加するリスクを比較検討しなければならない。重要度の低い他の機能を後回しにするなど、リスクを軽減できる要因も考慮する。
3.明確なタイムラインを構築する
エグゼクティブスポンサーは、プロジェクトの明確なタイムラインを作成するようチームを促すべきである。これにより、メンバーはスコープ追加がもたらす課題を正しく理解できる。タイムラインで今後のタスクを可視化すれば、新機能の追加が主要なマイルストーンに悪影響を与えることを示せる。
4.オープンなコミュニケーションを確立する
情報の風通しを良くしておくことは必要だ。これにより、メンバーが新しい機能について適切な人物に相談し、適切なメンバーが評価できるようになる。
プロジェクトのスケジュールや全体的な進捗(しんちょく)状況についても、チーム内で定期的かつオープンに話し合う必要がある。そうすることで、承認なしに勝手な機能実装が行われる事態を防げる。
5.優先順位を頻繁に議論する
企業がERP導入に踏み切るのは、経営陣が新システムを戦略的優先事項だと判断したからだ。導入の目的には、プロセスの合理化、コスト削減、レポート機能の改善などが挙げられる。
導入の目的を全員が明確に理解できるよう、新システムがなぜ重要なのかを頻繁に議論すべきだ。これにより、新たな要件が発生した際も優先順位を付けやすくなり、真に重要な変更だけをリストに追加できるようになる。
6.潜在的な新要件を追跡する
大規模なERP導入は複数フェーズに及ぶことが多い。導入開始後に提案された未承認の要件は、切り捨てるのではなく「将来のフェーズ」に追加するとよい。こうすれば新しい要件を見失うことがなく、早い段階から具体的な要件に基づいて次期フェーズの計画を立てられる。
機能の肥大化を抑えることは重要だが、過度に警戒しすぎてはならない。組織全体の長期的なシステム機能を向上させる正当な懸念や改善案まで見落とさないよう注意が必要だ。
7.スケジュールに余裕を組み込む
要件の審査や承認を適切に行っていても、プロジェクト期間中にどうしても機能実装が必要になる場合がある。エグゼクティブスポンサーは、予期せぬニーズに対処するための「スラック(余裕時間)」をスケジュールに割り当てるようチームに促すべきだ。リーダーはこの時間を慎重に管理し、プロジェクトの早い段階で使い果たさないように注意を払わなければならない。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
クラウドERPへの移行は正解か? 2800万件のデータ移行失敗から学ぶ教訓
クラウドERPへの移行は不可避に見えるが、安易な判断は禁物だ。独自カスタマイズの継承やデータ移行の複雑さ、予期せぬ運用コスト増など、情シスが直面する現実的な課題と、移行を成功させる判断基準を詳解する。
経営者などの約半数が「ERPが何か分からない」 導入後最多のつまずきは?
プロトスターは、ERPの利用実態に関する調査結果を発表した。導入率は17.5%にとどまる一方、導入企業の57.1%が満足と回答した。導入期間の長期化やデータ移行、利用者間のスキル格差が課題として浮かび上がった。
SAP移行で「ERP崩壊」 小売業の1900億円赤字が示す「ベンダー任せ」の限界
大手スーパーのアズダは親会社からの独立に伴うIT刷新を断行したが、1900億円もの巨額赤字を計上した。専門組織を構築して挑んだSAP移行の裏で何が起きたのか。経営リスクとしてのIT管理の重要性を解き明かす。
ERPを「AIで自社開発」した企業の末路……結局市販製品が“優位”なのか?
AIツールを利用すれば、自社の要望に完全に適合したERP/SCMシステムのモジュールを手軽に作成できる。同時に、システム連携の不備など複数の問題を招も恐れがある。AIツールで自社開発する利点、欠点を比較する。
LIXILがSAPのブラックボックス化を解消できた訳 障害調査を年200時間削減
Gartnerは、ERPのカスタマイズ率を20%未満に抑えるよう薦める。一方LIXILは、Gartnerが推奨する形でERPを運用した結果、新たな問題に直面したものの、ビジネスを停滞させる構造的課題を解決できた。何をしたのか。