前回のブログでITアーキテクチャが社会的背景やビジネス環境のトレンドに左右されることをお話したが、今回はその中でもここ数年のビジネス課題であるグループ経営に焦点を当てて、あるべきITアーキテクチャとの関係についてお話したい。
私が前職で2000~2005年にユーザ企業の経営企画部に所属していた頃は、ちょうど単体経営からグループ経営への移行する時期であった。当時の経営企画部には、各事業の代表者からなる“ドリームチーム”と呼ばれる事業支援Gと、経理・人事・情シス等の間接部門出身者からなる経営企画Gの2つのグループがあり、私は経営企画Gに所属していた。個別事業の競争力を強化する“遠心力”と、グループ全体の統治を強化する“求心力”の、2つの相反するベクトルのバランスについて、日夜、喧々諤々議論したことを昨日のように思い出す。
今思えば、この頃の経営改革に向けた議論の結果、現在の会社経営のスキームがほぼ決まった気がする。また当時、情シ出身の私のミッションの1つに、グループ全体の会計システムの刷新があった。2004年4月、まさに上記の議論を色濃く反映した新会計システムがグループ24社で稼働を開始した。アプリケーション・アーキテクチャの概略はおおよそ図1のようなものになった(多少、実物を抽象化しているが)。会計システム刷新といっても、その上流に位置するシステムで取引が発生するので広義のSCMシステムも含めた対象範囲で描いている。
バックナンバー2014.7.1AA(アプリケーション・アーキテクチャ)への入り口でご紹介したように、AAを図式化する際には、ただ長方形を羅列しそれらを線で繋ぐよりも、核となるデータベース(特に主要トランザクション)を併記することでビジネスが垣間見えてくる。この図では右端の終端にある連結会計から左側に遡り、グループ連結企業各社がどこまで共通システムを用いることで経営ガバナンスを強化し、どこから先はマーケットや商品特性に応じた事業競争力を個社の事業にはたらかせるべきかを示している。
パターン①は親会社とそれに近いマーケット、規模を有する大規模子会社のケース。パターン②ではマーケット、商材の違いから受発注・物流・生産管理等の現場系システムが異なる中規模子会社群のケース。パターン③は、マーケット、商材のみならず業種も異なるような子会社群で、単体会計から後ろのみ参加してくるケース。④は海外子会社群のように単体会計まで別システムで連結のみ参加するケースである。①から④に向けてシステム全体における共通部分の面積が徐々に減ってくる。なお、パターン②③④のそれぞれにおける色違いのアプリケーションプロセスは、同一パターンに所属する複数会社間では極力統一することが好ましいが、”緩やかな移行期”においてはその限りではない。また、異なるパターン間での色違いの業務(例えば受発注・物流など)の間でもコンポーネント部品の共有等が考えられるが、こちらもビッグバンでない限りは無理にとは考えない方が良いだろう。あくまでビジネスのROIが優先であり、IT部門の自己満足に終わってはならない。
大事なのは、グループ内子会社がこのモデルのどのパターンに該当するかは、ビジネスの実態を知らなければ到底、正解には辿り着かないという事である。また、将来の子会社経営がどのような方向に向かうかも重要なインプットとなる。このようにエンタープライズシステムはまさにビジネスの写像であり、ITの都合だけで安易な“グループ統合“を試みることは非常に危険である。図1で、親会社が含まれるパターン①のラインに、子会社群がどの位置で束ねられるかをクリップ止めで描いてみたが、束ねる位置により求心力と遠心力のバランスが決まることになる。”グループ経営“とは、そもそもこのバランスを取る事ともいえる。さらに、パターン①に結合する直前にある(コードやデータモデルの)”変換”が個社のオリジナリティを活かしつつも、必要な部分についてのみグループ標準に合わせるショックアブソーバの役割を果し、経営の柔軟性を担保している点も重要なポイントである。