SAPプロジェクトのリスクアセスメント：実践版

SAPプロジェクトのリスクアセスメントは、プログラムを脱線させかねないものを洗い出し、各リスクを発生確率と影響度でスコア付けするものです。各リスクには指名された担当者を1人置き、それが起きる前に対応を合意し、リストは毎週レビューします。SAPプログラムを沈めるリスクが、意外なものであることはまれです。データ移行、連携、要員の確保、スコープのずれ、定着です。このガイドは、フォルダに眠るだけのリスク登録簿ではなく、意思決定を変えるリスク登録簿を求めるプログラムマネージャーとスポンサーに向けたものです。スコア付きのマトリクス、登録簿のテンプレート、実際の失敗事例3つ、そしてRISE with SAPとクリーンコアが加えるリスクを示します。まず、すでにお持ちのすべてのリスクに、指名された担当者を付けるところから始めてください。

多くのSAPリスクアセスメントは、最初のステアリングコミッティの前に作られ、一度レビューされ、それきり触られなくなります。それはリスク管理ではありません。ただの文書です。

居心地が悪すぎて早い段階で言い出せなかったために、無視されたリスクを見てきました。その沈黙は、ほぼ必ず、後でより高くつきます。資材管理（MM）での小さな連携の問題が、突然、財務を止めます。テストでは問題なく見えたレポートが、システムの更新後に壊れます。そうしたことを、一度ならず見てきました。

リスクは意外なものではありませんでした。文書化されていました。誰も対応しなかったのです。

スコープ。プロジェクトは標準モジュールから始まります。やがて誰かが「あともう1つだけレポートを」と言い、次にダッシュボード、さらにいくつかの拡張が加わります。危険なのは、ワークショップ、メール、廊下での会話で非公式に持ち込まれたスコープ変更を、プロジェクトマネージャーが設定の済んだ後で初めて知ることです。統制については、私のスコープクリープを避けるためのガイドで扱っています。

リソース。アーキテクトが本番の障害対応に引き抜かれます。主要な開発者が辞めます。業務ユーザーは、本業が止まらないため、テストサイクルに参加できません。稼働できる時間は、書面で確保してください。口約束は、人員のプレッシャーの下で消えます。

技術。ターゲットの構造に対して検証されていない項目マッピング。単体テストには通るのに、実際の取引量で壊れるインターフェース。本番の負荷がかかるまでは問題なく見えるカスタムコード。どこを見るべきかを知っていれば、これらは予測できます。

スケジュール。ブループリントが遅れてテストが圧迫されるのに、本稼働日は固定のままです。UAT、研修、データ準備が急がれます。フェーズゲートを逃しながら、下流の計画を動かさないほぼすべてのプログラムで、同じパターンが現れます。

定着。人は、理解していないものを拒みます。弱い、あるいは遅い研修は、回避策を生み、回避策はデータを劣化させ、システムはチェンジマネジメントの失敗の責めを負わされます。

これらの事例は公開されていて、十分に記録されています。パターンは、どの規模でも繰り返されます。

Lidl：7年間で約5億ユーロ

Lidlは2011年に、SAP for Retailを基盤とするeLWISプロジェクトを開始し、一部の小規模な国で本稼働しましたが、2018年に断念しました。報じられた費用は約5億ユーロです。広く報じられた原因の1つは、Lidlが在庫を購入価格で評価していたのに対し、SAPの標準の小売モデルは売価を使うことです。Lidlは、慣行を変えるのではなくカスタマイズを選び、同社は、当初の目標は妥当な労力では達成できないと述べました。

教訓：自社のデータモデルとSAPの標準との不一致は、1週目のリスクであり、5年目に発見するものではありません。

HP：約4億ドルの売上損失

2004年、HPはサーバー事業の一部を、SAPベースの統合された受注・サプライチェーンシステムに移行しました。注文は、レガシーのフロントエンドとSAPの間で落ち、手作業が必要になり、バックログは倍増しました。HPのCEOは、この問題によりサーバー・ストレージ部門が約4億ドルの売上と2億7,500万ドルの営業利益を失い、1億2,000万ドルのバックログが残ったと述べました。HPのCIOは後に、チームは3週間の混乱を想定して計画しており、4〜6週間分の備えがあるべきだったと語りました。

教訓：平均的なカットオーバーではなく、悪いカットオーバーを想定してコンティンジェンシーの規模を決め、切り替える前に在庫やチャネルのバッファを確保してください。

Nike：1億ドル超の売上損失

2000年、NikeはSAPのERPプログラムより先に、i2の需要計画ソフトウェアを本稼働させました。このソフトウェアはNikeのレガシーシステムと連携するよう大幅にカスタマイズされており、動作が遅く、商品の量の下でクラッシュしました。ある靴は過剰に、別の靴は過少に発注されました。Nikeは1億ドルを超える売上を失い、株価は約20%下落しました。その後、Nikeは短期と中期の計画をSAPに移しました。

教訓：連携は、実際のデータで本番の取引量を流すまで、動くと思い込まないでください。

前提に基づいて作られたアセスメントは、ないよりも悪いです。誤った安心感を生むからです。重要なインプットは6つです。

1. スコープ文書：憲章、承認済みのスコープ、署名済みの要件。これらがなければ、スコープのリスクはすでに高い状態です。
2. リソースのコミットメント：部門長からの書面によるコミットメント、重要な役割のスキルマトリクス、すべての主要ポジションに指名された代替要員。
3. 予算とスケジュール：コンティンジェンシーを含む承認済みの予算と、類似のプログラムと照らして確認したスケジュール。全面展開に6か月と最小限の資金という前提は、今のうちに指摘すべきリスクです。
4. ベンダーのコミットメント：サービスレベルとペナルティを定めた契約。RISEでは、SAPの責任範囲とエスカレーション経路。
5. 技術環境：レガシーとの互換性、データ移行の複雑さ、導入形態、カスタム開発に対するクリーンコアの計画。
6. 過去のプロジェクトの記録：以前のSAPまたはERPプログラムのリスク登録簿、課題ログ、振り返り。リスクの大半は、新しいものではありません。

各リスクを、発生確率と影響度で1から5でスコア付けし、掛け合わせます。以下の例は、S/4HANAプログラムの一般的な出発点です。実際のスコアは、皆さんの場合とは異なります。

リスク	発生確率（1〜5）	影響度（1〜5）	スコア	優先度
データ移行の失敗	4	5	20	高
連携の遅延	4	4	16	高
リソースの制約	4	4	16	高
予算超過	3	5	15	中
コア内のカスタムコードがアップグレードを妨げる	3	5	15	中
スコープクリープ	4	3	12	中
テストカバレッジの不足	3	4	12	中
ピーク負荷時のパフォーマンス	3	4	12	中
コンプライアンスの不備	2	5	10	中
SAPへのエスカレーション経路がない（RISE）	2	5	10	中
ユーザーの定着の低さ	3	3	9	中
サブスクリプションまたはライセンスの費用リスク	2	4	8	中
KPIを追跡していない	3	2	6	低

16以上のスコアには、指名された担当者と、今すぐの行動が必要です。8から15のスコアは、定義されたエスカレーションのトリガーを付けて監視します。8未満は、優先して時間を割かずに、登録簿に残します。スコアは出発点であり、評決ではありません。10とスコア付けされたコンプライアンスの不備が、規制の厳しい業界では25になることもあります。

スコアだけでは何も変わりません。各リスクには、次の項目をすべて埋めて記載します。

項目	書く内容	例
リスク	事象を1文で	ベンダーマスタデータが、モックロード2の前にクレンジングされていない
オーナー	指名された1人	買掛金のリード
スコア	発生確率 × 影響度	4 × 5 = 20
トリガー	行動を起こす、測定可能なポイント	モック1の抽出で重複率が5%を超える
対応	回避、軽減、移転、受容のいずれかと、その行動	軽減：買掛金担当のアナリスト2名を3週間クレンジングに充てる
次回レビュー	日付	次の月曜日のリスクレビュー
ステータス	オープン、対応中、クローズ	対応中

可能なら、コストを現実の言葉で書いてください。「高リスク」は曖昧です。「UATが1週間遅れると、チーム工数でおよそ6桁の費用がかかり、本稼働が3週間後ろにずれる可能性がある」なら、注意を引きます。

カスタムコードは、独立したリスクカテゴリーです。S/4HANA Cloud Public Editionでは、コア内のカスタムコードは不可能です。拡張は、SAP BTP、リリース済みのAPI、またはキーユーザー向けツールを通じて行います。プライベートクラウドとオンプレミスでは、引き続きコアを改修でき、そうすることに慣れたパートナーは改修します。その技術的負債は、最初のメジャーアップグレードで表面化します。特定されたカスタマイズのうち、クリーンコアの方針が合意されているものがいくつあるかを追跡し、パートナーのBTP拡張の経験を確認し、Exploreの終わりまでにレビューの場を立ち上げてください。

RISEは、可用性の責任の所在を変えます。SAPがインフラを運用するため、リスクは「自社のチームが可用性を持つ」から、「SAPが持ち、何か障害が起きたときに素早く連絡をつける手段が自社に必要」に移ります。SAPの担当者の氏名、エスカレーション経路とサービスレベル、そして本稼働前に合意したインシデント対応計画を記録してください。それがないと、SAPに上げるべき問題が、プロジェクトチームの中に長く留まります。

AIが助けるのは書類作業であり、判断ではありません。SAP Cloud ALMのJouleベースのアシスタントや、Microsoft Copilotなどのツールは、ステータスレポート、不具合ログ、議事録から、登録簿の記載やステアリング資料のドラフトを作れます。ソースデータが整っているプログラムでは、登録簿の維持が速くなります。ただし、データにすでに見えているリスクを見つけるだけです。どのリスクに対応する価値があるかを決めること、担当者を動かすこと、経営陣が無視したがるリスクをエスカレーションすることは、できません。

1. 5つのカテゴリーすべてにわたってリスクを洗い出す。IT、業務、ベンダーとワークショップを行います。それぞれが違うリスクを見ているからです。RISEでは、少なくとも1回はSAPの担当者を含めてください。チームが見落としがちなリスクは、ITと業務が異なる期待を持っていること、外部連携の定義が甘いこと、UATのオーナーが確保できないこと、非公式なスコープ変更です。
2. 各リスクをスコア付けする。発生確率と影響度について、可能なら実際の数字で。
3. リスクごとに担当者を1人置く。チームではなく、個人です。担当者がいなければ、追跡も解決もありません。
4. リスクが現実になる前に、対応を定義する。回避、軽減、移転、受容です。「監視して対応する」は計画ではありません。判断の先送りです。
5. 毎週レビューする。オープンなリスクを確認し、新しいリスクを加え、状況が変わったものは再スコアし、トリガーに近いものはエスカレーションします。上位のリスクは、色の評価ではなく、提案する判断を添えて、ステアリングコミッティに持ち込んでください。

1. 01洗い出す五つのカテゴリーすべて
2. 02スコア付けする発生確率 × 影響度、1から5
3. 03担当者を置くチームではなく一人
4. 04対応を定義する回避、軽減、移転、受容
5. 05毎週レビューする再スコア、トリガー付近はエスカレーション

16以上：指名された担当者と、今週中の対応

SAPプロジェクトにおけるリスクアセスメントとは何ですか？

何がうまくいかない可能性があるかを洗い出し、各リスクを発生確率と影響度でスコア付けし、それぞれに担当者を置き、起きる前に対応を合意するプロセスです。SAPプログラムは、複数のモジュール、連携、データ移行、チェンジプログラム、固定された本稼働日を同時に抱えるため、非公式なリスク管理は持ちこたえません。実際のリスクを担当者付きで短くまとめたリストは、誰も読まない長い文書に勝ります。

SAPプロジェクトのリスクマトリクスはどう作りますか？

スコープ、リソース、技術、スケジュール、定着に加えて、RISEでのクリーンコアとSAPへのエスカレーションまで、リスクを洗い出します。それぞれを発生確率と影響度で1から5でスコア付けし、掛け合わせます。16以上を高、8から15を中、8未満を低とします。中と高のすべてのリスクに、担当者と、測定可能なトリガーを置きます。たとえば「第16週までにUATの完了率が80%を下回れば、本稼働日をレビューに回す」といったものです。毎週、そして各フェーズゲートで再スコアします。

SAP導入で最も多いリスクは何ですか？

データ移行の失敗です。レガシーデータは、見積もりよりほぼ必ず雑然としているからです。連携の遅延は、特に文書化されていないレガシーインターフェースとサードパーティベンダーで起きます。テストと研修を圧迫するスコープクリープ。主要な人員が引き抜かれる、月末のUATの間にユーザーが確保できないなどのリソースの制約。画面を見せるだけで、業務をシミュレーションしない研修による定着の低さ。RISEでは、コア内のカスタムコードと、SAPへのエスカレーション経路がないことが加わります。

リスクアセスメントは、SAPプロジェクトのどの時点で行うべきですか？

プロジェクトの開始前です。データモデルの不一致や非現実的なスケジュールといった構造的なリスクを、最も安く直せる時期だからです。SAP Activateのフェーズゲートの前にも毎回行います。各フェーズでリスクの様相が変わるからです。スコープ、予算、リソースが変わるたびにも行います。そして、リスクが問題に変わったときにも、ほかに何が影響を受けるかを確認するために行います。その間は、毎週レビューします。

SAPプログラムでは、誰がリスクを持つべきですか？

対応できる人です。データ移行のリスクはデータリード、連携のリスクは技術アーキテクト、定着のリスクはチェンジリード、クリーンコアのリスクはソリューションアーキテクトが持ちます。RISEでは、SAPへのエスカレーション経路をCIOまたはプログラムディレクターが持ちます。プログラムマネージャーは登録簿の健全性を追跡しますが、すべてのリスクを自分で持つわけではありません。

ERPのリスクアセスメントを省くと、何が起きますか？

大規模なものでは、Lidlのような事例になります。同社は約5億ユーロを費やした後、2018年にSAPの小売プロジェクトを断念しました。あるいはHPです。2004年のSAP受注システムの移行で、サーバー部門に約4億ドルの売上損失が出ました。もっと小さな規模でも、仕組みは同じです。データモデルの不一致が遅れて見つかり、連携が本番の取引量で失敗し、弱い研修のために定着が失敗します。リスクは、問題になる前に特定できたはずのものでした。