第7回：組織マスタの主要な論点
前回は、品目マスタの主要な論点について紹介しました。
第4回・第5回の「顧客マスタ」、前回の「品目マスタ」に続き、今回は企業のビジネスやデータ管理（MDM）を支える最重要マスタの一つである「組織マスタ」を取り上げます。
組織マスタは、単なる人事的な「組織図」をデータ化したものに留まりません。売上や費用の集計軸、承認ワークフローの制御情報、あるいはシステムへのアクセス権限のコントロールなど、企業全体で多角的に参照される非常に重要なデータです。
利用目的によって異なる組織体系
ある一つの企業内であっても、利用目的によって組織の定義は複数存在します。代表的な3つの組織体系を示します。
人事・労務組織（指揮命令・雇用・評価の軸）
会社法や労働法、社内の就業規則に基づき、「誰が誰を指揮・評価するか（上司と部下の関係）」や雇用区分を管理するための正式な階層構造です。「〇〇部 〇〇課 〇〇係」のように階層が固定化されやすく、定期的な人事異動や組織改編の主軸となります。
具体的な組織名・部署名の例
・人事本部 人事労務課
・製造本部 第1生産部 業務第2係
・東京本社 総務部 施設管理班
など
営業・業務組織（実務・市場・プロジェクトの軸）
実際のビジネス活動（営業推進・顧客対応・プロジェクト遂行）を目的として設定される、実務運用上の組織です。人事上の「〇〇部」に所属しつつ、業務上は「〇〇プロジェクト」に所属するなど、兼務やマトリックス構造が発生しやすいのが特徴です。期途中での新設や解散も頻繁に行われます。
具体的な組織名・部署名の例
・東日本営業部 大手自動車メーカー担当タスクフォース
・DXソリューション事業推進プロジェクトチーム
・グローバル営業本部 APAC（アジア太平洋）エリア推進室
など
会計・管理会計組織（費用・利益集計の軸）
決算や管理会計において、「どこで費用が発生し（コストセンター）、どこで利益を生み出したか（プロフィットセンター）」を計測するための損益管理単位です。
コストセンターの例
・本社共通部（情報システム部コストセンター）
・中部物流センター（保管・配送コスト集計ユニット）
など
プロフィットセンターの例
・スマートデバイス事業部（事業部損益管理単位）
・産業機器営業統括部（売上・粗利集計ユニット）
など
人事組織上の「課」レベルでは損益を管理せず、複数の課をまとめて1つのコストセンターとして扱ったり、逆に1つの部の中に複数のプロフィットセンターが同居したりと、人事組織と1:1にならないケースが多発するポイントでもあります。
上記から、同一の社員集団に対しても、システムや目的ごとに『組織』の認識が異なることがあります。例えば、人事部からは『第1営業課』、経理部からは『コストセンターコード：CC-1023』、営業現場からは『A社プロジェクトチーム』と認識されるケースです。
まず社内での組織に対する認識状況を正しく理解・共有した上で、それぞれの組織体系を統合するか、完全に別の概念として独立して定義・管理するかを見極める必要があります。
組織階層を表現する2つのデータモデル：特化モデルと汎化モデル
組織の階層や構造をデータモデルとしてどのように表現するかについては、大きく2つのアプローチがあります。
特化モデル（用途別に個別のエンティティを定義）
「会社」「部」「課」など、それぞれの組織階層ごとにエンティティ（テーブル）を独立させ、エンティティ間に親子関係を表すリレーションシップを持たせるモデルです。
シンプルで直感的ではありますが、以下のような問題があり、実務的なシステムで使われることは少ないと考えられます。
- 「課」を「部」に昇格させるような、階層を跨ぐデータの変更が面倒である。
- 「社長直下のプロジェクトチーム」など、想定している組織階層に収まらないイレギュラーな組織の表現が困難である。
- 社員の所属部署を示す場合、「課に所属しない部長」や「部に所属しない社長」など、社員の立場により所属組織を示すコードの組合せが複雑になってしまう。
特化モデル
汎化モデル（単一エンティティの再帰的参照）
すべての組織単位を一つの「組織」エンティティに保持し、子組織のレコードに、同じエンティティの親組織レコードへの外部キー（自己参照リレーション）を持たせるモデルです。
この汎化モデルには、以下のようなメリットがあります。
- 組織の階層数に制限がなく、階層の浅い組織系統と深い組織系統を共存できる。
- 組織間の上下・紐付け関係を柔軟に変更できる。
- すべての組織レベルを、同一体系の組織コードで表すことができる。
汎化モデル
『パーティーモデル』の採用には注意が必要
さらに抽象度を高めたデータモデルとして、「パーティー（組織または人）」という概念を導入することがあります。
一般的なデータモデルでは、「グループ会社」「社員」「顧客」「仕入先」などはそれぞれ別の概念として別々のエンティティで管理します。しかしパーティーモデルでは、ビジネスに関わるすべての組織・人を「パーティー」という上位概念で一つのエンティティとして表します。
一般的なデータモデルの考え方
概念ごとにエンティティを定義する
パーティーモデルの考え方
組織・人については全て「パーティー」として定義する
■メリット
同一の組織・人に対する情報（名称や住所、法人番号など）を複数のエンティティで重複して保持する必要がなく、全てパーティーエンティティで一元管理できます。また、将来的に新たな組織・人の概念や関係性が増えた場合も、データモデルを根本から変更することなく、同一のモデル内で柔軟に表現できます。
■デメリット
データモデルを見ただけでは、どのような組織・人の概念が存在し、どのような関係性があるのか直感的に判断しづらくなります。データモデルの抽象度が高くなるため、設計や理解の難易度が跳ね上がります。
一般的なデータモデルであれば、どのような組織や人が存在するか、またそれらの関係がデータモデルから読み取れる
パーティーモデルの場合、組織や人の種類やそれぞれの関係性がデータモデル上では抽象化される
パーティーモデルは、ERPなどのパッケージアプリケーションにおいて汎用的な実装を行い、設定によって動作や保持データ種類の変更を行う場合には非常に有効な手段です。
一方で、データモデルの抽象度が高くなるという特徴は、「自社のビジネスや業務のデータを正確に理解し定義する」というデータモデリングの本来の目的にはふさわしくない面もあります。そのため、自社のデータ管理基盤にパーティーモデルを導入するかどうかは、慎重に判断する必要があります。
「組織」は身近な概念だが奥深い
今回は、組織マスタにおける基本的なデータモデルの考え方に焦点を当てて紹介しました。
組織マスタには他にも、履歴管理や組織変更への対応、社員の所属の表現方法などの検討ポイントがあります。
組織マスタのデータモデルは、単に人事の組織図が表現できればよいというものではありません。自社における「組織」の定義や業務での運用実態、さらには将来どのような軸でデータ分析を行うかを深く考慮して設計することが極めて重要です。
B-EN-Gでは、製造業をはじめとする多様な業種での知見をもとに、お客様のビジネスモデルに最適なデータ基盤の設計・構築を支援しています。組織マスタの設計や既存システムのデータ構造見直しにお悩みの際は、ぜひB-EN-Gにご相談ください。
DMBOKに基づくチェックリストを用い、企業のデータマネジメント成熟度を測定し、今後の重要な改善ポイントやロードマップをご提言します。
Share
Tweet
Share