KPIツリーを実際に運用してみると、売上や粗利といった数値データだけでは、ツリーが前に進まない場面が必ず出てきます。
特に多いのが、次の状態です。
- 行動KPIは達成している
- しかし、先行KPIがまったく動かない
例えば、
- 行動KPI：提案件数
- 先行KPI：受注件数
提案数は積み上がっているのに、受注が増えない。
このときに必要なのは「もっと提案しろ」ではありません。
なぜ、その行動KPIが先行KPIに効かなかったのかを、構造として説明できる状態を作ることです。
ポイントは「非数値データ」を意思決定に使うこと
ここで重要になるのが、営業ログなどの非数値データです。
ただし、自由記述のままではデータドリブン運用には使えません。
そこでまずやるべきことは一つ。
営業ログを「構造データ」にする（ここは人がやる）
最初に行うのは、ログの構造設計です。これは生成AIではなく、人が決めます。
① 状況の整理
- 進捗中
- 停滞
② 課題分類（超えないといけない壁）
- 価格
- 提案内容
- 納期
- 信頼
- お客様本気度 など
③ 共通の評価軸
- 可変性（自社の努力で変えられるか）：高／中／低
- 再現性（他案件でも同じ理由が出るか）：高／中／低
④ 課題分類ごとの評価軸（※1つに絞る）
- 価格：価格合致度（合う／要調整／合わない）
- 提案内容：代替提案可否（可能／一部可能／不可能）
- 信頼：実績提示可否（可能／一部可能／不可能）
- お客様本気度：即時性（今すぐ／1年後／いつかは）
- 納期：対応可否（可能／一部可能／不可能）
注意点は2つあります。
- ログの入力タイミングは「案件が動いたとき」ではなく、週次で固定する（不定期入力は必ず崩れる）
- 構造化の目的は、行動KPIを積み上げても先行KPIに効かない案件を「課題分類×評価軸」の組み合わせとして特定すること
非数値データを取り込む「入口」を作る
次に、非数値データを現実的に集める仕組みを用意します。
- スマホアプリ
- 実績データを吸い上げ、非数値データ（営業ログ）を入れる口を作る
入力内容は、
- 上記の構造データ
- 自由記述データ（音声入力も可）
ここまでが「人がやる設計」です。
この段階で、はじめて生成AIが戦力になります。
ここから生成AIの出番（ただし判断はしない）
ここから先は、生成AIが得意な領域です。
ただし、やらせるのは判断の一歩手前までです。
前提（状況）
- 提案件数（行動KPI）は達成している
- 受注件数（先行KPI）が増えない
評価対象の絞り込み（重要）
可変性：低の案件は、自社の行動で結果を変えられないため、行動KPI見直しの判断材料から外します。
生成AIにやらせること①：事実の集計・比較
生成AIには、次を指示します。
- 可変性：中・高の案件のみを対象に
- 課題分類 × 評価軸の組み合わせ別に
- 受注率／停滞率／長期化率 を集計・比較
ここで生成AIがやっているのは、事実の整理と比較だけです。
生成AIにやらせること②：効かなかったパターンの列挙
次に、
- 行動KPIは動いたが、先行KPIに効かないパターン
を列挙させます。
ここでも、生成AIは理由を断定しません。
あくまで「どの構造の案件が、どの結果になりやすいか」を事実ベースで並べるだけです。
生成AIにやらせること③：選択肢を「候補」として出す
そのうえで、生成AIには次の3案を出させます。
- 継続
- 条件変更
- 撤退
ただし、これは判断ではありません。
「この構造の案件に対して考えられる選択肢の候補」を並べるだけです。
最後の判断は、必ず人が行う
重要なのは、ここです。
- 生成AIは「整理・比較・候補出し」まで
- 判断は「人」が行う
会議でやるべきことは、
- この行動KPIを「継続」するのか
- 条件をどう変えるのか
- どこで「撤退」するのか
を意思決定として確定することです。
行動KPIを「評価」ではなく、判断の道具に戻すということです。
まとめ
行動KPIが効かなかったときにやるべきことは、行動を増やすことでも、数字で詰めることでもありません。
非数値データを構造化し、生成AIでパターンと境界を可視化し、最後は人が判断する。
この役割分担を守れば、生成AIは「正解を出す存在」ではなく、意思決定を支える補助線として十分に戦力になります。
コメント