SAPの組織構造
法人・部署・物理的場所・実組織などを元に、それぞれが担う役割に応じてマッピングする。
SAPを利用する上で、最も重要なデザインと言える。
そもそもSAPにおける組織とは何か？ †
SAPにおける組織とは、ざっくり言えば、機能の実行制御、レポーティングのキー、データの切り口、権限制御をするためのものといって差し支えないかと思う。
実際の組織論でいえば、機能別組織やプロジェクト型組織あるいはマトリクス型組織などが挙げられるが、SAPの組織定義を語る上では、ざっくり地理的組織と人的組織およびそれ以外に分けられるかと思う。
地理的組織 †
国や地域に準拠して定義された組織で、「関東支社」だとか「北米支社」といったものが当てはまる。
実態として、物理的な距離が一定以上離れた組織や拠点を同じコードで表現することはあまりなく、具体的には違う国に属する組織が同じ法人とすることは一般的でない。
当たり前のように聞こえるが、SAPの考え方として国や地域が違えば税制や貿易統計など取引関係の申告先などが異なるため、いかなる組織も、まず地理的な要素によって定義／分割されるものであり、またどんなに距離が近くても、国が違えば組織を分けることは基本中の基本と認識すべき。
島国の日本ではピンとこないかもしれないが、欧州生まれのシステムであり、特にEU圏での導入をイメージしてもらえれば重要性は理解いただけるかと思う。
人的組織 †
これがある意味メインの定義となる種類の組織で、とにかく「人の集まり」。
その定義の考え方については、機能別組織やマトリクス型組織などがあるが、それらは人の集まりであることには変わりなく、「組織」という言葉でイメージしやすい定義。
基本的には「あるだけ」「ありのまま」を定義すればよいのだが、プラントだけは話は別。
実績の集計という意味では、組織コードを細かく定義して任意に集計すればよいという考え方を採用できるが、SAPのロジの真骨頂は計画と予実分析であり、特に生産管理や所要管理においては最上位単位がプラントであるため、下手に細かくしてしまうとSAP本来のコンセプトと乖離してしまう。
もちろん原価センタや利益センタといった会計組織コードについては、ロジとの繋ぎ部分を除けばある程度細かくてもよいかと思うし、ロジ組織でも販売組織なんかは営業組織をあるだけ登録しても構わないかと思うが、とにかくプラントだけは話は別。
それ以外 †
大きくは、「組織コードではないけれど数値把握などのために便宜的に定義されるもの」と「ダミーを含めシステム的な都合で定義されるもの」がある。
前者は、簡易的にプロジェクトやイベントのコストを把握すること等を目的として定義される原価センタが代表的。
後者については、例えば出荷業務について細かい要件はない場合に「とりあえず」ひとつだけ定義される出荷ポイント、販売管理で言えばイマイチ役割を担わない流通チャネルなどが該当する。
何のために定義するのか？ †
SAPにおいては、システム機能の制御やレポーティングのキーとしての側面が強いこともあり、必ずしも人の集まりを意味しない。
一般的に組織構造と言えば即ち人的組織を指すため、業務プロセスや分析統計における役割など、これを基軸にシステムの概観が決定されるため、ベンダは正しく理解し、ユーザへの理解を促さなければならない。
この部分をもう少し言及すると、下記が挙げられる。
複雑な企業構造を簡単に表現する †
決して簡単ではない、という声も聞こえてきそうだが、実組織は多種多様な役割を負っているもの。
ロジスティクス的な或いは管理会計的なという観点から、データを入力しレポーティングするのが在るべき姿であり、これを役割別に要素分解することで、それぞれの目的別に管理できるようにする。
例えば「第一営業部」という実組織があったとすれば、これは販売組織や利益センタにマッピングされ得る。
しかしながら、同じ「第一営業部」という名称が付与されていても、組織定義の位置付けとして前者は販売管理の目的において、後者は管理会計の目的において定義されており、その前提で利用されなければならない。異なる目的で定義された別々の存在であるということを正しく理解しなければならない。
ここが立ち行かず、SAP本来のコンセプトと異なる利用をしてしまった場合、せっかく導入したシステムをより良く使えないばかりか、足を引っ張られ利用可能な機能やソリューションが制限されてしまう。
組織変更に対応させる †
変更に弱いデザインをするインプリ屋も少なくないが、SAP本来のコンセプトに従って定義しさえすれば、変更は然程苦しくは無い。
そのためにCOグループマスタなどが存在するわけであり、組織変更時の対応が難しいということは、逆に言えば良いデザインではないことを意味する。
具体的には、末端組織をプラントや事業領域にマッピングしてしまうと、新組織への移管処理やカスタマイズ変更などが煩雑極まりなくなる。
これは、最も簡単に個別組織でP/Lを見ることができるという即物的な理由で商社向けソリューションなどでよく用いられる悪い例である。
そのため、「ツブシの利く」利用方法として、末端は利益センタにマッピングし、サマリは利益センタグループで見るなど、動的かつ容易に変更可能であるようデザインする必要がある。
注意事項として、システム外、特に社外にデータを送信することはよくあり、その折り返しを受信するケースも多々ある。（導通の信号というシステム的な意味ではなく、ここでは業務的な意味の話）
これについて、送った時と返ってきた時で組織変更対応を跨ぐなんて話もあるわけで、組織変更後に折り返されたデータが旧コードだったらどうやってケアするの？という話がある。
そのため、旧コードは生かしたままグルーピングするとか、そもそも組織情報を直接入れないとか、受信側PGで読み替えるとか、方法は考えておきたいもの。
組織変更の種類と実際の対応 †
そもそも、「組織変更」などというピンボケした表現を使っていては、漠然とした話から先に進まなくなってしまう。
そのため、ここでは下記の分類にカテゴライズして語ることとする。
- 新設
文字通り、新たにできるパターン。
基本的には、コードの登録と上位グループとの紐付けで充足する。 - 統合
こちらは、末端のコードはできず、上位グループとの紐付けのみを変更するパターン。
新しいコードを取ることもあるが、グルーピングだけで対応できるならば、それに越したことは無い。 - 廃止
これは、コードの削除や転記ブロックと上位グループからの紐付け解除が相当する。
但し、解除してしまうと過去実績が見づらくなってしまうため、変更前のグループ自体をバックアップとして退避しておくなどが必要。 - 分割
これは面倒くさいパターン。
というのも、上記と違い「暖簾分け」をしなければならないからだ。
振替伝票の起票は避けられず、それなりに面倒くさい。 - それらの組み合わせ
一部を廃止したもの同士を統合する、統合はするが一部を切り離すなどのややこしいパターン。
こういった組織変更が頻発すると、デザインに関係なく、それなりにきつい。
各モジュールでの組織構造 †
SAPの組織構造は、会計組織とロジ組織に大別することができ、各々のコンセプトや定義例などを紹介する。
なお、最上位構造はクライアントであるが、ここで触れる実組織や機能および分析の切り口に基づいた観点とは毛色が異なるため、詳細はリンク先を参照のこと。
会計組織 †
財務会計 †
管理会計 †
- 管理領域
- 分析対象
- 利益センタ
最近ではFIの組織とされているようだが、「利益センタ会計はCO（EC）なのに、利益センタは何故FIなんだ！」という思いからこっちに。 - 利益センタグループ
- 原価センタ
- 原価センタグループ
ロジ組織 †
販売管理 †
購買管理 †
在庫管理およびロジスティクス共通 †
関連ページ †
SAPの組織構造/トランザクションコード
SAPの組織構造/関連テーブル
コメントはありません。 Comments/SAPの組織構造?
