はじめに

前回のブログでは、データマネジメントが出来ていないために生じる困りごとの事例『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』の前編「お客様に寄り添いたいのに・・・」をお送りしました。

海外から上陸したEC事業を展開する競合Z社の猛追にさらされた大手小売りチェーンB社の戦いと、期待の顧客履歴統合新システム「Gather」のリリース。しかし、リリース初日にまさかの事態が起きた・・・というところまで書きました。

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

参照：第１回『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』前編―

B社の現場で起こった混乱～ お客様、あなたはどこの誰ですか？

急拡大する競合Z社への対抗策として、B社は顧客エンゲージメントの向上と顧客のライフタイムバリュー全体への拡販による成長戦略を兼ね備えた「お客様への寄り添い力」戦略の基盤となる新システムGatherは、満を持してリリースされました。

Gatherのリリース初日、店舗やコールセンタでは「顧客の履歴データがうまく表示されない」「Gatherの情報を元に接客したらお客様に怒られた」と、「お客様への寄り添い力」を支えるはずのGatherが、利用者の大混乱を引き起こしてしまいました。

なぜ、このような状況に陥ったのでしょう。

Gatherで顧客履歴を検索すると、同姓同名の顧客がいても住所や電話番号でソートすれば同一人物であるか否かを簡単に識別できる仕様でした。

何しろ、統合対象の４つの顧客履歴データの管理部門への事前調査では、いずれも業務プロセスの連携には一切問題が起こっていないと太鼓判を押してくれたのです。

このため、プロセス間の共有言語として通用するのは間違いないと見越していました。

しかし、実際のデータを見ると、住所には大文字と小文字が混在し、丁目番地の入力も “○丁目△番地”と書かれているものと“○―△”とハイフンで書かれているものがあります。

また、マンションやビル名、階数や部屋番号の入力にいたっては入力の仕方が統一されていないどころか、そもそもデータが入っていないものもあります。

幸い電話番号は全て半角数字で統一されていたものの、市外局番があったり無かったりで、こちらも顧客を特定する情報としては当てになりません。

これではどのデータを信じて同一人物と特定すれば良いか分かりません。

肝心の拡販戦略であったライフタイムバリューの刈り取りでは、Gatherの履歴情報で５年前にランドセルの購入履歴がある顧客に対して「来春、中学生になられるお子様の勉強机など、ご一緒に新調されてはいかがでしょう？」とお勧めすれば、「はぁ？わたし独身ですけどっ」と怒られる始末です。

せっかく開発した新システムでしたが、一週間も経たずに現場から「まるで使えないシステム」の烙印を押され、誰も使わないシステムになってしまいました。

B社Gatherシステム失敗の原因～ 2025年の崖の手前の落とし穴

B社は一体どこで道を誤ったのでしょう？

それまでバラバラだった（サイロ化した）４つの顧客履歴情報を統合して、その顧客と自社との関係を一元的に可視化するという考え方そのものは決して間違っていなかったと思います。

B社が落ちてしまった落とし穴は、大きく２つありました。

・落とし穴その1　目的に合ったデータ構造（アーキテクチャ）の見誤り

１つ目の落とし穴は、「目的に合ったデータ構造（アーキテクチャ）の見誤り」です。

B社は「顧客との全ての関わりを可視化する」という要件に従って４つの履歴データを一つのデータベースにまとめましたが、本当は統合すべきだったのは「履歴」ではなく「顧客」だったことはケースをお読みいただければ分かると思います。

複数のデータを統合する際に最初に考慮しなければならないのは、複数のデータを連結するハブとなる項目（エンティティ）を見極めることです。

ゴールとするデータの構造（データアーキテクチャ）を俯瞰することで、データ間のつながりや連結のハブが明らかになります。

データアーキテクチャは「概念データモデル」によって描き出すことができます。

プロジェクトの最初の段階で概念データモデルを作成することで、データ構造（アーキテクチャ）の誤りという落とし穴を回避することができます。

・落とし穴その2　業務データの品質に対する過信

２つ目の落とし穴は「業務データの品質に対する過信」です。

顧客履歴データの元になっている４つの業務プロセスがスムーズに連携していることから、そこで発生する業務データはプロセス間を横断して共通に利用できると考えられていました。

しかし、実際には個々の業務プロセス内で必要なデータの品質や内容は異なり、業務の現場では、その業務で必要な品質と内容でしかデータを入力しません。

よく「配送データは物理的にモノを届けているのだから絶対に正確な住所のはずだ」と言う人がいますが、送付する人や受取る人にとって住所の記載内容は“とにかく届けば良い”のです。

配達ボックスのあるマンションの住人は、いちいち「〇〇号室」と書く必要はありません。

データの品質を評価する際は、システムの仕様やフォーマット定義だけでなく、実際のデータの中身を開いて、入力されている内容をアセスメントしなければなりません。

B社の戦略とシステムはきっと蘇る～ データで創る一歩先の未来へ

Gatherシステムがもたらした混乱の原因をB社内で検討した結果、統合データベースのアプリケーションではなく格納されたデータの問題であるとの結論に至り、データマネジメントの専門会社であるリアライズに支援を依頼しました。

駆けつけたコンサルYは、まずはデータアセスメントを行ってデータ品質の実態を確認することと、データアーキテクチャの誤りを正すために改めて概念データモデルを描くことを提案しました。

そして、概念データモデルは、本来ビジネス側の視点で作成するものであると続けるコンサルYにB社の経営陣は心配そうに聞きました。

「私達はITの専門知識がありません、その何とか言うモデルが書けるものでしょうか？」

コンサルYが落ち着いた声で「概念データモデルに必要なのは、ITの知識ではなく、ビジネスへの深い洞察です。皆様以上にB社のビジネスを理解されている人が他にいるでしょうか？ご安心ください、私がサポートさせていただきます。」と答えると、B社経営陣の顔に安堵の色が浮かびました。

一時は頓挫するかと思われたB社の「お客様への寄り添い力」戦略とGatherシステムは、この瞬間に再生のスタートを切りました。（完）

おわりに

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

第２回『気をつけろ、2025年の崖の手前には落とし穴があるぞ！』後編―いかがだったでしょう。

リアライズは、お客様の業務プロセスやビジネス戦略に基づいたデータアーキテクチャの設計させていただきます。

また、既存のデータについても、データの中身にまで踏み込んだデータアセスメントから、名寄せ・データクレンジングなどのデータ整備からデータ品質の維持運用まで、トータルにサポートします。

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

敬具

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

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

他の人気ブログ