SAP方法論
SAP ActivateのExploreフェーズとFit-to-Standardワークショップの進め方
SAP ActivateのExploreフェーズでFit-to-Standardワークショップを実務的に進める方法を解説。準備、適合確認、Fit-Gapの整理、意思決定、Realizeへの引き継ぎまでを具体的にまとめます。
SAP ActivateのExploreフェーズでは、導入対象の業務を標準プロセスに照らして確認し、追加開発や設定変更が必要な領域を整理します。中心となる活動がFit-to-Standardワークショップです。単に画面を見せる会議ではなく、標準機能を基準に業務要件、意思決定、後続作業を確定するための実務セッションとして設計します。
このフェーズの成果は、要件一覧を増やすことではありません。標準プロセスを基準にした合意を作り、Realizeフェーズで設定・開発・テストへ進める状態を作ることです。業務部門、プロセスオーナー、導入チーム、データ担当、連携担当が同じ前提で判断できるようにします。
Exploreフェーズの役割
Exploreは、Prepareで定めたプロジェクト方針やスコープを、業務プロセス単位の実行計画へ具体化する段階です。対象範囲、優先順位、業務上の制約を確認しながら、標準機能で対応する領域と、追加検討が必要な領域を分けます。
ワークショップの開始前には、対象業務、参加者、使用する業務シナリオ、確認対象の組織範囲を確定します。たとえば受注から出荷、購買から入庫、請求書照合、月次決算など、業務の始点と終点が明確な単位で設定すると議論が追いやすくなります。
SAP Activate全体の段階や成果物との関係を把握するには、SAP Activateの概要も参照できます。Exploreだけを独立した要件定義工程として扱わず、前後の判断とつなげて管理することが重要です。
Fit-to-Standardワークショップの準備
準備では、標準シナリオを説明する資料、業務フロー、サンプルデータ、確認事項、意思決定者の一覧を用意します。業務部門には、現在の手順を細部まで再現する資料だけでなく、将来プロセスを判断するための業務上の目的も確認してもらいます。
参加者は、プロセスオーナー、現場のキーユーザー、データ担当、権限担当、連携担当、導入パートナーなど、判断に必要な役割で選定します。情報提供者だけを集めると、会議中に判断が止まるため、スコープや業務ルールを承認できる担当者を含めます。
事前に次の事項を配布します。
- 対象プロセスと対象外プロセス
- ワークショップで確認する標準シナリオ
- 前提となる組織、製品、権限、データ、連携条件
- 参加者が確認しておく業務上の判断事項
- 決定、保留、追加分析に使う記録項目
- セッション後のレビュー期限と承認者
プロセス資料には、業務の開始条件、入力情報、担当ロール、主要な判断、出力結果、例外処理を含めます。現行業務の説明に時間を使いすぎると標準プロセスの評価が不足するため、現行手順は差分を判断するために必要な範囲で扱います。
ワークショップの進行方法
最初に、対象範囲と成功条件を確認します。次に標準プロセスを一連の業務シナリオとして実演し、参加者から質問を受けます。その後、業務上の必須条件、法令・監査上の条件、データや連携の制約を確認し、対応方針を記録します。
進行は、説明、確認、判断、記録の順に繰り返します。標準機能の画面項目を一つずつ確認するよりも、受注、引当、出荷、請求のような業務結果まで通して確認すると、プロセス間の依存関係を把握しやすくなります。
各論点には、少なくとも次の情報を持たせます。
- 論点の識別子
- 関連する業務プロセス
- 業務上の要求または制約
- 標準機能での対応方針
- 追加設定、拡張、開発、運用変更の候補
- 影響を受ける組織、データ、権限、連携
- 決定者、期限、現在のステータス
会議中に結論が出ない論点は、単に「要確認」と記録せず、確認方法と判断期限を設定します。必要なサンプルデータ、担当者、検証環境、関連プロセスを明記すれば、後続の調査が作業として実行可能になります。
Fit-to-StandardとFit-Gapの違い
Fit-to-Standardは、標準プロセスを実際の業務に当てはめ、標準の採用可否と必要な対応を判断する進め方です。一方、Fit-Gapは標準と業務要件の差分を記録し、その差分への対応を評価する分析結果や管理対象を指します。
したがって、Fit-Gap一覧を最初から要求一覧として作るのではなく、標準プロセスを確認した結果として作成します。差分が見つかった場合も、すぐに開発要件へ変換せず、業務変更、設定、拡張、連携変更、帳票対応、データ整備、運用手順変更の順に選択肢を評価します。
評価では、業務上の必須性、法令・監査要件、標準機能での代替可能性、将来の保守負荷、データ品質、連携への影響、テスト範囲を確認します。差分の数を減らすことだけを目標にせず、業務価値と将来運用を含めて判断します。
差分の分類と意思決定
差分は、少なくとも次の分類で整理すると、担当チームと承認経路が明確になります。
- 標準プロセスを採用する
- 設定で業務要件に合わせる
- 業務手順を変更する
- 権限やロールの設計で対応する
- 既存データを変換または整理する
- 標準連携の設定を行う
- 拡張や追加開発を検討する
- 対象範囲から外し、別の業務や後続リリースで扱う
開発や拡張を選択する場合は、目的、利用者、入力、出力、エラー処理、性能条件、監査要件、テスト方法、運用責任者を記録します。業務部門が求める「今の画面と同じ動き」という表現は、そのまま開発仕様にせず、必要な業務結果と制約に分解します。
承認には、プロセスオーナーだけでなく、データ、権限、連携、運用の責任者も関与させます。ある変更が一つの業務では小さく見えても、マスタ、会計、在庫、購買、販売、外部システムへ波及する場合があるためです。
記録と成果物の管理
ワークショップの記録は、議事録だけでなく、プロセス、差分、決定、未決事項、依存関係を追跡できる形で管理します。各項目にプロセスIDや業務領域を付けると、後でテストケース、権限設計、データ移行、トレーニングへつなげやすくなります。
成果物には、標準採用の判断、設定項目の一覧、拡張候補、帳票と連携の一覧、データ準備事項、ロール設計事項、テスト観点を含めます。ワークショップの録画だけに依存せず、判断結果を構造化した記録として残します。
ロードマップ上のアクティビティや成果物の位置を確認する際は、SAP Roadmap Viewerの使い方が役立ちます。プロジェクト固有の期限や責任者は、ロードマップの一般的な説明とは分けて管理します。
各セッション後には、参加者へ記録を配布し、訂正期限を設定します。期限を過ぎた項目は承認済みとして扱うのか、プロセスオーナーの明示承認を必要とするのかを、プロジェクトのガバナンスで決めておきます。
ExploreからRealizeへの引き継ぎ
Exploreの終了条件は、すべての論点が完全に解決していることではありません。Realizeへ進むために、対象プロセスの判断状況、未決事項、前提条件、責任者、期限、優先順位が明確であることが重要です。
引き継ぎ時には、次の項目を確認します。
- スコープと対象外範囲が承認されている
- 標準採用、設定、業務変更、拡張の判断が記録されている
- 追加開発候補に受入条件がある
- データ移行とマスタ整備の担当者が決まっている
- 連携、権限、帳票、監査の依存関係が可視化されている
- テストシナリオの元となる業務結果が定義されている
- 未決事項に期限とエスカレーション先がある
Realizeでは、Exploreで決めた標準方針を設定、開発、データ準備、テストへ変換します。Exploreで保留した事項を無制限に持ち越さず、実装開始前に優先順位と判断期限を見直します。
よくある停滞と対処
標準デモが長く、判断が進まない場合は、業務結果と判断事項を先に示します。参加者が画面操作の細部に集中している場合は、プロセスの開始条件、終了条件、例外処理へ議論を戻します。
現行業務の説明が中心になる場合は、現行手順を標準との比較に必要な項目へ絞ります。現行の担当者や帳票をそのまま再現することより、業務上の目的、統制、必要な結果を確認します。
差分が大量に発生した場合は、業務要件、制約、希望、既存仕様を分けて再評価します。すべてを同じ優先度で扱わず、法令・監査、業務継続、顧客対応、データ整合性などの観点で順位を付けます。
意思決定者が不在のまま会議を続ける場合は、保留項目を明示し、判断者と期限を設定して次の会議へ移します。結論のない議論を記録上の合意として扱わないことが、後工程の手戻りを防ぎます。
SAP Activateとアジャイルな反復計画を組み合わせる場合は、SAP Activateとアジャイル開発の進め方も確認してください。Exploreで得た判断を短い実装・検証サイクルへ渡す際の役割分担を整理できます。
実務で使える確認チェックリスト
開始前には、対象プロセス、参加者、標準シナリオ、サンプルデータ、意思決定者、記録方法を確認します。実施中は、標準プロセスの結果、必須条件、例外、依存関係、対応方針を記録します。終了時には、決定済み、保留、追加分析、除外の状態を確認します。
特に重要なのは、差分を発見した時点で開発を約束しないことです。まず業務変更、設定、データ整備、権限、連携、帳票、拡張を比較し、影響と保守性を踏まえて承認を得ます。
Exploreの成果物をRealizeの作業へ変換できる粒度まで整えると、設定担当や開発担当が判断の背景を確認しやすくなります。これにより、同じ要件を複数の会議で繰り返す状況を減らし、テストと受入の観点も早い段階で準備できます。