SAPプロジェクトの立て直し：軌道を外れたプログラムを救う

SAPプロジェクトの立て直しとは、軌道を外れた移行や導入をいったん止め、その本当の姿を突き止め、その事実から計画を立て直すことです。うまくいくかどうかは最初の1週間で決まります。プログラムのステータスを評価し、設計をレビューし、システムに実際に導入されているものを評価します。

結論から言えば、この3つのチェックが互いに一致し、計画とも一致するなら、そのプログラムに必要なのは救済ではなく後押しです。一致しないなら、現在の計画にどれだけ労力を足しても直りません。新しいベースラインを伴う正式な立て直しが必要です。

この記事は、その診断と、その後に続くことについて書いています。アプローチ、スケジュール、期限を扱った私のECCからS/4HANAへの移行ガイドを構成する記事の一つです。ここでの問いはもっと絞られています。プログラムが困難に陥っている。では、どうするか、です。

遅れているプログラムの多くは、救済を必要としていません。必要なのは、より速い意思決定、キーユーザーの手を空けること、あるいはベンダーに期日を守らせることです。それが後押しです。

救済は別物です。その兆候は、私が最初の1週間に行う同じ3つのチェックから出てきます。シグナルは単純です。ステータス、設計、導入されているものが、互いに、あるいは計画と一致しないのです。

私なら救済のシグナルとして扱うパターンをいくつか挙げます。

1. ステータスは緑なのに、システムはそうではない。 報告では構築の大半が完了していることになっているのに、テストシステムでは基本的な受注から入金までのプロセスすら動かない。
2. 設計は承認済みなのに、構築がそれを無視している。 設定が、承認された設計ではなくワークショップのメモに基づいて行われている。
3. 計画に本稼働日はあるのに、そこへの道筋を誰も説明できない。 テスト、データロード、カットオーバーのリハーサルに現実的な枠がない。
4. スコープが増える一方である。 WRICEFリスト（レポート、インターフェース、コンバージョン、拡張機能、フォーム、ワークフロー）が、Exploreフェーズをとうに過ぎてもまだ増えている。

どれか1つなら、後押しで直せます。2つ以上が同時に起きていれば、たいてい直せません。

最初の1週間は、何が事実かを突き止めるためのものです。直すためでも、責めるためでも、新しい計画を書くためでもありません。私は3つのことを、ステータス、設計、実際に導入されているものの順で評価します。

各チェックの対象と、食い違いが何を意味するかは次のとおりです。

チェック	私が見るもの	答える問い	ほかと食い違う場合
プログラムのステータス	計画、ステータス報告、RAIDログ、未処理の変更要求、予算に対する支出	プログラムは自らをどう認識しているか	報告が楽観的か、デリバリーと切り離されている
設計	業務プロセスの設計、Fit-to-Standardの成果物、WRICEFリスト、未決の設計判断	業務部門に何が約束されたか	構築が合意内容からずれているか、設計が完成していなかった
導入されているもの	開発・テストシステム、設定、移送、カスタムコード、これまでのデータロード	今日、実際に何が存在しているか	システムにない作業について進捗が報告されている

ほとんどのレビューが飛ばすのが3つ目のチェックです。システムについての文書を読むのではなく、システムの前に座ってプロセスを実行することを意味します。

ステータス報告と設計書は主張です。システムは証拠です。

チェックを誰が行うべきか

ステータス報告を書いた人が、それを検証する人であってはなりません。非難しているのではありません。監査人が自分の仕事を監査しないのと同じ理由です。

私なら、導入パートナーから独立した人に最初の1週間を任せ、システムへの完全なアクセス権と、プログラムの誰とでも話せる権限を与えます。それが無理なら、少なくともパートナーに、導入済みのシステムをスライドではなく実機で見せてもらってください。

2018年、私は航空業界のあるプログラムの立て直しに携わりました。モジュールは導入されていましたが、業務要件に基づく設定は何一つ行われていませんでした。

最初の1週間の3つのチェックは、まさにこうした状況を明らかにするためにあります。導入されたモジュールは、機能する設計と同じではありません。その違いは、システムの中を見て初めて分かります。

航空会社では整備、調達、財務が密接に結びついているので、一つの領域の穴がほかへ波及します。SAPがこの業界にどう合うかは、私の航空業界向けSAPのページで扱っています。

私が主導または立て直した21のSAPプログラムを通じて、私が見る最大の誤りは、導入の開始時にきちんと計画しないことです。救済とは多くの場合、欠けていた計画を、遅れて、しかも重圧の中で行うことです。

ほかに繰り返し現れる原因が2つあります。

1. ベンダーがスコープを握っている。 システムインテグレーターがスコープを書くと、それはインテグレーターが提供するつもりのものを記述したものになります。穴は後から変更要求としてやってきて、同じベンダーが値段を付けます。
2. カスタムコードが超過する。 私の経験では、カスタムコードは移行で最も超過しやすいフェーズであり、最も見落とされやすい隠れたコストでもあります。

予算面、つまりなぜExploreフェーズでコストが跳ね上がるのかは、私の記事SAPプロジェクトが予算を超過する理由で扱っています。ここでは繰り返しません。

もう一つの共通点は、管理の弱さです。プログラムに、追跡、エスカレーション、変更管理の週次のリズムが一度もなかったなら、救済でそれを導入しなければなりません。私のSAPプロジェクトの計画と管理のガイドでは、そのサイクルを担当者とともに示しています。

何が事実かが分かれば、立て直しには明確な順序があります。手順を飛ばすと、たいてい救済を二度やることになります。

SAPプログラムの立て直しの順序

1. 01

   診断

   ステータス、設計、導入されているものを互いに照合する。

2. 02

   スコープを取り戻す

   顧客が握るスコープを凍結し、すべての変更に値段を付ける。

3. 03

   ベースラインの再設定

   根拠に基づく新しい計画を1つ作り、予備費は自社側で持つ。

4. 04

   フェーズにゲートを置く

   残りの各フェーズの終わりに品質ゲートを置く。

5. 05

   リハーサルとカットオーバー

   本稼働日を確定する前に完全なリハーサルを行う。

1. スコープの主導権を取り戻す

誰かが計画を立て直す前に、誰がスコープを握るかを決めてください。答えがまだベンダーなら、新しい計画も古い計画と同じように失敗します。

スコープを顧客側で書き、導入されているものと比較し、凍結してください。それ以降、変更はすべて、担当者が付いた値段のある判断になります。

2. ベースラインの再設定は根拠に基づいて一度だけ

立て直しで設定する新しいベースラインは1つです。小さな遅延の積み重ねではありません。古い計画が期待していたことではなく、システムが示すことから作ってください。

まずカスタムコードを見積もり直してください。超過が最も多く生じるのはそこだからです。次にデータです。データ移行は工数の30から40%を占め、困難に陥ったプログラムではたいてい遅れています。

10から20%の予備費を自社側で確保し、特定されたリスクに対してのみ使ってください。数字を左右する要因は、姉妹記事のS/4HANA移行のコストで説明しています。

3. 各フェーズの終わりに品質ゲートを置く

困難に陥ったプログラムは、たいてい根拠ではなく日付でフェーズからフェーズへと進んできています。それを正してください。

SAP Activateでは、ExploreフェーズでFit-to-Standardワークショップを行い、承認された差分要件はRealizeに向けてプロダクトバックログに入ります。設計が完成しないままExploreを出たのなら、戻って完成させてください。SAP Cloud ALMはチェックリスト付きのチェックポイントとしての品質ゲートに対応しており、プロジェクトの概要画面に表示されるので、ゲートをスプレッドシートで管理する必要はありません。

4. 日付を約束する前にリハーサルする

ブラウンフィールドのコンバージョンでは、カットオーバー前に3回の模擬コンバージョンを計画します。困難に陥ったプログラムは時間節約のためにリハーサルを削りがちで、それはリスクを本稼働の週末へ移すだけです。

私が見てきたカットオーバーのダウンタイムは、週末1回から1週間までです。救済されたプログラムは、その数字を見積もりではなくリハーサルから知っているべきです。

5. 本当に守るべき期限を確認する

エンハンスメントパッケージ6から8のSAP ERP 6.0では、メインストリームメンテナンスが2027年12月31日に終了し、2ポイントの追加料金で2030年末までのオプションの延長メンテナンスを受けられます（SAP News）。立て直しによってECC移行が2027年を越えるなら、延長メンテナンスを堂々と予算に入れるべきです。

2027年という日付に押されて、リハーサルが裏付けていない本稼働をしないでください。本稼働が遅れれば保守料がかかります。本稼働に失敗すれば、はるかに大きな代償を払います。

救済では、現在のシステムインテグレーターを続けるかどうかという問いがよく持ち上がります。パートナーを替えるのが正しいこともあります。しかし多くの場合、より大きな問題はプログラムの立ち上げ方にあり、新しいパートナーはそれを引き継ぐだけです。

判断する前に、私なら次の質問をします。

1. 導入済みのシステムを、承認された設計と照らし合わせて実機で見せてもらえるか。 デモ環境でもスライドでもなく。
2. どのWRICEFオブジェクトが構築、テスト、移送まで済んでいて、どれが完了と報告されているだけなのか。
3. 完了までのハイレベル設計はどうなっているか。当社と似たプログラムを立て直した事例で、連絡できるものはどれか。 事例とハイレベル設計は、署名前に私がどのパートナーにも求める2つのものです。
4. 当社から必要なのに得られていないものは何か。 決まっていない判断と兼務のキーユーザーが、話の半分を占めることはよくあります。
5. RISE with SAPの顧客の場合：パートナーではなくSAP側にある問題はどれで、誰がエスカレーションするのか。

危険信号は、選定時に私がパートナーを見送る理由と同じです。一般論の回答です。立て直し計画がどの企業にも当てはまるなら、それは自社のために書かれたものではありません。選定の側面は、私のS/4HANA移行パートナーの選び方のガイドで扱っています。

プログラムでソースシステムのきちんとしたアセスメントを一度も行っていないなら、今行ってください。SAP Readiness Checkは既存システムを分析するもので、SAPは実際の使用状況を正確に把握するために本番環境で実行することを推奨しています。それが何を見落とすか、まずカスタムオブジェクトについては、私のSAP Readiness Checkと移行アセスメントの記事で説明しています。

プログラムディレクターとSAPの責任者と半日の時間を取り、3つのものを並べて見せてもらってください。最新のステータス報告、承認された設計、そして1つの業務プロセスを最初から最後まで実行しているテストシステムです。3つが同じことを語っていれば、後押しです。そうでなければ、次のステアリングコミッティの前に正式な立て直しを始めてください。

軌道を外れたプログラムについて独立した視点が必要でしたら、私はまさにこうした診断を支援しています。こちらから面談をご予約ください。

SAPプロジェクトの立て直しとは何ですか？

SAPプロジェクトの立て直しとは、軌道を外れたSAPの導入や移行を再び管理下に戻す作業です。プログラムのステータス、設計、実際に導入されているものの診断から始め、スコープの主導権を取り戻し、新しいベースラインを1つ設定し、残りのフェーズに品質ゲートを加えます。

SAPプロジェクトに救済が必要かどうかは、どうすれば分かりますか？

3つのものを比べてください。ステータス報告の内容、承認された設計の内容、そしてシステムに実際に導入されているものです。それらが互いに一致し、計画とも一致するなら、プログラムに必要なのは後押しです。一致しないなら、現在の計画にさらに労力を注いでも直らず、正式な立て直しが必要です。

SAP導入の立て直しの最初の1週間には何をすべきですか？

診断だけです。プログラムのステータスを評価し、設計をレビューし、実際に導入されているものを評価します。理想的には、導入パートナーから独立した人が主導します。この3つのチェックが終わるまで、新しい計画は書かないでください。

立て直しの間にSAP導入パートナーを替えるべきですか？

自動的に替えるべきではありません。パートナーに、導入済みのシステムを承認された設計と照らし合わせて見せてもらい、類似の立て直しの事例を添えた完了までのハイレベル設計を出してもらってください。

回答が一般論なら、替えるべきだという強いシグナルです。本当の問題がスコープの主導権や自社側の決まっていない判断にあるなら、新しいパートナーはそれを引き継ぐだけです。

SAP S/4HANA移行はなぜ軌道を外れるのですか？

私が見る最も多い根本原因は、導入の開始時にきちんと計画しないことです。ベンダーにスコープを握らせることもその一つで、最も超過しやすいフェーズはカスタムコードです。工数の30から40%を占めるデータ移行も、たいてい遅れています。

立て直しによってECC移行は2027年の期限を越えてしまいますか？

その可能性はあります。エンハンスメントパッケージ6から8のSAP ERP 6.0のメインストリームメンテナンスは2027年12月31日に終了し、オプションの延長メンテナンスは2ポイントの追加料金で2030年末まで続きます。リハーサルが裏付けていない本稼働を強行するのではなく、延長メンテナンスを予算に入れてください。