統合シナリオに備えるIT戦略/M&A時代のIT戦略　1回/全3回(2/3)

IT投資のタイミングと実現方法

　「(1)公開された戦略を理解しモデル化してから施策をできる限り速やかに遂行できる文化や環境を築いておくこと」、「(2)ITにおける自社の資産を深く理解し価値の増大を目的として透過性を高めること」、の備えは共に重要であり、これらに備えておかなければたとえ統合シナリオが開示されても、システム構築の実行能力がネックになり足を引っ張ってしまうかもしれない。あるいは価値が分からないことが原因で、何を基準に統合していくべきなのか判断できないかもしれない。

　しかし、これらの備えは通常時において経営戦略そのものを達成するものではないことから、直接的に投資対効果を期待することは難しい。よって、業績向上の予測とその実績にこれらのIT投資を紐付けることができず、IT投資にかかるコスト削減というシナリオと一致しない限り、投資対効果に対して判断がつけられないという事態に陥ってしまう。そのため、これらの投資に関しては次のいずれかの方式に基づいて行う必要がある。


方式1 実施の影響が及ぶ業務と財務的なインパクト、それにかかわる社員のワークスタイル、構築期間といった事前調査と指標／KPIの設定
方式2 直接的に「企業価値の創造」が実現できるプロジェクトに合わせてこれらの費用は業務側改善要望の中に同梱

　　　 　方式1には売上予測と販売実績との関連性など各要素を推測するための情報、すなわち定義済み（分析可能）でかつ計画、実績両方のデータを過去数ヶ月から数年にわたって必要になる。そのため、データを活用する目的のプロジェクトで、データが必要になるというジレンマに陥る。この方式を採用することが望ましいが、これ以外にも売上との関連性の紐付けなどの準備まで必要になってしまうため、はじめから採用することは難しい。
　結果として、多くの企業はまずは方式2を選択することになるであろう。
　それでは、実際に何をどのように行えばいいのであろうか。再び図1を見ていただくと、柔軟性、可視化ともプロセスとデータに分けて議論することができる。


図1　IT戦略として備えるべき要素

さらにこれらは業務系〈※注5〉∥プロセス、情報系∥データと定義できる。情報系データの分析自体は、データを蓄積場所（DWH、DM等）からビジネス・インテリジェンス等の仕組みで取り出す。これはエンド・トゥ・エンドで結ばれるので、プロセスは介在しないと定義できる。また、データ自体は業務系、情報系共に存在するが、情報系で必要とするデータが企業価値向上に結びつくと定義できるため、業務系でのデータはある程度柔軟かつ個別に対応して構わない〈※注6〉。
企業合併などを考慮すると分かりやすいと思うが、業務系まですべてのデータを統一化することは現実的に不可能であり、情報系ではグラニュアリティ（データの細かさ）と分析の際に必要となる各マスターのコード標準及び管理要素が整っていればいい。これらを考慮しながら、主となる企業価値を向上させるプロジェクトに組み込み、投資対効果を鑑み「起案の容易性」「即効性」の観点から実行すべきプロジェクトの領域を判断することが必要である。企業ごとに現状の達成レベルが異なることから、一概にこれからすぐに行うべきだという判断はアセスメント前の段階ではできない。

しかし、これらの取り組みがすべての分野において不完全であるということを前提にした場合、実現性を優先し「起案の容易性」を主軸、「即効性」を副軸とすると図3のようなマトリクスになる。起案の容易性においては、プロセスは業務改善ニーズがある場合でしか実施できなく、データは業務を変革しなくても始められるということから柔軟性、可視化を問わずデータに関するプロジェクトの方が起案の容易性が高い。即効性においては、ビジネスプロセスマネジメントなど業務上のクリティカルパスの発見／改善が行える柔軟性／プロセス、定型／非定型分析を行うことによって実際に起こっている、あるいは起こり得る問題の抽出ができる可視化／データの2つに関するプロジェクトが有効性を発揮する。
　この結果として、データの可視化とデータの柔軟性確保を実施できるプロジェクトが選定しやすいということが分かる。ただし、企業によっては直近で業務改革を実施するなどの要件があるかと思うが、その場合は起案に対する懸念が払拭されるため、プロセスの柔軟性確保が有効になる。

〈※注5〉 業務系でもデータは存在するが、業務の中でのみ存在するデータは企業価値を高める情報としては取り扱わない。しかしながら、企業／業務価値を判断するためのKPIの要素となるデータやマスターデータは重要になるため、データ収集前にデータモデリングしておくことが必須であるが、本資料においては情報系のための整備作業と定義する。また、業務要件の変更に伴い業務系アプリケーションでコード標準化などを導入することを否定するものではない。
〈※注6〉 情報系で必要とするデータ項目のグラニュアリティに対応していることは必須である。そのため、アプリケーションを新規／変更する場合、社内統一コードがある場合は準拠、ない場合は情報系で要求するレベル（グラニュアリティ）に合わせる必要はあるがレコードセット、コード値自体はある程度自由度を持てるということを意図している。