SAPプロジェクトの体制パターンについて徹底解説!

SAPプロジェクトの体制について徹底解説!

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は製造部門となります。

SAPプロジェクト体制_パターン1

 

この体制の場合、ポテンヒットになりやすいところは以下です。

  • FI-SD/MM間の債権・債務
  • SD-PP間の出荷
  • MM-PP間の外注、棚卸
  • CO-PP間の製造原価
SAPプロジェクト体制_パターン1_ポテンヒット

 

チームまとめパターン②

2つ目のパターンはSAPを導入する最大のメリットかつ最大の難所である製造原価をポテンヒットさせないためにCO/PPを1つのチームにした体制です。

この場合、FIは本社経理と、COは工場経理と相対することになります。

SAPプロジェクト体制_パターン2

 

この場合、本社経理側で握っている予算に関して、CO側が要件定義をしないといけないケースが出てきます。

  • FI-CO間の予算管理
SAPプロジェクト体制_パターン2_ポテンヒット

 

アプリリード、会計・ロジリードの存在

モジュールカットの場合、アプリ全体リードや会計・ロジリードを配置するプロジェクトもあります。

リードを配置することにより、モジュール間の課題解決や整合性を取る動きをするため、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つあります。

  1. SD/MMが細分化されているのでポテンヒットを出さないようにすること
  2. Fit to Standardと言いながら、モジュール(システム)カットの体制ではなく業務部門カットなので、業務にシステムを合わせないようにすること

 

注意点① ポテンヒットを出さない

業務部門カットであるため、日々同じ担当者と相対することになります。

モジュールカットであれば「他の部門の方とも打合せが必要だ!」となり、導入企業側が自発的に部門間の業務を検討できていたのが、やりにくい体制になっています。

 

特にSD/MMがOTC/WTD/PTPに分かれているため、同じSDでも出荷は知らないというOTCメンバーや、在庫管理は知らないというPTPメンバーがどのプロジェクトでもいます。

ポテンヒットになれば、本稼働延期や本番障害につながるだけなので、率先してチーム間の課題を拾いに行く動きがより重要になります。

SAPプロジェクト体制_パターン3_ポテンヒット

 

注意点② 業務にシステムを合わせないようにすること

業務部門ありきのチームカットになっているため、Fit to Standardを目指したSAP導入をするプロジェクトであれば、より一層システムに合わせる意識を持つように動くことが重要になります。

特に大企業ともなれば部門間の壁・軋轢は少なからずあるため、分からないところは自部門でアドオンするというケースも散見されます。

チーム間の連携が必須で、チーム間でコミュニケーションをとることにより、

  • モジュール間連動のSAP標準機能で対応できることはないか
  • アドオンを共通化できることはないか

と効率的に検討することがより良い進め方に思えます。

SAPプロジェクト体制_パターン3_F2S

 

(最後に)体制に関わらずポテンヒットを拾おう!

導入企業やプロジェクトによって、プロジェクトマネージャがベストな体制を選択します。

どの体制であっても一長一短あり、どの体制だとプロジェクトが成功しやすいとかはないです。

1つ言えることは、どの体制であってもチーム間のポテンヒットが生まれるということです。

 

SAPプロジェクトは忙しく、自分のスコープを決めてしまいがちです。

ただ、自分の市場価値を上げたかったり、社内評価をあげたかったりする人は率先してポテンヒットを拾うことをおすすめします。

人がやりたくないことには価値があります。

ポテンヒット拾おうな

関連記事(一部広告含む)

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

ABOUT US
TK
製造業界、素材産業にて、SAP ERPの導入・保守を経験。会社の情報システム部門→外資系コンサル会社→育休→独立(フリーランス)。 SAP導入プロジェクトの仕事をする傍ら、SAPに関する情報をブログで発信。