SAPとAIのデリバリーに役立つコンサルティングフレームワーク7選

SAPやAIのプログラムが行き詰まるとき、原因はたいてい構造的なもので、7つのシンプルなフレームワークでそれを突き止められます。現状をマッピングします。RACIで、誰が何を決めるかを合意します。作業をビジネスケイパビリティに結びつけます。なぜなぜ分析で根本原因を探します。MoSCoWで要件に優先順位をつけます。プログラムを実際に止めかねないものを基準に、リスクに順位をつけます。各フェーズの後に、本物のポストモーテムを行います。このガイドは、SAPとAIのデリバリーに携わるプログラムマネージャー、コンサルタント、スポンサーに向けたものです。まず下の表から、自分の症状を探し、対応するフレームワークから使い始めてください。

カタールの中堅メディア企業が、複数の地域にSAPを展開していました。フェーズ1では、財務と調達が本稼働する予定でした。同社は、レポーティングにAIの予測モデルも組み込みたいと考えていました。

6週目になると、遅れが忍び寄ってきました。ビジネスユーザーは、要件には承認したものの、自分たちが何を受け取るのかはまだよく分からないと言っていました。AIのユースケースは提案されていましたが、データの所有者が誰なのか、出力をどう使うのかを答えられる人はいませんでした。会議に遅れて来る人も、まったく来ない人もいました。

あの中途半端な時期でした。失敗と呼ぶには早すぎます。自然に直ると思い込むには遅すぎます。

私たちは、フレームワークを一つずつ順に適用しました。最初は、すべてが歓迎されたわけではありません。静まり返ったセッションもありました。脱線したセッションもありました。それでも、構造があることで作業は楽になりました。チームは堂々巡りをやめ、バックログは扱える量になり、AIのユースケースには本当の担当者が決まりました。プロジェクトは、計画より8週間遅れて本稼働しました。完璧ではありません。それでも着地し、フェーズ2は、より固い足場の上で、未知の要素も減った状態で始まりました。

私は、湾岸地域、欧州、その他の地域でのSAP、Oracle、AIプログラムのデリバリー23年を通じて、この7つすべての何らかの形を使ってきました。特別なものは一つもありません。ドキュメント作成の作業としてではなく、規律をもって適用すれば、どれも機能します。

症状とフレームワークを対応させます。

見えている症状	フレームワーク	得られるもの	一般的な工数
ユーザーが要件を承認したのに、まだ混乱している	1. 現状マッピング	今の仕事が実際にどう進んでいるかを示す、共有の地図	ワークショップ3〜5日
意思決定が会議の間をたらい回しになる	2. 重要な意思決定に対するRACI	20〜30件の主要な判断に、名前の入った意思決定者を置く	ワークショップ1回、その後は運用の徹底
スポンサーが「ITプロジェクト」から距離を置いている	3. ケイパビリティマッピング	進捗をビジネスケイパビリティとして報告する	Fit-to-Standardに組み込む
同じ種類の不具合が繰り返し出る	4. なぜなぜ分析	変えられる根本原因	課題ごとにファシリテーション付きセッション1回
すべてが優先度「高」になっている	5. MoSCoW	順位づけされたスコープと、現実的なMust Haveリスト	ビジネスとITの合同セッション1回
リスクログは問題なさそうなのに、チームに緊張感がある	6. リスクの順位づけ	プログラムを止めるリスクと、厄介なだけのリスクを分けた別々のリスト	毎週30分のレビュー
同じ失敗がフェーズごとに繰り返される	7. ポストモーテム	担当者つきの3〜5件の変更	各フェーズの後に半日

プログラムの開始時に最もよくある間違いは、現状を文書化する前に、解決策へ飛びつくことです。プロセスの文書は、たいてい古くなっています。人は、物事が実際にどう動いているかではなく、どう動くべきかを語ります。その二つのギャップに、導入上の問題が潜んでいます。

役に立つ現状マップは、管理する人ではなく、実際に仕事をしている人たちとのワークショップを3〜5日かけて作ります。内容は、順番に並べたプロセスのステップ、各ステップで使うシステム、手作業による介入と回避策、部門間のデータの流れです。

探すべきものがあります。当たり前になって誰も口にしなくなった手作業のステップ、あまりに長く続いて今では標準プロセスと見なされている回避策、そして誰もが知っているのに誰も直していないデータ品質の問題です。

カタールでは、現状マップは文書からではなく、ユーザーとのワークショップから作りました。承認済みの要件をめぐる混乱が晴れ始めたのは、そこからです。

きちんと行えば、現状マップは数日でできます。文書を集める作業として扱うと、数か月かかり、誰も信用しないものができあがります。

意思決定の権限は、SAPやAIのプロジェクトで最も欠けがちな構造的要素です。誰もが意見を持っています。最終判断を誰が下すのかは、誰も知りません。決定は次の会議に回され、その会議はステアリングコミッティに判断を委ね、ステアリングコミッティはワーキンググループへ差し戻します。

RACIマトリクス（Responsible：実行責任者、Accountable：説明責任者、Consulted：協議先、Informed：報告先）は、すべての意思決定と成果物に担当者を割り当てます。Accountableは1人だけで、Responsibleを兼ねても、委任してもかまいません。Consultedの人は意見を出します。Informedの人は結果を知らされます。

実践的なやり方はこうです。現在のフェーズで最も重要な意思決定を20〜30件挙げ、意思決定者に同席してもらってRACIのワークショップを開きます。割り当てに異論が出た箇所は、そこから学べることがあります。ガバナンスが不明確なのか、権限をめぐる政治的な争いがあるのか、どちらかです。どちらであっても、14週目ではなく2週目に表に出します。

運用の徹底がないRACIは飾りです。名前は、実際に権限を持つ人と一致していなければなりません。説明責任を、名前のある個人ではなく役職名に割り当てるのは、誰がリスクを負うのかという話し合いを避ける手段です。

SAPとAIのプログラムでは、ビジネス側から見えない技術的な作業が数多く発生します。作っているものと、それがもたらすべき成果とのつながりは、抽象的になっていきます。スポンサーは関心を失い、実際にはビジネス側の意思決定が原因の遅れまで、「ITプロジェクト」のせいにされます。

ケイパビリティマッピングは、システムの機能を、組織が実行できなければならないことであるビジネスケイパビリティに結びつけます。発注ワークフローが設定済みかどうかを追う代わりに、組織が仕入先請求書を受領から3日以内に処理できるかどうかを追います。設定は手段です。ケイパビリティが成果です。

SAP Activateでは、これはExploreフェーズのFit-to-Standardワークショップに対応します。対象範囲にある各プロセスがケイパビリティであり、SAP標準と必要なケイパビリティとのギャップはそれぞれ判断事項になります。標準を受け入れるか、バリアントを設定するか、拡張するかです。会話をケイパビリティのレベルに保つと、構築の間もビジネス側の関心が続きます。さらに、全員が対象範囲に含まれていると思い込んでいたのに、誰も確認していなかったケイパビリティが見えてきます。

同じ種類の問題がスプリントやフェーズをまたいで出続けるなら、個々の事例にパッチを当てても役に立ちません。原因は上流にあります。

なぜなぜ分析は、最もシンプルな根本原因分析のツールです。問題がなぜ起きたのかを問い、次にそれがなぜ起きたのかを問い、変えられるものにたどり着くまで続けます。たいてい5回繰り返すと本当の原因に届きます。2回では、症状で止まることがほとんどです。

データ移行を例にします。試行ロードでデータ品質のエラーが出ました。これが症状です。なぜか。ソースの抽出データで、項目のマッピングが誤っていた。なぜか。マッピング仕様を、業務側のデータオーナーが一度もレビューしていなかった。なぜか。データオーナーが決まったのは、マッピングが終わってからだった。なぜか。計画で、データオーナーの関与をマッピングの前提条件にしていなかった。これが根本原因で、対処はデータの修正ではなく、ガバナンス上の判断です。私の記事SAPのデータ移行が失敗する理由と対処法では、まさにこの連鎖がどれほど頻繁に現れるかを示しています。

1. 01試行ロードのエラー症状
2. 02誤った項目マッピングなぜロードは失敗したのか？
3. 03仕様が未レビューなぜマッピングは誤っていたのか？
4. 04オーナーの指名が遅すぎたなぜ仕様はレビューされなかったのか？
5. 05計画が依存関係を見落としたなぜオーナーは遅れたのか？

根本原因は、データの修正ではなく、ガバナンス上の判断である

責任追及のない場で行う根本原因分析は、率直な答えを引き出します。犯人探しをする場では、防御的な反応しか生まれません。ファシリテーターの役割は、会話を人ではなくプロセスに向け続けることです。乱雑な問題を、なぜと問い始める前にどう分解するかは、私の構造的思考と問題解決のガイドで扱っています。

SAPとAIのスコープをめぐる議論には、必ず合意の罠があります。誰もトレードオフを選びたがらないため、すべてが優先度「高」になります。すべてが高優先度なら、優先されているものは何もなく、構築チームはすべてをやろうとします。

MoSCoW（Must have：必須、Should have：重要、Could have：あれば望ましい、Won't have this time：今回は対象外）は、選択を迫ります。Must Haveは、本稼働に最低限必要なものです。Should Haveは重要ですが、稼働を妨げるものではありません。Could Haveは、時間と予算が許せば望ましいものです。Won't Haveは、明示的に先送りするものです。

規律が問われるのは、Must Haveの線引きです。MoSCoWの最初の一巡では、たいていMust Haveに入れすぎます。MoSCoWの発祥であるAgile Business ConsortiumのDSDMガイダンスは、Must Haveに充てる工数の上限を60%とし、それを超えるとデリバリーが危うくなると警告しています。最初の案と現実的なリストとの差は、大半が検証されていない思い込みです。

MoSCoWは、ビジネス側とテクノロジー側を同じ部屋に集めて行います。別々に行うと、ITのMust Haveリストとビジネス側のMust Haveリストは両立しないことが分かり、設定が始まるまで誰も調整しません。

リスク登録簿の多くは、発生確率と影響度でスコアをつけた長いリストで、月に1回レビューされ、RAGステータスはほとんど動きません。リスクを記録するだけで、行動を促すことはありません。

プログラムを止めかねないリスクと、進めにくくするだけのリスクを分けます。前者には、担当者、対応計画、毎週の可視化が必要です。後者には、モニタリングが必要です。

カタールでは、リスクログは書面上は問題なく見えましたが、誰もが神経を尖らせていました。月次ではなく毎週レビューする、手早いリスク影響度マトリクスによって、本当の懸念が表に出てきました。

チームが緊張しているのに問題なく見える登録簿は、ほぼ間違いなく何かを隠しています。真実は登録簿の中にはありません。その周りで交わされる会話の中にあります。「14番の項目の状況は？」と尋ねるより、「昨夜、何が気になって眠れなかったか」と尋ねる毎週のレビューのほうが、多くを引き出せます。スコアリングと担当割り当てのテンプレートは、私のSAPリスク評価マトリクスにあります。

フェーズや本稼働の後に行うポストモーテムは、次のフェーズで同じ失敗が繰り返されるのを防ぎます。同時に、スケジュールに余裕がなくなると真っ先に削られるものでもあります。

役に立つポストモーテムでは、4つの問いを立てます。何を達成する計画で、何を達成したのか。何がうまくいき、繰り返すべきなのか。何がうまくいかず、その原因は何か。次は何を変えるか。終わりは、起きたことをまとめた文書ではなく、担当者つきの具体的な行動3〜5件であるべきです。

よくある失敗は、チームが判断を検証せずに擁護する、正当化の場になってしまうことです。前向きな場にしてください。問うべきは、6週目の遅れを誰が引き起こしたかではありません。次のフェーズで遅れを防ぐために、どんな構造上の変更が要るかです。

カタールでは、ポストモーテムを本稼働の直後に行い、責任追及ではなく行動に焦点を当てました。フェーズ2がより固い足場の上で始まった理由の、大きな部分がこれです。

フレームワークは変わっていません。変わったのは適用の仕方で、3つの点があります。

下書きは速くなったが、傾聴は速くならない。 AIツールは今や、ワークショップの文字起こしやプロセス文書から、数分で最初のマップを作ります。SAP Cloud ALMは、Fit-to-Standardの文字起こしから要件の下書きを作成できます。ワークショップそのものは、従来と同じ時間がかかります。聞くことこそが本質だからです。下書きで節約した時間は、そのマップを人と一緒に検証し、問い直すことに使うべきです。

RACIの下書きはすぐ手に入るが、難しい部分は残る。 汎用のAIアシスタントは、プロジェクト憲章とワークパッケージの一覧から、1分でRACIを作ります。求められる規律は、交渉へと移ります。すべてのセルについて、権限とエスカレーションに関する本物の話し合いが必要です。下書き作成で節約した時間は、そうした難しい話し合いに使うべきです。

AIが同席すると、MoSCoWは難しくなる。 AIによる要件の順位づけは、もっともらしく、洗練されていて、その組織内の政治的な力学についてはしばしば的外れです。それを問い直さずに受け入れるコンサルタントは、白紙から始めるコンサルタントより、質の低い優先順位リストを作ります。AIの下書きは出発点として扱い、答えとして扱ってはいけません。

これらのフレームワークの上に載る判断力の価値は、今のほうが高く、低くはなっていません。コンサルタントとしてこうしたスキルを身につけているなら、SAPopediaのキャリアパスに、SAPキャリアの各段階でどのスキルが重要かがまとめられています。

コンサルティングフレームワークとは何で、なぜSAPプロジェクトで使われるのですか？

分析、意思決定、問題解決のための、構造化されたアプローチです。SAPやAIのプログラムでは、ビジネスリード、アーキテクト、プロジェクトマネージャー、インテグレーター、スポンサーに、共通の手法を与えます。

共通の手法がなければ、各グループはそれぞれの思考モデルに頼ります。プロセスの成果、アーキテクチャ、あるいはスケジュールとリソースです。現状マッピング、RACI、MoSCoWなどのフレームワークは、意見の食い違いを明示し、解決できる形にします。SAP Activate自体が、フェーズ、ゲート、成果物のためのフレームワークです。この7つはその内側で機能し、方法論だけでは解決できない構造面と人的な面の問題に対処します。

SAP導入で、現状マッピングはどのように進めますか？

設定が始まる前に、既存の文書が「こう動くべきだ」と述べている姿ではなく、プロセスが実際にどう動いているかを文書化します。プロセスを運用している人たちとのワークショップで作り込みます。対象は、ステップ、システム、引き継ぎ、手作業による介入、回避策です。

これは、SAP ActivateのExploreフェーズにおけるFit-to-Standardワークショップへの入力になります。そこでは、現状がSAP標準プロセスと比較するためのベースラインになります。ワークショップが始まる前に完成させてください。そうしないと、ギャップ分析が思い込みの上に成り立ってしまいます。

MoSCoWによる優先順位づけとは何で、SAPプログラムではいつ使いますか？

MoSCoWは、要件をMust have、Should have、Could have、Won't have this timeに分類します。Must Haveは本稼働に最低限必要なものです。Won't Haveは明示的に除外するので、後からこっそり戻ってくることはありません。

最も役立つのは、フィットギャップの結果が拡張の判断を左右するExploreフェーズと、不具合と機能強化が構築の時間を奪い合うRealizeフェーズです。よくある問題は、最初の一巡でMust Haveが多すぎることです。DSDMは、Must Haveに充てる工数を60%以内に抑えるよう勧めています。ビジネス側とIT側が同じセッションに入り、ファシリテーターが一つひとつに異議を唱えれば、そこに到達できます。

SAPプロジェクトで、効果的なリスクレビューはどう進めますか？

ステータス報告ではなく、会話として進めます。登録簿を順に確認する前に、「今週、登録簿に載っていない最大の懸念は何ですか？」のようなオープンな質問から始めます。

優先度の高いリスクごとに、何が変わったか、どんな対応を取ったか、傾向は改善しているか、対応計画は今も適しているかを尋ねます。何も対応しないまま、数週間同じ評価で止まっているリスクは、過小評価されていることが少なくありません。活発なフェーズでは毎週レビューし、ステアリングコミッティには、登録簿の全体ではなく、ステータスと次のアクションを添えた上位5件を示します。

SAPの本稼働後のポストモーテムを役立つものにするには、何が必要ですか？

次のフェーズに向けた、具体的で実行可能な変更です。起きたことの要約は記録であって、ポストモーテムではありません。

目指していたこと、達成したこと、うまくいったこと、うまくいかなかったことを扱います。「リソースが足りなかった」といった表面的な説明で止まらず、掘り下げます。リソース計画が誤っていたのか、スコープが誤っていたのか、エスカレーション経路が機能していなかったのか。最後は、それぞれに担当者と期日を付けた、3〜5件の変更で締めくくります。

SAP環境でのAI導入に、コンサルティングフレームワークはどう役立ちますか？

AIプロジェクトが失敗する構造的な理由は、SAPプロジェクトと同じです。加えて、AI特有の理由がいくつかあります。所有者のいないデータ、定義されていない成功指標、出力に基づいて動くための合意されたプロセスがないことです。

現状マッピングは、モデルが必要とするデータを誰が所有していて、その品質がどの程度かを示します。RACIは、出力を誰が検証し、誰がそれに基づいて動くかを決め、誤っていたときに誰が責任を負うのかに答えを出します。MoSCoWは、不可欠なユースケースと、面白いだけのユースケースを切り分けます。明確な担当者と成功指標を持つ、不可欠なユースケース2つか3つから始めてください。一度に15個も始めてはいけません。