EDW 2023 Fall

9月18日(月)から開催されている、EDW2023に参加しています。4日間にわたって70を超えるセッション、セミナー、チュートリアルが展開され、330人が参加しています。

DAMAホイールの各領域に加えてAI関連のセッションも増えてきました。データファブリックやメッシュ、ナレッジグラフやオントロジー関連のセッションもあり、「不易と流行」の両方を押さえていると思います。

今回DAMA日本支部は、82の支部の中から5支部に与えられる支部表彰を受けることになりました。その表彰式にも参加します。

大会の詳細のレポートは後日ご報告させていただきます。お楽しみに!

 

NestléのGlobeプログラム

皆さんはNestléのGlobeプログラムをご存知ですか?始まりは2000年前後ですのでもう20年以上前のお話です。Nestlé、Globeで検索してみるとこのストーリーがビジネスケースになっていたりします。

当時のCEOはPeter Brabeckでプログラムを率いたのはChris Johnsonでした。この頃のNestléの収益性が、コカコーラ、ジェネラルミルズ、ケロッグなどに比べ劣っていたことが投資家から問題視されていました。競合14社の販売費の平均が売上比5.8%だったのに対し8.4%、管理費は競合平均が6.2%なのに対し8.3%と高かったのです。

各市場のトップが売上と利益責任を追っており、オペレーションとシステムはバラバラでした。それまでITがリードした改善プログラムが走っていましたが成果を生み出せませんでした。1999年秋のUSでのSAP導入プロジェクトは失敗に終わり商品の出荷が滞ったほどでした。

そこでPeterはグローバルにオペレーションのベストプラクティスを導入しSAPで実装する決断をしました。台湾のマネージャーだったChrisをスイス本社に呼び寄せプログラムのリーダーにしました。最年少の上級管理職、費用負担などをめぐる各市場トップとの軋轢などを乗り越えてプログラムを進めていく様子は、まるで池井戸潤のテレビドラマのようでした。

プログラムの目標は3つあります。
1.調和の取れたNestléビジネス・エクセレンス・ベストプラクティスを導入する
2.“データを会社の資産として管理する”ためにデータスタンダードとデータマネジメントを導入する
3.標準化された情報システムと技術を導入する

目標1は地域ゾーン毎に、どういうオペレーションが最も効果的・効率的かを関係者が話し合って決めていきました。当時、知り合いの日本ネスレのSCM担当者がよくオーストラリアに出張していました。
目標3はSAPの導入です。未だかつて経験したことのない規模のSAPロールアウトになりました。ライセンスは$250 millionと報じられました。

そして目標2です。あれ、いつも聞いていることですね。230を超えるデータスタンダードが定義され、2003年までに市場を跨いで供給されていた品目がマスターデータ・リポジトリに登録されました。品目、得意先、仕入先データの実に半分以上がゴミデータだったということです。

その後Globeプログラムは徐々に各市場へ展開され、様々な効率化プログラムのenablerとして大きなビジネス成果を上げることになりました。

Data management is not a sexy job.

これはChrisがテレビか何かのインタビューに答えていたものです。華々しいSexyなjobに対して、ビジネスに理解してもらうのが難しく、地味な仕事ということだと思います。これは20年経った今も変わっていないと思います。ただ、当時のPeterのようにDXを進めていくためには、データマネジメントが基盤となるので重要である、と感じてくれる経営者が増えてきている感じがします。難敵はやはり今も現場のビジネスマネージャーでしょうか。

Sexyな仕事をやっている人達にデータマネジメントの重要性を彼らの言葉で話しかけて理解してもらい、not a sexy jobをやっている人達を支援しビジネスの成功を持って認めてもらえるような取り組みを、DAMA日本支部で一緒に進めましょう!

参考資料
https://www.nestle.com/sites/default/files/asset-library/documents/library/presentations/investors_events/investors_seminar_2005/globe_jun2005_johnson.pdf

データモデルと「統制語彙」

中岡さんが「統制語彙」とデータモデルに関する話題、を書いてくださいました。待ってました!該当の第10分科会は仕事で参加できませんでした。残念!そこで二番バッターとしてこの場で話題を引き継ぎ、皆さんの意見をいただいて実装に向けて議論を深めることができればと思います。

この辺のお話は、セマンティックレイヤー、論理が物理を隠ぺいする、「データレイク(湖)」じゃなくて「データスワンプ(沼)」だ!、とかに関連しています。

データとデータを組み合わせるとビジネス上の良いことを得ることができるらしい! ー> いろいろなデータが取得できるようになりました。 + 大量のデータを蓄積できるようになりました。= 誰も何のデータが蓄積されているのか分からないようになりました。 ー> 活用されないデータが大量に蓄積され誰も手が付けられないようになりました、とさ。
いくらクラウドのストレージが安くなったからと言ってこれでは困りますね。

何故データとデータを組み合わせるとビジネス上の良いことが得られるのでしょう。クロスセル/アップセル的アプローチ?SCMがどこまでも繋がりまくるインダストリー4.0?そこにS&OPが絡んで尚且つROIC!?いやいや他人が苦労してクレンジングして分類付けしてくれたデータを活用して手間を省きたい?(その逆の説も!)動機は様々ですね。

ビジネスの世界で「もの」+「こと」=「実体」を扱っている。それらはビジネスプロセスの中で言葉で伝達されてビジネスの成果を得ている。だから言葉ですね。この言葉をリレーショナルモデルで表してみる。基本に立ち戻ってみます。

おなじみコッドのタプルです。各行が実態の一つ一つを表しています。それらはドメインという値の集合から寄せ集められて成り立っています。だからこの値が一つでも違えば別の実体と見なされます。ほとんど同じドメインから値を持ってきているのに一部だけ、他と異なるドメインの値が追加されているとか、一部だけあるドメインの値が持ってこられない=Nullである場合は異なるタプルとして全体の箱自体を分ける、つまりサブタイプですね。そいうことだと理解しています。

この命名規則は古典中の古典ですね。

こうやって見ると、タプルを構成するドメイン達、すなわちこれが実体を表すメタデータになりますね。どのドメインで実体を表すかを統制するのが標準メタデータです。例えばある実験の結果には必ず「温度」と「湿度」と「色」が必要という具合です。この標準メタデータ設定の目的は実験の再現性でしょうか。仮に温度が欠けると再現実験ができない。ではこの温度とは何でしょうか。摂氏?華氏?色とは?どの色見本帳と比較して色を決めるのか?これが決められていないとやはり再現できなさそうですね。これらは標準リファレンスデータと呼ぶ?

実体に対しこれらの標準メタデータと用いられる値の指定を業務で使用されているすべての言葉に当てはめていくのは気の遠くなる作業ですね。誰もそんなこと気にして使ってませんものね。まぁ一部、標準リファレンスデータは決まっているかもしれません。企業内の組織コードとかで表される実体やUoM:計測単位だったり。本来KPIとかはソースデータと計算ロジックにこの考えがないといけないと思いますが、足せないものを足したり、精度の低い値を掛けて有効桁数を無視したり?とかありがちですね。

せめてこのKPIだったり、機能/業務/組織をまたいで接続したいデータについて、この標準メタデータとリファレンスデータを「統制語彙」として整備して、その言葉でコミュニケーションできるようにする、というのが今取り組んでいることで日々頭を悩ませています・・・

DXとBPR

かつてのBPRが何故上手くいかなかったのか。「BPR失敗」で検索するといろいろでてきますね。ところで改めてBPRとは?

業務工程のリエンジニアリングですよね。BPはスタートがあってエンドがある一連の業務活動の繋がりかな。リエンジニアリングは検索トップのWeblioによれば、”re-engineering リエンジニアリング: ソフトウェアの保守において, 既存の資産をより抽象度の高い形式に変換した後に再構成する技法.”
ですと。

データマネジメントもそうですが、ある一つの事業を営むためのBPが一つの会社に収まり部門間のやりとりも日本語で事足りていれば、そりゃ多少部門間の軋轢が生じるかも知れませんが目標達成のための調整が働くし、組織を跨った改革も進められるかも知れません。

これが製造は複数の海外拠点で販売も複数の海外拠点、拠点の法人は複数の事業部門をカバーしており、法人としての業績も問われるとなるとどのゴールに向かって頑張れば良いのか分かりにくいですね。グローバルの共通語は英語でしょうけどどうしても言葉(考え方)の違いによるすれ違いも生じがちです。部門間の壁も法人、部署をまたがりレポートラインが錯綜していてなかなか崩せませんね。

DXにより導入するソリューション(DXS)はその答えになる可能性があると思います。DXSはデータをデジタル化し、リアルタイムにつなげ、データアナリストがPythonコードを書き未来を予測する取り組みとしてみて、マーケティングとならぶ製造業の本丸、SCMで考えてみます。

どこまでも得意先の果てまで、どこまでも仕入先の果てまでのデータを繋げることによって我々は「神の目」を手に入れることができる。神の目でみてみるとそこは部分最適のオンパレードで最終目的である例えば生活者の便益はまだまだ改善の余地がある、とする。

デジタル化もまだまだ道半ば、例えば物流の運賃表(タリフ)はデジタル化されているか?データを繋げることもいろいろ大変。マスターやリファレンス類はもとよりトランザクションだって処理のプロセスが違ったり、ERPへのインプリが違っていたり。区分値を合わせるのも一苦労。未来を予測するモデルも最初はよちよち歩きでSME(業務領域の専門家)に馬鹿にされる始末。

でもこの状態が逆にチャンスを生む。SMEは油断してモデルを鍛えてくれる。(全くオメェは馬鹿だなぁ、この観点が抜けてんだよ!)デジタル化もオーナーを定めて地道に進めて行く。繋ぐことは昨今の技術の進歩で少しやりやすくなった。

そうするとおぼろげながら「神の目」には徐々にゴールの姿が見えてくる。それは例えば生活者の便益で個別最適の連鎖の結果、毀損されている。

我々の最終目的が生活者の便益ならば、個別最適から全体最適に移行しなければならない。「神の手」を動かすためには個別最適を犠牲にして全体最適に貢献する部門に報奨が必要だ。神の目にはある個別最適を犠牲にしたときの全体最適への貢献度合いが分かるから報奨の額も設定できる。

やがて部分最適を主張する部署は無くなり、One Team!で生活者に向かい合えるようになる。

なんてことをこの寝苦しい夜に夢見ています。一緒に夢をかたちにしませんか?

DXと用語の定義

DXについて多くが語られています。DXを進めて行くとはどういうことなんでしょう。いろいろなレポートを読んでも今まで今一つ腹落ちしませんでした。それが急にDXを推進することになった会社のガイドを見て、さらに先日のADMCの講演を聞いてストンと腹落ちしました。

DXの推進にはいくつかのステップがあるがDX1.0が大事である、すなわちそれは、顧客の価値を再定義し、デジタルソリューションの適用範囲を定め、全体を管理するKPIを設定する。データはこのデジタルソリューションとKPIに使われる。

デジタルソリューションとは何か?CJさんによればPython codeを書いて未来を予測できること(人達)。大量データを瞬時に読込み・組み換えとかもありますね。生産計画とかに使えそうです。

この次は何か。それは繋がること。今までの責任分界点を超えて繋がること。これにより今まで絵空事だった例えばグローバルSCMの最適化、なんてことがスコープに入ってくる。責任分界点を超えるとは、法人の中では機能組織の間でしょうし、製造・販売が分かれていればそれは法人間を超えて繋がることだと思います。

その時、何が起こるのか。今までは責任分界の中で自分最適で自分のシステムと仕事をしていれば良かったけど、今度は責任分界を超えてより大きな責任分界で最適化するために異なるシステムのデータを繋いでいく必要が生じる。今までは人間系で悠長に(月次?週次?日次?)翻訳しながら回していたけど、デジタルソリューションはリアルタイムにトランザクション毎に処理して行く?のでこのままだとデータが衝突してしまう。

残念ながら各所のシステムはこの意味で標準化されていないのです。世の中には標準化されている(いわゆるワンインスタンス)企業も数多あるとは思いますが、これが現実だ。データとデータをマッピングしながらデジタルソリューションを適用していかなければならない。CJさんとホバーマンさんの講演は一つ一つ私の胸に刺さりました。

デジタルソリューションから見て責任分界を再編することは、かつてBPRで多くの企業が討ち死にしたことを思い起こします。でもそれは例えばSCMの神の手を得るために必要なことだと思うけど、大丈夫かな?

DXと騒いでいるけど、多少未来が予測できるようになるかも知れないが、やるべきであったのに今までやれなかったことをやり通すことも、大きな割合を占めているように感じます。

やっぱり先ずは業務用語集とデータディクショナリーで今流に言えばデータカタログからかな。

BIのマスターはメンテされない!

マスター登録を業務(例えば受注ー出荷ー請求ー入金)のためのマスターと分析のためのマスターに分けて考えてみる。

前者に必要なマスター(製造業では商品、取引先、出荷先、請求先等)の登録を間違えると、誤った商品を誤った場所に出荷し誤った請求先に誤った請求額で請求することになり、修正の遡りで多大な対応が必要となる。誤りが繰り返されれば取引先の信用を失うことにもつながり、誤ったマスターはすぐに修正されるべくフィードバックがかかる。

後者に必要なマスターは分析の観点から新たに付加される商品や取引先などの分類とその属性や、様々な組織で生成されるデータを統合するためのマッピングマスター等がある。しばしば分析のプロジェクトは熱く燃え上がり(この軸でも管理したい!より細かく管理したい!)苦労してマスターを登録し素晴らしいアウトプットを見てうれしくなるが、それは往々にしてその時の担当者の視点に留まっていて、時が経ち担当者が変わり後任のマスター登録が回らなくなりアウトプット実績が他の基準となる資料と合わなくなっていく。

担当者の上司も変わる頃には、実績がおかしいことが話題になり、ベンダーの甘い誘惑に負けて最新のツールは何でも安く・早く・上手くできるように思え、また新たな管理視点を入れた最新のBI導入プロジェクトが立ち上がって行く。

なんてこと、皆さんの周りで起こっていませんか?

分析のためのマスターはメンテされない。どうすれば良いのか?決定打はなさそうだが、いくつかポイントを挙げてみる。

1.マスター登録の業務設計が成されていない。不十分。

誰が、どういうトリガーで、何のマスターを登録するのか、この業務設計がキチンとできているか?突っ走る分析担当者にこの重要性を認識してもらうのが中々大変。

2.管理の目的が組織全体で共有されているか?

管理するデータが生成されるタイミングで同時に分析のための分類が登録されないと後から付与するのは初回はともかくメンテが大変。そのためには管理の目的が組織全体で共有されていることが大事。

3.利用されるコードセット(リファレンスデータ)の標準コード

利用されるコードセットの標準コードが定義され運用されているとマッピングの回数を減らすことができる。標準コード類は後から導入できない。先に合意しておいてデータ生成組織が運用する現地コードの属性として追加していくとか、システム更新の機会をとらえて導入するとかが必要。

結局、できる限り管理対象のデータが生成される上流で管理のためのマスターが登録されないとだめかなぁ・・・。

データガバナンスとデータマネジメント

 ガバナンスが「統治」とか「統制」の意味を持つので例えば個人情報の扱いだとか、国、通貨等の標準コードの使用とかについてのルールを守らせることをガバナンスを効かせるという言い方をする。データガバナンスについて書かれたものには、データをマネジメントすることについて書かれたものも多く、ガバナンスに必要な要素が分かりにくくなっている。DMBOK2を見てみよう。この二つの言葉は以下のように表されている。

実際にデータに触れているのは?

 データガバナンスとは「正しいことを行う(Do the right things)」ことであり、データマネジメントとは「正しくことを行う(Do things right)」ことである(Ladley, 2012)。p607

 監査人は財務プロセスを統制するが実際には財務管理をしていないのと同様に、データガバナンスはデータが適切にマネジメントされるようにすることであって、データマネジメントを直接実施するわけではない。(図15参照)。p99

 データガバナンス:データを適切にマネジメントさせること

 データマネジメント:ゴールに到達するためにデータを管理すること p100

実際にデータを管理しているのはデータマネジメント側である。

データガバナンスは何故必要か

 正式なデータマネジメント機能を持っているかどうかにかかわらず、組織というものはデータに関する何らかの意思決定をしている。正式なデータガバナンス・プログラムが導入されれば、より明確な意図のもとに職務権限と統制を行使できるようになる。p94

データガバナンスは現場で行われているデータマネジメントを、組織の正式な取組に引き上げる。

データを資産として管理するための原則、ポリシー、プロセス、フレームワーク、評価指標を提供し、組織の各階層レベルでデータマネジメントプログラムを牽引する。 p98

 データアナリティクスからビジネスの価値を得る取組を見出したり、デジタルトランスフォーメーションに対応していくためには、その土台としてDAMAホイールに記載されている領域を中心としたデータマネジメントの実践が前提となる。実際行われてはいるが組織間でばらつきのあるデータマネジメントの取組みを一定のレベルまで引き上げ、さらにビジネスの目的に沿うレベルまで到達するには地道な取り組みと時間が必要だ。この取り組みをトップがコミットして組織横断で進めることがデータガバナンスである。

 DMBOK2では第3章でデータガバナンスについて包括的にまとめ、各章の後半ではそのデータマネジメント領域でのガバナンスの取組みに触れている。この総体がデータガバナンスということになる。ちょっとまとめづらい構成になっているけど第3章に加え、取り組み優先順位の高いデータマネジメント領域の章を合わせて是非読み進んでいただければと思います!