避けたいERPモダナイゼーションの10の間違い

最も痛手になるERPモダナイゼーションの間違いは、技術的なものではなく、戦略的なものです。本稼働をゴールとみなす。レガシーのプロセスを新しいシステムにそのまま写す。データとチェンジの作業を遅く始める。何もかもERPに作り込む。5年間のモデルなしにライセンスに署名する。これらは、リアルタイムではまず表に出ません。本稼働後、約束された効率化が現れず、回避策が戻ってきたときに表面化します。

この記事は、S/4HANAなどのERPモダナイゼーションを計画している、あるいは立て直しているCIO、CFO、プログラムディレクターに向けたものです。以下の間違いはそれぞれ、実際にどう見えるかと対処法を示し、そのあとに1ページの早期警告チェックリストと、2026年のSAPの変更が意味することを置いています。

私は、潤沢な予算と経験豊富なチームと、十分な顔ぶれのアドバイザーを揃えたプロジェクトが、それでも目標に届かないのを見てきました。原因がシステムであることはまれです。互いに依存する決定を下すチームの間で、責任の所在、連携の計画、コミュニケーションに穴があることが原因です。

1. 本稼働をゴールとみなす

システムが稼働すると、多くのチームは、大変な仕事は終わったと考えます。本当のプレッシャーが始まるのは、そこからです。日々の業務、変わり続ける要件、実際のユーザーの行動が、設計に押し寄せます。

本稼働の直後にステアリングコミッティが解散するプロジェクトを見たことがあります。6か月後、定着は横ばいで、バックログを持つ人は誰もいません。

対処：本稼働後6〜12か月のガバナンス期間に予算を確保します。ステアリングコミッティの任期を延長します。稼働時間だけでなく、プロセスの定着を監視します。担当者名を付けた、本稼働後の品質ゲートを設けます。

2. レガシープロセスを見直さずに移行する

承認の連鎖が、そっくりそのまま作り直されるのを見たことがあります。関わる人の半数が、現在のプロセスと無関係だったにもかかわらずです。そのステップがまだ必要なのか、誰も問うていませんでした。結果は、古いワークフローを動かす最新のERPでした。すでに持っていたものの、より高価なバージョンです。

S/4HANAでの例はこうです。ECCから、カスタムのバッチジョブをそのまま移し、もはや存在しないテーブル構造の上に作られている。移行は技術的にはきれいです。ビジネスロジックが壊れています。

対処：構築の前にプロセスを再設計します。オペレーション、財務、デリバリーの各チームと、各ワークフローを一緒にたどり、あらゆるステップを問い直します。

レガシーの領域	よくある失敗	代わりにすること
ECCのカスタムコード	使われていないカスタムコードがS/4HANAに持ち込まれる	使用状況の分析とSAPのカスタムコードチェックを実行し、未使用のコードを廃止する
古いワークフロー	自動化できるようになったのに、承認フローが作り直される	ビジネスオーナーと見直し、標準のFioriアプリやSAP Build Process Automationを使う
標準外のマスタデータ	柔軟なレガシーの設定が、S/4HANAの検証を通らない	移行前にクレンジングと統一を行う。適する場合はSAP MDGを使う
レガシーテーブルを使うレポート	テーブルへの直接アクセスが、S/4HANAのデータモデルと合わない	CDSビューで作り直す
隠れた手作業の回避策	本稼働後に、サイドプロセスが再び現れる	移行前にプロセスマイニングを使い、穴をデジタル化する

3. データ移行の開始が遅すぎる

不良データを新しいERPに移すのは、何も捨てずに引っ越すようなものです。がらくたも一緒についてきて、構造化されたシステムの中に入ってしまうと、片づけはさらに難しくなります。

以前、中核のデータセットに、それぞれ独自のコード体系を持つ5つの異なる事業部のエントリが混在していることに誰も気づかず、本稼働が失敗したのを見たことがあります。技術的な移行は正しく行われました。データが使い物にならなかったのです。レポートは壊れ、ユーザーは信頼を失い、稼働中のシステムでのクリーンアップには数か月かかりました。

対処：データを、ビジネス側が責任を持つワークストリームにします。技術コンサルタントだけでなく、プロセスオーナーを割り当てます。移行を始める前に、何を持ち込み、何をアーカイブし、何を作り直すかを決めます。少なくとも2回の完全なモックロードを実施し、ロード順の依存関係マップと、ロードごとの定義済みのロールバックを用意します。SAPのデータ移行が失敗する理由の記事で、さらに掘り下げています。

4. チェンジマネジメントを付随的なタスクとして扱う

よくあるパターンはこうです。チェンジマネジメントは「すでに対応済み」で、それは数枚のスライド、デモ、本稼働前の1回のトレーニングを意味します。

人が抵抗するのは、変化が嫌いだからではありません。なぜ変わるのか、それが自分にどう役立つのかを、誰も説明しないときに抵抗するのです。チェックリストを通す程度にしかシステムに従わず、そのあとスプレッドシートに戻ります。

引き金になるのは、たいていスケジュールのプレッシャーです。時間を取り戻すためにトレーニングが圧縮され、本稼働時にユーザーが圧倒され、追加のハイパーケアのコストが、削ったトレーニングよりも高くつきます。

対処：チェンジマネジメントに、独自の予算、タイムライン、シニアのオーナーを最初から与えます。役割を早期にマッピングし、現場のチャンピオンを見つけ、技術マイルストーンと並べて定着のKPIを追跡します。チェンジマネジメント計画のガイドで、その構成を示しています。

5. ベンダーのロードマップを前提に計画する

ベンダーの将来のリリースを前提に連携戦略を立てたところ、それが12か月延期されたのを見たことがあります。その間、チームは一時的な回避策を作るしかなく、その回避策が恒久化しました。

ベンダーは、幅広い顧客層向けにロードマップを作ります。あなたのビジネスが、その設計の中心になることはまれです。

対処：ロードマップは、入力の1つとして扱います。今日、一般提供されているものを前提に設計し、計画に組み込む前に新機能をサンドボックスでテストし、ロードマップ上の便益は予算ではなく上振れとして数えます。

6. レガシーシステムの廃止計画がない

年に2回レポートを引き出すだけの6人のユーザーのために、古いシステムを動かし続けるのに年間6桁ドルの費用を払っている企業を見たことがあります。誰も廃止計画を立てていませんでした。

対処：プロジェクトチャーターに、初日から廃止を盛り込みます。ITだけでなく、法務、コンプライアンス、データガバナンスも関与させます。保持期間とアーカイブの方針を本稼働前に合意し、旧システムへのインターフェースをすべてマッピングして切り離し、停止する役割を1つのチームに与えます。

7. 連携の複雑さを過小評価する

連携が失敗したとき、ビジネスはITより先に気づきます。ワークフローがテスト環境ではなく、本番の途中で止まるからです。

よくあるパターンはこうです。ITとビジネスが、それぞれ、相手が連携の要件を定義していると思い込んでいる。どちらも定義していない。穴がテストで見つかるころには、再設計する時間がありません。

対処：ブループリントの段階で連携設計を始めます。シナリオ、ミドルウェア、マッピング、メッセージ量をそれぞれ定義し、インターフェースごとにリアルタイムかバッチかをビジネスと明確にします。本稼働前に、SLA付きのインターフェースオーナーを指名します。新規のSAPプログラムでは、ミドルウェアはSAP Integration Suiteです。SAP PI/POは、2027年末にメインストリームメンテナンスから外れます。

8. ERPなら何でもできると思い込む

私は、複雑なサービスのワークフロー（ITチケット、資産申請、エスカレーションのルーティング）を、ServiceNowのような外部システムを巻き込みたくないという理由で、ERPに無理やり押し込んだプロジェクトに携わったことがあります。結果は、あちこちにカスタム項目があり、手作業の回避策があふれ、まったく合わないプロセスに閉じ込められたユーザーでした。

ERPが得意なのは、構造化された、トランザクション型の、財務に紐づくプロセスです。ITサービスリクエスト、ワークフローのオーケストレーション、ナレッジ管理は、専用のプラットフォームのほうが優れています。

対処：ERPに何を作らないかを、意図的に決めます。例外にはSAP BTPのサイドバイサイド拡張を使い、トランザクションの中核の外にあるオーケストレーションには、ServiceNowなどを使います。この切り分けは、SAPとServiceNowによるERPモダナイゼーションの記事で取り上げています。

9. 長期のライセンスコストを過小評価する

単一の機能のために上位のライセンスが必要になり、2年目にライセンス費用が倍になったチームを知っています。ビジネスケースは、本稼働時のコストしかモデル化していませんでした。

ERPのライセンスは、ユーザー、モジュール、トランザクション、API使用量に課金され、計画していたかどうかにかかわらず、コストはビジネスとともに増えます。SAPでは、デジタルアクセスのモデルにより、サードパーティのシステムが作成したドキュメントに、当初の商業モデルになかったライセンスコストが生じることがあります。RISEとSAP GROWでは、フルユーザー換算（FUE）の数が、利用の拡大とともに増えます。

対処：署名の前に、3〜5年のライセンスモデルを作ります。役割をライセンスタイプにマッピングし、現実的な定着曲線に基づいてFUEの伸びをモデル化し、外部システムをつなぐ前に間接アクセスを理解し、本稼働後に非アクティブなユーザーを監査します。

10. ERPをITプロジェクトとして扱う

最もよくあり、最も被害の大きいパターンです。計画はITで始まり、ITが主導し、ITの問題を解決します。

私は、書類の上ではすべてのマイルストーンを達成しているのに、それでもビジネス側は、なぜ何も良くなった気がしないのかと尋ねているチームを見てきました。たいていは、オペレーション、財務、営業の責任者を設計に入れないまま、ERPが昨日のプロセスのために作られたことを意味します。

対処：営業、財務、オペレーションの責任者を、最初からステアリングコミッティに入れます。技術的なスコープだけでなく、戦略との整合をチャーターに明記します。設計が始まる前に、プログラムの目標を、取締役会レベルの成果に照らして検証します。

ステアリングコミッティのたびに使ってください。警告サインがあれば、解消されるまで、指名されたオーナーがそれについて報告します。

1. プロジェクト憲章責任と費用オペレーションや財務のリードがおらず、五年間のライセンスモデルも、廃止日もない
2. ブループリントプロセスと連携の設計現在のプロセスの写しで、インターフェースは未設計のまま
3. 最初のモックロードデータデータ品質レポートがまだない
4. 本稼働その後に起きることその後の12か月分のガバナンスに予算がない

間違い	早期警告サイン	オーナー
1. 本稼働をゴールとみなす	本稼働後12か月分のガバナンス計画に予算がない	スポンサー
2. レガシープロセスの引き写し	設計ワークショップが「現在のやり方」の画面から始まる	プロセスオーナー
3. データ対応の遅れ	最初のモックロードの前に、データ品質レポートがない	データ移行リード
4. チェンジを付随的なタスクにする	チェンジ計画がトレーニングのカレンダーにすぎない	チェンジリード
5. ロードマップへの依存	設計上の決定が、未リリースの機能を待っている	ソリューションアーキテクト
6. 廃止計画がない	チャーターに、どのレガシーシステムの廃止日もない	PMO
7. 連携の過小評価	ブループリントの終了時点でインターフェースが未設計	連携リード
8. ERPに何でも載せる	トランザクション型でないワークフローのためのカスタムオブジェクト	エンタープライズアーキテクト
9. ライセンス	ビジネスケースに5年間のライセンスモデルがない	CFO
10. ITだけのプログラム	ステアリングコミッティにオペレーションや財務のリードがいない	スポンサー

デプロイメント：新規のSAPプログラムでは、既定はSAP Cloud ERP Private上のRISE with SAP、または中堅企業向けにはパブリックエディション（SAP Cloud ERP）上のSAP GROWです。新規のオンプレミス導入はまれです。ECCのお客様は、メインストリームメンテナンスの2027年12月31日終了に直面しており、間違い2、3、7を直すための時間が短くなります。

クリーンコア：SAPは現在、拡張を4つのクリーンコアレベルで評価しています。A（公開済みのAPIのみ。BTP上のサイドバイサイド、またはABAP Cloudによるシステム内）からD（クリーンではない）までです。パブリックエディションが許すのはレベルAのみで、それが間違い2の背景にある議論を迫ります。プライベートエディションでは従来型の拡張が引き続き許されるため、規律はガバナンスから生まれなければなりません。従来型のカスタムコードこそが、あらゆるアップグレードをプロジェクトにしてしまう原因です。私のクリーンコア戦略の記事で、さらに踏み込んでいます。

デリバリーツールにおけるAI：JouleはSAP Cloud ALMとSAP Activate Roadmap Viewerに搭載され、SAP Build CodeはJouleを拡張開発に使います。AIツールがパートナーの料金表にどう反映されているかを尋ねてください。反映されていなければ、価格が高いか、削減分がパートナーの利益になっているかのどちらかです。

ライフサイクルツール：SAP Cloud ALMは、クラウドプログラム向けのライフサイクル管理ツールです。Solution Manager 7.2は2027年末でメインストリームメンテナンスから外れるため、両方を運用している環境は、移行の計画が必要です。

10の間違いは変わっていません。間違えたときのコストが変わったのです。RISEのプログラムでは、クリーンコアの判断、デプロイメントモデル、FUEモデルは、すべて動員の最初の数週間で決まります。影響を及ぼせる時間は短いのです。

ERPモダナイゼーションの取り組みが、本稼働後に期待に届かないのはなぜですか？

ほとんどのチームは、本稼働までを計画して、そこで止まります。拡張、フィードバック、プロセスの修正、バックログを、誰も担当していません。本稼働でステアリングコミッティが解散するのは、問題を示す最も確実なサインです。初日から、本稼働後6〜12か月のガバナンスに予算を確保してください。

レガシーのプロセスを新しいERPに写すリスクは何ですか？

新しいシステムが、古い非効率を、より高いコストで引き継ぎます。特にS/4HANAへの移行では、ECCのテーブル向けに作られたカスタムコードやバッチジョブが動かないことが多く、移行は技術的にはきれいでも、ビジネスロジックが壊れることがあります。

データ品質の低さは、ERPモダナイゼーションをどう損ないますか？

重複する仕入先、一貫性のないマスタデータ、レガシーのコード、不完全なレコードは、誰かが先に整理しない限り、すべて新しいシステムに持ち込まれます。レポートは壊れ、ユーザーは数字を信頼しなくなり、稼働中のシステムでのクリーンアップには数か月かかります。

ERPプロジェクトでチェンジマネジメントが過小評価されやすいのはなぜですか？

コンフィグレーションのようには、プロジェクト計画の上で目に見えないからです。経営層は、数回のトレーニングで十分だと思い込みます。チェンジマネジメントとは、本稼働の前に、日々の仕事の中で実際に何が変わるのかを人々に備えてもらうことです。現在はSAPの傘下にあるWalkMeのようなデジタルアダプションツールは、アプリ内のガイダンスに役立ちますが、なぜ変えるのかという説明の代わりにはなりません。

ERPの本稼働から何年も経つのに、レガシーシステムが動き続けるのはなぜですか？

停止する計画を誰も立てていないからです。全員が新しいERPの稼働に集中し、古いシステムは、コンプライアンス、参照、あるいは安心のために残り続けます。廃止は、法務とコンプライアンスを巻き込んで、初日からスコープに入れる必要があります。

RISE with SAPとクリーンコアは、これらの間違いをどう変えますか？

パブリックエディションでは、クリーンコアのルールが深いカスタマイズを不可能にし、間違い2の背景にあるプロセスの議論を迫ります。プライベートエディションでは従来型の拡張が引き続き許されるため、クリーンコアはガバナンス次第です。PI/POのメンテナンス終了に伴い、連携はSAP Integration Suiteに移ります。ライセンスは、FUEの伸びの問題になります。廃止は、より緊急になります。複数年のサブスクリプションに加えて、レガシーシステムを並行稼働させるとコストが上乗せされるからです。