コンサルタントが実際にしていること：現実的な見方

SAPコンサルタントは、企業のためにSAPを設定し、構築し、テストし、安定させます。実際には、その価値の大半はプログラムの途中で生まれます。ずれてしまったスコープを明確にし、誰も行わなかったウォークスルーを実施し、UAT（ユーザー受入テスト）の不具合を切り分け、本稼働後の運用を安定させます。ファンクショナルコンサルタントはモジュールの設定を担い、テクニカルコンサルタントは拡張と連携を担い、プログラムおよびチェンジコンサルタントはデリバリーと定着を担います。この記事は、外部の支援を入れるかどうかを判断するリーダーと、コンサルティングをキャリアとして検討している人に向けたものです。リーダーの方は、下の兆候の表を見れば、いつ声をかけるべきかが分かります。コンサルタントの方は、日常業務のセクションを読めば、この仕事の実際の中身が分かります。

外部の支援を検討するたびに、同じ疑問が出ます。自分たちにできない何を、コンサルタントは実際にしているのか。

正直な答えは、コンサルティング業界にとって、あまり名誉なものではありません。価値の大半は、壊れるはずのなかったものを直すことから生まれます。すでに問われているべきだった問いを投げかけることから。そして、社内チームのキャパシティと見通しの両方が尽きたまさにその時に、それらを補うことから生まれるのです。

これは社内チームへの批判ではありません。SAPプログラムは、えてしてそう進むものです。社内チームは手一杯です。システムインテグレーターには、自社の優先事項があります。意思決定は積み上がり、スコープはずれていきます。12か月のプログラムの6か月目に、誰かが課題ログを開くと、3週目から放置されたままの「要解決」の項目が20件見つかります。

たいていは、このタイミングで連絡が入ります。

ブループリントや計画の段階で呼ばれるコンサルタントもいます。多くは、プロジェクトの途中で、2、3か月の進捗の遅れや引き継ぎの不備を経てから声がかかります。ステアリングコミッティへの報告は、オレンジ色の状態です。チームは懸命に働いています。進捗は遅く、その理由を正確に言える人はいません。

1. ExploreワークショップとギャップFit-to-Standardワークショップ、ギャップを文書化
2. Realize構築とウォークスルー設定と拡張。立て直しの連絡が来るのは、たいていプロジェクトの途中
3. DeployUATの切り分けとカットオーバー設定、プロセス、トレーニングのどのギャップか？切り分けで決まる
4. ハイパーケア安定化最初の月次決算と課題キュー

典型的なきっかけは次のとおりです。

1. スコープがずれてしまった。 Exploreで承認された内容が、構築チームが取り組んでいる内容と一致しなくなっています。要件がワークショップで非公式に追加され、変更ログは管理されず、確定したスコープ一覧を持っている人はいません。
2. 重要なワークストリームが止まった。 データ移行が、改善計画のないまま、何週間も同じエラー率のまま足踏みしています。UATでは、解消される不具合より、新たに起票される不具合のほうが多い状態です。
3. 本稼働日が固定されているのに、計画がそれを支えていない。 日付を決めたのは取締役会です。計画は、実際の進捗と突き合わされていません。プログラムマネージャーは、今の軌道では日付に間に合わないと分かっていますが、まだエスカレーションしていません。

どのケースでも、仕事は既存の計画に人を足すことではありません。実際に何が起きているかを見て、問題をありのままに名指しし、先へ進む道筋を作ることです。その立て直しの手順は、私のSAPプロジェクトを軌道に戻すためのガイドで扱っています。

スコープとプロセスの明確化

設定は正しいのに、その周りのプロセスが壊れていることがあります。よくあるパターンはこうです。チームはExploreで作成したFit-to-Standardの文書に沿って設定しましたが、ビジネスユーザーは、承認以降、その設定を一度も見ていません。何を作っているかは伝えられても、実物は見せられていないのです。

解決策は技術的なものではありません。会話の欠落です。仕事は、UATの前に、ビジネスユーザーに設定を順に見せて回り、テストが始まる前に、変更点の明確な一覧を作ることです。

華やかな仕事ではありません。これが、仕事の実際の姿です。

技術チームとビジネスチームの橋渡し

SAPプログラムでは、技術的には正しいのに、ビジネス側が使えないものが日常的にできあがります。90%のケースでは機能するのに、輸出受注で破綻する価格決定。正しく転記されるのに、照合チームが見覚えのない会計伝票を生成する在庫の入出庫。

ファンクショナルコンサルタントは、そのギャップを埋めます。その場で最も技術に詳しい人になることによってではありません。システムの挙動とビジネスへの影響を十分に理解し、適切な人が適切な判断を下せるようにすることによってです。

UATの支援

ユーザー受入テストは、プログラムが積み重ねてきた判断が持ちこたえるか、崩れるかが決まる場です。Exploreでの近道、非公式なスコープの追加、概要レベルで書かれたテストケースのすべてが、ここで表に出ます。

優れたUAT支援とは、不具合を正しく切り分け、設定のギャップ、プロセスのギャップ、トレーニングのギャップを仕分けることです。また、ビジネスユーザーが失敗続きでプログラム全体への信頼が揺らいだときに、場の温度を調整することでもあります。それがないと、UATセッションで出る不具合の一つひとつが、本稼働そのものを疑う理由になります。たいていは、切り分けが弱く、「本稼働可能な状態」とは何かを誰も定義していなかったことが原因です。

本稼働後の安定化

SAPコンサルティングで最も地味な仕事が、ハイパーケアです。本稼働が済み、お祝いのメールが飛び交い、導入チームは離れ始めます。そこへ最初の月次決算がやってきます。転記が照合フォーマットと合いません。製造指図は完了しても、精算されません。ヘルプデスクは、トレーニングは受けたものの、例外的なケースへの備えがなかったユーザーでいっぱいになります。

ここは、実際の価値の多くが生まれる場面であり、同時に、ほとんどのプログラムでリソースが不足している場面でもあります。ハイパーケアチームは、課題キューを体系的に処理し、構造的な問題と単発のエラーを切り分け、システムへの信頼を立て直します。

仕事の構造は変わっていません。変わったのは、時間の配分です。

ドキュメントは、ほぼ自動で下書きされる。 2025年から一般提供されているSAP Joule for Consultantsは、SAP Notesを含むSAP自身のナレッジベースをもとに設定に関する質問へ回答し、ABAPコードを解説します。SAP Cloud ALMのJouleベースのアシスタントは、ワークショップの資料から要件とテストケースの下書きを作成します。ファンクショナルコンサルタントは、文書を打ち込む時間が減り、ワークショップの結論を問い直す時間が増えます。

コードは、書くよりレビューされる。 SAPの開発者向けアシスタントはコードを下書きします。SAP BTP上のJavaやJavaScriptの拡張向けのSAP Build Codeもその一つです。テクニカルコンサルタントは、それをレビューし、セキュリティを確保し、テストする役割を担うようになりました。

ハイパーケアデスクへの定型的な問い合わせが減る。 Jouleは、休暇残日数や経費の処理状況といった定型的な質問に、SAPアプリケーションの中で答えられます。その分、ハイパーケアデスクの件数が一部減ります。コンサルタントの時間は、プロセスのギャップ、マスタデータの問題、人が対応すべきケースへと移ります。

コンサルタントを入れる意味は変わっていません。こうしたツールを使いこなせるようになったコンサルタントは、判断、コミュニケーション、エスカレーションに多くの時間を使い、AIが今では十分な水準で下書きできる作業には、あまり時間を使いません。SAP自身によるJoule for Consultantsの説明は、その対象範囲を的確にまとめています。

ファンクショナルコンサルタントは、FI、CO、SD、MM、PP、EWM、SuccessFactorsなどのモジュールを専門とします。業務プロセスに合わせてシステムを設定し、SAP標準とクライアントの要件との間のギャップを埋めます。彼らの価値は、モジュールの深い知識と業務プロセスの知識の組み合わせにあります。

テクニカルコンサルタント（ABAP開発者、SAP BTPのスペシャリスト、インテグレーションアーキテクト、Basis）は、設定では対応できない拡張と連携を構築します。最新のS/4HANAプログラムでは、クリーンコアの原則により、新しい拡張はSAP BTPやリリース済みのAPIに載せることになり、従来のABAPによる修正とは異なるスキルセットが求められます。

プロジェクトマネージャーとプログラムマネージャーは、デリバリーの骨格を担います。ガバナンス、リスク、スケジュール、課題解決を受け持ち、プログラム全体を見渡すことで、問題が危機に発展する前にエスカレーションされるようにします。

チェンジマネジメントコンサルタントは、人の側面を担います。トレーニング、コミュニケーション、エンゲージメント、そして、ユーザーがシステムを使いこなすのか、それとも迂回するのかを左右するガバナンスです。

大規模なSAPプログラムの多くは、この4つすべてを必要とします。中堅企業のプログラムでは、少ない人数が複数の役割を兼ねることが多く、そこにギャップが生まれます。コンサルティングフレームワークと、コンサルティングで重要なスキルは、この4つのどれにも共通です。これらの役割を通じて、自分自身のルートを描こうとしているコンサルタントの方には、SAPopediaがキャリアパスとコースを示しており、ERPCVは、その経験をリクルーターに伝わる形で提示する助けになります。

コンサルティングで最も高くつく失敗は、人を入れるのが遅すぎることです。本稼働の4〜6週間前に行うカットオーバー前のリスクレビューなら、まだ時間があるうちに重大な問題を見つけられます。カットオーバーに失敗した後の立て直し案件は、はるかに高くつきます。しかも、業務上のプレッシャーのもとで、システムへの信頼を失った組織の中で進めることになります。

表は、兆候と、それぞれに必要な支援を示しています。

兆候	通常、何を意味するか	入れるべき支援	2週間で届けてほしいもの
課題ログの項目が4週間以上未解決で、解決期日もない	技術ではなくガバナンスの問題	独立したプログラムアドバイザー	担当者と期日つきの意思決定リスト
本稼働が60日以内なのに、カットオーバーのリハーサルをしていない	未検証のカットオーバー。本稼働時の想定外は、その場では挽回できない	カットオーバーまたはプログラムのリード	リハーサル済みのカットオーバー計画と、Go/No-Goの基準
ビジネスオーナーが出席しなくなった	意図的な介入がなければ、UATは失敗する	チェンジリードとファンクショナルリード	主要ユーザーとのウォークスルーと、再び関与してもらうための計画
1つのワークストリームが、数週間同じエラー率のまま止まっている	根本原因が見つかっていない	そのワークストリームの専門家	根本原因分析と、立て直しの計画
プログラムの健全性を見る手段が、SIの報告だけ	独立したチェックがない	クライアント側のアドバイザー	スポンサーに向けた、率直な健全性の評価

SAPコンサルタントは、プロジェクトで実際に何をしますか？

ビジネス要件を分析し、それを支えるようにSAPを設定し、SAPの標準と、ビジネスが必要とするものとのギャップを埋めます。Exploreでは、Fit-to-Standardワークショップを運営し、ギャップを文書化します。Realizeでは、設定を構築し、開発者と拡張に取り組みます。Deployでは、UATを支援し、不具合を管理し、カットオーバーを準備します。ハイパーケアでは、本稼働後の課題を解決します。職務記述書に書かれていないのは、フェーズの合間に生じるギャップを切り分け、プレッシャーのもとでデリバリーの規律を保つ部分です。

組織は、実際にいつコンサルタントを必要としますか？

ほとんどの案件は、3つの状況でカバーできます。1つ目は、プログラムの立て直しです。スコープがずれた、ワークストリームが止まった、本稼働日が危うい、といった場合です。2つ目は、専門能力の補強です。PP-PIの設定や、SAP BTPでの連携など、モジュールや技術のスキルがチームにない場合です。3つ目は、ガバナンスです。システムインテグレーターが運営するプログラムに、独立した監督を置きたい場合です。事態が悪化するのを待ってから声をかけるのが最もよくあるパターンで、最も高くつきます。

SAPのファンクショナルコンサルタントとテクニカルコンサルタントの違いは何ですか？

ファンクショナルコンサルタントは、FI/CO、SD、MM、PP、EWMなどのモジュールで、業務プロセスを支えるようにSAPを設定し、要件についてビジネスユーザーと直接やり取りします。テクニカルコンサルタントは、設定では対応できないものを構築します。ABAPやBTPの拡張、連携、Basisによるシステム管理です。クリーンコアの原則により、技術的な作業は、システム内部のABAP修正から、BTPの拡張やリリース済みのAPIへと移りつつあります。

コンサルタントが価値を生んでいるかどうか、どう見分けますか？

指標は3つあります。既存の意見を追認するのではなく、検証されていなかった前提と、先送りされていた判断を表に出します。何週間も止まっていた意思決定が、下されるようになります。そして、解決しないまま項目をクローズするのではなく、根本原因が直されることで、課題ログが縮みます。動きがあるのにログの長さが変わらないなら、問題が構造的なものか、対処が原因に届いていないということです。

コンサルティング業務で最も難しいのは何ですか？

クライアントがすでに知っているのに、行動に移していない問題に名前をつけることです。ずれたスコープ、書かれていないテストケース、関与しなくなったスポンサーなどです。それには、話を聞いてもらえるだけの信頼、信じてもらえるだけの信用、そして不都合なことを言う率直さが必要です。診断を犠牲にして関係を守るコンサルタントは、高くつく同調にすぎません。

すでにSIがいるのに、なぜ独立したコンサルタントを雇うのですか？

システムインテグレーターは、契約した範囲を納品する責任を負います。独立したコンサルタントは、成果についてクライアントに責任を負います。これは別の仕事です。クライアント側のアドバイザーは、設計上の前提に異議を唱え、設計がビジネスの要件を満たしていることを検証します。変更管理の場でクライアントの商業的な立場を守り、インテグレーターの報告を通さない、プログラムの健全性の見方を経営層に提供します。これは構造的な利益相反であって、インテグレーターへの批判ではありません。