今週のブログはちょっと視野を広げてグローバルFDWH(Financial DataWareHouse)について書いてみたい。前回の内向きな“データ辞書の整理法“に反して今回は思い切り外向きのグローバルが対象である。規模の大小は違えども、異なるシステム間の相互接続ではデータの定義(意味と形式)が重要である点で勘所は同じである。
基本的な考え方はバックナンバー(2014.8.27 グローバル対応モデル)に記載した通りであるが、グローバル経営を推進する企業にとってこのFDWHの早期構築が急務であることから、今回はさらに踏み込んで具体的データ・アーキテクチャをご紹介したい。まず早期構築を優先するので、各国の基幹業務システム(ERP等)を改修することはインターフェース作成以外はやらない事が前提となる。下図に全容を図示したのでご覧いただきたい。図が小さいのでクリックして拡大してみてほしい。プリントアウトすればさらに見易いと思われる。図の上部(左から右)、下部(世界地図部分)の順に説明する。
図の上部にはCloud上のGLOBAL-DATA-HUBが描かれており、そこには全世界の取引明細を格納したグローバルTRN(FDWH)と、GL-ITEM(グローバル品目)及びGL-CSTM(グローバル顧客)からなるグローバルMSTが格納されている。グローバルTRNの項目には品目、取引先、売上数量・金額をはじめ、売上原価、売上利益等があり、その粒度は伝票明細レベルから可能となっている。このFDWHを基に、BI-TOOL等を用いてグローバルな業績分析を行い、グローバルレベルでの各種利益分析(品目別、顧客別、SBU別)を行なう。そして、過去実績の分析の先は未来の業績予測に繋がる。
図の下部は世界地図に各リージョン{ヨーロッパ(EU)、中国(CN)、アジア(AS)、日本(JP)、アメリカ(US)}が配置され、各々のERPはリージョン固有のコード体系、フォーマットのローカルTRNを保有している。もちろん通貨もリージョン固有である。そして各リージョンには、ローカルコード(ITEMやCSTM)を主KEYとしグローバルコード(GL-ITEMやGL-CSTM)を属性に持つ、”変換テーブル”(図上では変換MSTと表現)が存在する。各リージョンのローカルTRN内のローカルコード(ITEMやCSTM)はこの変換テーブルを利用してグローバルコードに置き換わる。さらに金額も(例えば)円貨換算された結果、統一コード、統一通貨、統一フォーマットとなったグローバルTRN(F-DWH)がCLOUD上に完成する。
各リージョンの既存システムに新設されるものはGLOBAL-DATA-HUB向けにローカルTRNを抽出するI/Fと変換テーブルのみであり、新規構築の大半は図中上部のグローバルFDWHとBIということになる。なお、この変換テーブルは各リージョン側に実装するケースと統合してセンター側に実装する2通りがあるが、いずれの場合もマスタメンテナンスはローカルな事情に詳しい各リージョンに任せることが好ましい。
どうだろうか、この設計であれば最短時間で構築可能ではないだろうか。そして“シンプルな設計“とともに構築の速度を速めるポイントが3つある。1つ目はグローバルTRNを各リージョンから集信しFDWHに変換&格納する処理をプログラムレスな”ETL-TOOL”で担うこと。2つ目はGLOBAL-DATA-HUBを”クラウド環境”に実装することである。そして、3つ目はローカルTRNの切り出しと変換テーブルの整備を、各リージョンに分担してもらうことである。そこでは各リージョンのERP保守ベンダーが頼りになる。全体設計で1か月、グローバルDWH構築と並行しリージョン側改修で2か月、結合・総合テストで2か月の合計で正味5か月、ロスタイムを1か月みたとしても6か月あれば十分であろう。
今後の企業システムは、1法人を越えてグローバルな企業グループを対象としたものになってくるに違いない。スコープが徐々に拡大していく場合には目先の増改築を繰り返すのではなく、できるだけ早くゴールを見据えたアーキテクチャを描いておくことが大事である。ここでは、中央集権型の密結合ではなく、リージョン毎の多様性を認めた連邦型の疎結合アーキテクチャを採用している。少なくとも日本発のグローバル経営の場合はこの型が良いと思われる。そして、各リージョン⇔グローバル間の“変換テーブル“は、グローバルシステム全体を柔軟にする”ショックアブソーバ“の役割りを果たす重要な部品として機能する。海外でのM&Aがいつなん時あるか分からないこの時代、統合システムのアーキテクチャには柔軟性、拡張性が求められる。