データ分析・データドリブン経営の実行方法
はじめに
以前、経営管理の記事でフロント（事業部）側の活動はBIか何かで可視化しようという話をしました。
PLまたは売上高をKPIに分解して、マーケティングファネルを可視化して追っておこうという話ですね。
経営管理というと財務・会計畑の話が多いのに、なぜここだけWebマーケティングのような話をしているのかと疑問に思った方もいると思います。
簡単にいうと、トップラインの予実を外さないためと、売上づくりも事業部任せだとままならないことがあるからです。
私はむかし2年ほどWebマーケティングの仕事をしていたことがあります。その世界では、前日の数字を見て朝会でその日やることが決まるのが普通でした。クリック率やCVR、CPAなどが変わると、日次の振り返りで次のアクションが決まっていたものです。
その世界から初めて経理に来たとき、「月次決算だと年に12回しかPDCAが回らないのか」と思ったことを覚えています。それだと予実も合わないし、業績が悪くなっているときに原因もわからないよねと。
それもあって、経営企画、経営管理たるもの、事業部側の構造も可視化しておいて、「いま会社がどうなっているのか」を追えるようにしておきたいなと思ったわけです。
何を可視化するか
さて、いざ可視化するとなったときに、何を可視化するかです。
以前の記事で述べたとおり、財務諸表の売上高がどうやってできているのか、マーケティングファネルを可視化したいところです。具体的には、「お客さんが自分たちの会社に初めて接してから会社の銀行口座に入金があるまで」の流れをトレースしたいですね。
上記は売上側ですが、在庫や調達が重要な業態だと仕入側も一連の流れをトレースしたいところです。
toCのオンライン完結事業なら、広告運用の各種指標とWebとスマホのアクセス解析あたりが最前線になって、自社サイトに着地してからの購買履歴と仕入・在庫あたりが追う数字になると思います。
toBなら案件の進捗を可視化していつどれだけ売上が立つかと入金はいつかを見たいですね。
見る数字としては、基本の件数×単価から、各プロセスの離脱（残存）率、その結果としてのLTVなどが見られると良いと思います。私が見たことあるダッシュボードでは、「●月に加入した顧客のLTV」をX軸Y軸そろえて可視化しているものなどありました。以下のようなイメージです。
どこからデータを取るか
前述のとおりの可視化なので、会計システムから仕訳データを取っていたのでは間に合いません。というか、粒度が違いすぎます。財務データからは結果しかわかりません。
プロセスまで追うには、BtoCならWeb関連の解析ツールや店舗のPOSデータ、BtoBならSFAやスプレッドシートの管理表からデータを吸い上げてBIに突っ込まなきゃです。別にExcelでもいいです。
ECやってる会社だと在庫管理システムから在庫データも取れると良いですね。
ここで問題なのは、APIやコネクタを用意してくれている一部の優良サービスを除いて、直接はデータにさわれないことです。
比較的小規模の会社で使うSaaSはデータ連携機能が充実しているものが多いですが、レガシーな業界で使っているPOSとか、大企業の古い基幹システムなんかだと、恐ろしく使いにくい「データ抽出画面」みたいなのがあって、そこからExcelやPDFで帳票が吐き出せるとかいう地獄の世界です。
相手が中小ベンダーの場合は直接話すと意外に柔軟に対応してくれることがあります。追加料金で分析用のデータをクラウドに置いてくれたりとか。
基幹システムが入ってるくらいのところだと、データ分析基盤構築を専門にしている会社に頼んだ方が良いでしょう。
これらのデータを直接BIにつないでも良いですが、できれば、DWHや分析用共通DBのようなところに、なるべく汎用的なテーブル設計で格納しておいたほうが良いでしょう。単発のダッシュボードのために毎回データソースを用意していたのでは将来のカオスが確定します。
ダッシュボード乱立問題の解決法
さて、このようにデータの整備を進めていくと、だんだんダッシュボードが乱立してきます。いや、業種によってはしないかもしれません。このあたりは従業員のITリテラシーによります。
このときの問題は、どの数字が正なのかわからないことと、結局業績にどうリンクしているのかわからないことですね。
大きな会社の場合、中小やベンチャーの「あるSaaS一本」ではなく、「●●システム」のパッチワークで会社が回っています。作った時期も違えば、目的もバラバラ、相互接続するときはデータベースのテーブルに無理やり変なコードを入れて「運用でカバー」とか。
迷宮すぎてマスタに入っているデータは誰がメンテナンスしているのか、していないのか、データが取得できてもこれ信じていいのかわかりません。POSと基幹とMDシステムで数字が一致しているのか確証が持てないとか。使ってないカラムに古い情報が残ったままとか。
こういう場合、分析用のデータは一か所に集約するのが良いです。取れるデータを調べて、マスタのメンテナンス状況を調べ、必要なものを一か所に集める。前述のとおり、なるべく汎用的なテーブル設計にしてですね。中間集計済みのデータにすると後から粒度細かくしたくなったときにまた作り直しになるので、なるべく生データです。
大きな会社だとDWHが必要ですが、小さめの会社なら普通のMySQLとかで大丈夫です。分析用のSQLを投げてデータベースがメモリ不足でエラー吐くようなら普通のデータベースじゃダメです。
共通のデータベースができていれば、基本的にはダッシュボードが乱立してもまあ良しでしょう。各担当者がそれぞれの業務用のBIとか作り始めて収集がつかなくなりますが、数字がそろっていればまあアリです。
困るのは、各種会議体で担当者が自分用のBIとかで発表し始めて、もうミクロすぎてよくわからないというときですね。この問題は次のセクションで。
日々の業務に落とし込む方法
基本的には、ダッシュボードなりBIなりは「見る人と見る目的によって違う」のが原則です。
Web広告を回している担当者と経営層では見る数字と粒度が違うでしょうし、関心事項が違います。担当者は自分の業務のプロセスを説明したがりますが、経営層は最終的な数字の出来上がりと主な指標くらいしか興味がありません。
なので、BIのドリルアップドリルダウン機能を使って粒度を変えておくか、「会議体の説明や全体把握用の概要画面」と「個別の指標の詳細を追う画面」に分けて作ったほうが良いです。パワーポイントのエグゼクティブサマリーとスライド本体とappendixみたいなものです。
粒度別に画面を作ったら、各階層の会議体ではなるべくその画面を見てから議論するようにしましょう。議論の前に全員の頭をそろえるのが大事です。マーケの朝会だったらマーケ担当者用の画面を見れば良いし、経営会議だったらそれなりの粒度のものを見れば良いのです。
リテラシーの高い担当者が自分用に作っただけだと、そのうち誰も見なくなります。がんばって運用オペレーションに組み込むのです。
統計学、データサイエンス、AIは要るのか
よっぽどリテラシーの高い組織でもない限り、普段は要らないかなあというのが私の感想です。
このテスト結果は統計的に有意なのかとか、このキャンペーンは本当にリフトアップの効果があるのかとか、やっても良いですが、説明コストとリターンがあまり見合わない気がします。普通の会社だったら、統計学の話をしてわかるのは5%くらいじゃないかと思います。
計数管理で言うと、PLがけっこうわかってもらえて、BSとキャッシュフローが難しい、管理会計は一握り、統計学がわかる人なんて出会えた奇跡に感謝です。
ですし、実験室でリソースが少ない場合と違い、実業では実際にやってみることができますし、試行回数も多くとればそこまでミスリードはしないのではないかなと思います。
つまり、「可視化で充分」「まずはAIよりBI」「記述統計で充分」ですね。このとき、「試行回数も多く」ということで言うと、期間を長めに引っ張って見てみるのがお勧めです。
「昨日より単価が下がってる！」だとたまたまの可能性も高いですが、ダッシュボードの画面で3年くらい引っ張ってみて単価が下降傾向だったら何かが起こっています。
会計というちょっと難しい言語を理解することを除けば、経営は基本的に四則演算と国語の世界です。Excelとパワーポイントと同僚との会話を頑張りましょう。
まとめ
ということで、「売上と仕入の流れを可視化しておこう」「データソースはそろえよう」「粒度には気を付けよう」「オペレーションに組み込もう」「まずは集計だけでいいよ」というまとめでした。