今回のテーマは、グローバルでの情報共有をどうモデル化するか?についてである。既にバックナンバー2014.8.27「グローバル対応モデル」や、2015.12.5「大規模&疎結合アーキのかなめ(その3)」でグローバル・システムのアーキテクチャ概要について言及してきたが、今回はさらに情報共有の為のデータ・アーキテクチャに特化して深堀りしてみたい。
“情報共有“を具体化するとすれば、どのサイトとどのサイトが、どんなデータを共有するかを定義するという事になる。グローバル企業の組織階層をグローバル⇒リージョン⇒カンパニーの3階層と仮置きした場合、この3階層の組織間での情報共有を図1のようなモデルに表すことができる。この図の中での共有データは、基幹系システムにおける構造化データに限定して描いている(本ブログでは文書等の非構造化データは除く)。
そもそもグローバル企業における広域の情報共有では、同列の組織階層の情報を束ねて1つ上の階層が把握管理するという形態がとられる。つまり、上位組織が必要とする情報は1つ下位組織のサマリーであり、階層を飛び越えてさらに下位層の情報を直接アクセスすることは例外的情報ルートと位置付ける。もちろん高度情報化社会においては、個々人の情報リテラシーに委ねたネットワーク型のN:N情報共有モデルというものもあり得るが、大規模組織におけるフォーマルな情報共有には未だ一定のルールが必要である。
基幹系システムで取扱うデータは、大きく分類するとマスタデータとトランザクションデータに二分される。マスタデータに関しては、2015.12.5のブログで表したシャンパンツリーの如きダウンフローでのマスタ共有が行われる(発生源はグローバル本社、リージョン本社、カンパニ-本社と3パターンあり)。しかし、マスタデータの共有自体がやりたい事の目的ではない。目的は、グローバル本社、リージョン本社、カンパニー本社が、それぞれの立場で、システムを用いて戦略立案が出来るようにする事である。従って、それぞれの戦略立案でどんな情報が必要になるか?という事を調査&定義する事が、最初である。
戦略立案に必要なデータを調査すると、マーケティングに必要な製品別・取引先別・地域別売上実績や、サプライチェーンプランニングに必要な製品別・拠点別在庫数量、工場別・製品別製造実績数量といった実績データが必要になる事が分かる。そしてこれらの実績集計データを得る為には、取引実績明細すなわちイベント・トランザクションデータと、集計KEYとしての製品コード、取引先コード、拠点コード等が必要になる事が分かる。さらに集計KEYに加えて、製品や取引先をカテゴライズ&分析する為の区分コードも戦略立案には欠かせない。共通マスタデータはここで必要となるのだ。そして、この集計KEYや分析軸となる区分コードはその意味(範囲や粒度)やコード体系(型、桁)が揃っている事が前提となる。なお、これらのコードは、最低限、1つの上位組織で束ねるべき下位層の組織間で統一される必要がある。
上記の理由からトランザクションデータの共有が必要となる事が分かるが、ここでの共有は、マスタデータでのダウンフロー型の共有ではなく、上位組織で下位層のイベントデータを集めて集計するアップフロー型のものとなる。なお、ここのでトランザクションデータは“xxx別yyy別売上集計“といった単一目的の為であればその集計結果のみを上位組織にアップすれば良いが、多目的の分析に供する為にはトランザクション明細データ全件が必要となる。ここで常連の読者はお気付きかも知れないが、このトランザクションデータの蓄積がトランザクションHUBにおけるTR-DWHそのものである。このTR-DWHと共通マスタが格納されたものを総称してエンタープライズデータHUBと呼ぶ。
どうであろうか、この図1のグローバル情報共有モデルをもってすれば、図の下部に描かれた各種の基幹系業務アプリケーション(プロセス)のグローバル統一が必ずしも必要でない事が分かっていただけるだろう。ERP(プロセス)製品の販売をビジネスモデルとするベンダーが、声高にERPのグローバル統一を推奨しても、グローバルでのERP統一は短期間では出来ない。何年もの間グローバルVIEWが得られない事はそもそも経営に資する情報システムとは言い難い。もちろん、プロセスを統一する事でシステムのメンテナンス工数を極小化したり、業務そのものの標準化を図る事の意味がないとは言わない。だが、グローバルVEWの取得を優先する事の方が、CEOが望むところではないだろうか。