SAPの組織構造のバックアップ(No.1)

法人・部署・物理的場所・実組織などを元に、それぞれが担う役割に応じてマッピングする。

SAPを利用する上で、最も重要なデザインと言える。

目的 †

SAPにおいては、システム機能の制御やレポーティングのキーとしての側面が強いこともあり、必ずしも人の集まりを意味しない。

一般的に組織構造と言えば即ち人的組織を指すため、業務プロセスや分析統計における役割など、これを基軸にシステムの概観が決定されるため、ベンダは正しく理解し、ユーザへの理解を促さなければならない。

この部分をもう少し言及すると、下記が挙げられる。

決して簡単ではない、という声も聞こえてきそうだが、実組織は多種多様な役割を負っているもの。ロジスティクス的な或いは管理会計的なという観点から、データを入力しレポーティングするのが在るべき姿であり、これを役割別に要素分解することで、それぞれの目的別に管理できるようにする。

例えば「第一営業部」という実組織があったとすれば、これは販売組織や利益センタにマッピングされ得る。

しかしながら、同じ「第一営業部」という名称が付与されていても、組織定義の位置付けとして前者は販売管理の目的において、後者は管理会計の目的において定義されており、その前提で利用されなければならない。異なる目的で定義された別々の存在であるということを正しく理解しなければならない。

ここが立ち行かず、SAP本来のコンセプトと異なる利用をしてしまった場合、せっかく導入したシステムをより良く使えないばかりか、足を引っ張られ利用可能な機能やソリューションが制限されてしまう。

変更に弱いデザインをするインプリ屋も少なくないが、SAP本来のコンセプトに従って定義しさえすれば、変更は然程苦しくは無い。

そのためにCOグループマスタなどが存在するわけであり、組織変更時の対応が難しいということは、逆に言えば良いデザインではないことを意味する。

具体的には、末端組織をプラントや事業領域にマッピングしてしまうと、新組織への移管処理やカスタマイズ変更などが煩雑極まりなくなる。

これは、最も簡単に個別組織でP/Lを見ることができるという即物的な理由で商社向けソリューションなどでよく用いられる悪い例である。

そのため、「ツブシの利く」利用方法として、末端は利益センタにマッピングし、サマリは利益センタグループで見るなど、動的かつ容易に変更可能であるようデザインする必要がある。

そもそも、「組織変更」などというピンボケした表現を使っていては、漠然とした話から先に進まなくなってしまう。そのため、ここでは下記の分類にカテゴライズして語ることとする。

新設文字通り、新たにできるパターン。基本的には、コードの登録と上位グループとの紐付けで充足する。
統合こちらは、末端のコードはできず、上位グループとの紐付けのみを変更するパターン。新しいコードを取ることもあるが、グルーピングだけで対応できるならば、それに越したことは無い。
廃止これは、コードの削除や転記ブロックと上位グループからの紐付け解除が相当する。但し、解除してしまうと過去実績が見づらくなってしまうため、変更前のグループ自体をバックアップとして退避しておくなどが必要。
分割これは面倒くさいパターン。というのも、上記と違い「暖簾分け」をしなければならないからだ。振替伝票の起票は避けられず、それなりに面倒くさい。
それらの組み合わせ一部を廃止したもの同士を統合する、統合はするが一部を切り離すなどのややこしいパターン。こういった組織変更が頻発すると、デザインに関係なく、それなりにきつい。