SAPプロジェクトの炎上の根本原因は「要件の複雑さ」でも「リソース不足」でもない。

「業務設計ができないコンサルタントが、作るべき成果物を作れないまま進め、

意思決定できる人員を確保せずにプロジェクトを走らせた」

という、プロジェクト設計そのものの失敗にある。

そしてその失敗を隠蔽する構造として

「人を追加すれば解決する」という人海戦術が機能し、

コンサルファームのビジネスモデルがその方向を加速させる。

【機能コンサルタントが「記録者」になっているときの症状】

・フィット&ギャップ分析の成果物が「Gapリスト」であり、「標準化提案」がない

・ユーザーが「〇〇したい」と言ったことを全てアドオン要件として記録する

・「SAPではこのやり方の方が業務が効率化できます」という提案が出てこない

・設計書が「ユーザーから聞いたことを書いた議事録」のレベルを超えない

・問題が発生したとき「追加要員を投入しましょう」しか言えない

【本来の「設計者」であるコンサルタントがすること】

・業務のAs-IsとTo-Beを自分で描ける（描かせるだけでなく）

・SAP標準プロセスと顧客業務のギャップを「どちらを変えるか」まで提案できる

・成果物のレビューで「この設計ではここが問題になる」と指摘できる

・プロジェクトが遅れているとき「何を削れば間に合うか」の優先判断ができる

□ 会議で「要件をまとめます」「確認します」「調整します」という言葉が繰り返されているが、何も決まらない

□ コンサルタントがTo-Be業務フロー（あるべき業務プロセス）を自分で描けない（ユーザーに描かせて記録するだけ）

□ フィット&ギャップ分析の結果が「GapはN件あります」で終わり、「どうするか」の提案がコンサルから出ない

□ 設計書はあるが、それを読んで開発・テストができるレベルの品質になっていない

□ スコープ変更・追加要件が発生したとき「誰が承認するか」が決まっていない

□ 発注者側に「業務のオーナー（最終決定者）」が実質的に存在しない

□ 「問題があります」という報告に対してコンサルの答えが「人を追加しましょう」だけである

□ プロジェクトの遅延理由として「ユーザーの要件確認が遅い」という言葉がよく出る

▶ 3つ以上当てはまるならコンサル品質の問題がプロジェクトに内在している。5つ以上で炎上進行中のシグナルと判断せよ。

業務設計なし

↓

「今と同じ業務ができることがFit」という基準でギャップを判断する

↓

SAP標準機能の大半が「Fit しない（Gap）」と判定される

↓

全GapにアドオンかConfigで対応しようとする

↓

開発工数が爆増。テスト量も爆増。

↓

「追加要員が必要」という診断が下される

↓

人が増え、コストが増え、期間が延び、品質が下がる

↓

炎上確定

── この連鎖は「業務設計をやり直す」以外で止まらない

□ To-Be業務フロー（あるべき姿の業務プロセス図）が、コンサルタントの手で描かれている（ユーザーが描いたものをそのまま採用していない）

□ To-Be業務フローがSAP標準プロセス（Best Practice）と比較・検討された上で設計されている

□ 「なぜSAP標準ではなくカスタマイズが必要か」の理由が、機能要件ごとに明文化されている

□ フィット&ギャップ分析の結果に「業務側を変える提案（Fitへの適合案）」が含まれている

□ 業務設計の変更（現行→将来）についてユーザー部門長が明示的に合意している

□ To-Be業務フローが設計書・テスト計画書・トレーニング計画書と一貫して連動している

□ 業務変革に伴う「誰の仕事がどう変わるか」が担当者レベルで文書化されている

▶ 4つ以上がNoなら業務設計は実質的に機能していない。フィット&ギャップ分析のやり直しを検討すべきタイミングだ。

【設計書品質が低い場合の典型的な時系列】

Month 3：業務設計フェーズが完了。設計書レビューは「ざっと見た」だけ。

「細かいところは後で詰めましょう」という台詞が頻出。

Month 7：実装フェーズ中。開発者から「この設計書、どう実装すればいいか分からない」

という問い合わせが頻発。コンサルが個別に口頭で補足説明。

口頭説明の内容は設計書に反映されない。

Month 12：統合テスト開始。モジュールAとモジュールBをつないだとき動かない。

「あの場面で決めた口頭の合意はどうなっていたんだっけ？」

という議論が始まる。議事録もなく、証拠がない。

Month 14：稼働3ヶ月前。手戻りが大量発生。追加要員を投入するが

「どこが正しい設計なのか」を追いかけることで時間が溶けていく。

Month 18：当初計画から6ヶ月遅延。原因は「設計書が曖昧だったこと」だが

誰もそう言わない。「要件が複雑だった」と総括される。

□ フィット&ギャップ分析の結果に「業務プロセスレベルの詳細」が記載されており、読んだだけで設計の根拠が分かる

□ 統合設計書（モジュール間の連携・データの受け渡し仕様）が独立した文書として存在している

□ 各モジュールの設計書について、担当外のコンサルタントがレビューし、矛盾・不備を指摘するプロセスがある

□ データ移行設計書に「移行元→移行先のフィールドマッピング」が全項目分記載されており、例外処理も定義されている

□ カットオーバー計画書に「タスク名・担当者・所要時間・開始条件・完了条件・エスカレーション先」が全て記載されている

□ テスト計画書に「テスト終了条件（件数・合格率・重大バグ数）」が明記されており、関係者が合意している

□ 成果物のレビュー基準（どのレベルであれば次フェーズに進めるか）が定義されており、PMOが管理している

▶ 4つ以上がNoなら「形式的な成果物しか存在しない」状態だ。テスト工程で大量の手戻りが発生することをほぼ確実に予告している。

役割①：エグゼクティブスポンサー（経営層）

役割：プロジェクト全体の方向性・重大な変更・稼働判定を最終決裁する

必要な条件：週1回のプロジェクト状況報告を受け、2営業日以内に判断を下す権限と実行力

役割②：業務オーナー（部門長クラス）

役割：業務要件・業務プロセス変更・UAT合格判定を決定する

必要な条件：自分の部門の業務を「SAP導入後にどう変えるか」の最終決定権を持つ

プロジェクトへの関与時間として週2日以上を確保する

役割③：プロジェクト推進責任者（発注者PM）

役割：日常的な意思決定・スコープ管理・ベンダー管理を行う

必要な条件：SAP導入の目的と業務知識の両方を持ち

「コンサルに全任せ」にならない実務推進ができる人物

①「このプロジェクトのアーキテクト（設計責任者）は誰ですか？」

→ 具体的な氏名とこれまでの類似プロジェクト実績を示してもらう

②「フィット&ギャップ分析を実施するコンサルタントは、

御社の業務と同種の業務に何年の経験を持つ方ですか？」

→ 「SAPのXXモジュールを設定できる」ではなく

「食品製造業の購買業務を理解した上で設計できる」人材かを確認する

③「追加要件・スコープ変更が発生した場合、

どの役職の方が影響分析を行い、どう報告してもらえますか？」

→ 変更管理プロセスと報告ラインの明確さを確認する

④「プロジェクト途中でメンバーが変わった場合の引き継ぎ体制は？」

→ 「知識が人に依存している」プロジェクトは危険。ドキュメント化の方針を確認する

⑤「進捗が遅延した場合、貴社はどのような回復策を取りますか？」

→ 「人を追加します」という答えしか出ない場合は要注意。

根本原因への対処方針を持っているかを見る

□ 発注者側に「スコープ変更を最終承認する権限者」が明文化されており、その人物が実際にプロジェクトにコミットしている

□ 受注者側に「設計の最終責任者（アーキテクト）」が指名されており、設計レビューの場に実際に参加している

□ 意思決定が必要な事項が発生してから、最終判断が下されるまでの「最大日数」がルールとして決まっている

□ スコープ変更・追加要件の影響（工数・コスト・期間）を定量的に分析するプロセスが機能している

□ Go/No-Go判定の基準（何が満たされれば稼働するか・何があれば延期するか）が文書で合意されている

□ 「調整中」「確認中」のまま2週間以上動いていない課題が、課題ログの中に3件以上ない

□ コンサルタントの成果物品質に問題があると感じたとき、それを発注者から受注者に正式に指摘できる関係性・仕組みがある

▶ 4つ以上がNoなら意思決定の空白地帯がプロジェクトの進行を妨げている。権限マトリクスの再設定とエスカレーションルールの再定義が急務だ。

失敗①：フィット&ギャップ分析が「現行業務の記録」になっていた

→ 「今の業務をSAPで再現するにはGapがある」という分析しか行われなかった

→ 「SAP標準プロセスに合わせて業務を変えた場合のコスト比較」が一切なかった

→ コンサルは業務変革の提案ができる人材ではなく、聞いたことを書く人材だった

失敗②：統合設計書が存在しなかった

→ PP・MM・FI はそれぞれ別チームが設計し、「後で統合する」とされていた

→ 統合設計書がないまま各モジュールの設計が進んだ結果

　 PP（生産指示）とFI（在庫評価）の連携設計に根本的な矛盾が生じた

→ これはテスト工程で発覚するまで誰も気づかなかった（気づける仕組みがなかった）

失敗③：「アドオンが増えた」は結果であり原因ではない

→ 「業務設計がなかった」→「全GapにアドオンかConfigで対応」という

　 意思決定の連鎖が本当の原因

→ 業務をSAPに合わせる判断をする「権限ある業務オーナー」が発注者側にいなかった

【この事例から学ぶ教訓】

アドオンの増加は炎上の「原因」ではなく「症状」だ。

症状を見て「アドオンを減らせ」と言っても遅い。

「業務設計のできるコンサルがいなかった」という診断から始めなければ

再び同じことが繰り返される。

失敗①：データ移行設計書が「書類」に過ぎなかった

→ 移行設計書は作成されていたが「何をどう移行するか」の粒度が粗すぎた

→ 「商品マスタを移行する」とは書いてあったが

　「どのフィールドを・どの条件で・どのSAPコードにマッピングするか」が未定義だった

→ コンサルが「移行設計書を作ること」を成果物と捉えており

　「移行が成功すること」を成果物と捉えていなかった

失敗②：データ品質改善が「技術的な作業」として位置づけられた

→ 150万SKUのデータ品質問題は技術的な問題ではなく

　「誰がデータオーナーか」「どのデータが正しいか」という業務の問題だった

→ この業務設計（マスタデータガバナンス）をコンサルが提案できなかった

→ 結果としてデータ移行の問題が発覚するたびに「修正作業」が発生し続けた

失敗③：移行テストの実施タイミングが遅すぎた

→ 「本番相当データでの移行リハーサル」が稼働6ヶ月前に設定されていた

→ 本来はプロジェクト初期から定期的に実施すべきだった

→ コンサルが「移行テストはFinal Preparationフェーズ」という

　 形式的なフェーズ設計に従っただけで、リスク管理の観点がなかった

事例C（食品メーカー）の本当の失敗：

・食品業界固有の規制要件（HACCP・食品安全基本法・賞味期限管理）を

　プロジェクト初期に調査・設計できるコンサルがいなかった

・QMモジュールの経験が浅いコンサルが「できます」と言って設計を担当した

・問題が発覚したのはUAT段階。「今更言えない」という沈黙が3ヶ月続いた後だった

事例D（物流3PL）の本当の失敗：

・3PL業界の業務特性（荷主別ルールの複雑さ）を理解せずに

　SAP TM+EWMの「標準的な導入アプローチ」で設計を進めた

・「荷主47社の個別ロジックをどう標準化するか」という

　最重要の業務設計課題に答えを出せないまま実装フェーズに入った

【共通する構造】

「業種を知らないコンサルが、知っているふりをして設計を進める」

→ 問題は必ずテスト工程で爆発する

→ その時点での修正コストは設計段階の10〜30倍になっている

対策の本質は「コンサルタントの業種経験を選考基準の最優先にすること」だ。

失敗①：業種固有の規制要件をフェーズ0（準備フェーズ）で調査しなかった

→ CSV要件はSAPの技術的な問題ではなく「製薬業界でERPを使うための前提条件」だ

→ コンサルの経歴確認で「製薬業界の経験」を確認していれば防げた失敗

→ 「SAPを導入できる」と「医薬品製造業でSAPを導入できる」は全く別の能力だ

失敗②：QMのバリデーション設計が「後付け」になった

→ QMは「システムを設定してから動作確認する」のではなく

　「バリデーション計画→設計→実装→テスト→文書化」という

　逆算されたプロセスで設計しなければならない

→ コンサルがこの要件を知らなかったため

　QM設計がシステム要件定義ベースで進み、バリデーション視点が抜け落ちた

失敗③：UATがバリデーションのOQ/PQ（運用適格性・性能適格性確認）を兼ねていなかった

→ 製薬業では「UATをバリデーション証跡として使える設計」にする必要がある

→ そのためにはUATシナリオ・テスト手順書・結果記録書が規定形式である必要があるが

　プロジェクトのUAT設計にその視点が含まれていなかった

【教訓】

「業種の規制を知らないコンサルが、その業種のプロジェクトを主導してはいけない」

これは技術的な問題ではない。採用・アサイン管理の問題だ。

失敗①：設計者が工場の「現場の動き」を理解していなかった

→ 自動車部品工場では「秒単位・分単位の生産タクト」が業務の基本単位だ

→ SAPのトランザクションは「分〜時間単位」で動くことが前提の設計になっており

　 現場の「今すぐ確認したい」というニーズに対応できなかった

→ コンサルが工場に来ていれば、この設計の齟齬は1日で分かった

失敗②：MES連携のインターフェース設計が「技術仕様の確認」だけで終わった

→ 「どのタイミングでどのデータをSAPからMESに送り、

　 どの判断基準でMESの実績をSAPに取り込むか」という

　 業務フローレベルの設計が曖昧なまま技術的な接続仕様だけを決めた

→ 接続は「できた」が「業務として正しく動く」設計になっていなかった

失敗③：現場ユーザーがUATに参加しなかった

→ UATは本社のIT部門と生産管理部門が実施し

　 工場の現場班長・作業者は参加しなかった

→ 「管理者目線で動くシステム」は稼働したが

　 「現場の作業者が使えるシステム」にはなっていなかった

【教訓】

製造業のSAPプロジェクトで「工場に行かない設計者」は

どれだけ優秀でも「机上の設計しかできない」。

現場に何度も足を運び、実際の作業を自分の目で見ることが

製造業の業務設計における最低条件だ。

失敗①：業務の「管理体系」を変えないまま、システムの「管理体系」だけ変えようとした

→ WBS設計は「SAP PSの機能を使う」技術的な作業ではなく

　「会社として案件をどういう軸で管理するか」という経営の意思決定だ

→ コンサルは「SAP PSでこういう設計が標準的です」と提案したが

　「御社の業務体系をどう変えるか」という本質的な提案ができなかった

失敗②：「管理体系の統一」という最重要の業務設計課題を先送りにした

→ 同社では部門・工事所によって案件管理の体系がバラバラだった

→ SAP PSを導入する際には「全社で統一したWBS体系を先に決める」必要があったが

　「とりあえず今の体系をSAPに入れる」という判断がされた

→ これは業務設計の根本的な失敗であり

　コンサルが「統一の必要性」を経営に強く働きかけなかった責任がある

失敗③：COモジュールの内部原価設計とPSの連携が「後付け」になった

→ PS（プロジェクト原価）とCO（管理会計）の連携設計は

　 最も難度が高く最初に設計すべき部分だったが

　 「後でつなげればいい」として最後まで先送りされた

→ 「SAP PSで案件の原価が見える」という最大の導入目的が

　 最後まで設計されないまま稼働した

【教訓】

建設業のSAP PS導入は「WBS設計＝経営設計」だ。

SAP PSの機能を知っているコンサルではなく

建設業の原価管理体系を変革できるコンサルが必要だ。

この二つは全く異なる能力であり、両方を持つ人材は少ない。

調達段階で「建設業の原価管理改革の実績」を必ず確認すること。

失敗した事例を全て並べると、技術的な問題はほとんどない。

あるのは「知らない人が設計した」という問題だ。

・製薬業界を知らない人が製薬業界のプロジェクトを設計した

・工場の現場を知らない人が製造現場のシステムを設計した

・建設業の原価管理を知らない人がプロジェクト原価システムを設計した

そして「知らない」ということは、設計段階ではバレない。

問題はテスト工程か、稼働後にしか表面化しない。

その時点での修正コストは設計時の10〜30倍だ。

コンサル選定において「SAPを知っているか」は必要条件に過ぎない。

十分条件は「あなたの業種の業務を変革した実績があるか」だ。

この問いを契約前に必ず確認すること。それだけで炎上の半分は防げる。

原則①：本番切り替え前に最低2回のリハーサルを実施する

1回目（ドライラン）：問題を発見するための実施。時間超過・手順ミスを記録する

2回目（タイム計測）：修正後の手順で実施。制限時間内に完了することを確認する

原則②：手順書は「考えなくていいレベル」で書く

タスク名・担当者名・開始条件・完了条件・所要時間・問題時の連絡先

を全て記載する。カットオーバー当日は手順書を読むだけで動ける状態にする

原則③：Go/No-Go判定基準を事前に合意する

「稼働に踏み切る条件」「延期する条件」を数値で定義し経営層が事前承認する

当日の感情・プレッシャーで判断しないルールを作る

原則④：切り戻し計画（Rollback Plan）を必ず用意する

稼働後に重大問題が発生した場合に旧システムに戻せるか。

戻せない場合はそのリスクを経営に事前説明し承認を得る

SAPプロジェクトの最大の誤りの一つは「Go-Liveで完了」という認識だ。

Go-Liveは終わりではなく、業務変革の始まりだ。

稼働後の業務パフォーマンス向上を誰が推進するか、

その体制をプロジェクト計画の段階から設計しておくことが

長期的なSAP ROIを決定する最重要の組織設計だ。

稼働後に継続的な改善を行うCCoE（Cloud Center of Excellence）や

業務改革推進チームを、プロジェクト終了後も維持すること。

「コンサルが終わったら全部自分たちで動かせるか」を

稼働前から設計しておくことが、本当の成功条件だ。

□ Hypercare期間（稼働後1〜3ヶ月）のサポート体制（ヘルプデスク・常駐SIer・キーユーザー）が稼働前に設計されている

□ 稼働後に追跡するKPI指標と目標値が、経営レベルで合意されている

□ 稼働後の業務改善活動を推進する担当者・組織が指名されており、プロジェクト終了後も活動継続する計画がある

□ SAP Fiori・SAP Analytics Cloudなど稼働後の高度活用に向けたロードマップが計画されている

□ 稼働後6ヶ月・12ヶ月時点での「SAP活用度レビュー」のタイミングが設定されている

□ コンサルタントが撤退した後、社内でSAPを運用・改善し続けられる人材・知識の移転計画がある

▶ 4つ以上がNoなら「稼働したが何も変わらなかった」というSAP導入の失敗パターンに向かっている。稼働後の体制設計を今すぐ始めよ。

□ 業務設計（To-Be業務フロー）が発注者業務オーナーの承認を得て確定している

□ コンサルタントの成果物品質に関する評価を実施し、品質基準を満たさないものを特定・改善済みだ

□ スコープが「稼働必須・後日実装・廃止」に分類され、経営の承認を得ている

□ 統合設計書が存在し、モジュール間の連携仕様が全て文書化されている

□ データ移行リハーサルの成功率が直近のリハーサルで90%以上に達している

□ 発注者側の意思決定者（エグゼクティブスポンサー・業務オーナー）が実際にプロジェクトに関与している

□ Go/No-Go判定基準が文書で合意されており、経営層が内容を知っている

□ 稼働後の体制（Hypercare・KPI追跡・業務改善推進）が設計されている

▶ 6つ以上がYesなら立て直しは軌道に乗っている。4つ以下のYesなら、まだ根本的な問題が残っている。焦って稼働しないこと。

このプロジェクトは、なぜうまくいかなかったのか。

「要件が複雑だったから」でも

「リソースが足りなかったから」でも

「スケジュールが無理だったから」でもない。

「業務を設計できる人が、業務を設計しなかった」

「作るべきものを、作れるレベルで作らなかった」

「決めるべき人が、決めることから逃げ続けた」

この三つのどれかが、必ず炎上の根にある。

プロジェクトを立て直すとは、この三つの問いに正直に向き合い、

構造を変えることだ。

人を増やすことでも、計画を作り直すことでも、会議を増やすことでもない。

「本当のことを言える場所」を作り、

「決断できる人」を座らせ、

「作れる人」に任せること。

そこから、プロジェクトは再生する。