グループの財務ディレクターにとって、月末に最も時間がかかる作業は、しばしば連結決算書の作成です。各子会社へのExcelによる回収促進：科目の基準が統一されておらず、顧客コードもバラバラで、内部取引が完全に相殺されていない。根本原因は財務部門が努力していないからではなく、マルチエージェント環境において、統一された組織・権限・マスターデータの基盤が欠如している——各子会社は情報の孤島となっており、グループとしては「事後的な組み立て」しか行えません。
マルチエージェント管理の典型的な痛点
- 組織の境界が曖昧である：法人、管理ユニット、利益センター、コストセンターが混在しており、レポートの次元が一致しません。
- 権限を一律に制限するか、すべて開放するか：子会社がグループのビューを確認できないか、あるいはグループが子会社の明細を変更できるため、責任の所在を巡って揉め事が生じる。
- マスターデータの分裂：同一の顧客が異なる子会社で異なるコードを持ち、同一の部品名称や規格の表記方法が統一されていないため、購買と在庫の分析の統合が不可能です。
- 内部取引は相殺が難しい：関連販売、資金のやり取り、サービス決済に関するシステム上の記録がなく、連結時には手作業による照合に頼っています。
- システムの煙突：A 子会社は某 ERP を使用し、B は別のシステムを使用しているため、グループの BI は ODS 層のみを接続して強制的にデータを洗浄するしかありません。
業務はどのように分割されるのか：組織・権限・マスターデータの三層
組織モデル
提案の階層化：グループ → 法人主体（会社）→ 事業ユニット／事業部 → 部門 → 職位。法人主体は…に使用されます法定報告書と税務；業務ユニットは…に使用されます管理レポートと評価；部門は…に使用されます権限と承認フロー。一人が複数の組織に所属することも可能です（例えば、二つの子会社の幹部を兼任する場合など）、しかしデータの帰属明確にしなければならないのは、この注文およびこの費用がどの法人、どのBUに属するかである。
権限体系
採用するRBAC + データ範囲：ロールによる機能権限の定義（承認可否、マスターデータの変更可否）；データ範囲による表示・書き込みの境界の定義（当該法人内、当該BU内、グループ全体の読み取り専用、法人間では権限付与が必要）。重要な原則：
- デフォルトの最小可視範囲：子会社のユーザーはデフォルトで自社のみが表示されます。グループユーザーは集計表示に加え、ドリルダウン時には監査ログの記録が必要です。
- マスターデータの階層別維持管理：グループレベルのマスターデータ（顧客グループアカウント、グループ物料）は、グループのマスターデータ担当者だけが変更できます。子会社レベルの拡張フィールドは、子会社が維持できます。
- 主体間の業務における明示的な権限付与：A社がB社の在庫を販売する場合、内部取引ルールと両者の可視性設定が必要であり、共有アカウントに頼ることはできません。
マスターデータガバナンス
コアマスターデータドメイン：顧客、サプライヤー、材料、勘定科目、組織、従業員。各ドメインの定義：コード規則、必須属性、一意性制約、変更承認、有効バージョン。グループ顧客の「一人一コード」：子会社が入力する際にはまずグループライブラリを検索します、ヒットすれば参照し、ヒットしなければ新規承認を作成します。部品についても同様に、同一品目で複数の名称が存在することでMRPと購買の統合が歪められるのを防ぎます。
どのように設計するか：テナント、アカウントセットおよび統合アーキテクチャ
単一データベースのマルチテナント対 多データベースのフェデレーション
単一データベースのマルチテナント：一つのシステム、org_idデータを分離し、グループによる強力な管理と高い標準化レベルに適しています。マルチ在庫フェデレーション：各子会社が独立したインスタンスを持ち、グループレベルでは統合プラットフォームまたはMDMを通じて同期を行う方式で、子会社の自律性が高く、既存システムの移行が困難な場合に適しています。選定は、連結決算のリアルタイム性要件、子会社のIT能力、規制上の隔離要件によって決定されます。
内部取引と連結
システムは次の機能をサポートしている必要があります：社内販売注文、社内調達、社内決済価格、取引対照。連結決算エンジンは、ルールに基づいて内部の収益・原価・取引を自動的に識別し、相殺仕訳を生成します（または連結システムへエクスポート）。取引レベルの記録がなければ、連結は常に手作業のExcelに頼らざるを得ません。
承認とプロセスは主体を跨ぐ
グループレベルの制度（例えば資本支出や重大な契約）の承認フローは、法人を跨ぐ場合があります。すなわち、発起人である子会社 → 事業部 → グループ機能部門 → グループ幹部という流れです。プロセスエンジンはこれをサポートする必要があります。組織ルーティングに従う、しかも承認者は自分のデータ範囲内の伝票明細しか見ることができません。
どのように実装するか：フェーズごとの進捗と検収
分割払いをおすすめします
- 組織と権限の基盤：法人／BU／部門ツリーが稼働し、RBACとデータ範囲の機能が正常に動作することを確認しました。
- グループマスターデータ：顧客と資材に一人一コード／一物一コードを設定し、子会社が接続して参照します。
- 社内取引：関連する購買・販売および取引の照合が稼働しました。
- 連結決算報告：エクスポートによる相殺テンプレートからシステムによる半自動、さらには完全自動へと進化しています。
検収基準
- 新規顧客がいずれかの子会社で作成された際、重複率検査発効し、グループアカウントは関連照会が可能です。
- 子会社のユーザー権限を越えることはできません他の法人明細を確認する（セキュリティテスト合格）。
- 内部取引一覧と連結消去底稿ワンクリックでエクスポートできます、財務の手動表との差異＜約定閾値。
主体間協調の典型的なシナリオ
グループ内のA社が生産し、B社が販売する場合、システムは次の機能をサポートする必要があります：内部移転価格（主体間での不適切な利益移転による税務リスクを回避するため）、共有在庫の可視化（B が販売を約束する際、A の完成品の在庫量を確認できる）、統一された顧客ビュー（グループの顧客がいずれかの子会社で注文した場合、過去の注文を関連付けて照会できます）。これらの業務シーンでは、メールによる調整では対応に数日かかることがありますが、統一された組織体制とマスターデータ基盤があれば、対応時間を数時間レベルに短縮できます。
もう一つの一般的なニーズはグループ調達の集中：集中調達契約、分散受領、法人別決済。設計段階で明確にしておくべきことは、POは誰が発行し、受領は誰が確認し、請求書は誰が照合し、支払いは誰が発起するか——この四つのプロセスには三つの法人が関与する可能性があり、プロセスのルーティングは組織ツリーに従って自動的に案件を割り振るべきであり、人手による対応先会計への@処理であってはなりません。
よくある落とし穴
組織ツリーのみでデータ範囲がありません：機能権限は整ったが、データは依然としてグループ全体で無防備な状態だ。マスターデータの運動式クリーニング：リリース直前に一斉に統一したが、リリース後は保守担当がおらず、3か月も経たないうちにまた混乱している。子会社の変革に対する抵抗を無視する：グループコードの強制導入は抵抗に遭っており、それに伴うインセンティブと移行マッピング表が必要です。合併は財務のみを行い、業務は見ません：業務マスターデータが正しくないと、いくら統合データが正確でも経営判断を支えることはできません。
グループの多主体デジタル化の目標は、『子会社の柔軟な経営』と『グループの可視化・管理』を同一のルールのもとで共存させることであり、永遠に続くレポートの催収合戦ではありません。
Shandong XYN Information Technology Co., Ltd.（許願牛科技／XYN Tech）は、グループ企業向けに多組織対応のCRM、マスターデータ管理および連結決算関連のデジタル化システムを提供しています。詳細はxynadmin.com。