DXの具体的実務：KPIの落とし込み

DXは、データ起点で経営を改革していく取り組みです。その大きな強みの一つは、あらゆる活動の効果を、定量的かつ常時計測可能な「KPI」に落とし込めることでしょう。しかし、DXの実務では従来型のKPIとは異なり、技術的観点を熟知したうえでのKPI設計・運用が求められるため、従来よりも多角的な考察が要求されます。今回の解説では、DXの実務において必要となる、KPIの設計・管理・運用方法について総論的に解説します。

KPIをどのように設計すべきか

　データ利活用によるDXの最大の効果の一つは、データ利活用が継続するほど、「施策の精度」が向上し続けることです。施策の精度とは、各種DX施策の経営指標への「寄与度」です。

　したがって、指標設計と運用、つまりKPI設計とモニタリングは、DXの実務において不可欠な活動であり、DXの成否を決定的に左右します。

　これまでの連載で何度か指摘したとおり、データ活用を起点としたDXで実現したいアプローチの一つは、「顧客体験をオンライン・オフラインで統合すること」です。

　DXではオンライン・オフラインで各種施策の実施を企画・実行しますが、施策で活用するデータや施策実施後に収集されるデータは統合して管理・運用します。

　そして、各種施策で求める成果が得られたかどうかについて、データをもとに計測・評価する最も有効な経営管理手法の一つが、KPI管理です。

　KPIを設計するには、そもそも「何をKPIとすべきか」という視点が重要です。その際、少なくとも以下の4点は必ず考察すべきです。

1、そのKPIの数値が改善されれば、売り上げやコストなどの上位の経営指標に明確にインパクトをもたらすか？

2、そのKPIを改善する施策の内容とPDCAの推進方法を、明確にイメージできるか？

3、そのKPIを計測するために必要なデータと集計方法が明確か？

4、そのKPIの数値そのものを常にアップデートできる、データパイプラインの構築が可能か？

　施策がやりっ放しで効果を計測していない、何をすれば数値が改善されるか分からない、KPIを算出するためのデータがそもそも集まらない…。こういった状況では、KPI設計に費やした膨大な労力が徒労に終わります。

　特に、オンラインで収集されるデータは、集計・分析のための前処理が必須であり、組織的なエンジニアリング力が必須です。

　ここに、大きな落とし穴があります。例えば、施策の企画段階から「効果の計測方法」についての議論が丸ごと抜け落ちていて、実施後の効果が分からないまま「やりっ放し」になっているケースを数多く見てきました。

　一方、効果計測の方法を検討していたとしても、KPI計測・集計などに使用したいデータが外部ITベンダーによって管理されるシステムに集積されている状況で、そのデータをリクエストしても手元に届くまで1週間以上かかる、といったケースも目の当たりにしてきました。これらは決して珍しいことではありません。

　上記で例示したような状況では、スピーディーなKPI管理・運用などできるはずがありません。

　さらに、できる限りリアルタイムに確認することを企画当初から意図していたKPIにもかかわらず、データパイプラインが日次単位のバッチ処理のためシステム設計そのものがKPI管理との整合性が取れていない、という現象も頻繁に目の当たりにしてきました。

　リアルタイムなデータ処理すなわちストリーミング処理と、バッチ処理ではシステム設計が全くと言っていいほど異なるため、処理方法の変更には膨大なコストと時間が発生します。

　上記のように、どこかに考察の甘さが残った状態で管理・運用プロセスを企画してしまうと、実務のステップに進んだ際に思わぬボトルネックと遭遇し、組織活動が急速に停滞します。こういった状況は、KPI運用に限らず、DXの活動で至るところに存在します。

　その理由はさまざまですが、私が見てきた中で非常に多かった原因は、端的に言って「実務・技術への理解不足」です。

　そのようなトラップを回避し、KPIを設計していくにはどのようなステップで進めるべきか。

　まずは、いきなりKPIツリーを構築するのではなく、実務のプロセスを詳細に理解したうえでKPIとすべき指標を特定していきます。その際、連載第2回で提示した下図のような「可視化」を行います。

　実際のプロジェクトでは、このような資料を50〜100枚程度のスライドで細かく可視化していきます。理由はシンプルで、そのぐらい精緻に解像度を上げて理解しなければ、指標とすべきKPIを見極められないからです。