SAP導入プロジェクトの失敗原因を検索すると、だいたい似たような答えが出てくる。
経営層の関与不足。
要件定義不足。
スコープの膨張。
データ移行の失敗。
テスト不足。
ユーザー教育不足。
チェンジマネジメント不足。
どれも間違ってはいない。
しかし、私は以前から、この説明には物足りなさを感じていた。
なぜなら、これらを知っている企業でもSAPプロジェクトは失敗するからだ。
数十億円、場合によっては数百億円を投じるERPプロジェクトなら、PMOもいる。大手SIerもコンサルティング会社も参加する。SAPに詳しい人間もいる。
「テストが大切です」
「経営層のコミットメントが必要です」
程度のことを、誰も知らないわけではない。
それなのに、同じような失敗が何度も繰り返される。
なぜなのか。
ERPに関する日本語・英語・ドイツ語・スペイン語の事例や研究を調べ、私自身がこれまで複数のSAP・ERPプロジェクトに関わってきた経験と重ねると、違う景色が見えてきた。
失敗原因は10個、独立して存在しているのではない。
上流で発生した小さな判断ミスが、未解決のまま次の工程へ送られる。
その問題を前提に設計する。
さらに開発する。
さらにデータを作る。
さらにテストケースを書く。
そして最後に、テスト、データ移行、カットオーバー、本番稼働という「逃げ場のない工程」で、一気に表面化する。
つまりSAPプロジェクトの失敗とは、
「失敗原因の集合」ではなく「失敗が増幅していく連鎖」
なのではないか。
その前に、「失敗」とは何なのか
SAPが予定日にGo-Liveした。
予算も大きく超過しなかった。
重大障害も起きなかった。
これは成功だろうか。
プロジェクト管理上は、成功と評価できるかもしれない。
だがSAPを導入した後も、
月次決算が速くならない。
在庫が減らない。
Excelが大量に残る。
二重入力が残る。
経営情報が速くならない。
追加の運用人員まで必要になる。
ならば、数十億円を投じた経営投資として成功だったのだろうか。
この疑問には研究上の裏付けもある。
Ram、Corkindale、Wuは217組織のデータを分析し、ERPの**Implementation Success（導入成功）と、その後のOrganizational Performance Improvement（組織パフォーマンス改善）**を別の成果変数として扱う必要があると論じている。
これはERPを考えるうえで非常に重要だ。
Go-Liveできた ≠ ERP投資に成功した
のである。
逆に、本番直後に多少の混乱があったとしても、その後、在庫・決算・業務生産性・データ活用が大幅に改善されたなら、長期では成功と評価できるかもしれない。
したがって本稿では、単に「予定日に動いたか」だけではなく、
企業がERP導入の目的としていたBusiness Outcomeを実現できたか
まで含めて成功・失敗を考えたい。
SAPプロジェクトに現れる「10の症状」
SAPプロジェクトが危なくなったとき、表面には次のような症状が現れる。
これらを一つずつ対症療法で潰しても、なかなか根治しない。
なぜなら、その下にもっと大きな5つの構造があるからだ。
構造1 Standardization Paradox
現行業務を残しすぎても失敗する。標準化しすぎても失敗する
SAP導入で昔からある典型的な失敗が、
「現在のシステムでできているので、SAPでも同じようにしてください」
である。
これを無条件に認めれば、
現行帳票。
現行画面。
昔から存在する例外処理。
担当者独自のExcel。
過去のシステム制約から生まれただけの業務。
まで新しいSAPに移植される。
結果として巨大なアドオンシステムができる。
そこでS/4HANA時代には、Fit to StandardやClean Coreが強調されるようになった。
方向としては正しい。
ところが、今度は逆方向の失敗が生まれる。
「SAP標準に合わせること」そのものが目的になる。
山善の事例は、この難しさを非常によく表している
2026年にSAPが公開した山善の事例は興味深い。
山善はステップ1でFit to Standardを前提にSAP導入を進めたが、同社自身が「知識不足、経験不足が否めなかった」と振り返っている。
アドオン審議を厳しくしすぎた結果、
「顧客の要望に寄り添ってきた山善の強みが失われるのではないか」
という声が現場から出た。
そこで方針を修正すると、今度はアドオンが当初計画以上に膨らみ、計画全体の見直しが必要になった。
ステップ2では、ステップ1の経験を踏まえて目指すシステムの方向性を明確にした。Fit to Standard自体は維持しながら事業部の要望を精査した結果、SAP公式事例によれば、アドオン・工数とも想定範囲内に収めたという。
ここで重要なのは、
「標準化を徹底すれば成功する」
という単純な話ではないことだ。
むしろ山善の経験が示しているのは、
何を標準化し、何を残すのかを判断する能力そのものが必要
ということである。
Lidlは、その問題をさらに極端な形で示している
ドイツの小売大手Lidlは、2011年からSAPベースの商品管理システム「Elwis」を進めた。
約7年、約5億ユーロ規模を投じた後、2018年にプロジェクトを中止した。
ドイツのc't／heiseは、その背景の一つとして、Lidl固有の商品在庫評価方法とSAP Retailの標準的な考え方との大きな差を報じている。
在庫評価方法の細部については報道間で記述に差があるため、本稿ではそこを失敗原因と断定しない。
むしろ重要なのは、
企業固有の業務とERPパッケージの前提が根本部分で衝突すると、その差を埋めるコストが巨大になる
という点である。
しかもLidlの後日談はさらに面白い。
SAP導入済みだった4カ国を旧来の商品管理システムWawiへ戻し、最後のLidl USAも2023年に戻したとドイツの業界誌は報じている。
さらに現在は、Schwarzグループの自社クラウドSTACKITを基盤として、新たな商品管理システム「Wawi Nexus」を自社主導で開発しているとされる。
これは、
「標準ERPに合わせられなかった失敗企業」
とだけ解釈するより、
商品管理を自社の差別化領域として持つ、という経営判断へ戻った
と読む方が面白い。
「As-Is ≠ Requirement」
では、標準化と独自性をどう判断すればよいのか。
ここでまず重要なのが、
As-Is ≠ Requirement
である。
「現在こうやっています」は、要件ではない。
例えば、
この帳票は昔からこのレイアウトです。
と言われたとする。
すぐアドオン見積もりをしてはいけない。
まず、その要求を分解する。
法令要件なのか。
税務要件なのか。
内部統制要件なのか。
競争力につながる業務要件なのか。
取引先との契約要件なのか。
それとも単なる利便性なのか。
SAP標準で法的要求をすべて満たすなら、
「なぜ今のレイアウトでなければ業務できないのですか？」
と問い直す。
この質問がFit to Standardの本当の入口だと思う。
「Standard Function ≠ Business Process Works」
ただし、逆もある。
SAP標準でできます。
これだけで要件回答を終えるのも危険だ。
標準機能で請求書を発行できる。
しかし、
税務システムへ正しく連携されるのか。
取引先EDIは成立するのか。
取消・訂正の場合はどうなるのか。
会計へ正しい日付で転記されるのか。
例外が起きたら誰が再処理するのか。
月末の大量処理に間に合うのか。
まで成立しなければ、本当の意味で「業務ができる」とはいえない。
つまり、
Standard Function ≠ Business Process Works
である。
この二つの「≠」は、Standardization Paradoxを判断する実務上の重要な物差しになる。
構造2 Process Ownership Gap
社内の「横」を誰が決めるのか
SAPにはFI、CO、SD、MM、PPといったモジュールがある。
そして会社には、
営業部。
物流部。
購買部。
生産部。
経理部。
情報システム部。
がある。
ここに落とし穴がある。
会社組織は基本的に縦に作られている。
しかしERPの業務プロセスは横に流れる。
例えばOrder to Cashなら、
受注
↓
出荷
↓
請求
↓
債権計上
↓
入金
↓
消込
まで一続きだ。
「各チームでは正常」でも会社は止まる
SAPプロジェクトでは、こんな状況が起きる。
SDチーム。
「SD側は問題ありません」
FIチーム。
「FIも正常です」
インターフェースチーム。
「メッセージは正常に送信しています」
それでも業務が止まる。
なぜなら企業が必要としているのは、
SDが動くことでも、
FIが動くことでも、
IFが成功することでもない。
顧客から注文を受け、商品を届け、請求し、現金を回収できること
だからだ。
そこで必要になるのがE2E Process Ownerである。
Order to Cash。
Procure to Pay。
Plan to Produce。
Record to Report。
それぞれについて、
部門をまたいで最終的な業務判断を行う人
が必要になる。
本稿では、この社内横断プロセスの責任空白をProcess Ownership Gapと呼ぶ。
構造3 Accountability Gap
社内外の「縦」――誰が決め、誰が責任を持つのか
Process Ownership Gapが社内の横方向の問題だとすれば、Accountability Gapは、
ユーザー企業・業務部門・情シス・SIer・コンサルタントの間で、意思決定責任が垂直方向に抜け落ちる問題
である。
SAPプロジェクトには大量の専門家がいる。
ところが専門家が多いことと、
最終的に誰が決めるか明確であること
は別だ。
例えば、
「この要件はSAP標準へ合わせるか、アドオンにするか」
を誰が決めるのか。
業務担当者なのか。
Process Ownerなのか。
ITなのか。
SAPコンサルタントなのか。
Steering Committeeなのか。
Design Authorityなのか。
これを曖昧にしたままでは、会議参加者が20人いても誰も決められない。
アドオン審議会は「会議体」があるだけでは意味がない
例えばアドオン審議をするとする。
必要なのは、単に会議を開催することではない。
少なくとも、
誰が申請するのか。
何を根拠に審議するのか。
誰がSAP標準との差分を確認するのか。
誰が法令要件を保証するのか。
誰がBusiness Valueを判断するのか。
誰が最終決裁するのか。
どこから上位会議へEscalationするのか。
を決めなければならない。
契約上も同じである。
準委任なのか請負なのか、あるいは工程によって契約形態を分けるのかによって、ベンダーに期待する成果責任の範囲は変わる。
しかし、契約書を書けば企業側の業務意思決定まで自動的にベンダーの責任になるわけではない。
SAPコンサルタントは選択肢を提示できる。
SIerは技術的な実現可能性を説明できる。
だが、
「我が社としてどの業務モデルを採用するか」
は、最終的にはユーザー企業が決めなければならない。
構造4 Decision Debt
決めなかった問題は消えない。利息を付けて戻ってくる
ERP Todayでは2026年、ERPプロジェクトで重要な業務判断を先送りし、暫定的な前提でプロジェクトを進めることによって生じる負債をDecision Debtと表現している。
非常にうまい表現だと思う。
SAPプロジェクトでは、こういうことが頻繁に起きる。
「Intercompanyの将来業務をどうしますか？」
「次回までに検討します」
一週間後。
「税務部門に確認します」
一か月後。
「まだ経営判断が必要です」
しかしプロジェクトは止められない。
だからチームは、
暫定前提
を置く。
その前提でSAPを設定する。
インターフェースを設計する。
権限を作る。
テストケースを書く。
研修資料を作る。
すると最初は一つだった未決事項が、複数の成果物に埋め込まれていく。
後から判断を変えれば、
設定変更。
開発修正。
データ修正。
IF修正。
Regression Test。
UAT。
手順書修正。
研修修正。
が必要になる。
これがDecision Debtの「利息」である。
100万円の追加開発は100万円ではない
同じことは追加要件にもいえる。
100万円の帳票開発がある。
「100万円なら大した額ではない」
と思うかもしれない。
しかし実際には、
要件定義。
設計。
開発。
単体テスト。
結合テスト。
UAT。
権限。
移送。
操作手順。
運用保守。
将来のUpgrade影響確認。
まで発生する。
つまり、
追加要件の価格 ≠ 開発見積額
である。
見るべきなのはLifecycle Costだ。
そして小さな「合理的な追加」が100個積み重なると、巨大な複雑性になる。
ERPプロジェクトで怖いのは、
一人の人間による巨大な間違いだけではない。
むしろ、
その場では合理的に見える小さな判断を、誰も全体視点から止めなかったこと
なのである。
構造5 Change Surface Explosion
SAPだけを入れ替えるERPプロジェクトは、ほとんど存在しない
「ECCからS/4HANAへ移行する」
というと、システムを一つ交換するように聞こえる。
実際は違う。
変わるのは、
SAP。
マスタデータ。
トランザクションデータ。
インターフェース。
ジョブ。
帳票。
権限。
業務手順。
承認。
内部統制。
ユーザーの役割。
場合によっては物流・製造オペレーションまで含まれる。
本稿では、この同時に変更される範囲を便宜的にChange Surfaceと呼ぶ。
問題は、変更対象が2倍になると難易度も2倍になるとは限らないことだ。
SAPとWMSが相互作用する。
SAPとMESが相互作用する。
SAPと税務システムが相互作用する。
データと権限が相互作用する。
業務プロセスと内部統制が相互作用する。
変更項目間の組み合わせが増える。
だから複雑性は、単純な足し算以上に増えていく。
Revlonは「SAP障害」だけでは説明できない
2018年2月、Revlonは米国で新しいSAP ERPを立ち上げた。
その後、ノースカロライナ州Oxford工場でサービスレベルの混乱が発生した。
Revlon自身のForm 10-Kによれば、このERP導入に関連して、2018年に約6,400万ドルの売上相当の商品を出荷できず、さらに5,360万ドルの追加費用が発生した。
しかし、より重要なのはその先だ。
Revlonは同じ10-Kで、新ERP導入に関連して財務報告に係る内部統制上のMaterial Weaknessを認識している。
具体的には、
ERP導入に伴うリスク評価が十分でなかったこと。
十分な知識・訓練を持つ人員が不足していたこと。
在庫、売掛金、売上、売上原価などに関するプロセスレベルの統制が十分に設計・運用されなかったこと。
などを開示している。
ここが非常に重要である。
ERP切替とは、
ITを変更することではなく、業務と内部統制まで変更すること
なのである。
グリコも「IT障害」という言葉だけでは捉えきれない
2024年4月、江崎グリコは調達・生産・物流・ファイナンスなどの情報を統合する新基幹システムへ全面移行した。
切り替え時のシステム障害によってチルド商品の物流センター出荷に遅滞が発生し、その後段階的に復旧した。
同社は2024年度の有価証券報告書で、客観的な立場の法律事務所などの協力を得て原因究明の調査を行っていると開示している。
したがって、公開情報だけから、
「上流の○○が原因だった」
と断定するべきではない。
ただし、この事例から確実にいえることがある。
ERP障害の影響は、
情報システム部門の中だけでは終わらない
ということだ。
ERPが止まれば、物流が止まり、商品が店頭へ届かなくなる。
まさにBusiness Systemなのである。
SAPプロジェクトの失敗は「最後」に発生するのではない
Go-Live直後に大量障害が起きる。
すると、
「テスト不足だった」
と言われる。
それは正しいかもしれない。
しかし、
なぜテスト不足になったのか
まで掘らなければ再発防止にならない。
仕様確定が遅れたからではないか。
なぜ仕様確定が遅れたのか。
業務判断が終わらなかったからではないか。
なぜ業務判断が終わらなかったのか。
E2E Process Ownerがいなかったからではないか。
なぜProcess Ownerでも判断できなかったのか。
標準化と独自性を判断する経営原則がなかったからではないか。
そう考えると、本番障害は、
何カ月も前に作られた問題の最終症状
である場合がある。
もちろんRevlonやグリコの具体的障害について、この因果鎖がそのまま原因だったと断定しているわけではない。
これは多数のERPプロジェクトを考察するための仮説モデルである。
5つの構造は、こうつながる
私はSAPプロジェクトの失敗を次のように考えている。
成功の定義が曖昧 ↓
何を変えるか決められない
↓
Standardization Paradox ↓
何を標準化し、何を差別化領域として残すか決まらない
↓
Process Ownership Gap / Accountability Gap ↓
誰が業務横断で決めるのか、誰が最終決裁するのか分からない
↓
Decision Debt ↓
未決事項を暫定前提で設計・開発する
↓
Change Surface Explosion ↓
設定・アドオン・IF・データ・権限・統制の依存関係が増大
↓
設計・開発が遅延
↓
SIT・UAT・移行リハーサルの時間が圧縮
↓
Business Readinessが不十分なままGo-Live
↓
障害・手作業・業務停止・期待効果未達として表面化
ここで大事なのは、
テスト不足をテスト工程だけで解決しようとしないこと
だ。
処方箋1 すべての要件を「なぜ必要か」で分類する
現場から要件が出たら、
「できる／できない」
から入らない。
最低でも次の観点で分類する。
法令・税務上、必須なのか。
内部統制上、必須なのか。
企業の競争力・顧客価値につながるのか。
単なる利便性・現行踏襲なのか。
さらに必要なら、
取引先契約。
Global Policy。
Local Requirement。
などを追加する。
この分類を行えば、
「全部重要です」
という要件を減らせる。
そして、
競争力と無関係な業務はSAP標準へ寄せる。
競争力の源泉なら、意図的に差別化する。
という経営判断につなげられる。
処方箋2 Issue LogだけでなくDecision Logを持つ
SAPプロジェクトにはIssue LogやRisk Logがある。
しかし、本当に怖いのは、
問題が起きていることではなく、重要な判断が行われていないこと
である。
だからDecision Logを別管理する。
最低限、
Decision ID。
決めるべき内容。
選択肢。
推奨案。
Decision Owner。
決裁者。
期限。
影響するWorkstream。
期限を超えた場合の影響。
を持たせる。
そしてSteering Committeeでは、
「Open Issueはいくつか」
だけでなく、
「期限超過した重要Decisionはいくつか」
を見る。
さらに一歩進めるなら、
そのDecisionが、
設定。
開発。
データ。
IF。
テスト。
教育。
Cutover。
の何領域へ波及するのかを見る。
影響範囲が大きい判断ほど、先に決めなければならない。
処方箋3 E2E Process OwnerとDesign Authorityを分けて置く
一人に全部背負わせても機能しない。
私は、
Business Processを決める責任
と、
Solution Architectureを守る責任
を分けた方がよいと思う。
E2E Process Ownerは、
Order to Cash。
Procure to Pay。
Record to Report。
などの業務全体について判断する。
Design Authorityは、
SAP標準との整合。
Clean Core。
Integration Architecture。
データモデル。
拡張方式。
などを統制する。
そして両者で意見が割れる大きな論点だけをSteering Committeeへ上げる。
これなら、
業務部門がSAP設計を決める。
SAPコンサルが経営判断を決める。
経営会議が細かな項目レベルの仕様を決める。
という責任の混線を減らせる。