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章に加え、取り組み優先順位の高いデータマネジメント領域の章を合わせて是非読み進んでいただければと思います!