本文へスキップ

プロジェクト途中でSAP導入パートナーを変更する方法

プログラムの途中でSAP導入パートナーを替えても、先に文書、設計、コード、アクセスを確保しておけば乗り切れます。替えるべき兆候、押さえておくべきもの、引き継ぎの進め方を解説します。

プロジェクトルームのテーブルに置かれた保管箱、引き継ぎチェックリスト、移行計画
目次
  1. SAPパートナーを替えるべき兆候
  2. 決める前に診断する
  3. 退任するパートナーに伝える前に確保すべきもの
  4. プロジェクトの内容は自社のツールに置く
  5. 告知する日に向けてアクセスの変更を計画する
  6. 移行の進め方
  7. 後任はきちんと選ぶ
  8. 新しいパートナーとは違う形で契約する
  9. 並行期間を置き、それから再検証する
  10. 切り替えがコストとスケジュールに与える影響
  11. 独立アドバイザーが役立つ場面
  12. 次の一歩
  13. よくある質問

プロジェクトの途中でSAP導入パートナーを変更するには、まずパートナーが本当に問題なのかを確かめ、そのうえで、相手に伝える前にすべての文書、設計、コード、システムへのアクセスを確保します。そこで初めて後任を選び、並行期間を設けた計画的な引き継ぎを行います。

結論から言えば、替えるのは、パートナーが質の高い人材を出せず、それを改善できないときです。自社側にある問題から逃れるために替えてはいけません。新しいパートナーがそれを引き継ぐだけだからです。

この記事は、私のSAP導入パートナーの選び方のガイドの一部です。そのガイドは最初にパートナーを選ぶ場面を扱っています。この記事は、選んだパートナーがうまくいかないときにどうするかを扱います。

私はプログラムの途中でパートナーを替えたことがあります。きっかけは人材の質でした。プログラムが必要としているときに、そのパートナーは質の高い人を出せなかったのです。

私が最初に挙げる兆候はそれです。プログラムは、うまくいかなかったフェーズ、守れなかった日付、弱い設計からなら立ち直れます。有能な人を仕事に就けられないパートナーからは、なかなか立ち直れません。

行動に移す価値のある兆候は次のとおりです。おおよそ、私が重視する順に並べています。

  1. 現場にいる人たちの質が低い。 作業しているコンサルタントが、紹介された人たちではない。あるいは、自分の担当領域についての基本的な質問に答えられない。
  2. 人の交代に何度も失敗する。 誰かが抜けると後任の到着に何週間もかかる、あるいは経験の浅い人が来る。
  3. 誰もアーキテクチャと計画を説明できない。 パートナーのリードに、目標とする設計と本稼働までの道筋を説明してもらってください。それができないなら、誰もデリバリーの舵を取っていません。
  4. 成果物がレビューに耐えない。 設計書、テストスクリプト、構築文書が薄い、別の顧客からの流用である、あるいは存在しない。
  5. 具体的な問題に一般論で答える。 選定時と同じ危険信号です。どの企業にも当てはまる回答です。

遅れたフェーズ、Exploreでの超過、緊迫したステアリングコミッティは、それだけでは替える理由になりません。

誰かを替える前に、パートナーが本当に原因なのかを確かめてください。私のSAPプログラムの立て直しのガイドでは、私が最初に行う3つの確認を示しています。プログラムの状況、設計、そしてシステムに実際に展開されているものです。

その診断で、問題が双方にあるとわかることもよくあります。予算はExploreで、WRICEFリスト(ワークフロー、レポート、インターフェース、データ変換、拡張、帳票)が膨らむにつれて打撃を受けます。スコープの管理をパートナーに任せていたり、キーユーザーがプログラムに一度も割り当てられていなかったりすれば、新しいパートナーも同じ穴に落ちます。

だから、2つの問いに正直に答えてください。

  1. このパートナーに強いチームがいれば解決するか。 そうであり、パートナーがそのチームをすぐに出せるなら、人の入れ替えで十分かもしれません。
  2. 別のパートナーでも同じ問題に直面するか。 そうであれば、まず自社側のスコープ、意思決定、ガバナンスを正してください。

1つ目の問いの答えが「いいえ」で、その理由がパートナーが人を見つけられないことなら、答えは出ています。質の高い人材を確保できるかどうかは、契約の修正で解決できるものではありません。

ここは、ほとんどの顧客が間違える部分です。決定を告げてしまい、それとともに交渉力が消えてしまうのです。

退任するパートナーは、そのパートナーを替えるために必要な知識を握っています。その知識が手元に来るまでは、決定を少人数のグループの中にとどめてください。スポンサー、CFO、プログラムディレクター、そして法務または調達のリードです。

まず現在の契約から始めます。解約条項、通知期間、成果物の帰属、そして知識移転や離脱支援に関する規定を読んでください。作業範囲記述書が離脱について何も定めていないなら、次の契約に何を書き込むべきかは、私のSAPの作業範囲記述書に必ず盛り込むべきことの記事で扱っています。

確保すべきものと、それがふだんどこにあるかは次のとおりです。

確保すべきものなぜ重要か置かれるべき場所守り方
承認済みの設計と意思決定新しいパートナーが、一からやり直さずにその上に構築できる自社の文書リポジトリまたはSAP Cloud ALM最新の承認版を、承認記録とともに今すぐコピーする
WRICEFリストと仕様書スコープの基準線であり、構築のバックログSAP Cloud ALMまたは自社のリポジトリすべてのオブジェクトのステータス付きでリストをエクスポートする
カスタムコードと設定これまでに行われた実際の作業自社の開発システムとテストシステムパートナーの端末ではなく、すべてが自社のシステムにあることを確認する
テストスクリプトと結果実際に何が動くかの証拠自社のテストツールまたはSAP Cloud ALMスクリプト、結果、未解決の不具合をエクスポートする
データ移行の作業マッピング、クレンジングのルール、ロードプログラム共有ドライブと自社のシステムデータチームからマッピング文書とロードプログラムを回収する
システムとSAPサポートへのアクセス自社のシステム環境とSAPサポートアカウントの管理権自社のシステムとSAP for Meパートナーのユーザーをすべて洗い出し、当日に削除できるようにしておく
未解決の課題とリスク次のチームが最初に引き取るべきものRAIDログと状況報告RAIDログの日付入りのコピーを取る

プロジェクトの内容は自社のツールに置く

最もすっきりした守り方は、構造によるものです。どのプログラムでも初日から、プログラムの文書、要件、テストの証跡を、自社が所有するツールに置いてください。

ここではSAP Cloud ALMが役立ちます。SAPのCloud ALM FAQによると、SAP Enterprise Supportの契約がある顧客、またはRISE with SAPの顧客は、顧客番号ごとに1つ、追加料金なしで自社のテナントを申請できます。プロジェクトの文書が自社のテナントにあれば、パートナーが去ってもそれは手元に残ります。

告知する日に向けてアクセスの変更を計画する

パートナーのコンサルタントは、自社のシステムのユーザーアカウントに加えて、自社のSAPサポートアカウントのSユーザーIDを持っていることがよくあります。SユーザーIDは、SAP for Meで自社の管理者が管理しています。

SAPのユーザー管理ヘルプによると、退職したユーザーのIDを削除する責任は顧客の管理者にあります。また、ソフトウェア受領者や技術担当者のような特別な機能を持つIDは、SAPがその機能を別の人に移すまで削除できないとされています。どのパートナーのユーザーがそうした機能を持っているかを今のうちに把握し、まずそれを自社の人に移してください。

資料が確保され、後任が選ばれたら、退任するパートナーに伝えます。契約に沿って書面で行い、同じ会議で離脱計画に合意してください。

引き継ぎは、次の順序で進めるのが最もうまくいきます。

プログラム途中でのSAPパートナーの変更

  1. 確保

    誰かに伝える前に、文書、設計、コード、アクセス、RAIDログを手元に置く。

  2. 選定

    類似プロジェクトのリファレンスと、実際のチームによるプレゼン。工数は定量化する。

  3. 並行期間

    退任側と着任側のリードが並んで働き、体系的な知識移転を行う。

  4. 再検証

    新しいパートナーが、設計、構築、テストを、実際に展開されているものと照らしてレビューする。

  5. 再ベースライン

    証拠に基づいて新しい計画を一つ作り、次のフェーズが始まる前に承認する。

後任はきちんと選ぶ

選んでいる間もプログラムはお金を消費し続けるので、急ぎたくなります。私の経験では、きちんとした選定には約12週間かかり、ショートリストには少なくとも3社を残します。追い込まれた中での後任選びはもっと速く進むかもしれませんが、自社を守る手順は飛ばさないでください。

クライアントのためにパートナーを選ぶとき、私が最も重視するのは顧客リファレンスです。リファレンスコールでは、発注者と似たプロジェクトでのパートナーの経験を尋ねます。プログラムの途中であれば、別の会社が始めた仕事を引き継いだ経験をリファレンスに尋ねる、ということです。

私が入札を見送る理由は2つあります。提案された人材の質が低いこと、そしてアーキテクチャと計画を説明できないパートナーです。人材の質が原因で替えた後なら、この2つの基準は緩めるのではなく、より厳しく適用してください。

候補には、提案する人たちの認定バッジを求めてください。SAPのデジタルバッジのヘルプページが説明しているとおり、SAPは認定バッジをCredlyで発行しています。バッジが裏付けるのは試験に合格したことなので、経験はリファレンスでも確認してください。

選定の残りの部分は、私のSAP導入のRFPの書き方とティア別のSAP導入パートナーのガイドで扱っています。

新しいパートナーとは違う形で契約する

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

作業範囲記述書には、詳細な前提条件と除外事項も必要です。顧客はこれを書き漏らしがちですが、引き継ぎではさらに重要になります。新しいパートナーは、引き継いだ問題を除外したがるからです。

主要な人の名前も契約に挙げてください。指名要員の条項と、それによって署名後にシニアな人が消えるのを防げる理由は、私のERP契約交渉のメモで説明しています。

並行期間を置き、それから再検証する

退任側と着任側のリードが一緒に働く期間を計画してください。退任するチームが各設計領域、各未解決の不具合、構築途中の各オブジェクトを順に説明し、着任するチームが質問します。

そのうえで、新しいパートナーに既存のものを再検証させます。ギャップが見つかることも、その指摘の一部が工数を増やすための交渉材料になることも想定しておいてください。退任するパートナーの成果物について独立した見方を持つ価値があるのは、まさにこの場面です。

引き継ぎを、現在いるSAP Activateのフェーズに当てはめてください。SAPはDiscover、Prepare、Explore、Realize、Deploy、Runの6つのフェーズを示しています(SAP Activate)。

Exploreの間に替える場合、主なコストは設計のやり直しです。Realizeの間に替える場合は、構築とテストのやり直しのコストもかかります。コードは、理解しなければ完成させられないからです。

替えようとしているパートナーは、そのパートナーを替えるために必要な知識を握っています。一言でも口にする前に、それを確保してください。

ただで替えられることはありません。フェーズ、デリバリーされたものの質、退任するパートナーがどれだけ協力するかによって変わるので、私は数字を示しません。

予算に見込むべきコストは次のとおりです。

  1. 並行期間。 引き継ぎの間は2つのチームに支払います。
  2. 再検証と手戻り。 新しいパートナーが設計、設定、コードを確認し、その一部はやり直しになります。
  3. 契約からの離脱。 契約に定めるところに従い、通知期間、解約条件、仕掛中の作業への支払いが発生します。
  4. 選定の工数。 RFP、プレゼン、リファレンスコールにかかる自社のチームの時間です。
  5. 自社の人員の時間。 キーユーザーは、終わったと思っていたワークショップやテストを繰り返します。
  6. 遅延。 遅れが1週間増えるごとに、旧システムと社内チームの稼働も長引きます。

これらを、替えずにいるコストと比べてください。プログラムの要員を確保できないパートナーは、プログラムが難しくなるにつれて安くなることはありません。そして、Realize、テスト、カットオーバーは、それまでよりも難しくなります。

私はクライアントに、3つの時点で独立コンサルタントを入れるよう助言しています。契約の段階、設計、そしてパートナーの文書と成果物の評価です。パートナーの変更は、その3つすべてに一度に関わります。

独立したレビュアーは、新しいパートナーが手戻りの価格を付ける前に、退任するパートナーの成果物に実際にどれだけの価値があるかを教えてくれます。着任するパートナーの契約と、その設計に対する見解も確認できます。誰が何をするかは、私のSAPパートナーと独立コンサルタントの比較の記事で示しています。

今週中に、承認済みの設計、WRICEFリスト、テストの証跡、カスタムコードが実際にどこにあり、それぞれへのアクセスを誰が管理しているかを確認してください。替えるつもりがあるかどうかにかかわらず、行ってください。どれかがパートナーの手元にしかないなら、自社が所有するシステムにコピーを移してください。

パートナーの変更を検討していて、成果物や契約について独立した意見が必要であれば、こちらからご相談ください。

プロジェクトの途中でSAP導入パートナーを変更できますか?

できます。まず、契約の解約、通知、成果物の帰属に関する条項を確認してください。決定を告げる前に設計、コード、テストの証跡、システムへのアクセスを確保し、そのうえで並行期間を設けた計画的な引き継ぎを行います。

SAP導入パートナーはいつ替えるべきですか?

パートナーが質の高い人材を出せず、それを改善できないとき、あるいはそのリードがアーキテクチャと計画を説明できないときに替えてください。フェーズが遅れたというだけで替えてはいけません。スコープの主導権や自社の意思決定に関する問題は新しいパートナーにもついてくるので、まず診断してください。

契約を解除する前に、SAPパートナーから何を受け取るべきですか?

承認済みの設計と意思決定の記録、各オブジェクトのステータス付きのWRICEFリストです。自社のシステム内にあるカスタムコードと設定、テストスクリプトと結果、データ移行のマッピング、RAIDログも必要です。さらに、自社のシステムとSAPサポートアカウントにあるパートナーのユーザーをすべて洗い出し、当日にアクセスを削除できるようにしておいてください。

プロジェクト途中でSAPパートナーを替えるにはどのくらいのコストがかかりますか?

標準的な金額はありません。2つのチームの並行期間、再検証と手戻り、契約離脱の条件、自社の選定工数、遅延を予算に見込んでください。フェーズが後になるほど手戻りは増えます。コードとテストは、理解しなければ完成させられないからです。

SAP導入パートナーの交代にはどのくらいの期間がかかりますか?

私の経験では、きちんとしたパートナー選定には約12週間かかり、ショートリストには少なくとも3社を残します。追い込まれた中での後任選びはもっと速く進むかもしれませんが、リファレンスコールと実際のチームによるプレゼンは省かないでください。

SAP導入の文書とコードは誰のものですか?

それを決めるのは契約なので、成果物の帰属条項を確認してください。実務上は、文書を自社のリポジトリまたはSAP Cloud ALMテナントに、コードと設定をパートナーのサーバーではなく自社のSAPシステムに置いて、自社を守ってください。

Noel D'Costa

執筆者

Noel D'Costa

航空、政府、金融、小売、製造の各分野で、SAPとOracleのERPプログラムに25年携わってきました。財務出身です。経営陣とともに変革の範囲を誠実に定め、難航するプログラムを立て直し、本稼働後の最初の1年を乗り越えるシステムを構築します。

次のステップ

いまERPプログラムを進めていますか?

この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。