SAPの作業範囲記述書（SOW）に必ず盛り込むべきこと

SAPの作業範囲記述書（SOW）は、パートナーが何を、どれだけの工数で、誰によってデリバリーし、それがどう変わりうるかを定める契約文書です。スコープ、詳細な前提条件と除外事項、フェーズ別・役割別の工数、受入基準付きの成果物、指名要員、変更管理を盛り込まなければなりません。

たいていのSOWは、スコープならそれなりに書けています。顧客が書き漏らしがちなのは詳細な前提条件と除外事項であり、それこそが最終的な支払額を決める章です。

この記事は、私のSAP導入パートナーの選び方のガイドの一部です。SOWは、SAPパートナーのRFPとプレゼンの後に来る、選定プロセスの最後の手順です。署名前のSOWレビューの実例は、ERP契約交渉のケーススタディをお読みください。

よいSAPのSOWは、プログラムの運用マニュアルのように読めます。発注者側の誰が開いても、3つの問いに答えられるべきです。何を得るのか、それは何に依存しているのか、何かが変わったらどうなるのか。

必要な章と、それが欠けたときに起きることは次のとおりです。

章	書くべきこと	薄いと何が起きるか
スコープ	対象となるプロセス、モジュール、会社コード、プラント、国、ユーザー	ワークショップのたびに、何が含まれていたかが蒸し返される
前提条件	価格が依存する条件と、それぞれが成り立たなかった場合の帰結	パートナーが、発注者には反論できない変更依頼を出す
除外事項	パートナーが行わないことと、代わりに誰が行うか	作業が発注者とパートナーの間に落ち、誰の担当にもならない
アプローチとフェーズ	方法論、フェーズ計画、品質ゲート	フェーズが完了したと合意できる時点がない
工数	フェーズ別・役割別の見積工数	消化ペースが計画どおりかどうか判断できない
成果物と受入	名前を挙げた文書とアウトプット、受入基準、承認期間	未完成の作業に請求書が支払われる
要員	指名された主要な人、役割、配分、交代のルール	プレゼンで会ったチームが、現場のチームではない
発注者側の責任	自社の人員が何を、いつまでに提供しなければならないか	発注者側が原因の遅れが、パートナーの変更依頼になる
変更管理	変更をどう起票し、評価し、価格付けし、承認するか	変更依頼が第二の収益源になる
ガバナンス	ステアリングコミッティ、報告、エスカレーション	問題が遅れて表面化し、そのときには高くつく

価格を求める前に、スコープは自社で書いてください。そうすれば、パートナーは自社のスコープではなく、あなたのスコープで見積もります。

ここは、顧客が書き漏らしがちな章です。これがなければ、価格は、発注者側の誰も読んでも合意してもいない条件の上に成り立つことになります。

前提条件とは、パートナーが価格の根拠にした条件です。除外事項とは、パートナーがまったく価格に含めていない作業です。どちらも、第三者が成り立ったかどうかを確認できるほど具体的である必要があります。

書き出すべき前提条件の種類

どの前提条件にも、帰結が必要です。「これが成り立たなかった場合、その変更は影響評価を伴う変更管理に回す」と書けば、前提条件は飾りから統制に変わります。

SAPのSOWがカバーすべきカテゴリーは次のとおりです。

1. 組織のスコープ。 価格がカバーする会社コード、プラント、販売組織、国、法人の数。
2. プロセスのスコープ。 対象となる業務プロセスを名前で挙げたものと、パートナーが発注者に採用を期待するSAP標準プロセス。
3. WRICEFの量。 ワークフロー、レポート、インターフェース、データ変換、拡張、帳票の数を複雑度別に。このリストが膨らむにつれて予算はExploreフェーズで打撃を受けるので、基準となる数は契約に入れるべきです。
4. データ。 移行するデータオブジェクト、履歴の量、模擬ロードの回数、誰がデータをクレンジングするか。
5. インターフェース。 各インターフェースを名前で挙げ、相手側のシステムと、そのシステムを誰が変更するか。
6. テスト。 テストサイクルの回数、誰がスクリプトを書き、誰が実行し、誰が不具合を修正するか。
7. 発注者側の参画。 自社の誰が必要で、その人の時間のどれだけを割き、意思決定をどれだけ早く下す必要があるか。
8. 環境とライセンス。 システム、ツール、アクセスを誰が、いつまでに用意するか。
9. 拠点と言語。 チームがどこで働くか、オンショアとオフショアの比率、出張、文書とトレーニングの言語。
10. トレーニングとハイパーケア。 トレーニングのモデル、育成するトレーナーの人数、ハイパーケアの期間と終了基準。

予算にとって最も重要なのは、WRICEFの基準数です。SAP自身の教材は、Exploreフェーズを、承認された差異要件がRealizeフェーズ向けのプロダクトバックログに追加されるFit-to-Standard分析として説明しています（SAP Learning）。承認された差異はそれぞれ新しいWRICEFの工数になりうるので、増加を測るための出発点の数が必要です。

書き出すべき除外事項の種類

除外事項には、代わりに誰がその作業を行うかを書くべきです。担当者のない「除外」は、カットオーバー中に見つかるのを待っている穴です。

よくあるカテゴリーは次のとおりです。

1. レガシーシステムでのデータのクレンジングと補完。 多くは発注者側の作業です。
2. インターフェースの相手側にある、サードパーティシステムやレガシーシステムの変更。
3. ソフトウェアのライセンスとサブスクリプション。 これはSOWではなく、SAPとの契約に含まれます。
4. インフラとホスティング。 パートナーが明示的に運用する場合を除きます。
5. エンドユーザートレーニングの実施。 パートナーが発注者側のトレーナーを育成するだけの場合です。
6. 組織のチェンジマネジメント。 記載された範囲を超えるもの。
7. セキュリティ、ロール、権限の設計。 別の当事者が担当する場合です。
8. 性能テスト、ペネトレーションテスト、回帰テスト。 指定されたサイクル以外のもの。
9. 組織のスコープに含まれない国、法人、ローカライゼーション。
10. ハイパーケア後のアプリケーション保守。 これは別契約です。

2つのリストを、プログラムディレクターと並べて読んでください。どちらのリストにも載っていないものが、変更依頼の出どころになります。

SAP導入に私が推奨する契約形態は、工数を定量化したタイム・アンド・マテリアル（準委任型）です。つまり、フェーズ別・役割別の見積工数を契約に書き込み、毎月、実績工数をそれと比べて追跡できるようにします。

固定価格は取締役会には安全に見えます。実際には、価格が固定されているのはすべての前提が成り立つ間だけであり、SAPプログラムはExploreの終わりまでにその大半を試すことになります。固定価格のフェーズがそれでも意味を持つ場面は、私のSAP導入コストのメモで扱っています。

SOWの中で2つの形態を比べると、次のようになります。

比較の観点	固定価格	工数を定量化したタイム・アンド・マテリアル
契約で固定されるもの	前提条件が成り立つ間の価格	単価と、フェーズ別・役割別の見積工数
リスクの所在	パートナーが予備費として価格に織り込む	発注者側にあるが、毎月見える
スコープが動いたとき	あらゆる変更が交渉になる	工数が動き、それを見積りと比べて確認できる
追跡できるもの	マイルストーンと変更依頼	フェーズ別・役割別の、計画に対する実績工数
発注者を守るもの	厳密な前提条件と除外事項	厳密な前提条件、除外事項、工数報告

工数を定量化すれば、タイム・アンド・マテリアルは白紙小切手から管理された予算に変わります。見積りは、フェーズと役割を軸にした人日の表として求め、その表に対する毎月の報告を契約上の義務にしてください。

単価を工数の中に隠させないでください。役割の構成は、私のSAPプロジェクトの要員配置計画のガイドを使って市場単価と照らし合わせてください。

序盤にシニアの人日が多く、後半にジュニアの人日が多い計画はよくあります。その逆には説明が必要です。

成果物とは、完了の定義を持つ、名前のあるアウトプットです。「設計支援」は成果物ではありません。合意した基準に照らしてレビューされ、署名されたRecord to Reportのソリューション設計書は成果物です。

受入を品質ゲートに結びつける

SAP ActivateはDiscover、Prepare、Explore、Realize、Deploy、Runの6つのフェーズで進みます。SAPは各フェーズの後に正式な品質ゲートを置き、プロジェクトが先に進む前にそのフェーズの成果物が完成しているかを確認すると説明しています（SAP Learning）。

そのゲートをSOWで使ってください。各ゲートで期限を迎える成果物、受入基準、レビューに使える日数を列挙します。支払いは暦ではなく、受け入れた成果物に結びつけてください。

発注者側の誰かが、それらの文書を判断できなければなりません。これは、私が独立コンサルタントを入れることを推奨する3つの時点の1つです。契約時、設計時、そしてパートナーの成果物の評価です。2つの役割がどう連携するかは、私のSAPパートナーと独立コンサルタントの比較の記事で説明しています。

人の名前を挙げ、確認する

提案された人材の質が低いことは、私が入札を見送る2つの理由の1つです。もう1つは、アーキテクチャと計画を説明できないパートナーです。

SOWには、ソリューションアーキテクト、プログラムマネージャー、各機能リードと技術リードの名前を挙げるべきです。その配分、後任者を面接する発注者の権利、そして交代のたびに発注者が承認することを書き込んでください。指名要員の条項が実際にどう働くかは、ERP契約交渉のケーススタディで示しています。

経歴書を鵜呑みにせず、認定資格を確認してください。SAPは認定バッジをCredlyで発行しており、リアルタイムで検証できます（SAP Learning）。SAPの認定維持の仕組みでは、保有者が必須のアセスメントを受けなければ、認定は失効します（SAP Learning）。

この条項は、見た目以上に重要です。私はプログラムの途中でパートナーを替えたことがあり、きっかけは、そのパートナーが質の高い人材を出せなかったことでした。そうなる前に確保すべきものは、私のプロジェクト途中でのSAPパートナーの変更のガイドで扱っています。

変更管理は、薄いSOWが高くつく場面です。前提条件が曖昧なら、ほとんど何でも変更だと主張できてしまいます。

実用的な変更管理の章には、次の要素が必要です。

1. 発生条件。 変更が存在するのは、前提条件が崩れたとき、除外事項がスコープに取り込まれたとき、または発注者が新しいことを求めたときだけです。
2. 影響評価。 スコープ、役割別の工数、スケジュール、コストを、作業開始前に書面で。
3. 単価表。 変更は契約単価で価格付けし、合意がない限り緊急対応の割増はなし。
4. 承認権限。 発注者側の誰がどの金額までの変更を承認できるか。一定の閾値を超えるものはCFOが承認します。
5. ログ。 承認・却下を問わずすべての変更を、累計額とともにステアリングコミッティに報告します。
6. 基準線との結びつき。 新しいWRICEFオブジェクトは、前提条件に書いた数を基準に測ります。

パートナーは正当な変更も起票します。SAPプログラムでは、契約締結時には誰も知らなかったことが見つかるものです。目指すのは、誰かがお金を使う前に、それぞれの変更が見え、価格付けされ、承認されていることです。

私が主導または立て直してきた21件のSAPプログラムを通じて、最も多く目にする失敗は、最初にきちんと計画しないことです。SOWは、その計画が拘束力を持つ場所であり、そこにかける時間は、争いになる変更依頼に比べれば安いものです。

具体的な次の一歩はこうです。手元にあるSOWを取り出し、すべての前提条件と除外事項を1ページに書き出してください。それぞれの横に、それが間違っていた場合にどうなるか、誰が支払うかを書きます。その欄を埋められないなら、そのSOWはまだ署名できる状態ではありません。

署名前にSAPの作業範囲記述書について独立した目で読んでほしい場合、私は契約の段階でクライアントをお手伝いしています。こちらからご連絡ください。

SAPの作業範囲記述書には何を盛り込むべきですか？

スコープ、詳細な前提条件、除外事項、アプローチとフェーズ、フェーズ別・役割別の見積工数、受入基準付きの成果物、指名要員、発注者側の責任、変更管理、ガバナンスです。最も薄くなりがちなのは前提条件と除外事項であり、それこそが最終的なコストを決める部分です。

SAPのSOWにおける前提条件と除外事項の違いは何ですか？

前提条件とは、会社コードやWRICEFオブジェクトの数のように、パートナーが価格の根拠にした条件です。除外事項とは、レガシーデータのクレンジングのように、パートナーがまったく価格に含めていない作業です。各前提条件には成り立たなかった場合にどうなるかを書き、各除外事項には代わりに誰がその作業を行うかを書くべきです。

SAP導入には固定価格とタイム・アンド・マテリアルのどちらがよいですか？

私は工数を定量化したタイム・アンド・マテリアルを推奨します。フェーズ別・役割別の見積工数を契約に書き込み、毎月追跡します。固定価格はすべての前提が成り立つ間しか維持されず、SAPプログラムはExploreフェーズの間に大半の前提を試すことになります。

SAPの成果物の受入基準はどう定めればよいですか？

各成果物の名前を挙げ、完成とはどういう状態かを書き、自社のチームのレビュー期間を設けてください。それらを各フェーズの終わりにあるSAP Activateの品質ゲートに結びつけ、成果物が受け入れられたときにだけ支払いを行います。

SAPのSOWにはコンサルタントの名前を挙げるべきですか？

はい。主要な役割、つまりソリューションアーキテクト、プログラムマネージャー、機能リードと技術リードについては挙げるべきです。その配分、後任者を面接する発注者の権利、あらゆる交代に対する発注者の承認を加えてください。認定資格は経歴書に頼らず、CredlyのSAPバッジで確認します。

SAPの作業範囲記述書は誰が書くべきですか？

草案はパートナーが作りますが、スコープと前提条件は発注者から出すべきです。市場に出る前に自社のスコープを書き、署名前に、パートナーから独立した人に前提条件、除外事項、成果物をレビューしてもらってください。