製造業でも経営や業務のデータドリブンシフトの重要性が叫ばれるようになって久しい。だが変革の推進は容易ではない。本稿では独自の「概念データモデル」をベースに、「データを中心に据えた改革」に必要な要素を検討していく。
前回は、製造業のDX推進やデータドリブン経営実現のために、事前にビジネス全体を概念データモデルとして表現し、それを"改革の憲法”として個々の活動を進めることを提唱した。第2回では、筆者らの経験してきた事例に基づき、概念データモデルが役立つ具体的なシーンを3つ紹介する。
概念データモデルという単語自体は以前からあったが、多くの場合、業務要件をデータ構造として抽象的に表現したモデルを指してそう呼んでいる。このモデルは、業務要件決定後に作成することを前提とする。
これと異なり、本連載で扱う概念データモデルは、業務要件を決める前の段階で作成するものだ。特定の業務領域に限定せず、企業のバリューチェーン全体のデータ構造を抽象的に記載したモデルとして定義する(詳細は第1回を参照のこと)。この前提を基に読み進めていただきたい。
⇒連載「真に『データ中心の製造DX』を実現するには」のバックナンバーはこちら
概念データモデルが有効に機能する場面の1つに、事業全体のバリューチェーンの業務改革やシステムモダナイゼーションへの活用が挙げられる。
一般的に業務改革やシステムモダナイゼーションは、システムや業務機能の観点からその対象スコープを定めて、全体最適化を目指す取り組みがほとんどである。そして対象スコープの範囲で、システム導入を伴う複数のプロジェクトが立ち上がり、プロジェクト単位でQCD管理が行われる。
このような取り組みでは複数プロジェクトを同時期に行うビックバン的なアプローチをとることはまれで、数年の期間をかけて複数のプロジェクトを徐々に検討、実行していくのが一般的だ。この場合、改革の取り組み規模が大きく、かつ期間が長くなる。実現のために必要なデータの整合性がプロジェクト間で取れていないなど、“データのサイロ化”が発生することが非常に多い。
その解決策として有効なのが概念データモデルである。業務改革やシステムモダナイゼーションに着手する前に、自社の憲法となるデータ構造を定め、それに基づき改革を推進することで、データの矛盾や不必要/非効率なデータ変換、各活動の認識のずれを低減できる。
例えば、市販のパッケージシステムの導入を検討する際、自社の憲法となるデータ構造を事前に定めておけば、パッケージが前提とするデータモデルと自社のデータモデルの違いが明確になる。第1回で述べたように、概念データモデルは自社事業を中長期的に成立させる上で重要なデータを明らかにする。従って、作成した概念データモデルがパッケージシステムで対応できない場合は、何らかの手を打たなければ事業が成り立たなくなり、顧客にサービスや物を提供できなくなる恐れがある。アドオン開発や他システムの組み合わせなど、何かしらの対策を打つべきだと判断する根拠になるだろう。
パッケージシステムと自社開発のシステム、それぞれが扱うデータの範囲はどこまでか。どこまでを標準機能で対応し、どこまでアドオン開発を許容するのか。こうした判断を概念データモデルに基づいて実施できれば、追加コストの要否判断も容易だ。
複数のシステムをまたいで利用される品目などのマスターデータを持つシステムの変更時にも、影響範囲の検証がしやすくなるため概念データモデルは有効だ。特に、複数のビジネスドメインを有している、あるいは、グループ会社間でのデータのやりとりが多い企業では、どのデータをどのビジネスに関連させるべきかの検証を怠ると、結果として使えない業務/ITシステムを導入することにもなりかねない。概念データモデルをプロジェクト初期段階で作成することで、これらの問題を未然に防げる。
まとめると、概念データモデルを定義しておけば、企業の業務改革やシステムモダナイゼーションに対して有効にガバナンスを利かせられるのだ。
Copyright © ITmedia, Inc. All Rights Reserved.