はじめに

前回のブログでは、データマネジメントが出来ていないために生じる困りごとの事例『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』シリーズから、ケースその２「恐怖のゾンビデータ」前編をお送りしました。

想定外の世界的環境変化に見舞われた電子部品メーカーN社は、危機への対応を図ると同時に、この逆境をチャンスと捉え、果敢なビジネスプロセス改革を伴う「調達DX」プロジェクトを立ち上げ、新調達発注システムPROSIT（プロージット）の開発に先立つPoC（Proof Of Concept：概念実証）に着手したところまで書きました。

さて、続きはどうなるのでしょう。

（前編はこちら）

N社製品マスタに潜むモンスター～ ゾンビデータ

N社では、製品出荷予測データから製造に必要な発注部材を抽出するには、以下の３つのステップが必要でした。

（STEP-1）出荷予測された製品を特定する“製品コード”を決める

（STEP-2）“製品コード”に対応する“生産品番”を紐づける

（STEP-3）“生産品番”に紐づくBOM（Bill Of Materials：部品展開表）から必要な部材を展開する

新調達発注システムPROSITのPoCは、いきなり（STEP-1）で躓いてしまいました。

製品出荷予測データに記された製品名称に該当する“製品コード”を基幹システムの製品マスタで検索すると、同じ製品名称で異なる“製品コード”を持ったレコードが何件も出てきてしまうのです。

製品のことなら何でも知っているはずのプロダクトマネージャでさえ、製品マスタがこんな状況になっていることを知りませんでした。

プロダクトマネージャは、すでに生産終了になっている製品が、なぜか出荷可能なステータスになっているのを見つけると、小さな声で呟きました。……まるでゾンビだ。

N社の歴史が生んだ負の遺産～ ゾンビの履歴書

N社の製品マスタデータに潜むゾンビは、一体いつ生まれたのでしょう？

原因は20年以上前に大流行したBPR（Business Process Re-engineering）の取り組みでした。

その頃、N社では製品の設計開発リードタイムを短縮するために、設計開発部門の間接業務をできるだけ他の部署へ移管する業務改革が行われ、それまで同部門が行っていた製品マスタデータの入力とメンテナンスの作業が、物流センターへ作業移管されていたのです。

はじめの頃は単純に、設計開発部門から送られてくるリストを製品マスタに入力していたのですが、やがて物流センター内の業務改善のために、以下のような運用を行うようになりました。

・大口客先向けの専用在庫など、倉庫内で別管理が必要な製品に個別の製品コードを登録して、ひと目で区別ができるようにする

・物流センター本部で製品マスタを登録しているが、各地の拠点倉庫が各々の業務の都合に合わせて複数の製品コードを勝手に作っている

・在庫が残っている生産終了品を販売する場合、従来は営業部門が手書きの「特別出荷依頼伝票」で、その都度依頼しなければならなかったが、業務スピードを上げるため、在庫のある生産終了品は拠点倉庫の判断で、営業部門が受注システムから直接出荷指示ができるよう出荷可能ステータスを変更する

これらは物流センターなりの業務改善を積み重ねた結果なのですが、調達DXにとっては大問題です。

早速CDO（Chief Digital Officer）は製品マスタのデータを整理するようプロジェクトメンバーへ指示しました。

しかし、対象の製品マスタデータは数十万件に登る上、個別の製品コードを登録するルールも拠点倉庫ごとに考え方がバラバラなため、一件ずつ目視による判断が必要な状態で、どうにも手の付けようがありません。CDOは空を仰ぎました。

N社 問題の原因はMDMの不在～ 2025年の崖の手前の落とし穴

N社の調達DXを待ち構えていた落とし穴は、20年以上かけて掘られた厄介なものでした。

それは「マスターデータ管理（MDM）の不在」という名の、実はN社以外にも多くの企業の中で今日も人知れずゾンビを生み出している恐ろしい落とし穴です。

企業内のビジネスデータには、注文伝票や出荷指示のようなビジネス手続き（コト）を記録した「トランザクションデータ（以下、トランザクションと呼びます）」と、顧客リストや社員名簿のようなビジネス資源（モノ）を管理する台帳である「マスターデータ（以下、マスタと呼びます）」とがあります。

トランザクションの正確さに対する責任は、各々の業務プロセスの実行者にあるので自然と明らかなのですが、マスタの正確さに対する責任は、しばしば曖昧になってしまうことがあります。

N社の製品マスタの内容は、本来は設計開発部門が責任を負うべきものですが、データの入力作業を物流センターに移管したときに責任の所在を明確にしなかったため、実態としてマスタの内容に関する責任が不在となってしまったのです。

欧米のようにジョブディスクリプリョン（職務記述書）によって、詳細な管理責任を規定する文化の薄い日本では、N社と同様の問題が起こりがちです。

こうした状況に陥らないためには、社内のマスタの管理責任を持つデータオーナー部門を明確にアサインし、必要に応じてデータの入力・更新作業を担当するデータスチュワード部門を定めた「データガバナンス体制」の構築が必要です。

N社 祝杯（プロージット）をあげるその日まで～ データで創る一歩先の未来へ

数十万件におよぶ製品マスタデータの見直し方法に行き詰まってしまったCDOは、データマネジメントの専門会社であるリアライズに相談を持ちかけました。

やって来たリアライズのデータコンサルタントは、N社の部材調達が直面している厳しい環境変化と、製品マスタが陥っている問題の説明を聞くと、しばし腕を組みました。

部材の調達リードタイムの遅延問題は、早急に解決しなければならない喫緊の経営課題です。しかし、製品マスタは現在の業務に深く組み込まれているため、拙速な変更を行えば現場の業務に支障を来すことは目に見えています。

「ちなみに、製品マスタ以外にもゾンビが住んでいそうな心当たりはありますか？」というデータコンサルタントの問いかけに対して、CDOは暗い表情で答えました。

「製造業の根幹とも言える製品マスタで起こっていることですからね。恥ずかしながら他のマスタも推して知るべしと言ったところでしょう」

データコンサルタントは思案の末に、対策を短期的な課題対応と、中長期的な取り組みの２つに分け、以下のように提案しました。

１．短期的な課題対応

・新調達発注システムPROSITに適切な出荷予測データをインプットするために、優先順位の高いものから製品マスタデータを「名寄せ」して、暫定的な「調達DX」用の製品マスタのサブセットを構築する。似て非なるマスタが社内に併存するのは望ましいことではないが、下記の中長期的な取り組みの中で解消するという前提条件付きで容認することとする

２．中長期的な取り組み

・N社内の「データガバナンス体制」を構築し、継続的なデータマネジメントを行うことによって、今後のデータドリブンなビジネス推進を可能とするデータ運用の体制を整備する。その際にはゾンビの隠れ家を見逃さないよう、N社全体の概念データモデルを俯瞰して、重要度の高いところから実際のデータをアセスメントし、データ品質のチェックを行う

・現状の製品マスタから、物流センターの業務要件で追加された情報を別テーブルに切り出して、データガバナンス体制に基づく本来の製品マスタの運用を再構築する。そのうえで改めて製品マスタ全体の名寄せを行い、暫定的に作成したサブセットのデータを吸収して、類似マスタの併存を解消する

N社の会議室に集まったプロジェクトメンバーは不安そうに聞きます。

「データの名寄せって具体的にどうやるんですか？」

「国内でデータガバナンスが実際にできた事例はあるのですか？」

データコンサルタントは胸を張ります。

「ご安心ください、どちらもリアライズにとっては長年やってきた得意分野です」

思いもよらない20年越しのゾンビに道を塞がれたかと思われたN社「調達DX」と新調達発注システムPROSITでしたが、今はトンネルの向こうに輝く確かな光が見えています。

おわりに

ブログを最後までお読みいただき、ありがとうございます。

第４回『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』ケースその２（後編）いかがだったでしょう？

N社が直面した問題は、今も多くの日本企業で密かに発生している厄介なものでした。もしかしたら、あなたの会社にもゾンビデータが潜んでいるかもしれませんよ～。

リアライズは、現状のデータをアセスメントすることでデータ品質を評価し、値の不揃いや欠損を修正する「データクレンジング」、重複したデータに対する「名寄せ」を行います。また、データドリブンなビジネス展開に不可欠な、データガバナンスの構築と継続的なデータマネジメントの実現をご支援します。

次回も皆さまを“データで創る一歩先の未来”へナビゲートさせていただきます。

敬具

※本文中のケースは実際にあった事例をベースとしたフィクションです。実在する企業・団体とは関係ありません。

※記載内容は執筆当時のものです。株式会社リアライズは2023年1月1日に株式会社NTTデータ バリュー・エンジニアに社名変更しました。

他の人気ブログ