【初心者向けざっくり解説】SAP導入プロジェクトの基本 - 計画フェーズの作業内容、成果物【スケジュール、コスト・工数見積】

皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せているSAP導入プロジェクトの基本について解説します。

SAPとは、言わずと知れた基幹業務システムのシェアNo.1のERPパッケージシステムのことで、多くの日本企業においても既に導入されています。

SAPのERPパッケージの最新バージョンはSAP S/4 HANAとなるのですが、ひとつ前のモデルであるSAP ECCは2025年にサポート対応が終了するため、2022年現在、多くの日本企業がすでに導入済みのSAP ECCをS/4 HANAへ移行しようとプロジェクトを企画しています。

SAP導入プロジェクトの必要性が高まっている一方で、過去にSAP ECCを自社企業に導入した人材はすでに定年退職済みというケースも多く、SAPに関する知見を持つ人材が相対的に少ない状況であり、この問題をSAP業界では2025年問題と呼ばれています。

そうした状況下において、事業会社、SIer、コンサルティングファームなどではSAPの知見を持つ方を広く募集しており、SAPの知見を持つ人にとっては高い市場価値を発揮するチャンスとなっています。さらに、現時点ではSAPの知見がなかったとしても業界としては深刻な人材不足であるため、勇気をもってこの領域でキャリア形成を図ろうとする方は大歓迎される状況です。

私の周りでも多くのSAP導入未経験の元エンジニアの方がコンサルティングファームに転職され、SAP導入プロジェクトに関与するようになってきています。

本投稿では、そうしたSAP導入プロジェクトにこれから関わっていくという方向けに、SAP導入プロジェクトの基本知識を提供したいと思います。

今回は、SAP導入プロジェクトの基本アプローチであるWaterfallアプローチおける構想策定、Planningフェーズにおける作業内容について解説します。Planningフェーズには多くの作業が発生するのですが、本投稿ではプロジェクトにおけるスケジュールの決定とコストおよび工数の見積を取り扱います。

なお、実際のプロジェクトの中で皆様が経験されるものと一部異なる点がある可能性がございますが、本投稿で解説する内容は一般的なケースとしてご参考にして頂ければと思います。

想定読者

• SAP導入プロジェクトに初めて参加することになった事業会社、SIer、コンサルティングファームの方
• SAP導入プロジェクトを担当するSIer、コンサルティングファームのポジションへの転職を考えている方

SAP初心者向けの投稿記事まとめはこちら

先にこちらのブログで取り扱っているSAP初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。

プロジェクト全体のスケジュールを決める

さて、プロジェクトを進めていくうえでの前提やルールがいろいろと固まってきている状況だとして、ここでは、これまでの前提やルールを用いてプロジェクト全体のスケジュールを決めます。

スケジュールを決める際には、Top-Downで決める方法とBottom-Upで決める方法がありますが、Planning フェーズではまずTop-Downで計画を作成し、その後Bottom-Upで計画を作成してお互いをすり合わせていきます。

Top-Downで決める

Top-Downでスケジュールを考えるときは、プロジェクト計画書の作成で最初に着手したPJ目標に立ち返ります。

PJ目標は事業計画や中期経営計画を基にしているので、自然といつまでにPJを完了させたい、システムが動いている状況にしたい、という要望も確認出来ることが一般的です。

こうした都合をもとに、いつまでに終えたい、という観点からスケジュールを作成します。

まずは開始と完了の日付を決定し、それをフェーズに分割していきます。

開始日はプロジェクト計画書の承認がおり、そしてプロジェクトのメンバーが参加できるようになったタイミングとなります。完了日は、いつまでに終えたい、という希望をいったんは取り入れます。

開始と完了の日付が決まったら、それをフェーズごとに分割していきます。

もし、SAP導入プロジェクト以外に他のプロジェクトがあって、そのプロジェクトのDesign、Build、Testなどの開始とSAP導入のプロジェクトも足並みをそろえないといけない、といった事情がある場合はそうした都合も取り入れてどのフェーズにどれくらいの期間をかけるか、という点を整理します。

ここまでがTop-Down的な計画検討です。

Bottom-Upで決める

次に、Bottom-Up的に計画を作成しますが、その時はスコープが出発点となります。

スコープを基にして、まずはDesignフェーズにどれだけの議論をしなくてはいけないか、という点を整理します。そうすると、Designフェーズにかかる期間がわかるので、それを用いてBuild、そしてBuildフェーズの期間を参考にしてTestフェーズの見積もりをします。

Testフェーズ以降のDeployはスコープの影響は少ないため、大体Deployで2カ月、Hypercareで2カ月が一般的です。

Bottom-upで計画を作成するときは経験がどうしても必要になってくるのですが、作業の進め方としては以下のようになります。

まずはスコープの内容から、SAP導入を進めていくためにどんなことを議論して、どのような内容を決めていく必要があるか、という点を考えます。こうして整理したディスカッションポイントの一覧に、それぞれ誰が議論に参加するか、そして議論の結果として結論を得るまでにどれだけの工数を要するか、という点を見積もります。

工数の合計が算出されたら、あとは毎週何時間程度の時間を議論に割くことが出来るか、という観点で計算し、何週間かかるとすべてのディスカッションポイントに対して結論がつけられるかを計算します。

導入を行うコンサルティングファームやSIerの立場で考えると、SAP導入プロジェクトに100％集中できることを当然と思いがちですが、SAP導入プロジェクト以外にも定常業務を持っている業務ユーザーの立場としてはそう簡単にはいきません。

したがって、業務ユーザーが週に何時間程度の時間をSAP導入プロジェクトに割けるのかという点を確認し、その結果で工数の合計を割ると、何週間かかるのか、という点の試算が出来ます。

既に別のセクションでも触れていますが、業務ユーザーから頂ける工数があまりに少ないとそもそもの計画が破綻しますので、事前に相当程度の工数が必要になるということはプロジェクトのリーダー層から業務ユーザーに対して説明をしておくことが重要です。

こうして見積もった期間が、Designフェーズの期間となります。

あとは、Designフェーズで議論した内容次第でBuild、Testフェーズの期間は決まってくるのですが、そこまではPlanningフェーズの段階では見積もることが出来ないので、Designフェーズの期間と同じ期間をBuildフェーズにあてるか、マイナス1か月して求めます。

TestフェーズはBuildフェーズと同じ期間か、またはマイナス1か月とします。

ご参考：Designフェーズのディスカッションポイントを整理する方法

設計/Designフェーズの期間を見積もるためにディスカッションポイントと議論に要する工数を考える際、過去の経験からなんとなく見積もることが出来る人もいますが、そういった経験をお持ちでない方は大半かと思います。

そういったときに、どうやってディスカッションポイントを整理すればよいのか、という質問に対しては、プロセスフローから始めましょう、というのが私の回答です。

業務の流れを整理したプロセスフローを作ることで、各作業においてSAＰでは何をするか？何が出来るべきか？何がしたいか？という点を整理しやすくなります。

具体的な利用方法は後程別の章で解説しますが、SAPはBest Practice Explorerというものを提供しており、SAPが考える最も良いSAPの使い方がカスタマイズの内容と業務プロセスフローとして提供されています。

これを参照することで、SAPにおける業務の流れというものを理解することが出来ます。

業務の流れを理解したら、それを複数のグループにまとめます。SAPにおいて作成するデータの単位にまとめるとわかりやすいでしょう。

例えば、Purchase Requisition：購買要求を作る業務と、Purchase Order：購買発注を作る業務で大きく分割する、などです。

そうして整理したグループごとに、各作業そのものに関する議論と、データに関する議論が必要となるので、それぞれをディスカッションポイントとします。

作業そのものに関する議論では、誰がその作業をするのか、いつするのか、何を参照してどういった基準で承認などをするのか、自動化してほしいところはあるのか、状況によって異なる対応をするケースがどの程度あるのか、そしてどうやってそうした状況の違いを判別するのか、といった点がディスカッションポイントとなります。

データに関する議論では、データの粒度、手で入力するデータと自動で入力されてほしいデータなどがディスカッションポイントとなります。粒度については、例えば製品のデータがあるとして、製品のシリーズ名を使用するのか、シリーズ内の製品レベルの情報を使用するのか、色情報などを含めた製品コードレベルの情報を使用するのか、などの違いがあるため、こうした部分を整理するための議論が必要となります。

そして、業務プロセスをグループ別に整理した結果、議論が多く必要になるグループについては1時間から2時間の議論を複数回実施する計画にする、というように計画を作成していきます。

担当することになったプロセスや、モジュールによってディスカッションポイントは異なりますし、事前には想定できていなかっトピックが急浮上する可能性もありますので、バッファーとして多めに議論の工数は見積もることが推奨されます。

Bottom-Upの計画をTop-Downのプランに合わせる

こうしてTop-DownとBottom-Upの両方で計画を考えてみると、両者が一致することはほぼありません。

大半は、Top-Downで作成した計画よりも、Bottom-Upで作成した計画の方が長い期間を要するという結果になります。計画としてはBottom-Upで作成したものの方が現実的であることが多いので、あまりに大きすぎる差異が無いのであれば、Bottom-Upで作成した計画を採用してプロジェクト計画書に記述することになります。

その場合は、Top-Downで作成していた計画よりもどの程度各フェーズが長くなるのかを確認し、プロジェクト全体としてそうした期間の延長が許容できるものであるかどうかを判定します。

もし、Top-Downで作成した計画が実は必ず守らなくてはいけないもので、もっと早くプロジェクトを完了させなくてはいけない、という状況になるのであれば、方法としてはプロジェクトのスコープを絞る、または業務ユーザーがプロジェクトに提供できる工数を増やす、といった対応をすることでTop－Downで作成した計画に寄せることが出来ないかを考えます。

スコープを絞れば作業範囲が減るので早くシステム稼働を迎えることが出来ますし、業務ユーザーの工数が増え、設計/Designフェーズで前提としていた1週間に1回の議論を3回に変更することが出来るのであれば、大変ですがもっと早くシステム稼働を迎えることが出来るでしょう。

もちろん、そうして前提を変更する場合は、これまでに作成してきたプロジェクト計画書も修正をすることになります。

Bottom-Upの計画をTop-Downのプランに合わせる方法

• スコープの縮小を行い、議論すべきトピックを減らす
  • 業務ユーザーに求める工数を削減する
• 業務ユーザーがSAP導入プロジェクトに専念できるように定常業務の責任範囲を変える
  • 業務ユーザーがもっとSAP導入プロジェクトに工数を避ける状態にする

最初からBottom-Upだけで現実的な計画を作成すればいいじゃないか、と思う方もいるとは思いますが、このように経営層と現場の認識を整合させるという意味ではTop-DownとBottom-Upの双方での計画作成とすり合わせが必要になるのです。

プロジェクト計画書作成の段階で、Bottom-Upで作成する計画とTop-Down で作成する計画に非常に大きな乖離が出そうだな、と思われる場合はいったん手を止めて関係者と相談をするようにしましょう。

必要なコスト、工数を見積もる

スケジュールが出来ましたら、次はそれに沿ってコスト、工数を見積もることになります。

コスト、工数として見積もるべきは、以下の4つです。

• 社内リソースのコスト（工数、人件費）
• 社外リソースのコスト（コンサルやSIerへの委託費用）
• SAPのライセンス費用
• システム環境費用

社内リソースのコスト

まず社内リソースの人件費（工数）についてですが、SAP導入プロジェクトに関わる組織ごとに見積もります。購買部門、販売部門、SCM部門、管理部門、生産部門、などの現業部門に加えて、経営企画や事業企画などの工数を算出することになります。

事前に関係者と役割を整理していますので、それを活用して誰がどんな活動にどれくらいの期間携わることになるのか、という点を整理しますが、この部分はBottom-Upでのスケジュール作成の作業と一緒に実施を進めることになります。

スケジュール作成のために必要な工数を見積もり、関係者と合意し、関係者と合意した工数を基にしてスケジュールをもう一度修正する、という進め方になります。

プロジェクトの方針にもよりますが、社内のリソースについては工数だけでよいとするケースもありますし、工数に対して人件費をかけることで金額としての費用にすることもあります。この部分は事前にプロジェクトの責任者と確認しておきましょう。

社外リソースのコスト

次に社外のリソースのコストですが、これはコンサルティングファームやシステムインテグレーター（SIer）の費用見積を取ることになります。スケジュールが決まっていれば、それを用いて各フェーズの期間においてどの程度の人員をプロジェクトに投入するのか、という点を整理することであとは月単価と人数をかけてコストが見積もれます。

SAPのライセンス費用

SAPのライセンス費用は、SAP社との契約時に事前に判明していますので、そちらの費用を確認するようにしましょう。ライセンス費用の課金体系はユーザー数に応じて行われるケースや、取引量、または売上金額に応じるケースなど様々ですが、事前に整理できているはずです。

システム環境費用

最後に、システム環境費用です。SAPをクラウド上に置くのであればその費用ですし、オンプレミスの環境で管理するならばデータセンターの費用、サーバー、ストレージ、データベース、ネットワーク等の費用が該当します。

最近はマネージドサービスのクラウドを使ってクラウドサービス事業者に環境の管理を全てお任せするケースが一般的なので、その場合は月当りの費用を確認することでプロジェクト期間中の費用が見積もれるでしょう。

これ等のコスト、工数の情報を表形式にまとめたものをプロジェクト計画書に記載します。

コスト、工数の算出にはある一定の前提事項が伴うので、そうした前提事項も併せて記載します。

例えば、Buildフェーズの社内リソースと社外リソースの工数見積もりについては各業務領域に20件程度の追加開発プログラムが必要になると仮定して、20件の開発作業、開発結果の確認の工数にこれぐらいの工数が必要になると想定した・・・といった具合にまとめます。

詳しい計算についてはExcelでまとめるとすっきり整理できるので、プロジェクト計画書の別添資料としてExcelファイルを付けておく、ということももちろんあります。

ご参考：社外リソースのコスト（コンサルやSIerへの委託費用）を決める要素

日本企業の場合、SAP導入プロジェクトを自社のリソースだけで実施する企業はほぼありません。外資系企業の場合は要件を提示する業務ユーザーが日本にいて、開発などの作業を行うリソースがインドや欧州に存在するというケースもありますが、純粋な日本企業では自社保有の日本人のリソースでSAP導入プロジェクトを進めるというケースはほぼないでしょう。

したがって、必然的にこの書籍を読まれている皆様のケースでは、SAP導入プロジェクトにおいてコンサルティングファームやSIerといった外部のリソースを活用されているか、皆様ご自身がそうした企業のメンバーであるかと思います。

その場合、SAP導入を行う事業会社から外部の委託先に対して委託費用が発生するのですが、この費用を左右する大きな要素についてご紹介します。ずばり、SAP導入プロジェクトの費用を決定するのは開発オブジェクトの本数です。

SAPは基幹業務システムのデファクトスタンダートであり、非常によくできていて、この世界に存在するほぼ全ての業務プロセスをカバーすることのできる標準機能を持っています。しかしながら、SAPはそもそも欧州発の製品ですので、日本の業界固有の商習慣などには対応していないケースもあります。

そのため、SAPが標準機能で対応できない部分に対して手当てするために個別の開発を行うことになります。この、開発オブジェクトの本数によって、コンサルティングファームやSIerへの委託費用は決まります。

しょうもない例で恐縮ですが、例えば日本の場合は平成、令和といった元号が存在しますが、SAP製品はそうした元号という概念を日次の表現として持っていませんので、もしどうしても元号を表示したいという長剣がある場合は追加開発が必要になる可能性もあります。

個別の開発（Add-Onとも表現します）を行うと、その開発オブジェクトのために設計書の作成が必要になり、開発作業、テストが必要になり、結果として作業する人の数が増えます。人の数が増えると、当然ながら委託費用も増えます。

開発オブジェクトの本数が増えると、開発オブジェクトAのロジックと開発オブジェクトBのロジックがバッティングしないよう、うまくプロセスが回るように業務そのものとは全く関係のないシステム的な目線での微修正が必要になってくる、ということも多くなってきますので、さらに工数が必要になってしまいます。

したがって、プロジェクト全体の費用を抑えたいのであれば開発オブジェクトの本数は減らすべきなのですが、日本企業はこれがなかなかできません。筆者の経験としては、一つのSAP導入プロジェクトで、200本などの本数が必要になるケースもこれまでに見てきました。

可能であれば80～100本程度が望ましいのですが、従来より現場の業務ユーザーの意見が強い日本企業では、現場の業務を基本的に守る形式でSAPの方を業務に合わせるという方針でいることが多く、どうしても開発オブジェクトの本数が膨らんでしまいます。

企業によってはなかなか難しい側面もありますが、スピーディに、かつ低コストでSAP導入プロジェクトを完了させるためには開発オブジェクトの本数削減がカギであることはぜひ覚えておいてください。

終わりに

本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおけるPlanningフェーズの作業内容と成果物について解説してきました。

今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。