SAPプロジェクトの計画と統制：軌道を保つために

SAPプログラムの多くには、計画があります。統制があるものは、はるかに少なくなります。計画は、スコープ、スケジュール、予算、リスクを定めます。統制は、その計画に対する進捗を追い、依存関係を管理し、早い段階でエスカレーションし、承認の前にすべての変更を評価する、毎週の仕事です。このガイドは、SAPプログラムが当初の軌道から外れつつある、あるいは外れないようにしたい、プログラムディレクター、PMO、スポンサーの方に向けたものです。統制とはどういうものか、それがないと何が起こるかを示す公開された3つの失敗事例、そして今週から取り入れられる、担当者付きの週次の統制サイクルを取り上げます。

駆け出しの頃、紙の上では見事に見えるSAPプログラムに関わりました。スケジュール、リスク登録簿、変更ログと、期待されるものはすべてそろっていました。誰もそれに従いませんでした。ステアリングコミッティは、ほとんど開かれませんでした。財務はデータ移行を待っていました。ITはまだ着手していませんでした。誰も依存関係を追っていませんでした。誰もが、ほかの誰かが軌道を保ってくれていると思い込んでいました。

6か月目には、プロジェクトの半分が遅れ、私たちは自分たちの失敗を追いかけていました。最悪だったのは、誰もそれを予期していなかったことです。

計画の問題ではありませんでした。統制の問題でした。実効性のあるリソース配分も、適切なリスク軽減も、エスカレーションの経路もありませんでした。計画は一度作られただけで、会議に取って代わられ、放置されたのです。

計画が扱うのは、スコープ、スケジュール、予算、リソース、リスク登録簿、マイルストーンの約束事です。たいていのチームは、これを作ります。問題は、それを週ごとに誰かが使っているかどうかです。

統制が扱うのは、計画に対する実際の進捗の追跡、差異の早期の顕在化、依存関係の管理、遅れが出たときのエスカレーション、スコープやスケジュールが正式に変わったときのベースラインの見直しです。たいていのチームは、これが苦手です。

1. 01進捗を追うワークパッケージごとの、計画に対する実績
2. 02差異を顕在化する三日遅れたタスクはすべて
3. 03依存関係を確認するこれが遅れると誰が止まるか
4. 04エスカレーションする事前に合意した経路で
5. 05変更を評価するまず時間、コスト、リソース
6. 06ベースラインを見直す正式な変更の後にのみ

毎週、担当者を明記して

統制がないと、何が壊れるかを次に示します。

統制がないと壊れるもの	理由
納期が静かに遅れる	マイルストーンのレビューの合間に、誰も確認しない
前提が検証されないまま残る	各チームが、依存関係は別のチームが対応すると思っている
スコープが非公式に拡大する	影響評価なしに、会議の場で変更が承認される
リスクが現実になるまで放置される	リスクログの更新が、毎週ではなく四半期に一度
コストが予算を超える	工数はタイムシートにあるが、ワークパッケージに対応付けられていない
チームが連絡を取り合わなくなる	状況報告の会議が、アクションのない報告会になる

これらは、クライアントの話ではなく、公開された事例です。その根本原因は、アドバイザリーの仕事で私が繰り返し目にするものです。

Lidl：約7年、推定5億ユーロをかけて、中止に

Lidlは2011年に、SAP Retail上でeLWISプロジェクトを始めました。Lidlの在庫評価の実務は、SAPの標準モデルと異なっており、Lidlは実務ではなくソフトウェアのほうを合わせる道を選びました。2018年までに、システムはオーストリア、北アイルランド、米国で稼働していましたが、取締役会は、当初の目標は妥当なコストでは達成できないと結論づけました。Lidlはプロジェクトを中止し、自社システムの開発に戻りました。専門メディアは、支出を約5億ユーロと推定しており、IT担当の取締役は2017年に退任していました。Heiseがこの決定を報じたのは、2018年7月です。教訓は、レガシーな実務を守るために何年もカスタマイズを重ねるのは、ソフトウェアの失敗ではなく、統制の失敗だということです。

Hershey：約1億ドル分のハロウィーン向け注文が届かず

Hersheyの新しいSAP、Siebel、Manugisticsのシステムは、菓子の閑散期である1999年4月に本稼働する計画でした。それが3か月遅れ、ハロウィーンの注文が入り始める7月に本稼働しました。注文は、システムから倉庫へ流れませんでした。CEOはアナリストに対し、この問題のために、ハロウィーン向けの約1億ドル分の製品を届けられなくなると説明し、第3四半期の売上高は12.4%減少しました。CIO誌の記事は、本当の失敗はタイミングにあったとしています。繁忙期を守るスケジュールの統制があれば、本稼働の日付は別のものになっていたはずです。

Revlon：工場の混乱と、内部統制の重大な欠陥

Revlonは2018年2月、最大の製造拠点であるノースカロライナ州オックスフォードの工場で、SAPを稼働させました。サービスの混乱は、製造と、米国の大手小売業者への出荷に及びました。2019年3月、Revlonは、この展開に関連する内部統制の重大な欠陥を開示し、効果的な継続的リスク評価がなかったこと、影響を受けた業務に教育を受けた人員が少なすぎたことを理由に挙げました。投資家が訴訟を起こし、TechTargetがその訴訟を報じています。訴状は、約6,400万ドル分の出荷が履行されなかったと主張しました。

これらのどれも、SAPが誤った選択だったから失敗したのではありません。何十年も前から存在する、計画と統制の基本で失敗したのです。

作業分解構造

作業分解構造（WBS）は、全体のスコープを、明確な担当者を持つ成果物に分解します。これがなければ、作業は遅れるまで見えません。SAPプログラムでは、プロセス設計、コンフィギュレーション、データ移行、連携、テスト、教育、カットオーバーを対象とし、それぞれを、担当者と期日を持つタスクにまで分解します。

価値は、文書そのものにはありません。何が起こる必要があるのか、誰がやるのか、何に依存するのかという会話を、強制的に起こさせることにあります。プロジェクトを殺すのは、依存関係です。データ移行が遅れると、結合テストが止まります。それがUATを止め、カットオーバーの枠を圧迫します。WBSは、その連鎖を見えるようにします。

スケジュール管理

スケジュールが崩れる理由は、予測できるものです。人がほかの仕事に引き抜かれます。見積りが誤っていました。意思決定が、計画より長くかかります。コンティンジェンシーは、初日から、必要になる可能性が最も高いタスクの隣に、明示的なバッファとして組み込みます。あらゆる箇所に薄く上乗せするのではありません。

スケジュールは毎週追います。4週目の1週間の遅れは、話し合えば済みます。16週目の4週間の遅れは、危機です。同じ問題でも、直すコストは大きく違います。

本稼働のタイミングは、独立した意思決定として扱います。事業の繁忙期に向けて本稼働してはいけません。Hersheyの教訓は、すべての企業に当てはまります。

予算管理

予算が崩れる理由は3つあります。管理されないスコープ変更、過小に見積もられたデータ移行、当初の見積りを超えるハイパーケアのコストです。1週目から、計画に対する実際の支出を追ってください。差異がステアリングコミッティに届く頃には、たいてい、混乱なしに修正するには手遅れです。

変更管理は、予算を守る主な手段です。すべてのスコープ変更は、承認の前に、時間、コスト、リソースへの影響評価を受けます。評価が承認の後に来るなら、その変更は予算を迂回したことになります。変更管理委員会については、SAP導入でスコープクリープを避ける方法のガイドで詳しく扱っています。

リスク管理

四半期ごとにしか更新しないリスク登録簿は、形だけのものです。リスクには、毎週のレビュー、担当者の明記、対応計画が必要です。どのSAPプログラムでも、次の項目を明示してください。データ品質の問題が遅れて見つかること、連携の遅延、リソースを確保できない空白期間、カットオーバーの枠の圧縮、ユーザーへの定着の不足です。

あるクライアントは、データ移行ベンダーが納期を何度も破り、3か月を失いました。私たちは「あと2週間だけ」と聞かされ続け、予算を吹き飛ばさずにベンダーを替えるには手遅れになりました。担当者とトリガー日を持つリスクがあれば、その判断を何か月も前に迫れたはずです。SAPリスク評価マトリクスでは、こうしたリスクを採点し、担当者を割り当てるテンプレートを紹介しています。

コミュニケーションとエスカレーション

経営層に必要なのは、見出しです。デリバリーチームに必要なのは、具体的な内容です。プロジェクトマネージャーに必要なのは、差異のデータです。全員に同じ報告を1本出しても、誰の役にも立ちません。

エスカレーションの経路は、危機が来る前に文書化し、リハーサルしておきます。あるSAP導入では、ITは財務がコンフィギュレーションをレビューしていると思い込み、財務はITがレビューしていると思い込んでいました。本稼働が3か月先に迫り、重要な承認が欠けている状態になるまで、誰も声を上げませんでした。対応は、土壇場の大慌て、追加コスト、展開の遅れになりました。別の会社は、正しく運用していました。報告が構造化され、アクションに結び付いていたため、問題が起きたときには、誰が担当し、影響は何か、どう解決するのかを全員が把握していました。

エスカレーションが本領を発揮するのは、スコープです。私は、単純な予約システムの改修から始めた航空会社と仕事をしました。6か月たつ頃には、ロイヤルティの変更、乗務員のスケジューリング、財務モジュールが加わっていました。どれも緊急ではありませんでした。誰もノーと言いませんでした。スケジュールは2倍になり、コストは70%上がりました。

オンプレミス時代のやり方は、RISE with SAPのもとでは、そのままでは通用しません。違いは3つあります。

RISEが変えるのは、エスカレーション先です

RISE with SAPでは、SAPがインフラと技術運用を担い、定着状況を追うカスタマーサクセスチームを提供します。統制の体制には、彼らを含めなければなりません。プラットフォームの問題（システムのパフォーマンス、ハイパースケーラーのリージョン、SAPのサービスレベル）については、プログラムマネージャーが、導入パートナーを経由しない、SAPへの文書化されたエスカレーション経路を持つ必要があります。必要になる前に、書き出しておいてください。

クリーンコアは、スコープ管理に技術面の裏付けを与えます

すべてのギャップについて、今や判断が必要です。コンフィギュレーションで対応するか、公開済みのAPI経由で拡張するか（ABAP Cloudによるオンスタック、またはSAP BTP上のサイドバイサイド）、却下するかです。S/4HANA Cloud Public Editionでは、コアの修正という選択肢はありません。プライベートエディションとオンプレミスでは可能ですが、SAPのクリーンコアのガイダンスは、これを最後の手段と位置づけています。修正を加えるたびに、アップグレードの作業が増えるからです。

これは、スコープの管理に役立ちます。「標準のオーダー・トゥ・キャッシュのプロセスを、ちょっと手直しするだけ」という依頼は、気軽な設定の相談ではなくなり、設計、構築、テストの工数を伴う拡張になります。ステアリングコミッティの下に、承認または却下の権限を持つアーキテクトを1人置いた、小さな拡張レビューの場を設けてください。それがなければ、カスタマイズをめぐるあらゆる議論が、ステアリングに持ち込まれます。

AIが報告書の下書きを作り、判断は人が下します

AIは今や、統制に伴う書類作業を手伝ってくれます。SAPのアプリケーションライフサイクルツールであるSAP Cloud ALMは、プロジェクトのタスク、要件、テストの状況を保持し、ワークショップの議事録から要件のドラフトを生成できます。Microsoft Copilotは、ダッシュボードとステータスレポートから、ステアリング資料向けの差異のサマリーを下書きします。Power BIやSAP Analytics Cloudの異常検知は、通常のパターンから外れたKPIを知らせます。これは、リソースの使用状況、変更要求の件数、サポートチケットには有用ですが、自然に上下する指標にはあまり向きません。

AIがしないのは、行動することです。ダッシュボードが、スケジュールの遅れを6週間、赤で表示することはあります。ステアリングコミッティが何もしなければ、遅れは続きます。

これは、デリバリーの真っ最中にあるプログラムにとっての、最低限のリズムです。欠けている行があれば、何よりも先に追加してください。

統制	最低限の実践	担当	頻度
作業分解構造	すべてのタスクに、担当者、期日、依存関係がある	PMOリード	毎週更新
スケジュールレビュー	3日以上遅れているタスクにフラグを立て、クリティカルパスを確認する	プログラムマネージャー	毎週
予算の追跡	ワークパッケージごとの、計画に対する実績	プログラムの財務リード	毎週。報告は月次
リスクレビュー	すべてのアクティブなリスクに、担当者、トリガー、対応がある	ワークストリームリード	毎週
変更管理	承認の前に、時間、コスト、リソースへの影響評価を行う	変更管理委員会の議長	毎週、または要求が来たとき
拡張レビュー（RISEとGROW）	すべてのギャップについて、設定、拡張、却下を決める	ソリューションアーキテクト	隔週
ステアリングコミッティ	状況報告ではなく、決定を行う。資料は事前に送付する	エグゼクティブスポンサー	隔週。カットオーバーとハイパーケアの間は毎週

計画と統制の失敗の多くは、手法が間違っていたからではなく、4か月目までに規律が失われたために起こります。チームが14か月目にもまだ回していられるように、サイクルは小さく保ってください。ステアリングコミッティそのものについては、効果的なSAPステアリングコミッティの作り方のガイドをご覧ください。

プロジェクトの計画と統制の違いは何ですか？

計画は、ロードマップ、つまりスコープ、スケジュール、予算、リソース、リスクを作ります。最初に方向を定めます。

統制は、その計画に対する進捗の追跡、差異の顕在化、依存関係の管理、正式な変更が生じたときのベースラインの見直しという、継続的な仕事です。プログラムが続く限り、毎週行われます。

SAPプログラムの多くは、計画に多くを投じ、統制への投資が少なすぎます。差異がステアリングに現れる頃には、立て直しのコストが、数週間から数か月分、積み上がっています。

プロジェクト計画があるのに、SAPプロジェクトが失敗するのはなぜですか？

誰も計画に沿って動かないからです。依存関係が追われていないため、あるワークストリームの遅れが、静かに別のワークストリームを止めます。リスクログは四半期ごとにしか更新されません。スコープ変更は、非公式に承認されます。ステアリングコミッティは月に一度開かれ、現場で起きていることを隠すマイルストーンのサマリーを見るだけです。

Lidl、Hershey、Revlonには、いずれも計画がありました。欠けていたのは、能動的な統制です。正直な進捗の追跡、早期のエスカレーション、警告のサインが出たときの実効性のある対応でした。

長期のSAPプログラムで、スコープクリープをどう管理すればよいですか？

すべてのスコープ変更に、承認の前に、時間、コスト、リソースについての書面での影響評価を付けてください。それがなければ、変更を承認することは、未知のものを承認することになります。

最も効果的なルールは、何かを加えるなら、別の何かを外さなければならないことです。この1つの制約が、事業側のリーダーに、正直に優先順位をつけさせます。

経営層が後ろ盾にならなければなりません。CFOやCOOが変更管理を公に支持すると、非公式な要求は急速に減ります。RISEとGROWのプログラムでは、すべてのギャップについての拡張の判断が、技術面のチェックを上乗せします。

作業分解構造（WBS）とは何で、SAPでなぜ重要なのですか？

WBSは、全体のスコープを、それぞれ担当者と期日を持つ成果物に分解します。SAPプログラムでは、プロセス設計、コンフィギュレーション、データ移行、連携、テスト、教育、カットオーバーのすべてを、タスクにまで分解することを意味します。

実務上の価値は、依存関係のマッピングです。データ移行は結合テストの前提となり、結合テストはUATの、UATはカットオーバーの前提となります。1つが遅れれば、下流への影響がすぐに見えます。

RISE with SAPは、プロジェクトの計画と統制をどう変えますか？

SAPが、デリバリーの当事者になります。インフラと技術運用を担い、そのカスタマーサクセスチームが、定着と価値について独自のサイクルを回します。

そこから、3つの変化が生じます。プラットフォームの問題について、パートナーを経由しない、SAPへの文書化されたエスカレーション経路が必要です。クリーンコアのもとで、すべてのギャップをどう扱うかを決める、ステアリングの下の拡張レビューの場が必要です。そして、SAPのカスタマーサクセスのサイクルは、並行して走らせるのではなく、自社のガバナンスに組み込むべきです。

SAPプログラムで、ステアリングコミッティは何をすべきですか？

決定を下すことです。その役割は、プログラムチームには解決できないこと、つまりリソースの衝突、スコープをめぐる争い、予算の変更、部門横断の権限を要するすべてを解決することです。決定なしに終わるステアリングの会議は、状況報告にすぎませんでした。

大規模プログラムで月次のステアリングにすると、課題は最大4週間待たされます。デリバリーの真っ最中は隔週が最低限で、カットオーバーとハイパーケアの間は毎週です。進捗報告は事前に送り、会議は、そこから上がる決定のために使います。