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