【初心者向けざっくり解説】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初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。

システム導入における前提事項を決める

さて、SAP導入プロジェクトの目標、スコープ、全体構成が出来上がったとしましょう。

ここでいったん視点を変えて、こうして整理してきた内容を実際に活動に落としていく際に必要となる前提事項を整理します。

前提事項を列挙する際の視点は、主に以下のようなものとなります。

• プロジェクト目標について
• スコープについて
• システム構成について
• リソース（人材）について
• スケジュールについて
• プロジェクトの体制について

プロジェクト目標について

プロジェクト目標の設定の背景と根拠を示します。

例えば、事業計画や中期経営計画で定められた目標がそもそものプロジェクト目標設定の大きな理由である場合はそれを明示します。

また、仮に事業計画や中期経営計画が修正された場合にはプロジェクト目標の修正なども発生する可能性がある、ということについてプロジェクト計画書の中で触れておきます。

スコープについて

プロジェクトのスコープ定義の背景について記載します。

プロジェクト目標の時と同様に、なにか大きな見直しをかけなくてはいけないような事態になった場合は修正する可能性もあることをプロジェクト計画書の中で示します。

システム構成について

システム構成は、いつ時点で考案したものなのか、という点について触れます。

例えば、新たなテクノロジー、または画期的なシステムが登場した場合には修正をかけたほうが良いと判断される場合もあるでしょう。

そうしたときには柔軟に対応をとる、ということもプロジェクト計画書の中で触れておきます。

リソース（人材）について

プロジェクトを推進していくには、関係各者の協力が欠かせません。

リソースに関する前提として、情報システム部門などの協力はもちろん、業務ユーザーとなる事業部門の方々の協力が不可欠であることを示します。

よく問題になるのは日々の業務を持たれている事業部門の方々にも協力をしてもらう必要がある、という点になり、これをあらかじめ了承して頂くことがSAP導入プロジェクトでは必須となります。

前提として定義しておかないと後で事業部門の方々から協力を断られる可能性にもつながりますので、きちんと前提事項として触れておきましょう。

関係者の工数については、コスト、工数の見積を提示するセクションで詳細に触れることになりますが、そうした工数を関係者から提供してもらえることが前提である、ということをあらかじめプロジェクト計画書の中で触れておくという意味合いになります。

もちろん、前提事項として計画書の中に記載しておくだけではだめで、ちゃんと事業部門の方々に「このプロジェクトにはこれくらい関与して頂きますので、あらかじめご理解のほどよろしくお願いします」と認識合わせをしておきましょう。

スケジュールについて

SAP導入プロジェクトのスケジュールを検討するうえでの背景についても前提を整理しておきます。

特定のシステムのサポート切れがあり、SAP導入がそのサポート切れへの対応という位置づけでもある場合は、いつまでに対応を終えなくてはいけない、といったタイムラインに関する制約があることも触れておきましょう。

また、仮に明確な導入完了の期限、つまりDead Lineがある場合に、その期限を守れそうにない場合はどのようなオプションがあるか、またどういったことを考慮しながら対応方針を定めていくのか、という点をプロジェクト計画書の中で記述しておきます。

プロジェクトの体制について

プロジェクトの体制についても基本的な考えをプロジェクト計画書の中で示す必要があります。

どの部門が責任をもってプロジェクトを進めていくのか、システムベンダーやコンサルティングファームにはどういった役割を持ってもらうのか、という内容を記述します。

日本国内だけのプロジェクトであれば、比較的考えることはシンプルなのですが、仮に海外のグループ会社にも同時にシステム導入を行うというケースであった場合は、海外のプロジェクトと日本のプロジェクトをどのような体制で管理するのか、という点について触れておくことは非常に重要となります。

体制の案については様々ありますが、主に以下のような体制図が考えられるでしょう。

1つ目は、海外と日本で別々の体制を持つことです。

これは最も一般的かと思います。

２つめは、海外と日本でPMOだけは共通させておくというものです。

海外、日本という地理的な違いはあってもスケジュールや課題の状況は同じように取り扱いたいときはこうした体制になります。

3つ目は、海外と日本で同じプロジェクトチームが対応を行う、というものです。

海外と日本でシステムや業務、そしてスケジュールを厳密に同期させていかないといけないとき、そして言語の問題がクリアできるときはこうした体制が良いでしょう。

ただし、人数自体は海外と日本で別々の体制を持っているケースと同じくらいの規模が必要です。

4つ目は、海外と日本でProcessチームに関しては特に連携することを明示する体制です。

体制自体は海外と日本で別々の体制を持っていますが、業務プロセス自体は標準化させたい、つまり同じ業務にしたいという意思が強い場合は、明示的にProcessチーム同士が連携するということを体制で示します。

この部分はプロジェクト内のルールまたは仕組みとして連携する、という扱いにしてもいいですし、連携させることに責任を持つチームを置く、ということも案としては可能ですので、こうした前提事項をプロジェクト計画書の中では触れておきましょう。

具体的な人の名前なども入れた体制図は、また別途議論し、プロジェクト計画書に含めることになります。

関係者と役割を整理する（組織体制）

ここまでで、プロジェクトの目標、システムの構成、スコープ等が明確になってきました。

次に、これらのプロジェクトを実際に進めていく関係者とその役割を整理します。

ここでは、先ほど整理しておいたシステム導入の前提事項の一つである、体制を詳細化します。

そして、体制図をさらに分解し、Roles and Responsibility（R&R：役割と責任）の表にまとめます。

体制図は、プロジェクト全体の中にどういったチームがあるのか、そして誰が誰に何を報告する義務があるのか、という点がグラフィカルにわかるようにしているものです。

体制図にはチームの名称と、そのチームでリーダー(LeaderあるいはLead)の役割をする人の名前を入れておきましょう。

次に、Roles and Responsibilityの表では、各チームのメンバー全員の名前と、Role（役割）、Responsibility（責任）を記述します。

特に、各チームにはリーダーの役割を持つ人と、チームのメンバーとしての役割を持つ人がいますので、そうした点は明確に区別します。

また、サンプルの図で示しているR&Rの表では、プロセス/Processチームがさらに業務領域ごとにOrder to Cash（販売業務）、Procure to Pay（購買業務）といった具合に分割されています。

このように体制図では触れなかったものの、実際にはもっと細分化されて役割と責任を分けている、という場合にはR&Rの表では実態に合わせて記述を行うようにします。

ここで人の名前を入れておくのは、「貴方にはこういう役割とこういう責任があります」ということをプロジェクト内外の人たちに知らせるという意味を持ちます。

なお、プロジェクト計画書を作成している段階では、設計フェーズのことはイメージ出来ていても、開発フェーズやテストフェーズのことはイメージできないということもあるので、体制図やR&Rの表のうちのいくつかのチームは人の名前までは入れられない、というケースもあるでしょう。

もちろんそうしたケースでは人の名前は「TBD」と入れておいて問題ありません。

その場合でも、いつかこうした役割と責任を持った人がプロジェクトに必要になる、ということをあらかじめ関係者と合意しておくという意味で、プロジェクト計画書に役割と責任については記載を行いましょう。

専任のメンバーを置く、または相当の工数を確保することが重要

ここで一点、非常に重要なポイントがあるのでご紹介しておきます。

多くのSAP導入プロジェクトにおいてボトルネックになるもの、プロジェクト遅延の原因になるものがあるのですが、それは何でしょうか。答えは、業務ユーザーの工数確保です。

SAP導入プロジェクトをコンサルティングファームやシステムインテグレーター/SIerなどの外部ベンダーに依頼する場合、これらのメンバーは100％SAP導入プロジェクトに専念してくれます。一方で、依頼をする側の企業側でSAP導入プロジェクトに関わる業務メンバーの工数が確保できないというケースが多々存在します。

例えば、物流改革を目的としたSAP導入プロジェクトでは、購買業務、販売業務、倉庫管理業務などの業務に精通した業務ユーザーの方がプロジェクトに関与して頂く必要がありますが、そうした方々は当然、SAP導入プロジェクト以外にも、普段から実施している定常業務に責任を持っています。

しかしながら、SAP導入プロジェクトは相当の負荷がかかるものであり、フェーズにもよりますが打ち合わせだけで週に4時間から8時間といった工数が必要になってくることもあります。もし複数のチームの作業を兼務するような方であった場合はこれが2倍、3倍になる可能性もあります。

したがって、基本的にSAP導入プロジェクトが始まる以前の定常業務をそのまま実施しながらSAP導入プロジェクトに関与していく、ということは不可能に近いということをプロジェクトのリーダー層は理解したうえで関係者とその役割を整理する必要があります。

業務ユーザーが、週にどの程度の工数をかける必要があるのか、という部分について見通しが甘い状況でプロジェクトが始まると、後になって「そんなにSAP導入プロジェクトのためだけに時間は取れない」という状況になり、成果物の作成が進まない、レビューが進まない、結果としてプロジェクト全体の作業が遅れる、という事態に陥ります。

こうした事態を防ぐためには、SAP導入プロジェクトを開始する際には定常業務から離れた専任の業務ユーザーを置く、あるいはある程度定常業務の負荷を減らすことを確約し、きちんと工数を定常的にとれる状況にすることが必要となります。

具体的にどれくらいの工数が必要になってくるのか、という点はまた別途整理することになるのですが、SAP導入プロジェクトは定常業務を行いつつ、片手間に対応するだけで出来るものではないということを理解したうえで関係者の整理を行うようにしましょう。

各フェーズの成果物一覧を定義する

それでは次に、各フェーズでどのような成果物を作成するのか、というものをまとめます。

既に体制図とR&Rの表を作りましたので、その情報もここでは活用し、各フェーズにおいて、どのチームが、どの成果物を作成するのか、という内容を表形式でまとめます。

構想策定/Planningフェーズの成果物として表の中に記載しているProject Planning Documentはこれまでに解説しているプロジェクト計画書のことで、Project Kick Off　Documentはプロジェクトキックオフ資料のことを指しています。

終わりに

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

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