PART3 マスター不整合が引き起こす課題と　統合に向けた5つのポイント

マスター統合におけるポイントは何か。筆者は、(1)マスター項目の粒度、(2)項目定義の正しさ、(3)マスター項目の正確性、(4)マスター連動、(5)マスターの変化対応を挙げる。「きちんと設計し、実装しただけで済まないのがマスターデータ管理。効率よく正確にマスターを維持するには、設計時に事業の変化対応まで考慮するべき」という。（本誌）

図1　マスター統合で考慮すべき5つのポイント

「必要な情報が手に入るまでに思わぬ時間がかかる。結局、経験や勘頼みで意思決定をせざるを得ない」、「データや情報の定義に関して個人の解釈が介在し、信憑性に疑問がある」、「販売チャネル別、セグメント別、製品別など集計の切り口を変えるだけで、膨大な工数がかかってしまう。結果として自由な分析ができない」、「複数の事業部門システムを横断した得意先別の売掛金を把握できないため、焦げ付きが発生したことがある」。いずれも筆者がCIO、あるいはITコンサルタントとして複数の企業で見聞きした実話である。

このような、データや情報に関する信憑性の低さや正確性に対する不安、また必要なタイミングに対応しきれない原因はどこにあるのか。多くの企業では事業部門ごと、子会社ごとに異なるサーバーを立てて業務システムを構築・運用し、日常の業務オペレーションを行っている現実がある。システムは部分最適になり、データが各所に分散しているほか、マスターデータも齟齬がある。結果として、いざ情報を横断的に分析しようとしても簡単にはいかないことが、その一つであることは間違いないだろう。

マスター不整合に起因する問題

何よりもマスターデータの不整合は、様々な問題を引き起こす。複数のシステム群に散在したデータを結びつけることが非常に困難になり、情報を集約できない、できても現実的には多大な工数がかかるのがその典型例だ。筆者が関与したある企業では、製品マスター、得意先マスターが10種類以上のシステムにそれぞれ同じ、または異なる定義で存在していた。情報の集約はもちろん、日常の業務でも無駄な作業が生じていた。例えば新製品を発売した際に複数のシステムに重複してマスターを登録しなければならないといったことである。

この問題の難しい点は、単純にマスターを整備し、一本化すれば済むわけではないことにある。マスターの内容を変更すると、例えば過去に蓄積されたデータの意味が変わったり、無意味になってしまう問題が生じる可能性がある。部門別、製品別の過去の実績データが正しいのか正しくないのかの判断がしにくくなるのだ。自社のマスターの変更が取引先や顧客のシステムに影響を及ぼす可能性もある。

それでも冒頭で示したような、経営や管理業務における情報に関する問題の主原因が、マスターがきちんと管理されていないことにあることは間違いない。そうである以上、何らかのタイミングでマスターの整合性を確保し、それをきちんと維持・管理する仕組みを構築せざるを得ない。それは、内部統制の整備などを持ち出すまでもなく、厳しい競争にさらされる多くの企業においては喫緊の課題だろう。

マスター管理における2つの基本

では、マスターを整備するに当たって、マスターにかかわる何をきちんと管理すればいいのだろうか。まずマスター項目の粒度、細かさである。売り上げを例にすると、製品別売上金額なのか、製品別部門別売上金額、製品別部門別得意先別伝票別売上明細なのか。さらにそれは販売チャネル別なのか。製品そのものの属性（構成部品やバージョン）はどうか。こうしたことをきちんと見定めて、正しい粒度と整合性を持って集計を行うようにしたり、製品、集計の対象の網羅性を保障したりしなければならない。

次に、マスター項目の定義が正しいことが必要である。製品を例にすると、それが自社製品なのか、仕入れ商品なのか、預かり商品なのかによって、会計上の在庫計上の方法が異なる。支払い予定日や納品予定日という言葉も、意外に難物だ。これらはマスター項目のなかで使われるが、それは必ずその日である必要があるのか、あくまでも予定であるのかで、取り扱いロジックも、登録時の意識も異なる。それぞれのマスター項目を定義する際に、登録する目的と関連性を明確にした上で、定義を統一的に正しく行う必要がある。

マスターの正確性を担保する

第3に、マスター項目の内容が正確であることだ。同じ取引先であっても、部門や担当者によって（株）の位置が違っていたり、英字表記とカタカナ表記が混在していたりするのが典型例だ。

筆者が関わったケースで言えば、会員制度を持っていたある企業では、会員マスターに会員の性別の項目を設けていた。これがシステム開発時にデフォルトとして「男性」と指定されていたのである。結果として、少なくない女性会員がデフォルト値のまま男性として登録されており、属性分析がうまくいかないケースがあった。

ほかにも、マスター項目が登録時に必須であるものは正確性が高い傾向はあるが、Fax番号のように最近ではあまり使用されていない場合には、正しく登録されていないことが多い。このようにマスター項目の粒度や網羅性、定義が正しくても、内容が正しく登録されていない場合が数多く見られることを忘れてはならない。

マスターデータ項目の粒度や網羅性、定義の統一性、登録内容の正確性などがきちんと管理されているマスターを作ったとしても、それで十分とは限らない。企業内の複数のシステムに別々のマスターがある場合には、それぞれの関係性を正確に把握し、連動させることが不可欠である。これが第4のポイントである。人手で複数のマスターを更新するのは、短期的にはともかく中長期的には現実的ではないからだ。

さらにそれを実現したとしても、終わりではない。製品、技術、製造方法、製造拠点、販売チャネル、取引サービス形態、顧客、あるいは事業ドメインなどはすべて、時間とともに変化する。情報システムが経営や事業のPDCAサイクルに関わる情報を処理し、提供するものである以上、事業展開において求められる管理項目を洗い出し、マスターの構造に組み込む必要がある。言い換えれば、マスターデータの項目の種類と内容が、将来の経営の管理項目を支えるようになっていなければならない。

変化を考慮したマスター設計を

しかし現在、ほとんどの企業の製品マスターや顧客マスターは、必要とするマスター項目を事業の要請に従って追加したり、付加してきたものにすぎない。だから現在の管理項目を是としてマスターデータを整理し、再設計したとしても、そう遠くないうちに事業の実態に合わなくなる。

その結果、それまで静かに眠っていたExcelやFileMakerが顔を出し、“管理困難なマスター群”を増殖させるおそれがある。情報システムにシステム・ライフがあるのと同様、マスターにもマスター・ライフがある。このことをきちんと理解し、新たにマスターを設計する際に、将来の経営を支える管理項目をマスター構造に組み込まなければならない。

こうしたことを確実に実現するには、企業規模や事業領域、グローバル展開の有無などにもよるが、それなりの時間がかかる。その意味では情報システム部門の負担は大きい。しかし、その効果もまた多大なものがある。筆者が関与したある企業では、緻密な業務オペレーションと経営数字の見える化により、営業利益率が上昇するという顕著な効果があった。あくまでも推計だが、日本版SOX法への対応コストも従来のままだった場合と比較して、10分の1程度で済んでいることを付記したい。