外部委託先とのコミュニケーション・ツールとして使う

データ・モデルは、社内だけでなく、対象業務を複数の委託会社に分けて開発を行う場合など、外部委託先とのコミュニケーションを図る際にも有効です。

受注プロセスはA社、出荷プロセスはB社、といったように、業務プロセスごとに別の委託先に開発を依頼する場合を考えてみましょう。受注プロセスにも、出荷プロセスにも、同じデータ（商品や取引先）があります。しかし、委託先の会社では、それぞれが請け負ったプロセスしか見えません。このため、最終的に納品されたシステム間で、不整合が生じます。

データ・モデルは、全体最適を考慮したものです。しかし、外部の委託会社は、自社の開発生産性を主眼に置くため、データ整理後の「論理データ・モデル」ではなく、処理効率などを考慮した「物理データ・モデル」をベースに考えます。

複数の委託先が、それぞれの効率を考えた物理データ・モデルをベースとしている以上、全体最適にはなりません。このため、納品後に、システム間の差異を埋める連携プログラムを別途用意することになり、システムの保守が大変になってしまうのです。

この問題を解決するためには、全体最適を考慮する論理データ・モデルは、委託先ではなく可能な限り自社で作成すべきです。そして、自社の論理データ・モデルと、納品された物理データ・モデルを比較し、違和感を感じる場合には「なぜ、このようなデータ構造になったのか」を説明させます。こうして、説明に納得できないものについては再検討を促す、といった品質基準を作ることで、トラブルを未然に回避できます。

データ・モデルの活用は発想しだい

データ・モデルは、コミュニケーション以外の、どのような局面で有効でしょうか。

（1）システム統合時

企業合併や工場統合などにより、システムを統合しなければならないケースがあります。このケースでは、業務フローの統合もさることながら、データの統合も必須です。データ統合の際に、主に問題となるのは、「データ構造の違い」、「用語の違い」、「コードの違い」です。

アプリケーションの改修に大きくかかわることになるので、先に物理データ・モデルから統合するという方法はとれません。まずは、論理データ・モデルを用いて、システム同士にどの程度の差異があるのかを確認する必要があります。

最初に、各工場や企業の論理データ・モデルを作成し、それぞれのフィット・アンド・ギャップ分析を行います。次に、統合された、現状の論理データ・モデルを作成します。具体的な統合の手順は、前回の記事で説明した「最適化」を参考にしてください。

さらに、統合後の、あるべき姿となる論理データ・モデルを作成します。これを、現状の論理データ・モデルと比較することで、理想と現実（運用）がうまく噛み合った、理想的なデータ・モデルが完成します。

図5: 理想形となる共通データ・モデルの作成

（2）ERPパッケージの導入時

ERP（統合業務）パッケージを導入する最大のメリットは、システム構築の短納期化です。多くの企業では、対象業務の体系化を行った上で、ERPパッケージが提供する機能と比較し、充足していると判断したら、導入を検討します。

しかし、ERP導入の真の問題は、導入後にあります。「必要なデータが取得できない」といった問題が発生するのです。筆者が支援したユーザー企業では、ERPパッケージのテーブルからデータを取得して他のデータと連携させるブリッジ・プログラムを新規に作成したり、取得できないデータを投入する画面を新たに作成したりする、といったケースが多く見受けられました。

こうした問題は、ERPパッケージの導入前に、データの観点では分析していなかったことが原因です。

自社の論理データ・モデルを作成してあれば、ERPパッケージ導入の際に、データの観点でのフィット・アンド・ギャップ分析が可能となります。