皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せている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アプローチおける設計、要件定義フェーズにおける作業内容について解説します。要件定義フェーズには多くの作業が発生するのですが、本投稿ではFit＆Gapの実施、プロセスフロー、WRICEFリストの作成までを取り扱います。
なお、実際のプロジェクトの中で皆様が経験されるものと一部異なる点がある可能性がございますが、本投稿で解説する内容は一般的なケースとしてご参考にして頂ければと思います。
Agenda
想定読者
- SAP導入プロジェクトに初めて参加することになった事業会社、SIer、コンサルティングファームの方
- SAP導入プロジェクトを担当するSIer、コンサルティングファームのポジションへの転職を考えている方
SAP初心者向けの投稿記事まとめはこちら
先にこちらのブログで取り扱っているSAP初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。
設計/Design、要件定義フェーズの作業内容、成果物
SAP導入プロジェクトの構想策定/Planningフェーズが終わったら、設計/Designフェーズ、あるいは要件定義フェーズが始まります。
ここでは、事前に定めた業務スコープ内の各領域において、SAPが満たすべき要件の整理と、どのように要件を実装するのか、という点の初期的な設計を行います。ここで主役となるのが、本書籍の想定読者である皆様が所属する、プロセス/Processチームと呼ばれるチームです。
プロセス/Processチームの主な役割は、業務的に実施したい要件をシステム的な設計に落とし込むことで、設計/Designフェーズではまず要件がどういったものなのか、という点を整理します。
設計/Designフェーズで実施する作業と、このフェーズで作成する成果物は以下の通りとなります。
実施する作業
- 要件定義ワークショップの計画と実施
- 要件一覧の作成とFit＆Gapの実施
- プロセスフローの作成
- WRICEFリストの作成
- 開発に対する承認取得
成果物
- 要件一覧/Fit&Gap List
- プロセスフロー
- WRICEFリスト
それでは、個別に各作業についてみていきましょう。
本投稿では、以下2つを取り扱います。
- プロセスフロー
- WRICEFリスト
要件定義ワークショップの計画と実施
要件の整理を行うことを要件定義と呼び、この結果として要件一覧を作成します。
要件定義ワークショップの計画
まず、要件定義ワークショップを計画します。
要件定義ワークショップ（WS）では、業務ユーザーをお呼びし、どのようなシステムにしていくべきなのか、という点を議論することでSAPが実装すべき機能などの要件を決めていきます。
PJの中では、プロセス/Processチームを業務領域に分割し、それぞれの業務領域のチームが要件定義WSを計画します。
構想策定/Planning フェーズにおいて、プロジェクト全体のスケジュールを作成する際にDesignフェーズのディスカッションポイントを整理していました。
要件定義WSを計画する際には、ここであらかじめ整理しておいたディスカッションポイントを、さらに細かくブレークダウンしていき、議論するトピックの一覧を作成します。
構想策定/Planning フェーズでは、プロジェクト全体の計画という意味合いでプロジェクトマネージャー、またはPMOが大まかに論点を整理していましたが、設計/Designフェーズでは、業務領域ごとに分けられたチームが、大まかに分けられた論点をさらに詳細化していきます。
トピックごとに、議論に要する工数を算出することが出来たら、それをWSの計画に落とし込みます。仮に、1回のWSを2時間としているとき、30分で議論できるトピックがあるならばそうしたトピックを４つ、1回のWSに盛り込むことになります。
このように、どのトピックをいつ議論するか、そして議論する際にお呼びするべき業務ユーザーはだれか、また業務ユーザーに答えて頂く必要のある質問（Key Question）も整理しておきます。
要件定義WSの計画が作成出来たら、あとはスケジュールに沿って実行していきます。
要件定義WSを計画する際は、Bufferをあらかじめ設けておくことをおススメします。理由は、要件定義WSの計画時点では見つけられなかった論点が要件定義WSを実行することで見つかり、別途議論が必要なるというケースがあるからです。
要件定義WSを計画してみて、WSの回数が定まったら、その10％～20％程度を追加でBufferとして設けておくとよいでしょう。
要件定義ワークショップで使用するもの
要件定義WSを計画し、実行するといっても、どんなものを準備すればよいのでしょうか。
アプローチはプロジェクトによりますが、一般的にはプロセスフローと、システムデモ環境が事前に準備が必要なものとなります。
既に議論すべきトピックは一覧になっている状況なので、これを議論するにあたって関連する業務領域のプロセスフローをドラフトします。この段階では、議論のたたき台になるものを準備することが目的なので、実際の業務や、To-Beの業務とは異なるものが出来上がって構いません。
したがって、一般的な業務の流れを説明したプロセスフローでもいいですし、既に現業に関するプロセスフローがあればそれをそのまま使用します。
または、SAP Best Practice Explorerで見つけたプロセスフローを使用してもいいでしょう。Best Practice Explorerの利用方法は後段の章でまた解説していますので、気になる方はそちらをご覧ください。
そして、プロセスフローに従って、SAPではどういったオペレーションを取ることになるのか、という点を業務ユーザーに説明することで要件定義WSを進めます。そのため、細かな部分まではカスタマイズは不要ですが、最低限オペレーションのイメージがつかめる程度の状態に設定されたデモ環境を準備します。
要件定義WSでは、まずプロセスフローを確認し、「今からこの業務をSAPで実際に行ってみます」と言いながらSAPのオペレーションを実行し、それに対して業務ユーザーからフィードバックをもらいつつ、議論を行うことで要件を記録し、またプロセスフローの更新を行っていきます。
プロセスフローの作成や、デモ環境の準備は、あくまで要件定義の議論を行うためのたたき台として行うものなので、実際の業務の流れとの違いなどは意識する必要はありません。違いがあるのであれば、それは要件定義WSの中で業務ユーザーが責任をもって指摘することになります。
重要なのは、そうした指摘をきちんと記録し、「ではどのようなプロセスフローにすべきなのか」、「どういった機能を実装すべきなのか」と問いかけながら、SAPが実装すべき要件をクリアにしていくことです。
ご参考：海外拠点などの複数拠点を巻き込んだGlobal Templateの構築
なかなかに難しいケースになるのですが、海外拠点などを巻き込んで要件定義を行うという場合はどのように要件定義を行うのでしょうか。ここでは、筆者が過去に経験したプロジェクトの事例をご紹介します。
状況としては、日本に本社を持つ企業が世界各地に持つ拠点にSAP導入を行うプロジェクトを計画していました。プロジェクトのリーダー層は迅速かつ低コストに全世界の拠点にSAP導入を完了させたいと考えており、Global Templateの構築を考えていました。
Global Templateというのは、全世界に複数の拠点を持つ企業がそれぞれの拠点に対して迅速にSAP導入を行う際のアプローチの一つです。
SAP導入を全世界の複数の拠点に行う際、あらかじめどの拠点でもある程度はそのまま使えるようになっているカスタマイズや開発を行ったものをテンプレート（これをGlobal Templateと呼ぶ）として構築しておき、それを各拠点に導入した後で少しだけ各拠点の要件に合うように微修正を加えることで迅速にSAP導入を完了する、というものがGlobal Templateを用いたアプローチです。
まず本社などが主導してGlobal Templateを構築し、それを全世界の拠点に配る、という取り組みをGlobal Roll Outと表現し、反対に自社が本社ではなく拠点である場合はこうした取り組みをGlobal Roll Inと表現します。
筆者の経験した事例では、まさにGlobal Roll Outを考えていて、まずGlobal Templateを構築することが必要でした。しかしながら、日本本社だけでGlobal Templateを作成しようとすると日本固有の要件ばかりが入ったテンプレートになってしまうので、日本についでビジネスのボリュームが大きかった欧州の拠点も巻き込んで要件定義を行い、Global Templateを構築しよう、というアプローチをとることになりました。
そのため、要件定義の参加者が日本のメンバーと、欧州のメンバーとなりました。このプロジェクトでは、日本と欧州の間で議論を行い、両者に共通している要件をGlobalの共通要件として整理し、日本固有、もしくは欧州側固有の要件であるものはGlobalの共通要件ではないものの日本固有あるいは欧州固有の要件（Region要件と呼ぶ）として整理することでした。
一度の議論では何がGlobal要件で、何がRegion要件なのかを整理することが非常に困難であったため、1つのトピックに関する要件定義WSを合計4回に分けて実施するというアプローチをとりました。
一度目のWSには日本と欧州の業務ユーザーの双方を招集し、コンサルティングファーム側からSAPが提供する基本的な機能などの解説を行います。ここでは、まだ要件の議論まで踏み込みません。
その後、日本と欧州にそれぞれ分かれて議論を行い、ここで一度目のWSで説明を受けたSAPの基本機能に対する要件を議論します。ここで、「こういう機能が追加で欲しい、それはSAPの標準機能で実現できるのか」という議論を行います。
その後、再度日本と欧州のメンバーを集めて議論を行い、各Region別に議論した「こういう要件が必要だと思っている」という内容を共有します。ここで、「その要件はこちらのRegionと同じものだ」と判定されるものがGlobal要件とし、Global Template構築の際に取り入れられ、「その要件はこちらのRegionには無いな」と判定されるものはRegion固有の要件とする、ということをルールとして要件定義を実施しました。
一つのトピックで複数回議論することになってしまいますし、どこまで同じであれば共通の要件であるとするのか、という部分を明確に定義することはなかなかにハードでしたが、一つの事例として共有させて頂きます。あくまで一つの事例としてとらえて頂けますと幸いです。
要件一覧の作成とFit＆Gapの実施
要件定義WSを実施する際、並行して要件一覧という成果物を作成します。
要件一覧とは、言葉の通り、各業務領域において確認されたSAPが実装すべき要件を一覧にしてまとめたものです。
要件定義WSの中で要件が確認された場合、その要件がSAPの標準機能が対応できるかどうかを判定していきます。
標準機能が対応できる場合はSAPの標準機能に対してFit、対応できない場合はSAPの標準機能からのGap、と表現し、こうしたSAPの標準機能が対応できるかどうか判定を行うことをFit＆Gapの実施と言います。
Fit＆Gapの判定はSAP導入プロジェクトの経験を持つコンサルティングファームやSIer が判定を行います。
Fit＆Gapの実施結果も、要件一覧に記載していくことになります。以下に、最終的に出来上がる要件一覧のイメージを記載します。
要件一覧は文字通り、要件を一覧化してまとめたものですので、どういったことを実施したいのか、という内容を簡潔に、あとで誰が見ても理解できるように記録します。同時に、要件として記録する際に、SAP標準機能で対応できる要件なのかどうかをFit/Gapとして記録します。
要件定義WSでは一般的にプロセスフローを用いるということを解説しましたが、ここで要件を記録する際、どの業務領域の、どのプロセスに関係する要件なのか、という点をしっかり記録するようにしましょう。
要件定義をする際は、要件の記録と一緒にプロセスフローを整理していきます。その際、要件の変更はプロセスフローの変更につながる可能性がありますし、その逆ももちろん発生します。
そこで、要件を1行1行記録するさいには、どの業務領域の、どのカテゴリーの、どのサブカテゴリ―、というように詳細に関連するプロセスの情報を記載します。ここで役に立つのが、あらかじめプロセスフローにIDを振っておき、要件と一緒にプロセスのIDを記録しておくことです。
プロセスフローはこちらの図のように階層構造になっており、それぞれのプロセス、あるいはタスクと呼ばれるものに固有のIDを振って管理します。これがプロセスIDと呼ばれるものであり、要件を記録する際には要件とセットでプロセスIDを記録します。
こうすることにより、どのプロセスがどの要件に関連しているのか、という情報が一覧化できることになります。
プロセスフローの作成
既にプロセスフローについては触れていますが、プロセスフローの作成（更新）も設計/Designフェーズで行う大事な作業です。
要件定義WSの準備の段階でドラフトしたプロセスフローがあれば、要件の記録と合わせて更新をかけていきます。SAP導入プロジェクトにおいては、プロセスフロー作成の際に以下の要素を整理し、プロセスフローと一緒に別資料などで整理します。
プロセスフローに含める要素、または別資料として整理する要素
- プロセスID
- プロセス名
- トランザクションコード
- オペレーションの内容
- オペレーション実行を行う部門、部署
プロセスフローは、様々なタスクの流れを整理したものになります。それらのタスクの一つ一つに、固有のIDであるプロセスIDを割り振ります。このIDは、当然ながら重複しないように管理します。また、プロセスIDに対して1対1になるように、プロセス名を整理します。
次にトランザクションコードです。SAPでは、システムのプログラム一つ一つにトランザクションコードというIDのようなものが割り振られています。これは単なるIDではなく、SAPの画面上で打ち込むことでそのプログラムを実行することが出来るというものなのですが、プロセスフローを作成する際にはこのタスクはどのプログラムで実行するのか、という点を整理する必要があります。
プログラムを介さないタスクであればトランザクションコードはブランクとなります。
各タスクで実施する作業、つまりオペレーションの内容を整理します。プロセスフローは流れを可視化することを目的としており、事細かな作業内容を記録するのには向いていませんのでえ、別資料に記載を行います。
最後に、各タスクを行う部門、部署を整理します。この情報は、あとでプログラムの実行を行うことが出来る権限を整理するときのインプットになります。
WRICEFリストの作成
ここまでで、要件定義WSを行いながら要件一覧とプロセスフローの作成を進めるということを解説してきました。もう一度、要件一覧を確認してみましょう。
要件定義WSが終盤に差し掛かってくると、要件に対してどのように実装しようか、という想定ソリューションを考える必要が出てきます。
要件がFitと判定されているものも、Gapと判定されているもののどちらも想定ソリューションを整理しますが、Fitの場合はSAP標準機能をどのようにカスタマイズして実装するかという点を記述し、Gapの場合はどういった開発を行うのか、という内容を記述します。
SAPで行う開発ですが、WRICEF（ライセフ）と表現します。この部分は、別の投稿で詳細をご紹介しますが、まずは概要をご説明します。
開発(WRICEF)オブジェクトの概要
SAPが備えている標準機能で対応が出来ない機能が求められた場合に開発するものが、WRICEF（ライセフ）オブジェクトとも呼ばれる、開発オブジェクトです。
プロジェクトによってはアルファベットの順番を変えてFRICEW（フライス）と呼んでいるケースもありますが、
開発オブジェクトは内容を分類分けすると以下の6種類に分けることが出来るため、それぞれの頭文字をとってWRICEFと呼んでいます。
- WRICEF
- Workflow
- Report
- Interface
- Conversion
- Enhancement
- Form
より詳細に把握されたい方は別セクションでの詳細解説をご参照ください。
要件定義WSの終わりに近づいたタイミングで、要件一覧上でGapと判定されたものを実装するためには、どういった開発が必要になるのか、という点を考えます。このとき、大事なのはW・R・I・C・E・Fのうちのどの機能の実装が要件の充足に必要なのかを考える点にあります。
そこで、想定ソリューションとして、「XXXXを行うReportを開発する」、「XXXXを行うEnhancementを開発する」という具合にどんな開発が必要になるのかを記述します。
そして、一通りGapとなっている要件に対して想定ソリューションを整理した後に、まとめることが出来るものがないかを考えつつ、開発オブジェクトに対してこれまた固有のID、つまりWRICEF IDを割り振ります。
仮に、同じプロセスIDのタスクに関連する要件で、想定ソリューションがともにEnhancementであった場合、要件が2つだったとしても1つの開発オブジェクトで2つの要件をまとめて実装することにする、といった具合に整理を行います。
気を付けたいのは、反対に1つの要件であるものの2つの開発オブジェクトが必要になりそうだ、というケースも存在することです。そういった場合は、そもそもの要件を2つに分割し、開発オブジェクトの数に分けるようにしましょう。
なぜ要件を分割するのかについてですが、これは後続のステップの開発に対する承認取得と関係します。
開発するオブジェクトの一覧を整理すると、そのあとどの開発オブジェクトを作って、どれを作らない、という整理をすることになるのですが、その時には開発オブジェクト1つ1つに対して判定を行っていくため、1つの開発オブジェクトがどの要件と結びついているのか、という点を明確にする必要があります。
2つの開発オブジェクトで1つの要件を実装する、という状況だと、正しく判定できなくなる可能性があるので、要件を分割するという手法が一般的となります。
要件一覧に対して、想定ソリューションの整理と、WRICEF IDの割り振りが完了したら、WRICEFオブジェクトだけを抜き出したWRICEFリストという成果物を作成します。
ただ要件一覧から開発オブジェクトを抜き出して作るというものではなく、ここからさらに情報を付け加えてWRICEFリストを最終化します。
WRICEFリストに含める要素
- 開発難易度
- 開発工数
- Must have/Nice to have
- ビジネスインパクト
- 代替案（Workaround）
WRICEFリストは個別のWRICEFオブジェクトを一覧にしたものですが、ここにまず開発難易度と、それに応じた開発工数を記載します。難易度の測定と工数の算出はコンサルティングファームやSIerが実施します。
次に、そのWRICEFオブジェクトは必須なのか、あればいいというものなのか、を整理します。（Must have/Nice to have）
そして、開発が行われた場合の影響としてビジネスインパクト、また開発がされなかった場合に代替策があるかどうかを整理します。
なこうした情報を整理するのかというと、こうした情報を基に次のステップである開発に対する承認取得の議論が行われるためです。 開発オブジェクトは、数が増えるとプロジェクト全体の費用の増加、期間の延長につながるため、基本的には少なければ少ないほど良い、というものになります。そのため、不要なものであれば開発しないようにすることが必要なのですが、そうした開発する/しないの判断を行うために、難易度、工数、必須かどうか、ビジネスへのインパクト、そして代替策があるかどうか、というものが必要になるわけです。
開発に対する承認取得
WRICEF一覧が出来上がったら、次にそれらの開発を本当に行うのかどうか、という判断を行います。
要件定義WSは各業務領域別に実施してきましたので、開発に対する承認取得もまた、各業務領域別に議論していくことになります。
業務領域別に要件定義WSを行ってきたプロセス/Processチームが、自分たちが必要だと判断したWRICEFリストを基に、プロジェクトのリーダー層へ開発の必要性をプレゼンします。
もちろん、事前にWRICEFリストを見直し、自分たち自身で「この開発は、そんなに重要度が高くないので取り下げよう」といった判断をしたうえで、自分たちで本当に必要だと思っているものについて、開発を行うことの承認を申請します。
リーダー層は、ビジネス的なインパクトや、工数を考慮して、開発を行うことについての是非を判断します。プレゼンしてもらった内容だけでは判断が出来ないという場合には、Processチームにもう一度なぜ必要なのかがわかるように情報を整理してほしい、という形でコミュニケーションをとることになるので、プレゼンを一回だけして承認を取得完了、となることは稀なので、複数回の打ち合わせを予定しておくことが一般的です。 さて、ここまでが設計/Designフェーズの作業内容と、成果物のお話しでした。ここまでで、要件が確定し、開発を行う対象が確定しましたので、あとは実際に開発を実施していく作業が始まります。
終わりに
本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおけるPlanningフェーズの作業内容と成果物について解説してきました。 今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。