SAPプロジェクトではプロジェクトごとにチームの切り口が異なります。
チームの切り方により、それぞれメリット・デメリットがあり、こう動いた方が良いというのが変わってきます。
この記事では私がこれまでに経験してきた体制についてお話します。
SAPプロジェクト体制-2つのパターン
SAPプロジェクトの体制は大きく2パターンあります。
- モジュールカット
- 業務部門カット
モジュールカットはSAPのモジュールごとにチームを切ることです。ただこれにもいくつかパターンがあるので、後ほど解説します。
業務部門カットはSAPを導入する会社の部門に合わせて、導入側のチームを切ることです。
モジュールカット
SAPの主なモジュールは以下です。
モジュール名 | 略称 | 英語名 |
財務会計 | FI | FInancial Accounting |
管理会計 | CO | COntroling |
販売管理 | SD | Sales and Distribution |
調達/在庫管理 | MM | Material Management |
生産計画/管理 | PP | Production Planning and Control |
品質管理 | QM | Quality Management |
大規模プロジェクトの場合、モジュールごとにチームを切ることもありますが、ポテンヒットを防ぐために複数のモジュールを1つのチームとすることもあります。
チームまとめパターン①
パターンの1つ目は、FI/CO、SD/MM、PP/QMでチームを切ることです。
担当する部門がFI/COは経理、SD/MMは受発注を受け持つ営業・調達、PP/QMは製造部門となります。
この体制の場合、ポテンヒットになりやすいところは以下です。
- FI-SD/MM間の債権・債務
- SD-PP間の出荷
- MM-PP間の外注、棚卸
- CO-PP間の製造原価
チームまとめパターン②
2つ目のパターンはSAPを導入する最大のメリットかつ最大の難所である製造原価をポテンヒットさせないためにCO/PPを1つのチームにした体制です。
この場合、FIは本社経理と、COは工場経理と相対することになります。
この場合、本社経理側で握っている予算に関して、CO側が要件定義をしないといけないケースが出てきます。
- FI-CO間の予算管理
アプリリード、会計・ロジリードの存在
モジュールカットの場合、アプリ全体リードや会計・ロジリードを配置するプロジェクトもあります。
リードを配置することにより、モジュール間の課題解決や整合性を取る動きをするため、SAP固有の画期的な体制だと思っています。
会計・ロジリードになる人は、SAP歴10年以上のあり、複数モジュールを把握している方がなります。
業務部門カット
近年出てきたのが業務部門カットでプロジェクト体制を組むことです。
S/4からグローバルでSAPを導入するケースも増えており、この業務部門カットは欧米発祥だともいわれています。
代表的なチームは以下です。
略称 | 正式名 | 業務部門 | SAPモジュール |
RTR(R2R) | Record To Report | 経理 | FI/CO |
OTC(O2C) | Order To Cash | 営業 | SD(受注・請求のみ) |
PTP(P2P) | Procure To Pay | 調達 | MM(購買・請求書照合のみ) |
PTD(P2D) | Plan To Produce | 生産 | PP/QM |
WTD(W2D) | Warehouse To Delivery | 物流 | SD(出荷)、MM(在庫) |
導入側からすると相対する部門が基本的に固定になるため、仕事の進めやすくなります。
またグローバルプロジェクトだと複数部門を跨いだ調整が難航するため、リソースを効率的に集約している体制であるともいえます。
ただしこの体制を組むときに注意が必要な点が2つあります。
- SD/MMが細分化されているのでポテンヒットを出さないようにすること
- Fit to Standardと言いながら、モジュール(システム)カットの体制ではなく業務部門カットなので、業務にシステムを合わせないようにすること
注意点① ポテンヒットを出さない
業務部門カットであるため、日々同じ担当者と相対することになります。
モジュールカットであれば「他の部門の方とも打合せが必要だ!」となり、導入企業側が自発的に部門間の業務を検討できていたのが、やりにくい体制になっています。
特にSD/MMがOTC/WTD/PTPに分かれているため、同じSDでも出荷は知らないというOTCメンバーや、在庫管理は知らないというPTPメンバーがどのプロジェクトでもいます。
ポテンヒットになれば、本稼働延期や本番障害につながるだけなので、率先してチーム間の課題を拾いに行く動きがより重要になります。
注意点② 業務にシステムを合わせないようにすること
業務部門ありきのチームカットになっているため、Fit to Standardを目指したSAP導入をするプロジェクトであれば、より一層システムに合わせる意識を持つように動くことが重要になります。
特に大企業ともなれば部門間の壁・軋轢は少なからずあるため、分からないところは自部門でアドオンするというケースも散見されます。
チーム間の連携が必須で、チーム間でコミュニケーションをとることにより、
- モジュール間連動のSAP標準機能で対応できることはないか
- アドオンを共通化できることはないか
と効率的に検討することがより良い進め方に思えます。
(最後に)体制に関わらずポテンヒットを拾おう!
導入企業やプロジェクトによって、プロジェクトマネージャがベストな体制を選択します。
どの体制であっても一長一短あり、どの体制だとプロジェクトが成功しやすいとかはないです。
1つ言えることは、どの体制であってもチーム間のポテンヒットが生まれるということです。
SAPプロジェクトは忙しく、自分のスコープを決めてしまいがちです。
ただ、自分の市場価値を上げたかったり、社内評価をあげたかったりする人は率先してポテンヒットを拾うことをおすすめします。
人がやりたくないことには価値があります。