最近、多くの企業で、

「データドリブン経営」という言葉を耳にするようになりました。

・BI導入
・ダッシュボード構築
・AI分析
・データ基盤整備

など、“データ活用”を前提とした取り組みが急速に広がっています。

しかし、その一方で、私は多くの企業において、

「結局、何が分かったのか分からない」という状態が起きているように感じています。

もちろん、データ自体は大量に存在しています。

例えば、

・売上
・顧客
・商品
・契約
・請求
・入金

などです。

しかし、本当に重要なのは、「データ量」ではありません。

本当に重要なのは、「業務構造を表現するデータが存在しているか」なのです。

ここで非常に重要なのは、「会計処理を成立させるためのデータ」と、

「業務を分析するためのデータ」は、全く別だということです。

現在、多くの企業システムは、「会計を成立させること」を中心に構築されています。

つまり、

・売上が立つ
・請求出来る
・支払い出来る

ための最低限データは持っている。

しかし、本当に分析が必要なのは、その手前です。

例えば、本来業務構造を分析するためには、

・誰から依頼された業務なのか
・誰へ依頼したのか
・どのリソースを確保したのか
・いつリソースを解放したのか
・どの条件で状態が変化したのか
・誰へ完了報告したのか
・どの調整が発生したのか

といった、「業務状態遷移データ」が必要になります。

さらに重要なのは、「その業務を通じて何を学んだのか」です。

つまり、

・どのノウハウが得られたのか
・どの判断が有効だったのか
・どの条件で問題が発生したのか

といった、「業務知識」まで、本来は蓄積される必要があります。

しかし、多くの企業では、これらは記録されません。

なぜでしょうか。

それは、日本企業では長年、「人間が分かっているから不要」と考えられてきたからです。

例えば、

・誰へ相談すれば良いか
・どこで調整が発生するか
・誰が実質責任者か
・どの順番で進めるべきか

は、“暗黙知”として運用されてきました。

つまり、多くの企業では、「業務構造そのもの」がデータ化されていないのです。

ここが極めて重要です。

本来、データ分析とは、「結果を見ること」ではありません。

本当に重要なのは、「なぜ、その結果になったのか」を、業務構造として理解することです。

しかし現在の多くの企業では、「業務がどう成立したか」を表現するデータが存在していません。

例えば、

・誰が判断したのか
・なぜ例外処理になったのか
・どこで滞留したのか
・何を調整したのか

が記録されていない。

すると、「売上は分かる」

しかし、「なぜ、その売上構造になっているのか」は分からない。

「処理件数は分かる」

しかし、「どこで調整コストが発生しているのか」は分からない。

つまり、「数字」は存在しても、「業務構造」が存在していないのです。

ここで重要になるのが、「業務モデリング」です。

業務モデリングとは、本来、

・誰が
・何を
・どの条件で
・どの状態へ遷移させ
・どのリソースを使い
・どこへ引き継ぎ
・どの知識を獲得したのか

を構造として定義することです。

つまり、「業務そのものをデータ化可能にすること」なのです。

そして、この構造が定義されて初めて、

・データ分析
・AI活用
・業務最適化
・ノウハウ継承

が成立します。

私は、多くの企業で、

「データ活用」が目的化してしまっていると思っています。

しかし、本当に必要なのは、「分析可能な業務構造を定義すること」なのではないでしょうか。

なぜなら、業務構造が定義されていない組織では、

・調整
・属人化
・暗黙知

が増殖し続けるからです。

逆に言えば、業務モデリングされた企業では、「業務そのもの」が資産化されます。

つまり、

・データ
・ノウハウ
・判断
・状態遷移

が企業知識として蓄積される。

私は、本当の意味でのデータドリブン経営とは、「数字を見る経営」ではなく、

「業務構造を理解する経営」だと思っています。

そして、その土台になるのが、「業務モデリング」なのです。

合同会社タッチコア　小西一有

[先週からの関連Blog]

第1回 「現場に聞けば業務は分かる」という危険な誤解 

第2回 「断捨離」が局所改善になる会社

第3回 日本企業は「調整」を仕事にしてしまった 

第4回 なぜ要件定義でシステムが壊れるのか

第5回 「動くが誰も触（さわ）れないシステム」が完成する 

第6回  業務モデリングとは「仕事の設計図」である

第7回 システム構造は、業務構造によって決まる