皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せている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フェーズには多くの作業が発生するのですが、まずはその中でもプロジェクトの目標設定、システムの目標設定、スコープの決定、そしてシステム全体構成のドラフトまでを取り扱います。
なお、実際のプロジェクトの中で皆様が経験されるものと一部異なる点がある可能性がございますが、本投稿で解説する内容は一般的なケースとしてご参考にして頂ければと思います。
Agenda
想定読者
- SAP導入プロジェクトに初めて参加することになった事業会社、SIer、コンサルティングファームの方
- SAP導入プロジェクトを担当するSIer、コンサルティングファームのポジションへの転職を考えている方
SAP初心者向けの投稿記事まとめはこちら
先にこちらのブログで取り扱っているSAP初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。
構想策定/Planningフェーズの作業内容、成果物
SAP導入プロジェクトは、まずは構想策定/Planningフェーズから始まります。
ここでは、SAP導入プロジェクト全体の計画を作ります。SAPを導入する対象の業務領域、SAP製品の中で使用する機能モジュール、プロジェクトに関わるチームの体制や、各チームがいつ何を実施するのか、という点を明らかにしていきます。
構想策定の段階では、まだSAP導入プロジェクト固有の用語が出てくることはそこまで多くありません。そのため、このセクションの解説は比較的一般的なシステム導入プロジェクトの内容に近いものにとどまりますが、子のフェーズで実施する作業と、作成する成果物は以下の通りとなります。
実施する作業
- プロジェクト目標を定義する
- システム目線の目標を定義する
- 業務目線、システム目線のスコープを議論する
- システム全体構成を決める
- システム導入における前提事項を決める
- 関係者と役割を整理する
- 各フェーズの成果物一覧を定義する
- 進捗管理、成果物管理、変更管理の方法を決める
- プロジェクト全体のスケジュールを決める
- 必要なコスト、工数を見積もる
- 投資対効果の推定、評価方法を検討する
- プロジェクトの実行計画書を作成し、承認を得る
- プロジェクトキックオフ資料を作成する
成果物
- プロジェクト実行計画書
※以下の要素を含む（以下要素を個別に成果物とするケースもある） - プロジェクト目標
- システム目標
- プロジェクトの対象スコープ
- 想定システム全体構成
- プロジェクトの前提事項
- プロジェクト体制（R&R）
- 成果物一覧
- プロジェクト管理方針
- プロジェクト全体スケジュール
- プロジェクト工数、コスト見積
- 投資対効果の推定結果、評価方法
- プロジェクトキックオフ資料
作業は色々ありますが、最終的にはプロジェクト計画書という、プロジェクトの目標、運営方針、スケジュールや工数などをまとめた文書を作成し、プロジェクトの責任者から「これでプロジェクトを進めていく」ということに対して承認をもらうことが主な活動となります。
承認を得られたら、そのあとはプロジェクト計画書から一部を抜粋するような形式でプロジェクトキックオフ資料を作成します。これは、プロジェクトの関係者と「これからプロジェクトを始めますよ、よろしくお願いしますね」というふうに認識合わせを行うための資料です。
それぞれ、詳細に見ていきましょう。
プロジェクト目標を定義する
プロジェクトの構想策定、Planningフェーズでは、まずプロジェクトの目標を決めます。
そもそもどういったことを実現したいのか、という内容を文章にしたためることになるのですが、多くの場合は事業計画、中期経営計画などの中にある戦略的な目標がインプットになります。
例を挙げておきましょう。
- SAP導入を通じてデータドリブン経営を実現する基盤を構築する
- SAP導入を通じて製造、販売、調達業務を効率化し、コストの最適化を図る
プロジェクト目標というのはいわばビジネス的な目標のことで、この段階ではまだそこまで具体的な内容には落とし込む必要はありませんが、まずはプロジェクト目標をプロジェクト計画書に記述します。
システム目線の目標を定義する
プロジェクト目標が定まったら、それをインプットとしてシステム目線の目標を定義します。
ここでは、先ほどのビジネス目線での目標がより具体的な内容になっていきます。
SAP導入が、どのようにビジネス目線での目標の実現を行うのか、という部分がわかるようにシステム目線での目標が定義されます。
システム目標サンプル
先ほどのプロジェクト目標の例を用いて、どのようなシステム目標がたてられるのか、サンプルをご紹介します。
- プロジェクト目標：
- SAP導入を通じてデータドリブン経営を実現する基盤を構築する
- システム目標：
- SAP導入を通じてグループ内の拠点における顧客対応で得られるデータを取得し、統一フォーマットで管理することを可能とする
- SAPに取得した顧客データを用いてKPI管理を行い、データに基づく販売施策の立案、検討、評価を行う業務サイクルを確立する
- SAP導入を通じて財務会計、管理会計データを全グループ企業から自動収集し、連結業務の効率化を図るとともに迅速な予実差異分析機能を具備し、戦略的意思決定のスピードを速める
- プロジェクト目標：
- SAP導入を通じて製造、販売、調達業務を効率化し、コストの最適化を図る
- システム目標：
- SAPの需要予測モジュールの導入を行い、従来のマニュアルでの需要計画をシステム化、計画策定業務全般の効率化を行うとともに在庫削減を実施する
- SAP導入を通じて各拠点の調達業務を標準化し、効率的な購買活動の実施、仕入先評価を実施し調達コストの低減を行う
- SAP導入を通じて販売管理と物流管理を一体化させ、効率的なオペレーションを実装し顧客への納品リードタイムを短縮し、サービスレベルを最適化する
ここでたてたシステム目線での目標は、定性的な目標と定量的な目標にさらに分解されますが、いずれの場合においてもプロジェクトが完了した時点で評価することになります。
後で評価を行うために、定量的な目標については具体的な数値での目標を設定することが必要となります。
定量的な目標の例としては、以下のようなものとなります。
- 連結業務の作業工数のXX％削減
- 需要予測の精度XX％向上
- 期末在庫をXX%削減
- 納品リードタイムをXX％削減
議論の最初の段階では具体的な数値を決めず、まずはどんな指標を定量的な目標に使用するのか、という点を明らかにしておくことが一般的です。
このあと、システムのスコープなどを検討していくことになるので、それに応じてシステムが出来ることも変わっていきます。具体的な数値目標はPlanningフェーズの最後に実際に試算してみて定めるということになります。
数値目標の設定時は、積み上げ方式で計算するという方法か、ベンチマーク情報を活用するという方法があります。
積み上げ方式で作成するシステム目標サンプル
積み上げ方式は、作業工数などについて用いることが出来る方法です。
サンプルは以下の通りです。
- 算出したい定量的な目標
- 連結業務の作業工数の削減（％）
- 目標設定の根拠
- システム導入により、連結に要する調整作業が自動化される
- 計算方法
- 現状の連結業務をプロセスフローで整理する
- プロセスフローの中のどの作業にどの程度の期間/工数をかけているのかを明らかにする
- システム導入により、プロセスフローの中のどの作業が自動化されるのかを明らかにする
- (自動化された作業が占めていた工数) ÷ (自動化前の作業工数全体)を計算する
⇒システム導入による作業工数の削減（％）がわかる
ベンチマーク方式で作成するシステム目標サンプル
ベンチマーク情報を活用する場合についても解説しておきます。
SAP社の場合は、システム導入によってどういった効果がどの程度見込めるか、という内容について過去事例を調査し、まとめていますので、それを活用させてもらおう、という方法です。
サンプルは以下の通りです。
- 算出したい定量的な目標
- 期末在庫の削減（％）
- 目標設定の根拠
- システム導入により、需要予測精度が向上し、結果として在庫削減が見込める
- 計算方法
- SAP社提供の対売上高在庫削減効果（％）を参照する
- (自社の売上)×(SAP社提供の対売上高在庫削減効果)を計算する
⇒在庫削減金額がわかる
- (在庫削減金額)÷(自社の在庫金額)を計算する
⇒在庫削減効果（％）がわかる
プロジェクト計画書の中ではこれらの定量的目標の計算根拠などはAppendix資料として含めておくようにしましょう。
業務目線、システム目線のスコープを議論する
プロジェクト目標、そしてシステム目線の目標が定めたら、それらをインプットとして、業務目線とシステム目線のスコープを検討します。
ここまでに何度かスコープという言葉を使ってきましたが、あらためてスコープとは何か、解説しておきます。
スコープとは、仕事を行う範囲、作業の範囲、検討を行う領域のことを指します。
プロジェクトでは、あらかじめ作業の計画を作成することになるわけですが、何から何までがプロジェクトの作業の中に含まれ、そして逆に何が入らないのか、という点を明確にする必要があります。
こうした、何がスコープの中に入るのか（Scope In）、何が入らないのか（Scope out）、という点を明確化するのがスコープの定義と表現されます。
スコープは業務的な目線とシステム的な目線の双方で検討する必要があり、それらのインプットは前工程で定義したプロジェクト目標とシステム目標となります。
スコープの整理の方法は様々ありますが、業務スコープ、システムスコープの双方に共通する方法は表形式での整理となります。
表形式で整理する場合には、業務またはシステムを細分化してリストアップし、どれがスコープに含まれ、どれが入らないのか、という点を整理します。
このとき、必要に応じて業務もシステムもより細かな粒度に分解をしていきます。
例えば、販売管理のシステムを導入する場合、単純に業務を販売管理と大きなくくりで表現するのではなく、案件登録、受注登録、見積作成、といった具合に細かな単位に分解します。そうすることで、何がスコープに入っていて何が入っていないのかが明確にできるのです。
同様に、システムについては、単純に基幹システムという呼び方をするのではなく、販売管理モジュール、購買管理モジュール、財務会計モジュール、というように細分化し、どの機能部分がスコープに入るのかが明確になるようにします。
業務スコープについては、プロセスフローでスコープを定義する方法もあります。
業務の流れをプロセスフローとして整理し、どこからどこまでの業務に対してシステム導入がされるのか、という点を整理します。
プロセスフローを用いたスコープ整理は、表形式でまとめたケースに比べて理解しやすいというメリットがある一方、プロセスフローを作成するのに時間を要するというデメリットもあります。
システムスコープについては、システムダイアグラムでスコープを定義する方法もあります。
既存のシステムの状況、つまり現在の状況を整理し、その状況がこれから行うシステム導入によってどう変化するのかを整理することで、何がどう変わるのかを図示します。
そして、変化する部分がスコープである、という定義をします。
表形式で整理する方法は手軽にできる一方で、現況をよく理解できている人でないと抜け漏れが発生してしまいます。したがって、プロセスフローでの整理、システムダイアグラムでの整理は一定程度、取り入れることが一般的です。
システム全体構成を決める
スコープが決まりましたら、次にシステム全体構成を決めます。
システムスコープの部分でシステムダイアグラムを既に作成している場合は、それがインプットになります。
どのようなものがシステム全体構成と呼ばれるのか、サンプルを以下に示します。
システム全体構成では、システム同士の関係性を整理します。
システムが持つ機能が比較的シンプルな場合は単純にAシステムとBシステムの間で連携をする、というように整理しておくだけで十分なのですが、SAPは基幹業務システムであり、様々な機能をモジュールという形式で保有しています。
そこで、SAP内のどのモジュールが他の製品と連携をするのか、という点を整理することがシステム全体構成の目的となります。
特に注意が必要なのはシステム同士の連携部分について、あらかじめどのような方法で連携を行うのか、という点を整理しておくことです。
詳細は割愛しますが、連携の方法にもフラットファイル連携、DB連携、バッチ処理での連携、RPAの活用、など様々な方法があるので、この時点である程度のめどをつけておくことが重要となります。
また、サンプルとしてお見せしている図の中にはアプリケーションのことしか記載がありませんが、各アプリケーションが存在するサーバー情報、インスタンス情報、などのインフラ寄りの情報も併せて整理する必要があります。
ここでお見せしたサンプル図では、システムとその内部のモジュールまでの情報を取り扱っていますが、具体的にどういった情報、データのやり取りを行うのか、という点まで具体的に整理したものをシステム全体構成と呼ぶこともあります。
プロジェクトの作業範囲（Scope）が大きいと、システム全体構成に含まれる範囲も大きくなるのでそこまでは書かないものとする、というケースもありますが、比較的作業範囲が狭い場合は具体的にどういった情報、データをシステム間でやり取りするのか、という部分をあらかじめ整理しておくケースが一般的です。
例として、SAPのOrder Management、Inventory Management、Material Managementモジュールが非SAP製品のSPMと連携をする部分がプロジェクトの作業範囲（Scope）であったとして、その部分を抜き出してみると、次の図のようになります。
こちらの図では、SAP内の各モジュールと、SPMという外部のシステムがどのような情報を送りあうのか、という点が整理されています。
まだまだ詳細化の余地はありますが、構想策定の段階ではここまでの粒度でシステム全体構成を定義しておけば問題ありません。より詳細なデータ連携の仕組みについては、設計/Designフェーズにおいて機能設計図書（FS：Functional Specification）という文書に記載します。
終わりに
本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおけるPlanningフェーズの作業内容と成果物について解説してきました。 今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。