データマネジメント データマネジメント記事一覧へ

[データマネジメント—“活用されるシステム”の極意]

突然の事業環境変化にデータマネジメントを対応させる:第4回

データの関係を捉えるための3つのポイント

2011年1月21日(金)大西 浩史(NTTデータ バリュー・エンジニア 代表取締役社長)

情報システムを経営に生かす-その根源となるのはデータの品質である。SOA(サービス指向アーキテクチャ)やクラウドコンピューティングなど技術革新の 激しいITの世界だが、データ品質の維持管理の視点が欠けていては恩恵を享受することはできない。「活用されるシステム」を具現化するための、データマネジメントの勘所を解説する。

第4回は、企業統合や法令変更といった、自社を取り巻く経営環境が突然変化することによって発生するデータマネジメントの問題と、その対応策について説明する(第1回に説明した3つの問題のうち、図1のCの部分)。

データの品質低下は様々な要因で起こり得る
図1 データの品質低下は様々な要因で起こり得る

実際の現場に関わったことがない人と話をすると、「企業統合により、一方のシステムを他方のシステム統合する必要が発生したら、旧コードで運用している取引先などの関連システムに影響が出ないように、両システムのコード対応表を用意して運用するのだろう」と考えている人が多く見受けられる。しかし、そうは簡単に行かないところが、この領域のおもしろみでもある。

今回は、製造業の企業統合に伴うシステム統合のケースをもとに、データマネジメントで苦労した実際の事例を挙げる。現場感を味わいながらお読みいただきたい。

企業統合に伴って変更が必要な
データマネジメントの基本的な考え方

図2は、グローバルに展開している製造業B社が、従来使用していた旧ホストのシステムを捨て、買収した海外企業A社が使っている販売管理パッケージシステムに乗り換えたときの統合イメージだ。

図3-1 分析・活用すべき情報の広がり
図2 大手製造業のシステム統合イメージ(図をクリックで拡大)

B社側では、統合前の旧ホストと連動したコード体系をもつ大口ユーザーシステムや販売店オンライン発注システム、素材加工工場システムが、旧ホストとは別に存在していた。これらのシステムは数多くの会社が導入しており、同時期に全部のシステムを入れ替えるのは非常にリスクが高い。そのため、販売管理パッケージシステムを移行するときに、旧ホストと素材加工工場システムなどへのコード読み替え用インタフェース(I/F)を設けることになった。

こうした読み替え用I/Fの作成は、企業統合に伴うシステム統合や、企業内でバラバラに運用されてきた複数のシステムのデータ連携を取る場合によく使用される基本的な考え方だ。

異なる企業のオペレーション統合を難しくする現実の問題

図3のように、旧ホストと販売管理パッケージのコード読み替えが単純にできる場合には、多少の手間はかかるものの、それほど難しいロジックはなくI/Fを作成できる。しかし現実には、それほど簡単ではないケースが圧倒的に多い。

コードの対応表
図3 コードの対応表

例えば今回例示しているケースでは、図4のように、工場で正式な品目コード“A12345-1”に対し、付属部品の切断や加工情報を変更した新品目コード”A12345-1AB”を独自で新規登録していた。これは、その工場が製品を納品している顧客向けに仕様を若干調整した製品コードであり、その工場でのみ通用する製造ルールを円滑に運用するためのものである。

各拠点や部署のローカルルールで多種多様なコードを発番していては、机上で作った読み替え用I/Fは、現場ではまったく使えないものになってしまう。連載第3回でも述べたように、「現場は必ずしも全体最適を意識せず、その場で適宜対処する」といった事象が頻発している。ER図やデータモデルを見ただけではデータ統合ができない、という好事例であろう。

現場で増殖するコード
図4 現場で増殖するコード

このケースのように、我々が顧客向けのプロジェクトの中で見てきたのは、単純な1対1対応の読替え用I/Fを作れば完了するような問題ではなく、発見しにくく、現場の運用によって変化するデータの問題が大半である。

「その工場のローカルルールで運用できているのであれば、支障はないのではないか」と思われるかもしれない。だが実際はそうではない。筆者の経験では、同一工場内でも、日勤で作った10枚の製品のうち1枚が出荷検査で不良判定を受け、再生産指示がかかったとき、夜勤担当者が独自コードではなく正規コードで生産指示を出したため、1枚だけ別の仕様になっていたというケースがあった。担当者が変わったタイミングでルールが忘れ去られたり、製造工場が切り替わるタイミングでも問題は発生する。

現実にシステム統合で問題になるのは、コードの読み替え用I/Fの作成ではない。優秀な現場のワーカーが、過去のトラブル事例などを参考に、独自の対応策を編み出して運用している―。そうしたケースこそ、発見や対応が難しい問題になるのである。今回例示した日本企業の素材加工工場では、基幹システムである販売管理パッケージシステムには含まれていない情報までもが、製造に必要となっていた。

実は日本の多くの現場は、いい意味でも悪い意味でも優秀なため、「顧客別に製品に付けるラベルを変更する」「以前クレームがあった顧客には製品を梱包する向きを変更する」「必要以上によく磨いている」など、過去の経緯から学習して、システムには入っていない情報を使って業務遂行しているケースが少なからず見られる。わかりやすいケースは、現場に模造紙で顧客別の運用ルールを貼っているなどだ。

こうしたローカルルールがたくさんあると、生産の全体最適のために製造拠点を変更することは不可能だ。筆者のプロジェクトチームは、こうした状況にあった企業で、他の製造拠点にも展開できるように、現場ローカルルールを抜き出す使命を帯びてプロジェクトを遂行した経験が複数ある。その時に留意すべきなのは、製造プロセスと製造に関係するデータの関係をしっかりと捉えることだ。具体的なポイントを次ページに記した。

●Next:データの関係を捉えるための3つのポイントを紹介

この記事の続きをお読みいただくには、
会員登録(無料)が必要です
  • 1
  • 2
バックナンバー
データマネジメント—“活用されるシステム”の極意一覧へ
関連キーワード

組織再編 / M&A / データ統合 / NTTデータ バリュー・エンジニア / SOA

関連記事

トピックス

[Sponsored]

突然の事業環境変化にデータマネジメントを対応させる:第4回情報システムを経営に生かす-その根源となるのはデータの品質である。SOA(サービス指向アーキテクチャ)やクラウドコンピューティングなど技術革新の 激しいITの世界だが、データ品質の維持管理の視点が欠けていては恩恵を享受することはできない。「活用されるシステム」を具現化するための、データマネジメントの勘所を解説する。

PAGE TOP