Techopediaスタッフ、2016年5月25日
持ち帰り：ホストのエリック・カバナがマスターデータ管理について、デズ・ブランフィールド、ロビン・ブロア、ジョン・エヴァンス、ダイアナ・コリンズと話し合います。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ：了解しました。ご列席の皆様 、夏の時期が近づいています。ここは暑くなってきています。 なんで？ Hot Technologiesの時代だからです。 はい、私の名前はエリック・カバナです。 私はショーのモデレーターになります。何がホットで、何が起きているのか、市場で何がクールなのかを話すべきです。 これはTechopediaとのパートナーシップです。 私たちはこれらの人たちが大好きです。 数年前から彼らと仕事をしています。 彼らは素晴らしいサイトを持っています。 技術の世界で何かを知りたい場合、その定義がどうであるかを知りたい場合は、techopedia.comにアクセスしてください。 そして今日は、MDM、マスターデータ管理について話しています。 正確なタイトルは「最大の画像：複数のプラットフォームで顧客を知ること」です。そして、このゲームは変わりつつあります。
本当にあなたについてのスポットがあります。Twitter@eric_kavanaghで私を見つけてください。 私に返信する人には誰でも返信しようとします。 今年は暑いです。 MDMにとっては間違いなく暑いです。 暑いのは、大企業だけでなく、多くの異なるシステムを持つ中小企業にとっても暑いことです。 CRMシステム、電子メールマーケティングシステム、ERPシステム、Web分析システム、eビジネススイートなど。顧客に関する情報へのさまざまなアクセスポイントがあり、企業がそれを一緒に織ることでより良い仕事をすることができます。顧客にサービスを提供できるようになります。顧客にチェックを入れて、それらの顧客を維持することはできません。 彼らにもっと何かを買ってもらいましょう。
2003年頃からMDMを実際に追跡してきましたが、これはこの用語が実際に造られた頃です。 率直に言って、銀行、実際にはチェイス銀行がありました、それは当時の銀行でしたと思います、そして私の友人の一人、ジョー・ノーザンという名前の男はラザ・ソリューションズと呼ばれる会社で働いており、彼らはDRMツールになりましたオラクルの。 そのため、彼らは実際にアカウントをロールアップし、当時銀行の階層管理を行っていました。これは、マスターデータ管理の初期の一部です。
そのため、最近では分析MDMと運用MDMの両方について話します。 今日はそのようなことについて多く話し、このテクノロジーを活用して顧客を完全に把握し、彼らが誰であるかを理解し、彼らのニーズを確実に満たすことができる方法を理解するのに本当に役立つでしょう世界中で率直に言って非常に競争の激しい環境です。 私たちはあちこちでそれを見ています。
だから、ここのキャラクターのロックスターキャスト：デズ・ブランフィールド、ロビン・ブロア、ジョン・エヴァンス、ダイアナ・コリンズ。 世界中の4つの異なる場所から電話をかけます。 Dez Blanchfieldから始めて、それから私はあなたにキーを渡すつもりです、Dez、そして私はツイートを始めます。 奪って
Dez Blanchfield：エリック、ありがとう。 ミュートを解除することを思い出させる必要がありました。 申し訳ありません。 これについて発表する機会をありがとう。 それで、私は、組織の挑戦の実世界の例の観点からこれに来て、彼らがいくつかの人のために見ようとしている組織に対する最大の混乱の1つと呼んでいるものに対処します時間。 多くの課題があります。 GFCのヒット企業はそれに対処しなければなりませんでした。 私たちは対処しなければならないプライバシーに関する法律を定期的に変更しています。
組織が来ないことに気付いたと思うことの1つは、この有名人体験の問題全体の影響でした。 そして本質的に、携帯電話を持って走り回る人々は、何らかの形で即座に満足を望んでいます。 しかし、うんざりするような幼稚な方法ではなく、良い方法で即座に満足する。 彼らが顧客であること、彼らがお金を払っていること、そして彼らがその価値を手に入れるべきであるということに気づくだけです。 そして、顧客中心主義のこの造語や、顧客中心の組織になりました。 それで、私はそれが何を意味するかをすぐに歩き、議論のもう少し技術的な部分にすぐに導くつもりです。
私はただそれを公表して、まず、顧客中心の組織であるということは、1つの簡単な事柄に帰着すると言います。顧客と顧客データの完全なビューが必要です。 システムが異なる場合があります。 さまざまな製品があります。 組織内に50の異なる部門がある場合がありますが、組織内のどこにいても、職務が何であるかに関係なく、すべての顧客、または顧客に関連する顧客の完全なビューを取得できる必要があります。あなたの職務は何ですか。 そして、あなたが持っているデータセットのすべての部分、またはあなたが持っているデータセットのすべての部分は、その顧客の国家の状態を教えてくれます。
すべてのシステムの顧客の全体像は、単なる見栄えではないということをこの行に書きました！ 今日ではそれは必要です。 そして、特にライブ、電話、ウェブチャット、またはさらに恐ろしい人の場合、顧客とのやり取りを扱っているシナリオに最初に巻き込まれます。 「あなたが彼らについて知っておくべきすべてを彼らに話してはいけない、それは非常に明白になり、それは非常に不幸な状況にある。
実世界のシナリオに関する非常に簡単な逸話から始めます。 これはホワイトボードの写真であり、5日以内です。 これは、数日前の最近の部屋のホワイトボードでの実際のシナリオであり、ビジネスの90の異なる部分のような非常に大規模な組織からどのように進むのかというまさにトピックについて話します。 アジアの銀行で、90の異なるビジネスユニットがあります。 彼らは、社会ローン、ピアツーピアおよびマイクロローンから、衛星を宇宙に置く資金調達に至るまで、あらゆることを行っています。 だから彼らはモンスターです。 彼らは数千万人のクライアントを持っています。 彼らは5000万人未満のクライアントを持っていると思います。 そして、彼らは、マスターデータ管理だけでなく、特に顧客データと単一ユニットクライアントにどのようにアプローチするかという、この典型的な課題に直面しています。
そして、このホワイトボードから私たちを飛び出させたのは、彼らが単に問題を抱えているだけではなく、システムがお互いに話し合っていないため悪夢だったということです。 銀行のどこか、またはビジネスのどこかに行ってローンを要求することができます。それは自動車ローン、住宅ローン、中小企業ローンかもしれませんが、彼らは自分自身に何も言えないか、できませんでした。銀行と私が持っていた他の関係について何かを発見する。 そして、道端の銀行はすでにこれを行うことができ、エイトボールから12、15年遅れている可能性があることに気付いたので、彼らの昼光を絶対におびえていました。 そして、クライアントが探しているこれらの重要な価値提案に帰着しますが、これは顧客としての私の一貫した見解であり、あなたはそれをどのように提供するのかを理解する必要があります。 特に今はウェブ上であなたとやり取りしているので、最近はアプリ経由の場合が多いでしょう。
「重要なのは顧客である」ということです。したがって、顧客中心の文化がどのようなものであるかを明らかにするとき、最初のようなものをキャプチャするコアシステムから得られるものすべてを組み込むことが重要です。フォームに記入するか、オンラインで記入するか、アウトレットのどこかにあるカウンターで私たちのところに来たときの名前、姓、その他の詳細、そして製品自体またはサービスを配達する私たちの旅全体を通して最初に知ることができます君は。 そして、それを上から下にマッピングします。 データとそれを理解するために使用するデータモデルを継続的に改善します。 ビジネスにおけるこれらのテクノロジーとプロセス、仕事の流れを調整し、お客様の見解を継続的に強化します。 お客様との継続的な関与。 クライアントに継続的に焦点を当て、クライアントとコミュニケーションをとる方法。 3つのサービスを販売している場合、毎月3つの異なる紙片や3つの明細書や請求書などを送信したくありません。
顧客中心のストーリーは今や真の牽引力を得ており、組織はその価値を認識しています。 「さて、私は10個の異なるシステムを持っているのに、お互いに話をしません。 そして、私があなたに見せたようなホワイトボードセッションを行う部屋に必ず人が集まります。 しかし、それはすべて、変換の左隅にある中核的なものに帰着します。 そして、組織の文化、人、スタッフ、運用モデルから、それらをサポートするテクノロジースタックに至るまでの変革。 したがって、組織がこのポイントに到達するために通過するかなり一般的なチェックリストがあり、顧客中心であることの意味と、システムを構築し、これを支援するツールにアクセスする必要性の課題を理解します。
それは、顧客の旅をライフサイクル全体にマッピングすることや、彼らが組織としてあなたと経験することのようなものです。 運用モデルを改善し、顧客と顧客に提供した価値提案に焦点を当てるように組織化する方法。 そしてもちろん、テクノロジーとテクノロジースタックおよびテクノロジー周辺のプロセスを調整して、実際に継続的にさらなるエンゲージメントを促進し、クライアントとのより良い、より緊密なエンゲージメントを促進します。 そして、幹部からの実際のエンゲージメントプロセス自体は下向きです。
フードチェーンのトップから、会議室から下へと世界観を変えていない場合、デポレベルまたは日々の財務スタッフが行動を変える可能性はほとんどありません。 あなたは上からリードする必要があります。 クライアントへの実際のフォーカスをターゲットにする方法を継続的に更新、再定義、再開発する必要があります。 では、組織のトップエンドでの文化的変化だけでなく、組織のボトムエンドでの行動の変化、およびそれを可能にするツールをどのようにもたらしていますか？
あなたが顧客中心の組織であり、人々が一方向に振る舞うことを望んでいると言うことは一つのことですが、あなたは彼らに手段とツールとそれを行う能力を与えていない、あなたは行動を得ることはありませんなぜなら、人々は自分たちが顧客中心の組織であると考える前に彼らが知っていた習慣に戻っていくからです。 そして、組織の異なる部分の全体的な統合と、その中に存在し、ツールとプラットフォームによって明らかに支えられた文化。
それでは、これらの異なるビジネスユニット、ビジネス、または組織の一部をどのように取り、それらを文化的観点と下向きに異なる動作にさせるのでしょうか？ まあ、あなたは彼らに適切なツールと方法と手段を提供し、クライアントとクライアント体験の完全で単一のビューを取得します。 そして、どのようにいくつかのKPIを置き、それに対してそれを測定し、それを追跡し、それらに対していくつかのメトリックを置き、それらのKPIを測定し、それに価値を提供しますか？ あなた自身にとってのビジネス価値、そして明らかに顧客にとってのバリューチェーンの何らかの形で価値を持ち、彼らが戻ってくるようにします。 そして、フィードバックやリアルタイムからクライアントと得たすべてのコミュニケーションを取り入れたり、繰り返し処理したりして、あなたの行動や文化の変化を何らかのフィードバックサイクルとフィードバックループで捉えることができれば、実際にマークを打つかどうか。
最終的に組織が異種データに効果的にdrれていることに気付くシナリオに到達します。ここでは、内部、外部のいくつかの種類を見ました。 歴史的には、顧客関係管理プラットフォーム、広告プラットフォーム、マーケティングプラットフォームがありました。 独立して実行されるあらゆる種類の異なるシステムがあり、それらが何らかの形で互いに対話することを願っています。 ここ数週間で、あなたとのやり取りが爆発的に増えました。そこで、ソーシャルメディア経由であなたと話します。ウェブサイト経由であなたと話します。あなたからメールを受け取ります。
電話であなたと話す私たちのIVRシステムは、そのデータをマップし直し、電話システムをどのように処理し、データベースとやり取りするかを教えなければなりません。リアルタイムでキャプチャされ、共通のビューを取得できるようにする必要があります。これは、その図の中心にある共通のデータ管理プラットフォームです。
「有名人の顧客体験」という最近造られたフレーズがあります。それはどういう意味ですか？ 私たちのエンドユーザーや消費者が行儀の悪いセレブだと思うのではなく、彼らが何らかの形で違うと感じるのではありません。 つまり、すべてのお客様を有名人として扱うべきだという事実に目覚めたということです。 彼らは、顧客として彼らを迎える喜びを持っているというライフサイクル全体を通して、彼らに出会ったその瞬間からVIP待遇を受けるべきです。
それで、私が定期的に尋ねられる質問-これをクライアントの少し逸話的な実際の話に戻す-は、セレブリティの顧客体験に対するその増大する需要をどのように組織が実現できるようにするのでしょうか？ 現在私たちが目にしているのは、組織にとって最大の混乱の1つであるため、クライアントへの約束を果たすという要件です。 有名人にカスタマーエクスペリエンスを提供するため。 私の経験から、そして確かに私が見ている世界中の組織は、彼らが実際の顧客についてすでに知っているか、または見ている他の影響からの変化に気付かずに混乱しています。 顧客は彼らを混乱させ、非常に深刻な方法で彼らを混乱させています。 そして、この有名人の経験を提供できず、組織がクライアントの単一のビューを取得するためのツールと方法と手段を提供できない場合、あなたは1マイル、少なくとも田舎のマイルで逃しますその約束を果たす能力と能力。
ここでいくつかの重要なポイントを挙げてから、Robinに技術的な詳細を渡して、すべての組織がこの配信に少しでも近いかどうかを非常に厳しく考えることをお勧めしますスタッフと組織が顧客中心のエンティティになるという約束。 そして、それは基本的なコンポーネントに焦点を合わせ、単一の顧客ビューを作成します。 それは非常に単純に聞こえますが、それはどういう意味ですか？ それは、適切なデータソースから適切なデータを常に適切なタイミングで取得することを意味します。 データが常に適切な場所にあることを確認してください。 時々だけではありません。
そして、それはしっかりと統合されなければなりません。 また、プラットフォームにネイティブに組み込まれている必要があります。 それはあなたがあなたが思うと思うことだけではありません。 単一のマーケティングキャンペーン。 顧客を見るたびに、これを常に取得できるようにする必要があります。 すべての適切な人々が常に利用できる必要があります。 ですから、部族の知識を求めて廊下を走り回るのは嫌です。 1つのツールにアクセスするだけで、すぐにこれを取得できる必要があります。 そして、適切なツールと適切なプラットフォームで提供する必要があります。 そのため、すでに使用している既存のシステムに組み込む必要があります。
CRMは、モバイルアプリから、Webサイトから、IVRとの対話、インタラクティブな音声録音、セルフサービスとして電話ヘルプデスクを自分で確認するまで、すべてを表示できる必要があります。 または、スターナインを押して人間に到達した場合、IVRが対処するようにプログラムされていないという少し難しい質問をします。 何か幸せなことをツイートしたり、LinkedInで記事を書いたりした場合。 これらはすべて最終的にCRMにフィードバックする必要があるため、顧客との関係を管理している場合はそれを確認できます。 例外ではなくデフォルトにする必要があります。
人々がキャンペーンを実行したい、販売とマーケティング活動を実行したい、または何らかの問題を解決したり、価格設定の問題に対処したいということは、依然として例外です。 1回限りのキャンペーンを実行し、クライアントの特定のセグメントの単一ビューを取得して、レポートの実行と物事の印刷を開始し、製本された印刷コピー形式で手渡します。 それは例外です。 それがデフォルトである必要があります。 システムは常に、クライアントのこの単一のビューを提供する必要があります。 そして、販売とマーケティング、単なる運用、製造、ロジスティクス、またはそれが何であれ、どのような観点からでも、私たちはそれを実現します。現実はあなたがすべてをしなければならないことです。顧客中心の組織になるためのこの移行への投資について堅実なROIを見ることができます。 すぐに勝ちます。 間違いなくすぐに勝ちます。 そのため、その面でいくつかの良いニュースがあります。 しかし、現実は、顧客中心の組織の完全な単一ビューへの移行を完了するまで、ROIは画面から飛び出しません。 そして、それは楽しい旅です。 それは価値のある旅です。 そして、適切なツール、適切なプラットフォームを持ち、合理的、技術的、商業的に実行可能な形式で、可能な限り早い時期に組織で利用できるようにすることによって、すべてが支えられています。 それを念頭に置いて、ロビンに引き渡します。 ロビン？
Robin Bloor：ありがとう、Dez。 私はあなたと同じことをしなければならなかった、私は自分自身のミュートを解除しなければならなかった。 さて、Dezが経験した一種の実用的なシナリオよりも、概念的な観点からこれにアプローチするつもりでした。 MDMの分野に入ると、もちろん顧客が大事であるときに、組織内の非常に具体的な一連の活動について話しています。 さまざまな理由から、顧客のエンティティアイデンティティを取得するのは、他の何よりもはるかに困難です。 最も重要なエンティティである可能性があります。 顧客が1人だけで、その顧客について取得できるすべての情報を持っている企業もあります。 非常にまれな。 ほとんどの組織には複数の顧客があり、顧客には複数のファセットがあります。 そして、データはいたるところに広がっています。 私はこのアイデア、つまりデータピラミッドのアイデアに取り組んでいます。 データと情報と知識の間に明確な違いがあり、実際に理解していること。 ただし、データ、情報、および知識はコンピューターに格納できます。 最も低いレベルのデータは、単なる信号と測定値です。 そして、あなたが手に入れることができる情報は何ですか？
エリック・カバナ：あなたの音声は少しフェードアウトし始めています、ロビン。 ちょうどあなたが知っているので。
Robin Bloor：マイクを動かします。 どのようにそのことについて？
エリック・カバナ：どうぞ。 それはずっと良く聞こえます。 行くぞ
Robin Bloor：ええ、データは主に信号、測定、記録などで構成されています。 特定のコンテキストはありません。 それはそのコンテキストを与えることで情報になります。 データをリンクします。 データの構造化。 視覚化、用語集、スキーマの作成。 あなたがその周りに作りたいものは何でも。 何らかの方法で特定のエンティティの動作を実際に予測し、それを処理するためのポリシーとルールを実装できるようになると、知識に変換されます。 完全に人間の生活を理解する。 そして、それは問題の一部です。 顧客の状況という観点で存在する断片化を実際に見ると、実際には販売には顧客の1つのビューがあり、マーケティングには別のビューがあることがわかります。 営業サポートまたは実際には単なる顧客のメンテナンスには、異なる見解があります。 顧客が組織に対して持つ多くの接点が存在する場合があります。 そして、それらのどれも適切に構造化された情報に統合されていないか、その多くが統合されていません。
そして、ここ数年ではるかに一般的になり始めた問題があります。人々に関する外部データを収集できますが、それは非常に便利ですが、実際の価値を得るためにはそれを統合する必要があります。 そのため、データの洗練では、断片化から大きな困難が生じます。 そのデータはさまざまな場所から来ており、十分に構造化されていません。 そして、新しいデータが絶え間なく供給される傾向があるという事実は、顧客に関して言えば、ほとんど常にそうです。 そして、すべてのエンティティは動くターゲットです。 おそらく3〜4年前には、顧客のソーシャルメディアプロファイルについては気にしませんでしたが、今は気にしています。 何が起こっているかに応じて、それが組織に損害を与えたり、組織を後押ししたりする可能性があるため、私たちはそれを気にします。
あなたが実際にアイデアを持っているなら、あなたが座って練習をして、5年前に顧客について興味を持っていたことを解決しようとしたなら？ そして、あなたは再びそれを行い、あなたはものが追加されたことを発見します。 そして、ものは取り除かれたかもしれません。 例えば、人々が実際に持っているファックス番号を気にする人はもういません。 一部の人々は、名刺にファックス番号を付けていました。 しかし、ファックスが死んだので、誰ももう気にしません。 だから、それは動いているターゲットです。 データモデリングとMDMを最初に見るとき、実際にこれについて言わなければならないのは、これがデータガバナンスの一部であるということです。これを行わない場合、データを管理する方法に問題があります。 実際にデータモデリングとMDMを実際に行っていない場合は、何らかの方法で、実際に特定のエンティティの非常に優れたトップダウンビューを実際に持っていないためです。
しかし、ここにデータガバナンスをリストしました。 系統、データ使用量、品質、セキュリティ、サービス管理、回復をリストしました。 ライフサイクルなどを追加できます。 データガバナンスとデータモデリングには非常に多くの問題があり、MDMはその基本であり、おそらく中心的な部分です。 変化は、人々が変化が起こっていることに気付くために変化が起こっていることに気付くという意味で、トップダウンから生じます。 したがって、ファイルやデータベースからデータ要素、ベータデータやビジネス定義まで、このスタック全体の観点から考えることができます。
実際に何らかの方法でスタック全体を管理し、スタック全体を最新の状態に保つ必要があると考えるかもしれません。ビジネス定義レベルで何かを知っていても、実際にデータをキャッチしているわけではないからです。ファイルおよびデータベースレベル。 それは非常に大まかな図であり、実際にそれについて考えるまで、それがどれほど広いかは分からない。 モデリングとMDMは、実際に見てみると、ビッグデータ全体の傾向は単にそれだけではありません。もっと多くのデータがあります。 これは、より多くのソースからより多くのデータがあり、実際に情報を収集している特定のエンティティについて、より多くの視点を提供するということです。 そして、複雑であるほど、モデルが必要になるほど、理解するのが難しくなります。 10、20、30のソースから実際にデータが送られてきたときに何が起こっているかを、データベーススキーマを見てみましょう。
理論的には、MDMはデータユニバースのビューを提供すると言うことができますが、実際にはそれはその一部です。 そして、実際にデータのビジネス上の意味を見ている場合、データの意味に関する情報が実際にあなたが見ているデータユニバースの一部であることを説明しました。 モデリングは上から下、下から上です。 つまり、ビジネスの観点から物事を見ることができますが、私たちが持っているものの観点から物事を見ることができます。 そして、両方向に構築します。 そして、これはプロジェクトではありません。 それを始めるのはプロジェクトです。 それは継続的な活動です。 一貫性のあるものが何もないので、プロジェクトとして開始することもできますが、いったん開始したら、それは継続的なアクティビティになります。 そして、データの範囲内で行われることは何でも、必要に応じてMDMチームがそれについて知っておく必要があります。
顧客の課題は、顧客エンティティに焦点を当てるだけです。 現在、他のどのエンティティよりもはるかに多くのソースから顧客について入手できるデータがはるかに多くあります。 そして、それは常に増加しているようです。 しばしば不正確です。 たとえば、私からデータを収集している場合。 私についてのデータを収集している場合は、さまざまなWebサイトにアクセスするときにミドルネームのイニシャルを使用するかどうかに関係なく、私には異なるアイデンティティがあることに気付くでしょう。 そして、特定のIDからスパムを取得する場所を見つけるためだけに、それを頻繁に行います。 しかし、多くの人がそうしています。 そして、人々は偶然の間違いを犯します。 そして、情報は古くなっています。
特定の個人に関する多くの情報を提供できると主張するこれらのデータリソースの1つにアクセスし、明らかなことを行い、自分について質問しました。 そして、彼らが私に提供した情報の半分は、実際には時代遅れでした。 とにかくそれのいくつかは間違っていました。 そして、あなたはそれを見て、何らかの方法で他のソースからデータを収集する場合、データをクレンジングし、それがあなたが持っているデータであるかどうかを識別することができるという大きな要素があると思います。 個人として一意の識別子はありません。 名前と携帯電話番号でほとんどの人に親しくなるでしょうが、誰もが携帯電話番号を持っているわけではありません。 そして、それは文化によっても異なります。 そして、分析の観点からデータの性質があります。
これについては詳しく説明しませんが、データは選択できます。 誰かのTwitterデータを取得している場合、Twitterに積極的にデータを投稿している個人はごくわずかです。 そして、彼らは選択しています。 彼らは無作為に選ばれた顧客ではありません。 彼らは、ツイッターで大声で話したいと決めた人たちです。 顧客を360度見渡すのは難しいことで有名です。 そして、それは部分的には皆の技術的歴史のためです。 3つ以上の顧客データベースがあることを発見することは珍しくありません。データベースと同様に、顧客に関して実際に収集する他の多くの情報源を気にしないでください。 顧客分析については、今が大きなチャンスだと言う価値があります。 以前は解約でセグメンテーションを行っていましたが、今では非常に多くの外部データが顧客に利用できるため、非常に多くのリレーションシップグラフ分析を実行できます。 これまで知らなかった予測分析を使用できます。 これまでに収集できなかったファッション情報や意見情報を収集できます。
顧客に関して何をしているのかをレビューし、持っているデータをどのように最大限に活用できるのかを考える非常に良い理由があります。 実用的なビュー。 顧客エンティティのモデリングは、正確で有用なBIと知識の洗練のために必要な活動です。 言い換えれば、かなり多くの顧客がいる場合、それは実際にはオプションではありません。 あなたはそれをやらなければならないのです。 そして、それが私が言いたいことのすべてだと思います。 ボールを渡しましょう。
エリック・カバナ：じゃあ、ジョン、次は行くと思う？ その後、ダイアナがデモを行います。 それで、ジョン・エヴァンス、それを取り去ってください。 皆さん、恥ずかしがらずに、いつでも質問を送ってください。 Q&Aのためにそれを監視します。 ジョンエヴァンス
ジョン・エヴァンス：わかった。 エリック、ありがとう。 そして、その紹介とそれらのコメントについて、DezとRobinに感謝します。 あなたがそこで語ったことと、今日私たちが話し、示すこととの間には多くの重複がありました。それは素晴らしいことです。 そして、この顧客中心性の概念は人々が達成しようとしているものであることに間違いなく同意するでしょう。そして、私たちはその根本で、あなたがあなたの顧客について得ることができる限りの良いデータを持つことは、それを達成する祈りを持つ唯一の方法です。 ですから、今日私たちがやりたいことは、顧客志向のマスターデータ管理について話し、それをどのようにアプローチし、その問題を解決し、それを作るために導入したばかりの新しい製品について話すことです。あらゆる規模の企業にとって、断片化されたデータ環境全体でより優れた顧客データを簡単に提供できます。 そのため、その風景は次のようになります。
ここにはさまざまなシステムがあり、多くの断片化されたアプリケーションがあり、それらの一部はクラウドで実行され、一部はオンプレミスで実行されています。 そして、これらのそれぞれの中で、定義により、顧客と顧客情報を識別するさまざまな方法があります。 さまざまな属性、さまざまな優先順位などを備えたさまざまな顧客データのモデル。 そして、あなたが自分自身であると考えている組織、SAPショップまたはOracleショップ、あるいは単にSAPで、または単にOracleでビジネスを運営している、またはSalesForceを使用している場合でも、自分の会社内であっても、これらのシステムの複数のインスタンスを持つことができます。 異なる場所や、さまざまな理由でセットアップされた地域、世界のさまざまなゾーン、または業種ごとに異なるセットアップが行われている可能性があります。 また、単一のERPを使用している場合でも、それらのカスタマイズを行った場合、データに競合が発生します。
今、私たちが見ている断片化は、クラウドベースのシステムと最高のアプリケーションの採用の増加によってさらに悪化しています。 そのため、このような非常に大きく、複雑で複雑な環境は、誰もが「本当に大企業でしか起こらない」と考えていたものでしたが、クラウドソリューションと最善のアプローチの出現により、その問題は現在、小規模な組織でも普及しています。 したがって、小規模企業から大企業まで、さまざまな範囲で実際に実行されます。 顧客データに関する同じ問題に誰もが苦しんでいます。 そして、ここにリストしたこれらの問題のいくつかを見ることができます。
私はそれらを3つのタイプに分けます。 重複したデータ、無効なデータ、欠落しているフィールド、一貫性のない情報、一貫性のない階層など、データ関連の問題があり、これらは時間の経過とともに悪化する傾向があります。 次に、人々がデータにアクセスできず、彼らが求めている質問に答えることができず、求めているところに、ロビンが話していた360度の視野を達成できない人々関連の課題があります。
そして3番目の領域は、複数の場所にデータを持っているプロセス関連の課題です。また、データが常に変化しているため、何がいつ変更されたのかがわかりません。 そのため、そのデータをクリーンに保つ方法を制御または管理することはできません。 したがって、よりまとまりのある/優雅な顧客体験を提供し、顧客と対話することを試みているので、それらの個人に関するあなた自身のデータが一貫性がなく、正確でない場合、それを達成することは本当に困難です。
余談ですが、先週か先週の「情報管理」の記事で、パーソナライズされたマーケティングがまだ正確ではない理由について話していたので、9つの理由を挙げました。 リストの最初の2つの理由は、データ品質が低く、データが統合されていないことです。
それで、これについて何ができますか？ さて、この問題を試して対処し、組織に何がかかるかという観点から考えることができるいくつかの方法があります。 データが生まれたときに攻撃するか、システムに侵入したら攻撃することができます。そこで、実際にデータが保存された30の異なる場所について強調した、私たちが作業した組織の写真を次に示します。そこに、彼らの風景の中に。
そのため、データがこれらの数十のシステムにリリースされると、見つけるのが難しくなり、維持するのが難しくなり、30か所で30か所に分けて修正しようとすると、修正するのに費用がかかります。 したがって、私たちが話したい概念の1つは、積極的に行動し、ライフサイクルのできるだけ早い段階で修正しようとすることです。それを行うと、見つけやすく、制御しやすくなり、修正と保守が安価になりますそのようにして、アプリケーションの下流で作業するときに、より良いデータを取得します。
したがって、これはプロアクティブMDMと呼ばれる概念であり、使用したいキャッチフレーズは、湖ではなく川をきれいにするという概念です。 そのためには、3つのステップがあります。まず、クリーンアップを行います。ここでは、ソースにできるだけ近いレコードを照合、マージ、クレンジング、サバイバルし、ゴールデンレコードを取得してダウンストリームアプリケーションを汚染しないようにします。 これは、ソースに対する制御を実装するか、データを一元的に提供する場所を提供することで実行できるため、データを公開する前に一貫性と正確性を確保できます。
エンリッチメントとは、参照データやソース運用システムにないその他の情報を含む、データに価値を追加することです。したがって、これは階層である可能性があり、たとえば、これらのシステムに本質的に保存されないセグメンテーションである可能性があります。
次に、3番目の部分はクリーンな状態を維持することです。ここでは、プロセスを適切に配置し、スチュワードシップとガバナンスを行うために特定された人々を確認し、それらのプロセスを有効にし、プロアクティブに一致させるためのツールを用意して、クレンジングします定期的にデータを保存して、そうしないようにします。たとえば、人々が仕事を変えたり、居住地を変えたりするときなど、自然に起こる減衰を回避します。
どうやってこれを手に入れますか？ さて、この問題を攻撃するために使用できる多くのオプションがあります。 データ品質ツールを使用したり、データ統合ツールを使用して情報を抽出したり、ワークフローツールを使用してワークアウトを別の人に分けたりすることができます。 ガバナンスツールを使用して、誰が何をしているかを追跡できます。 実際には、これらすべての異なる遺産ツールをつなぎ合わせて、多くの人をそれに投げつけることができます。
しかし、それはすべて非常に高価であり、非常にリソース集約的であり、展開が遅くなり、管理が難しくなり、顧客データから始めたいと思うかもしれませんが、最終的には製品を管理したいと思うこともあります、それらの顧客が持っている製品のリスト、それらの製品のサプライヤーのリスト、何が起こっているかを追跡し、それらの顧客にサービスを提供する従業員を管理するためにビジネス全体で使用しているアカウントのチャートなど。 したがって、あなたはあなたのビジネス全体を360度見渡せるようにするために、複数のドメイン、サプライヤー、製品、勘定体系、従業員などについて話している。
理想的には、顧客マスターデータを統合、照合、クレンジングする1つのソリューション、スチュワードシップとガバナンスを管理できる1つのソリューション、およびすべてのデータドメインを管理するために使用できる1つのツールが理想です顧客と先に進みます。 これが、先ほど発表したばかりのMagnitude ONEという新しいサービスの目的です。 Magnitude ONEは、以前に説明したように、使用中の一般的なSaaSまたは非オンプレミスアプリケーションでマスターデータを統合、調和、および管理するために設計されたMDM製品であり、Magnitude ONEには多くのコンポーネントが含まれています。
最初に含まれるのはKalido MDMソリューションです。これは世界のいくつかの企業に展開されています。エリックは、2003年にマスターデータと管理にさらされたことについて話していました。このツールを使用して、この分野の初期のパイオニアでした。 情報の分析的使用にサービスを提供することから始めて、良いデータが倉庫に届き、顧客が運用上のユースケースでそれをますます使用し、顧客と製品および財務を含む複数のドメインを管理していることを確認しましたベンダーと従業員など。 したがって、Kalido MDMはこのソリューションの中核部分です。
また、SCRIBEオンライン統合プラットフォームをサービスとして使用するSCRIBEソフトウェアとのパートナーシップにより、さまざまなソースシステムへの接続と統合を提供します。 That's a cloud-based integration offering with connections to over forty systems both on premise and SaaS systems that organizations use. So with those two together, with our Kalido MDM solution it also includes and ability to have a workflow-driven environment for master data management and manage it through its whole life cycle. We have a matching engine that's in there that's specifically designed for handling customer data and we also provide in addition to the software, some virtual classroom training on the Kalido MDM product and the modeling components.
So Robin, you talked about the model, that's a really critical part and that's actually where we start in our solution and we'll show you that in a moment, how you take that white board that Dez showed and translated that into something that can actually set up your MDM system. Your final point about Magnitude ONE is it's available on premises or as a cloud service, you can get a subscription license or a perpetual license. The idea is it's going to going to be easy for you to buy, maintain, implement and maintain.
So what this looks like then is Magnitude ONE at the center here, with the robust capabilities to do everything in the white and the blue boxes. So connect to and access customer data through the SCRIBE connector that I talked about. Then do all the mastering exercises you need to do around matching data, merging, surviving and enriching the data to get it clean. Then authorize and publish accurate and consistent data out to your consuming systems along with an access layer for people to search for data, browse data and even author new records so that your operational and analytical systems can stay clean as time goes on.
We provide a web-based user interface for both the stewards and the admins, which you'll see in a moment, as well as the business users. Not only can they just browse and access that published master data, they can even play a role in the stewardship process. So imagine your sales representative's out talking to customers, they learn something new about the customer, they can raise a change request and say hey this customer's, they've changed their title, they've changed their email address, they've switched companies, maybe this physician has switched an affiliation with this hospital, we want to make sure that we keep track of that sort of stuff, or this insurance broker is now carrying these products, we want to make sure we market these new insurance products to them, for example. So those kinds of things can be raised and serviced right as your customer-facing employees are dealing with those individuals.
Couple of other attributes about our solution. Number one is this business model, remember that white board picture that Dez showed that had the circles and the arrows. That's basically the business requirements for how the data needs to be, how it's used in the real world. We start with something called a business information model and we can basically capture those requirements and the attendant business rules and actually deploy that to create the rules and the MDM repository. So it effectively acts as a way to bridge the communications gap that we so often see between business people describing a requirement and IT having to go back and translate that into tables and mappings and so forth.
So we have the business-model-driven approach to make sure that it's right from when you start. We also include automated processing for that and the embedded work flow and change management so that you can, if you have a change in your model where you add to it, you can rapidly deploy that and do that with a small team because of the automation, it doesn't require as much coding as maybe you might have expected to do.
実際に表示される画面も駆動するモデル駆動型の性質について説明しました。 そのため、顧客の説明があり、その属性がある場合、画面に表示されるのはモデルで定義されている属性であるため、すべて自動的に作成され、特定のインターフェースを作成する必要はありませんデータをマップする画面、それはすべてモデルから追い出されます。
もう1つの優れた機能として、データスチュワード向けのExcel統合の概念があります。 これは、データスチュワードがExcelを使用して、自動的に照合および承認および展開できなかったレコードを編集する場所として使用できることを意味します。 さて、これはまさに、Excelにデータをダンプしているだけだと思うかもしれませんね。 この機能の優れた点は、Excelからデータを読み込むことにより、データ更新を無視するだけの問題を克服できるためです。
実際、そのデータをKalido MDMからExcelインターフェースにダウンロードすると、検証ルールが付属します。 したがって、これらのセルのどれを有効なレコードにするために入力する必要があるかがわかり、使用可能な値のドロップダウンリスト、または承認された値などが表示されるので、基本的にマスタデータレコードを更新するときにエラーが発生します。
次に、組み込みワークフローエンジンで、データがすべて処理され、公開が許可されていることを確認します。また、誰が何をいつ実行したかを追跡し、以前のすべてのマスターデータ値を基本的に確認および監査できるため、データがどのように変更されたかを確認できます時間。
そのため、顧客データの観点から、この利点は、顧客とのよりパーソナライズされた関連性の高い対話および対話ができる場所に到達できることです。 MDMは、特にそこで行われている1対1のマーケティングを考えると、ビジネス上の重要性が増してきており、これは、発生するサイクルの良い例です。
顧客に関するデータから始めましょう。これはあなたが習得したものであり、彼らは誰なのか、どの製品を所有しているのでしょうか。 次に、それらについてのより多くの情報と過去にどのようにやり取りしたかでそれを豊かにします。 彼らは何に反応しましたか？ または、彼らはどのように連絡を取りたいですか？ たぶん、彼らはファックスで連絡したいので、それはまだそれが彼らの名刺にある理由です。 しかし、その情報は、対話するために必要な洞察を提供します。
それでは、他にどんな好みがありますか？ それのいくつかは、例えば社会的なソースから来ているかもしれません。 次に、それらの顧客にとって次に最適なインタラクションは何であるかを判断できます。どのようなオファーを作成する必要がありますか？ それは何らかのインタラクションを生み出し、何かをダウンロードし、何かを購入します。
もちろん、マーケティングインタラクションのこの好循環に送りたいデータをさらに作成します。 その結果、新しい顧客をより迅速に見つけてクローズし、アップセルを増やし、より良い顧客サービスを提供し、エラーをなくし、重複出荷をなくし、マーケティング資料の発送などを行うことができます。マーケティング費用。
そのため、英国の郵便局はKalido MDMを使用してより適切な顧客データを配信し、適切な製品を提供し、適切なチャネルで顧客との対話を続け、最終的に販売量を増やしました。それらのマージンを増やしました。
それが私の紹介コメントです。今からダイアナに引き継いで、私たちがこれをどうやってやっているかを正確に示したいと思います。
ダイアナ・コリンズ：ジョン、ありがとう。そうすれば、私たちはあなた方全員のためにこれのいくつかを生き返らせることができることを願っている。 したがって、画面に表示されるのは、Kalidoビジネス情報モデルの例です。 ソリューションの一部である、今日お見せするものは、salesforce.comからのデータの統合です。 ここでは、左下にsalesforce.comモデルがあります。 これは明らかにWebベースのアプリケーションであり、ソフトウェアはサービスの一種のアプリケーションです。 これを、ビジネススイートであるOracleのオンプレミス実装からのデータと統合します。
そのため、salesforce.comから連絡先とアカウント情報を取得し、それを売掛金アカウントと連絡先情報に統合して、単一の調和の取れたアカウントと連絡先構造に統合し、Microsoft Dynamics CRMに読み込みます。 したがって、ここでのシナリオは、過去のsalesforce.comの使用からDynamics CRMの使用への移行です。 私たちは、新しいDynamics CRM環境に基づいて、完全に統合された調和の取れた顧客リスト、360度ビューを持っていることを確認したいと考えています。
したがって、これを構築するために、salesforce.comとEBSからKalido MDMにデータを移動し、実際に調和プロセスを実行しました。 だから時間の利益のために、私たちは料理をやったので、食事を楽しむつもりです。 それでは、MDM環境に切り替えて、MDMソリューションがこれらのプラットフォームの単純な接続統合に追加する追加機能でできることの一部を紹介しましょう。
しかし、もちろん起こることの1つは、あなたの歴史を失うことです。 Microsoft Dynamicsのデータになりますが、どこから来たのか知っていますか？ それがMDMであり、MDMソリューションが私たちに提供できるものの1つであり、私たちに歴史をもたらします。
したがって、調和の取れたアカウントのリストを見て、そのうちの1つを選択します。 ここでアルバートの店を選んだとしましょう。 これにより、このAlbert's Storesレコードがどこから来たかについての情報が得られます。 これは、2つのレコードの統合であることがわかります。1つは、Albert and Gerardというsalesforces.comアカウントからのもので、もう1つは、Albert's StoresというEBS請求アカウントからのもので、Albert's Storesというこの単一の親アカウントに統合され、調和しています。
元のIDも確認できます。MicrosoftDynamicsからCMR IDを取得しているため、この日は既にMicrosoft Dynamicsに移行されています。 データが最後に更新された時刻を確認できます。 これに加えて、データを見ることができるだけでなく、グラフビューを使用して、データが参加している関連付けを見ることができる別のビューを提供します。
したがって、ここには同じレコード、売掛金勘定、salesforce.com勘定、および取引先責任者に関連付けられたAlbert's Storeがあります。 これらの連絡先のいずれかを選択すると、その連絡先は実際にはsalesforce.comの連絡先であることがわかります。 同様に、Adam AlbertのアカウントはEBSの連絡先だったので、この動きについては、画面上で自動的に発生していると思います。 しかし、これからも連絡先情報を見て、salesforce.comアカウントからのものであることがわかります。 実際に、データが関係するすべての関係を示すビューを構築します。
さらに、saleforce.comのデータを分類する方法、およびリストするには多すぎるアカウントが他にもあることを確認します。 リストするには数が多すぎますが、それらに到達することができます。 ここでページを下にスクロールして、グラフィックビューに表示するには数が多すぎたすべての追加アカウントのリストに移動できます。 もちろん、これらのグラフビューでも開始できます。 それが物事を扱う一つの方法です。 データを表示したり、データを操作したり、データを修正および修正できるようにしたいと考えています。 それでそれを見るいくつかの方法。
できることの1つは、先に進み、階層を見て、アカウントの階層をお気に入りの1つとして保存したことです。そのため、さまざまなカテゴリの情報をアカウントおよび階層パスとして保存できます。階層ブラウザで使用できます。 したがって、ここで階層をドリルダウンして、各アカウントとのさまざまな連絡先をすべて表示できます。
しかし、この環境が提供する他のことの1つは、すべての孤児を見つけるオプションです。 これらは、ソースに親がいなかった調和のとれたシステムを介して入った連絡先であるため、取り残された孤児です。 これらを持ち込み、特定しました。これらは孤児であることを知っていますが、それをどうやって修正するのでしょうか？ このスイッチをクリックして編集モードにすると、階層の別のビューが開き、これらのユーザーの分類を開始できます。 ビル・マレーがACネットワークで働いていたので、彼を引き継いでリストに追加することができます。これを変更することで、彼が強調されているのがわかります。 Sandyを移動し、AG Edwards and Companyに彼女を割り当てることができます。
これらの変更が行われているので、それらはここに記録されています。間違えたことがわかった場合は元に戻すことができます。 それらの複数を一緒にギャングし、それらに名前を付けることによってシステムとしてそれらをユニットとして移動させることができ、それらは私のシステムを通して単一の作業単位として処理されました。 ですからこれは一つの方法であり、もし私が積極的に活動しているのであれば、ここに行ってこれを見て、孤児がいないかどうかを確認し、その問題に対処したいかもしれません。 しなかった場合はどうなりますか？ 積極的でない場合はどうなりますか？ さて、私たちのシステムには、前述のワークフローが含まれています。これは、これをより直接的に処理できるワークフローソリューションです。
それを行うには、システム管理者としてログオフします。データスチュワードとしてログオンします。 したがって、これは無効なデータの管理を担当する個人になります。 ログオンするとすぐに、受信トレイに移動します。 連絡先とアカウント間の関係、関連付けは必須であるため、11の孤立したレコードがあります。 アカウントへの適切な接続がなかった調和アカウントはすべて無効です。 それらはワークフロー内を移動し、ワークフローの図でわかるように、ここでレコードを修正しています。 次に、それらは承認プロセスに流れ、営業部長によって承認され、経理部によって承認され、最終的にダイナミクスの次のバッチ更新で公開が許可されます。
もちろん、これはリアルタイムで実行するように設定することもできます。これは、公開されるとすぐに、公開が許可されるとすぐにダイナミクスをすぐに流し出すので、最後のステップをどのように設定するかはあなた次第ですインターフェース。 MDMツールを使用して環境を豊かにし、強化する方法の一部について、簡単なアイデア、概要をご紹介します。 顧客の情報の使用を強化し、すべての情報を1か所で利用できる顧客の真に調和のとれた360度のビューを実際に得ることができる方法は他にもたくさんあります。ユーザー。 このプロバイダーUIだけでなく、先ほど述べたように、ユーザーインターフェースも提供します。ユーザーがアカウントに変更があったことを知った場合、ユーザーは変更要求を発生させて対処し、その変更をラップできます。データスチュワードに直接リクエストして、このレコードを変更する必要があると思われる変更を加えるようにします。 この時点で、私はそれをエリックに引き渡して、QとAに進むと思います。
エリック・カバナ：もちろん。 そこで、ここから聴衆からいくつか質問があります。 私は1つを捨てますが、最初のデズまたはロビン、あなたは何か質問がありますか？ まずはデズから始めましょう。
Dez Blanchfield：組織でこの旅をするたびに出くわすことの1つは、このバージョン管理の挑戦です。 データまたは特定のバージョン管理に向けたアプローチに触れてください。組織の3つの異なる部分が顧客として私を扱っているシナリオを想像してください。ツール。 ビジネスを通じて送られてくるデータをバージョン管理するだけで、それを管理、管理、承認するのは誰ですか？
ダイアナ・コリンズ：それは素晴らしい質問です。 したがって、ソリューションに組み込まれ、組み込まれているものの1つは、監査証跡と履歴です。 それで、私は歴史を持つ記録を見つけることができるかどうかを見るでしょう。 履歴モードをクリックするとすぐに、使用していたAlbert's Storesのレコードに履歴があるかどうかを確認してみましょう。 ここで行われた暫定的な変更、およびそれらが行われた日付と時刻を示すように、それが欲しいです。 さらに、完全な履歴の詳細に移動でき、監査証跡を有効にした場合、それらの変更と変更がいつ行われたかだけでなく、監査証跡はそれらの変更を行ったユーザー、それらの変更を行ったユーザーも通知します。
バージョン管理のアプローチは、任意のラベルを設定するのではなく、より時間に基づいています。 ある時点を選択して、その時点でのデータを確認し、その時点でのデータを移行できます。 そしてもちろん、データコンテンツの履歴だけでなく、データモデルの履歴も追跡します。 データモデルが進化する可能性があるため、新しい分類を追加し、同様に追跡します。また、いつでもロールバックして、特定の時点の状態を確認できます。
Dez Blanchfield：データモデルはその点で課題を提起しています。 つまり 、いくつかの重要な記事を扱うことに大きな血統を得たということです。 すでに導入されているデータモデルのいくつかの例と、これを実行することに取り組んでいるいくつかの例、製造業、小売業、物流、金融サービスなどの主要セクターを教えてください。 銀行や損失管理などを得たので、ギャップがどこにあるのかを人々が知ることができるプロジェクトをすぐに起動できる以前のモデルで行われたアプローチはありますか、またはそのモデルを自分で構築して訓練する必要がありますか？
ダイアナ・コリンズ：私たちは長年にわたって両方のアプローチをとってきました。 私たちはモデルを考えてみましたが、モデルが完成すればするほど、変更を加える必要があり、顧客のためにさらにカスタマイズできるようになります。 そのため、私たちはモデルの断片のアプローチを実際に採用しました。これは、業界全体に本当に浸透している特定の基本的な共通要素です。
たとえば、金融サービスでは、証券やデリバティブなどの資本市場でのモデルがあります。保険、損害保険、再保険のモデルがあり、両方とも異なる方法でリスクを管理します。 製品の部品表、着陸表の製造モデルがあります。 サプライチェーンやその他のトラッカー、中間倉庫、流通モデル、在庫の老朽化などのモデルの他の部分があります。 多くのお客様にとって、ご存知のように、考えられるほぼすべての業種にお客様がいますが、多くのお客様については、お客様のために完成したモデルに組み立てる特定のコアコンポーネントを開発することができました。
ジョン・エヴァンス：ええ。 それに付け加えてください、ダイアナ。 ちょっと前にオレンジ色の背景で示したモデルは本当に概念的なモデルなので、母音があり、下線はありません。つまり、人間が理解できるということです。 それ自体はITの概念ではなく、ビジネスマンが理解できるものです。 これらの概念モデルがあります。既存のモデルをインポートし、この方法で取得するためにファクタリングします。Dianaが話したように、使用したモデルフラグメントまたはモデル例がある場合顧客に見せる前に、通常、少しの間、それを見て、画面上に置いて、ポインティングとジェスチャーの種類で、彼らは通常、そのモデルをリファクタリングしてきれいに表現することができます彼らが達成しようとしているものの。
そのため、これらの要件を把握するために時間を短縮して、それに取り組むことができますが、ここで示していないことは、この図がありますが、基本的に、操作と呼ばれるタブもありますボタンを押すと、MDMリポジトリに必要なすべてのオブジェクトと、これまでのルールが設定されます。設定、確認、オプション、必須、カーディナリティ、必要なものすべて行うには、そこにデプロイと言うボタンがあります、それはあなたがフロントエンドで作成したモデルを生成するだけです。 そのため、私たちには断片があり、さまざまな業界での経験があり、コンサルタントは顧客が非常に迅速に開始できるようにすることができます。
ダイアナ・コリンズ：ええと、私が見つけようとしていたもう一つのこと–
Dez Blanchfield：それで、Robinに引き渡す前のもう1つの手っ取り早いものです。
Diana Collins：これらのモデリングセッションは通常、ジャムセッションのようなものとして実行します。すべての属性の詳細にあまり興味がないので、後でそれを入力することができます。 私たちが本当に興味を持っているのは、データがどのように結びついているのか、そしてデータがどのように有用であるのかをビジネスビューで把握することであり、それがソリューションの構築方法です。
Dez Blanchfield：いいえ、それはすべて理にかなっています。 最後に手っ取り早く、ロビンに引き渡します。 ですから、私が担当している組織とマネージャーとの会話ですぐに思い浮かぶのは、彼らが見ている、すでに知っている、ガバナンス、フレームワーク、ツールがあるということです。管理チームがこのルートをたどり、顧客中心になり、顧客データをクリーンアップするか、単一の期限を迎えると決めたとしましょう。しかし、ITおよびビジネスの他の部分はすでに彼らを感じているかもしれませんその上で良い場所に到達するために、複数の作業プログラムを実行しますか？
ダイアナ・コリンズ：それは興味深い質問です。 ええ、MDMの実装は一般に、そのような高レベルのサポートがない限り失敗します。 これらのプロジェクトは、受け入れられる必要のある文化的な変化があるため、組織のかなり高いレベルから推進される必要があると思います。 ロビンはこれについて以前に話したと思います、それはあなたがプロジェクトとしてただ行うことではなく、IT組織でしばしばアプローチされる方法に依存するということです。 それは進行中のプログラムであり、コミットメントが必要なものであり、実装する場合は変更する意欲があり、それがあれば、実装が非常にうまくいくことがわかりました。
いくつかの実装で苦労しなければならないのは、高度な管理サポートがないか、IT組織が変化に抵抗している場合でしたが、どちらの場合でもそれらを勝ち取るのにかなり成功しています。 立ち上げて運用するのがどれほど簡単か、そしてデータコンテンツの責任を肩から奪う方法を示したら、ITがその責任を負うべきではないと思います。 ビジネスは良いデータを構成するものを知っているので、ITがそれを知る必要はありません。 ITは、データの整理、安全性の維持、安全性の確保、およびその方法など、彼らがうまくやっていることに責任を負うべきであり、通常はそのように動き回ります。
エリック・カバナフ：そして、聴衆からいくつか質問があります。これらをここに捨ててみましょう。 私たちは時間をかけて少しずつ進んでいますが、私たちができるか、少なくとも試してみることのできるすべての質問を得ると思います。 ジョンかダイアナ、どちらにせよ、これをあなたに投げます。 出席者は、「悪いレコードからゴールデンレコードに親を再構築する機能を開発していますか？」と尋ねます。 彼はここで何を意味するのか正確にはわかりませんが、できればそれに答えることができます。
Diana Collins：確かにレコードの親を変更できます。 これはこのオフィスソリューションの非常に標準的な部分ですが、運用システム内では直接ではありません。 MDM環境でそれを実行し、MDM環境から公開されたデータをMDM環境からプッシュバックし、運用システムにプッシュバックすることはできますが、データは直接キャッチされません-修正しませんMDM環境から運用システムに直接。
エリック・カバナ：わかった。 さて、ここで別の質問があります。「ツールを使用してデータ系統を確認できますか？」
ダイアナ・コリンズ：ああ、そうだね。 繰り返しますが、これはその種のイラストには適したモデルではありませんが、絶対にそうです。 データの履歴があり、データが複数の場所から来ている場合、そのソースにタグを付けて、その情報を公開されたデータまで引き継ぐことができます。
ジョン・エヴァンス：ありがとう。 モデルにはその要素があります。ダイアナでは、SFDCの連絡先とEBSの連絡先があり、実際にグラフフィールドにも表示されています。 それはデータの周りにある種のものです。
ダイアナ・コリンズ：ええ。 つまり、実際のリネージ環境では、より堅牢なソリューションと実装が得られ、基本的なものだけがここで実行されたことになります。
エリック・カバナ：わかりました。 さらに2、3の質問がありますので、まとめます。 出席者の一人は、「世帯の定義をどのように支持していますか？ ソーシャルネットワークで顧客マスターデータを充実させる方法はありますか？」
Diana Collins：それは私たちのロードマップ上にあります。ソーシャルネットワークデータからソーシャルネットワークを強化することは私たちのロードマップ上にあります。 現時点では製品にはありませんが、家計の観点から見ると、これはマッチング機能とマージ機能の一部です。 マッチングのプロセスでは、データの特定の部分の重みを制御できる非常に多くのノブとレバーが最終的にできることは、同じ世帯の一部である可能性がある個々の連絡先レコードをすべて収集することです。 次に、企業と人々の違いを理解します。 企業では、一般的に最初に名前の単語の意味の種類を見てください。 会社では、前から始めて終わりに向かって働きます。 しかし、家事をしているとき、あなたは本当に最後から始めて、人々の名前で正面に向かって働きたいです。 それはそれを理解しており、単一の世帯に属する連絡先を集めるという非常に良い仕事をすることができます。
エリック・カバナフ：最後の質問です。レストランのお客様はどうですか？ ここには、知識豊富なオーディエンスメンバーがいますので、レストランのお客様はいますか？
ダイアナコリンズ：実際にはありません。 それは私たちにとって新しい垂直になるでしょう。 私たちはそれを追求することに本当に興味があります。 レストランを提供する顧客はいますが、顧客であるレストランはありません。
エリック・カバナウ：わかりました、まったく心配はいりません。 皆さん、私たちはここで1時間5分間燃え尽きましたので、今日のプレゼンターに感謝します。 このWebキャストをアーカイブして、これらのアーカイブをすべて後で表示できるようにします。 本日はプレゼンターに感謝します。 洞察力についてはもちろんDezとRobin、そしてMagnitude Softwareに感謝します。 これはいいものです。 MDMはここにあります、皆さん、それについては疑いの余地はありません。 時間が経つにつれてより重要になる中央のビューを取得することは本当に重要です。 私たちの顧客が虐待されたくないと判断したとき、彼らは可能な限り最高の治療を受けたいと考えなければなりません。それがそうなるでしょう。
それで、その人々と、あなたに別れを告げるつもりです。 改めてありがとうございます。 明日また明日、別のウェブキャストでお話します。 Hot Technologyは、この頃最も人気のあるショーです。明日4時東部でお会いしましょう。 それまで、皆さん、気をつけてください。 さようなら。
