今回のテーマは、リーマンショック以降ここ数年再び活況を呈しているM&Aのシステム対応に言及してみたい。本ブログシリーズでは、バックナンバー2014.10.5「モデルドリブンM&A対応とCIOの振舞い」で、M&A対応ではまず両社のシステムのモデリングありきである事をお話した。今回はさらに踏み込んで、両社のシステムを結合するポイントに“データHUB”を用いる手法について具体的にお話したい。以前からデータHUBが大規模な企業システムにおける複数システム間I/Fとして有効機能する事をお話してきたが、M&A時の企業システム統合は、歴史も文化も異なる究極の複数システム間I/Fと捉えることができる。
ここでは、一般的なセオリーとしての“ビジネス統合スキームに従ったシステムの片寄せ”については説明を省略することとし、大規模システムを段階的に統合してゆく際に必須となるブリッジングに焦点を当ててみたい。図1はM&A時のデータHUB利用について、データの流れを中心に説明したものである。図はA社のシステムへB社のシステムを統合すべくブリッジングする例であり、マスターデータHUB(MST-HUB)と、トランザクションデータHUB(TRN-HUB)の2つのデータHUBが活躍する。以下に順を追ってデータ統合プロセスを説明する。
①B社の共通マスタ(取引先、組織、製品など)をA社に取り込み、A社の共通マスタと統合し、新社用共通マスタ(ゴールデンレコード)を生成する。取引先においては両者のプロファイリングを実施した結果、いわゆる“名寄せ“を行う。名寄せの結果は、コード変換テーブルにB社コード⇔A社(新社)コードの対応が登録される。組織コード、製品コードについても同様に、B社コード⇔A社(新社)コードの対応が登録される。なお、図上ではA社コード体系を新社コード体系としているが、第三のコード体系とする事も有りで、その際は対応テーブルはA社コード-B社コード-新社コードの1:1:1関係の登録となる。
②ゴールデンレコードへはコード統合された各種のマスタに加えて、当コード変換テーブルも重要なゴールデンレコード群の一画を占めることとなる。一元管理されたコード変換テーブルは、TRN-HUB上のコード変換プロセスに向けて配信される。トランザクションのコード変換については、このTRN-HUB内で一元的に実施することが好ましいので、このコード変換テーブルはあまり多方面への配信は行わない。
③B社システムから取り込んだB社トランザクションを、MST-HUBから配信されたコード変換テーブルをもとに各種のコード変換(取引先、組織、製品など)を施す。コード変換された共通トランザクションは各種の業務アプリケーションに配信され利用される。また汎化&統合された共通トランザクションは、テンポラリーとする場合と履歴を保持したDWHへとする場合の両方が考えられる。
以上が、ブリッジングのメカニズムであり、この機能が構築できていれば、あとはビジネス上の統合スキームに合わせて、順次、システムを統合して行けば良い。以下に3段階のステップを経て統合を完成させる一例を示す。
DAY1. (新社開始~初年度)
統合スキーム | システム統合 | ブリッジング |
バックオフィス統合 | 会計システム、債権管理システム | 組織コード、取引先コード、製品コード |
DAY2. (2年目~1年間)
統合スキーム | システム統合 | ブリッジング |
フロントオフィス統合 | 受発注システム、営業支援システム | 組織コード、製品コード、取引先コード(ブリッジ廃止) |
DAY3. (3年目~)
統合スキーム | システム統合 | ブリッジング |
人事制度統合、生産拠点統合 | 人事システム、生産管理システム | 組織コード(ブリッジ廃止)、製品コード(ブリッジ廃止) |
M&Aで最も重要な事は、まずDAY1の納期通りミニマムのシステム統合を完成させ、新社としての安定したスタートをきる事である。幾つかのA,B両社のフロント系システムが併設となることは差支えない。DAY2、DAY3とビジネス統合スキームに合わせて、システム統合とともにブリッジが取り外されることになる。
どうであろうか。綿密な計画をもってすればM&Aのシステム統合も恐れるに足らずである。DAY1におけるA,B両社共通の取引先の約定の統一や、DAY3の人事制度統合といった人間系の作業の方がよっぽど大変である。このようなユーザ側での努力を速やかにシステム統合に落とし込むことが情シス部門の役割である。その為には、細部においては時々刻々と変化するビジネス・スキームに対して敏感であることが前提となる。M&A 時のCIOは平常時と比べてCEOと最も近づいていなければならない。