SAP導入でスコープクリープを防ぐ方法

SAP導入でスコープクリープを防ぐには、あらゆる変更を目に見える形にし、承認に高い代償が伴うようにします。対象外とするものを、対象とするものと同じ丁寧さで書き出します。すべての依頼を、時間、コスト、品質への影響評価を伴う変更管理に通します。追加のたびに、トレードオフを求めます。経営層の後ろ盾があるスコープフリーズの日付を設定し、同じ規律をSIとの契約にも持ち込みます。このガイドは、S/4HANAプログラムのプログラムディレクター、スポンサー、PMOに向けたものです。次回のステアリング資料で、変更コストの表と契約条項をご活用ください。

SAPプロジェクトの多くは予算も期限も超過し、その最も多い原因がスコープクリープです。私は、SAPプロジェクトが制御不能に陥った企業を数十社見てきました。超過がステアリングの報告に表れる前に、3つの兆候が現れます。小さな変更が、影響評価のないまま積み上がる。変更管理が、文書化された権限ではなく個人的な関係で回る。そしてスポンサーが、コーヒーを飲みながら承認したことを、プロジェクトチームが1週間後に知る。

ある製薬会社は、18か月という明確なスケジュールで始めました。3年後もまだ導入を続けていて、コストは倍になっていました。ある製造会社のCIOは、要件が変わり続けたせいで、チームが何か月もかけて設定したモジュールをまるごと破棄したと話してくれました。スコープは膨らみきって、誰も当初の計画を思い出せなくなっていました。

これらは特殊な例ではありません。SAPプログラムが失敗する、最も一般的なパターンです。

始まりは無害です。業務リードが「小さな変更を1つだけ」と頼みます。次にもう一つ。「ついでに、これも」という言葉は、どんな技術的課題よりも多くのSAP導入を狂わせてきました。

ある小売クライアントと仕事をしたときは、すっきりした形で始まりました。中核の財務と、基本的な資材管理（MM）です。6か月が過ぎたころ、CMOが顧客分析を求めました。続いてCOOが、高度な倉庫機能を必要としました。当初の9か月というスケジュールが危うくなりました。私は反対し、2つの要望をどちらも却下しました。この規律こそが仕事です。

すべての変更がスコープクリープとは限りません。設計の段階で、誰も予想していなかった重大なギャップが見つかることもあります。プロジェクトの途中で規制が変わることもあります。これらは正当な変更であり、スケジュールと予算の調整を伴う手続きを経ます。スコープクリープは、気づけばそこにあります。たいていは、廊下での立ち話のあとに。

ある製造業のクライアントは、10本のカスタムレポートで始め、最終的に47本になりました。1本ごとに、設計、構築、テストの時間が加わります。レポートのワークストリームだけで、予算を200%超過しました。

200%

スコープのずれでカスタムレポートが10本から47本に増えた後の、レポートのワークストリームの予算超過

出典: 製造業クライアントのプログラム

警告サイン

私が注視している兆候と、それぞれへの対応です。

警告サイン	根本原因	対応
「あと一つだけ」が日常の言葉になる	スコープの境界が不明確	業務リードとベースラインを引き直し、正式な変更管理を徹底する
業務リードが非公式に機能を追加する	下流への影響が理解されていない	すべての依頼を影響評価に通し、コストを示す
正式な再計画なしにスケジュールが延びる	気づかれないままのスコープ拡大	スコープのチェックポイントを設け、変更委員会の承認のもとで再計画する
ドキュメントが、実際に構築したものと合わなくなる	スコープの非公式な扱いと、バージョン管理の欠如	承認された変更のたびに、仕様書と計画を更新する
予算の消化が進捗を上回る	文書化されていない変更に隠れた工数	工数をワークパッケージ単位で追跡し、差異を調べる
チームが遅れを取り戻すために夜間・週末に働く	スコープがキャパシティを超えている	変更委員会にエスカレーションし、スコープの判断を迫る
業務、IT、パートナーの間で責任の押し付け合いが起きる	スコープが、すでに制御を超えて膨らんでいる	スコープを凍結し、根本原因のレビューを行い、ベースラインをリセットする

すべてがつながっている

SAPはすべてをつなぎます。財務はサプライチェーンに影響します。人事は給与に関わります。販売は在庫につながります。1つの変更が、10の機能を壊すことがあります。

ある顧客は、購買発注のプロセスに項目を1つ追加しました。些細なことに見えました。ところが3つのインターフェースが壊れ、各部門でレポートの書き直しが必要になりました。別の顧客は、価格決定手順への「小さな変更」を頼みましたが、価格体系全体の再設定が必要だと判明しました。3週間の作業と、コンサルティング費用4万ドル。些細な変更のために、です。

10年に一度のプレッシャー

ほとんどの企業は、SAPの導入を10〜15年に一度しか行いません。どの部門も、次の機会は10年後だと知っています。誰も「フェーズ2」という言葉を聞きたくありません。多くの組織では、それは「やらない」を意味するからです。だから、あらゆるものが今回のプロジェクトに押し込まれ、スコープのリストは願望リストになります。

クリーンコアが変えること

クリーンコアは、カスタマイズに技術的なブレーキをかけます。S/4HANA Cloud Public Editionでは、コアの修正はできません。拡張は、リリース済みのAPIを通して、SAP BTP上のオンスタックまたはサイドバイサイドで行います。Private Editionとオンプレミスでは修正は引き続き可能ですが、SAPのガイダンスは、アップグレードの作業が増えるため、最後の手段として扱っています。

副次的な効果として、スコープの規律が生まれます。「標準のOrder-to-Cashに、この承認ステップを足すだけ」という依頼は、気軽な設定の相談ではなくなります。独自の設計、構築、テストのコストがかかる拡張になるからです。ステアリングコミッティの下に拡張レビューの場を置き、承認と却下の権限を持つアーキテクトを1人置けば、こうした依頼の多くは、ベースラインに入る前に止まります。この場のないオンプレミスのプログラムは、以前のパターンに逆戻りします。設置の方法は、私のクリーンコアのガイドで解説しています。

1. 明示的な除外を含めてスコープを定義します。対象外とするものを、対象とするものと同じ丁寧さで文書化し、双方に署名をもらいます。曖昧さは、議論の始まる場所です。
2. 結果を伴う正式な変更管理を運用します。すべての変更に、コスト、時間、品質への影響評価が必要で、承認する人に見える形にします。
3. ステアリングの会議のたびに、スコープの境界を伝えます。スコープの状況を、赤・黄・緑のシンプルな表示で示します。ずれの多くは、誤解から生まれます。
4. スコープ管理計画を書きます。変更をどう評価し、承認し、エスカレーションし、追跡するかを定めて、すべてのワークストリームが同じ方法で扱えるようにします。私のSAPプロジェクトスコープテンプレートが、出発点となる構成を示しています。
5. MoSCoWで優先順位をつけます。Must have、Should have、Could have、今回はWon't have。Must haveを短く保つよう、強く働きかけてください。
6. すべての判断をバージョン管理します。承認された変更は、そのたびにベースラインを更新します。却下された変更は、理由とともに記録します。
7. トレードオフを求めます。新しい要件が入るなら、何かが外れます。必須とされていたものも、代償を払うとなれば、たちまち任意になります。

これらを定着させるために私が使ってきた手法が、3つあります。

署名の規律。業務リードに、承認済みの要件へ署名してもらいます。あるプログラムで、業務リードが、特定のプロセスフローを承認した覚えはないと言い張りました。彼の署名入りの文書を出すと、議論は終わりました。署名は、お役所仕事ではありません。同じ議論が6か月後に蒸し返されるのを防ぐものです。

波及効果を見せます。私は、あるクライアントのために、受注の項目を1つ変えると、レポート、インターフェース、セキュリティロールまで、14の領域に影響が及ぶことを示すデモを作りました。行動が変わりました。教育に要するのは数時間。波及効果を理解しないことの代償は、数か月です。

変更のコストを見せます。設計中の変更は、5,000ドルで済むかもしれません。同じ変更でも、テスト中なら5万ドルかかることがあります。それを示すシンプルなグラフを人々の前に置けば、気軽な要望は減ります。

米国市場のS/4HANAプログラムにおける、変更コストの目安の範囲です。複雑さとパートナーによって変わります。見積りではなく、目安としてお使いください。

フェーズ	小規模な変更の一般的なコスト	中規模な変更の一般的なコスト
Explore（設計）	2,000〜1万ドル	1万〜3万ドル
Realizeの初期	5,000〜2万ドル	2万〜8万ドル
Realizeの中期（構築）	1.5万〜5万ドル	5万〜20万ドル
Realizeの後期（テスト）	3万〜10万ドル	10万〜40万ドル
Deployとカットオーバー	8万〜30万ドル	30万〜100万ドル以上
ハイパーケア（本稼働後）	15万〜50万ドル	50万〜200万ドル以上

このパターンは、研究が数十年前から示してきたことと一致します。エラーコストの増大に関するNASAの調査では、結合・テストの段階で見つかった要件エラーの修正には、要件の段階で見つかった場合の21〜78倍のコストがかかり、システムが運用に入ってからはさらに大きく膨らむことがわかりました。スコープ・ガバナンスは、変更をそのカーブの安い側にとどめるために存在します。

重要な契約条項

曖昧な契約は、高くつく問題を生みます。ある顧客が、「S/4HANAを導入する」としか書かれていない契約に署名したのを見たことがあります。パートナーは後になって、特定のプロセスは追加費用の必要なアドオンだと主張し、顧客は結果的に2倍を支払うことになりました。次の条項が、それを防ぎます。

条項	目的
明示的な除外を含むスコープ	固定価格がカバーする範囲を限定し、アドオンをめぐる曖昧さをなくす
よくある変更の事前合意単価	レポート、インターフェース、設定変更の価格を、プレッシャーがかかる前に固定する
コンサルタントの継続性	新しいコンサルタントが決定済みの事項を蒸し返し、スコープを広げるのを防ぐ
双方の承認権限	経験の浅いコンサルタントが、誰も承認していない機能を約束するのを防ぐ
マイルストーンベースの請求	支払いを、経過時間ではなく、署名済みの成果物に結びつける
成果物ごとの受入基準	誰かが争う前に「完了」を定義する
クリーンコアの拡張条項	拡張にリリース済みAPIまたはSAP BTPの使用を求める。最初のメジャーアップグレードでの手戻りを防ぐ

これらの条項に合意してもらう方法は、ERP契約交渉についての私のメモで取り上げています。

変更管理委員会

変更委員会は、適切な人が揃っていれば機能します。私が組む委員会には、3つの役割を置きます。機能面を重視する業務の意思決定者、スケジュールを重視するプロジェクトマネージャー、予算を重視する財務リードです。このバランスが、どれか1つの優先事項が支配するのを防ぎます。

1. 01依頼の提起書面で。コーヒーを飲みながらではなく
2. 02影響評価時間、コスト、品質を、誰かが承認する前に
3. 03トレードオフの明示入れる余地を作るため、何かが外れる
4. 04変更委員会の判断業務、プロジェクト、財務が同じテーブルに着く
5. 05ベースラインの更新却下した変更も、理由とともに記録する

スコープは、委員会を通じてのみ動く

委員会には、実際の権限が必要です。あるプログラムでは、委員会の承認なしにスコープが変わることは一度もありませんでした。ただの一度も、です。廊下での合意はなくなりました。営業担当VPが新しい要件を紛れ込ませようとしたとき、チームには、示すことのできる文書化された承認マトリクスがありました。

判断の大半は、委員会のレベルで完結させます。スポンサーに上げるのは、本当に意見が割れた案件だけです。そうすれば、スポンサーを巻き込みつつ、案件に溺れさせずに済みます。ワークストリームのリードとのスコープレビューを2週間ごとに開き、提出、承認、却下された依頼の件数を報告します。ステータスレポートに「今月のスコープ増加は15%」と載ると、人の行動は変わります。

必要な変更もあります。私が関わったある製薬会社は、導入の途中で、FDAの新しい規制の影響を受けました。取り込まざるを得ませんでした。これはスコープクリープではありません。現実です。

正当な変更が来たら、2つの質問をします。機能する最小の修正は何か。そして依頼した人には、場所を空けるために何を外す覚悟があるか。依頼に代償が伴うとわかると、緊急性はすぐに下がります。

選択肢は、スケジュールを延ばす、予算を足す、ほかの要件を削る、人員を増やす、またはその組み合わせです。何を選ぶにしても、文書に残し、すべてのベースライン文書を一度に更新します。古いままの文書が、次のスコープ問題を生みます。

いまは、事務作業をAIが助けてくれます。Microsoft Copilotのようなアシスタントは、長い変更要求のやり取りを、委員会がそのまま判断できる要約にまとめます。SAP Cloud ALMは、要件、変更、テストを紐づけておくので、変更の影響をたどりやすくなります。AIは、ある変更が14の領域に及ぶことを示せます。しかし、COOの要望が通ればCFOの要望は通らないと、COOに伝えることはできません。その会話は、依然としてあなたの役目です。

私が関わったある製造会社は、SAPプロジェクトを予定どおり完了しました。これは、本来あるべき頻度よりも稀なことです。スコープフリーズの日付を早い段階で定め、その後の変更にはCEO本人の承認を必要としました。プロジェクトは予算を残して終わり、本稼働のときに週末も働いている人は誰もいませんでした。

別のクライアントは、トークン制を使いました。各部門に、プロジェクト全体を通じて3枚の変更トークンを配ります。変更が欲しいなら、トークンを1枚使います。人々は何が大切かを真剣に考え、「必須」とされていたものも、限りある通貨を払うとなると、考え直されました。

どちらの方法も、複雑ではありません。必要なのは、規律と、リーダーシップの支えです。スコープのプロセスが本物かどうかは、COOが「小さな変更を1つだけ」と言ってプロジェクトルームに入ってくる日に試されます。その日のために作ってください。

SAPプロジェクトのスコープクリープとは何ですか？

スケジュール、予算、リソースの見直しを伴わないまま、要件が少しずつ、統制なく増えていくことです。SAPでは、たいてい小さな追加から始まります。レポートの追加、項目の追加、「ワークフローをちょっと変えるだけ」。一つひとつは無害に見えます。積み重なると、数か月が加わります。

正当なスコープ変更は、手続きを経て、スケジュールと予算の調整を伴います。スコープクリープは非公式に現れ、変更管理を素通りします。

SAPプロジェクトでスコープクリープが起きる、最も一般的な原因は何ですか？

一貫して挙がる原因は3つです。初期の要件が曖昧で、何でも対象範囲内だと主張できてしまうこと。正式な変更管理がなく、あらゆるレベルで変更がすり抜けること。そして、10年に一度という意識で、各部門が長年の問題をこのプロジェクトで解決しようとすることです。

SAPは機能が相互に結びついているため、この3つが増幅されます。1つの変更が、つながった10のプロセスを壊しかねません。業務リードがそのつながりを見えていないと、影響はテストの段階で現れ、そのときにはコストが何倍にもなっています。

クリーンコアは、スコープクリープのリスクをどう変えますか？

技術的なブレーキがかかります。S/4HANA Cloud Public Editionではコアを修正できないため、あらゆるギャップが、独自の設計、構築、テストのコストを伴う拡張になります。Private Editionとオンプレミスでは修正は可能ですが、アップグレードの作業が増えるため、SAPのガイダンスは推奨していません。

判断権限を持つアーキテクトを置いた拡張レビューの場があれば、多くの依頼はベースラインに入る前に止まります。その場がなければ、オンプレミスのプログラムは、以前の習慣に逆戻りします。

スコープクリープとゴールドプレーティングの違いは何ですか？

スコープクリープは、業務側から生まれます。合意した範囲を超える要望です。ゴールドプレーティングは、デリバリーチームから生まれます。誰も求めていない複雑さです。

SAPで言えば、ゴールドプレーティングとは、単純なルーティングで足りる場面で、コンサルタントが手の込んだワークフローのロジックを作ることです。スコープクリープとは、基本的なMMを対象としたプロジェクトで、6か月が過ぎてからCOOが高度な倉庫機能を求めることです。どちらもコストと時間を膨らませ、必要な規律も同じです。

実際に機能する変更管理のプロセスは、どう構成すればよいですか？

要素は3つです。すべての依頼に、スケジュール、予算、リソースへの影響評価を添えます。承認する委員会には、その3つのそれぞれを重視する人を入れます。何でも承認してしまう業務リードだけにしてはいけません。そして、あらゆる追加にトレードオフを求めます。何かが外れる、ということです。

この最後のルールだけで、本当に重要とは言えない依頼はふるい落とされます。

スコープクリープを完全に避けることはできますか？

できません。数か月を超えるプログラムでは、ビジネスの状況が変わり、規制が変わり、設計の過程でギャップが見つかります。

目標は排除ではなく、統制です。統制された変更は、文書化された手続きに従い、影響が評価され、ベースラインを更新します。統制されない変更は、手続きを素通りし、テストの段階や本稼働後に、誰も計画していなかったコストとして表面化します。

長期のSAPプログラムで、スコープフリーズを扱う最善の方法は何ですか？

結果を伴わせ、経営層が目に見える形で後ろ盾になることです。私が使ってきた最も効果的な形は、こうです。フリーズの日付を、初日からプロジェクト憲章に書き込む。変更プロセスで、実務上の「フリーズ」の意味を定義する。そして、日付が来る前に、ステアリングでスポンサーが公に念を押す。

フリーズ後のあらゆる変更をCEOが自ら承認するとなれば、リストはごく短くなります。