KPI-дерево з AI: від north star до командних метрик

Після спостережень за ~30 засновниками, які намагалися перекласти "хочемо вирости 2× за рік" у командні метрики, мій висновок: розрив майже ніколи не у стратегії. Він у структурі. Вони знають north star. Вони не можуть намалювати дерево.

Що таке KPI-дерево насправді?

Визначення: KPI-дерево — ієрархічна декомпозиція однієї north star метрики у менші, owned числа, рух яких механічно пояснює рух батька.

Ключове слово — "механічно". Якщо діти не пояснюють батька математично, у вас не дерево, а wishlist. Revenue = customers × ARPU. Customers = new − churned. New = leads × win-rate. Кожен крок — рівняння, не амбіція.

Більшість SMB-стратегій валяться бо командні OKR унизу деки не мають доказового звʼязку з верхом деки. Дерево це фіксить — або викриває.

Як вибрати north star?

Це єдине рішення, з яким AI не допоможе. North star кодує вашу стратегічну ставку: у чому компанія існує, щоб бути найкращою? Виручка на активного клієнта — інша ставка, ніж logo growth, яка інша, ніж product-engagement time.

Три тести north star:

1. Механічна декомпозовуваність — записується рівнянням із 3-5 дочірніх метрик.
2. Тижнева спостережуваність — рух видно щотижня, не лише квартально.
3. Стратегічна унікальність — конкурент із іншою стратегією вибере інше число.

Якщо кандидат провалив один тест — це слоган, не north star.

Три шари робочого KPI-дерева

Шар 1: north star. Одна метрика. Один власник (зазвичай CEO).

Шар 2: драйвери. 3-5 метрик, що математично складаються у north star. Один власник на драйвер — переважно функціональний голова.

Шар 3: входи. На кожен драйвер — 2-4 input-метрики на рівні команди або сквoда. Це числа, які команда реально змінює тиждень-у-тиждень.

Визначення: Input-метрика — число, яке одна команда може зрушити роботою цього кварталу без крос-функціональної залежності.

Якщо командна метрика вимагає кооперації трьох інших команд — це не input, це driver. Перекласифікуйте.

Робочий приклад: сервісна компанія 120 людей

North star (Шар 1): Квартальна визнана виручка на активного клієнта.

Драйвери (Шар 2):

• Активні клієнти (new − churned − paused)
• Середня вартість проєкту
• Project completion rate у квартал
• Маржа на проєкт

Inputs для "середня вартість проєкту" (Шар 3, sales):

• Discovery-call → proposal rate
• Середній розмір proposal за service line
• Proposal acceptance rate
• Add-on attach rate у перші 30 днів

Inputs для "project completion rate" (Шар 3, delivery):

• Cycle time від kickoff до першого deliverable
• Mid-project scope-change rate
• Resource utilisation проти committed plan
• Client-side delay days на проєкт

Кожна Шар-3 input має одну команду і одне тижневе число. Квартальний огляд CEO іде знизу-вгору: які inputs зрушили, які драйвери відреагували, що це каже про north star.

Як допомагає AI: патерн Сократівського критика

AI відмінно робить adversarial review дерева, яке хтось уже намалював. Промпт нижче використовує його правильно.

Ти досвідчений operator, що ревʼює чорнетку KPI-дерева.

Компанія: [напр. "$8M ARR B2B SaaS, 60 людей"]
North star: [метрика + 1-рядкове визначення]
Драйвери (Шар 2): [3-5 метрик з визначеннями]
Inputs за драйвером (Шар 3): [список]

Атакуй дерево:
1. Де математика НЕ тримається механічно (parent ≠ функція від дітей)?
2. Які Шар-3 inputs насправді вимагають руху кількох команд? (Мають бути драйверами.)
3. Які метрики дублюють ту саму поведінку?
4. Де стратегічна ставка захована як визначення метрики?
5. Які inputs неможливо зрушити за квартал — надто повільні для командного володіння?

Будь конкретним. Цитуй імена метрик.

Три з пʼяти питань виявлять щось, що засновницька команда пропустила. Четверте — "стратегічна ставка захована як метрика" — найбільш leverage. Половина суперечок про метрики — насправді суперечки про стратегію в маскуванні.

Tool tip (AIAdvisoryBoard.me): KPI-дерево виправдовує себе лише коли тижневий огляд кожного шару показує Plan → Fact → Gap — що власник пообіцяв, що input-метрика зробила, де розрив. Наша операційна система щоденного менеджменту котить рух Шар-3 нагору до Шар-2 і показує, який драйвер пояснює gap на north star. 7-денна діагностика будує першу версію вашого дерева з даних, які у вас вже є. На https://aiadvisoryboard.me/?lang=en.

Manager scan (2-хвилинний digest)

• North star — одна метрика, один власник, одне рівняння — без compound-цілей
• Шар 2 — 3-5 драйверів, кожен із явним визначенням і одиницею
• Кожен драйвер має рівно одного функціонального власника — без комітет-власності
• Шар 3 inputs — рухаються однією командою за квартал, не крос-функціональні проєкти
• Кожен input має Plan, Fact і письмове Gap-пояснення щотижня
• Дерево вміщується на один аркуш — інакше драйверів забагато або занадто granular
• Дерево переглядається квартально; малі правки місячно; без правок mid-month без письмової причини
• Математика перевіряється: візьміть квартал, перерахуйте parent з дітей, підтвердіть reconciliation
• Vanity-метрики живуть поза деревом, на інженерних чи ops-дашбордах
• Нові стратегічні ініціативи чіпляються до існуючого драйвера, не створюють нову гілку

Micro-case (що змінюється за 7-14 днів)

B2B-сервісна фірма на 110 людей мала три набори OKR — корпоративні, функціональні, командні — які ніхто не міг математично узгодити. Запустили AI-критик-промпт проти їхнього чернеткового дерева у день 1. Виявив чотири проблеми: "client satisfaction" зʼявлявся двічі — як driver і як input; "sales velocity" вимагав одночасного руху marketing, sales і customer-success; "team utilisation" уже рухався рекрутинговими циклами, не тижневою командною роботою; north star ("ARR") не був тижнево спостережуваним. До дня пʼять було перероблене дерево з тижнево-спостережуваним north star, чотирма реальними драйверами і Шар-3 inputs, які команди реально могли рухати. До тижня 2 понеділкова all-hands починалася з одного Шар-2 чарту і трьох Gap-пояснень від функціональних голів, що володіли misses. CEO описала це як "перший раз, коли стратегічний слайд реально передбачив операційну реальність".

Note on this case: Приклад ілюстративний — на основі типових патернів у компаніях 30-500 людей, не конкретний клієнт. Числа — округлені діапазони, не гарантії.

Tool tip (AIAdvisoryBoard.me): Більшість KPI-дерев помирають у місяці 2, бо немає системи, що автоматично котить Plan → Fact → Gap з командного рівня до драйверів. Наша система робить це щодня і пише gap-наратив звичайною мовою, тож CEO-огляд читає дерево, не таблиці. 7-денна діагностика показує, де математика зараз ламається. Старт на https://aiadvisoryboard.me/?lang=en.

FAQ

Чи можна мати більше однієї north star? Можна мати primary і guardrail (напр. revenue + retention). Не можна мати дві рівні north star — команда буде їх торгувати у протилежних напрямках, і ви ніколи не дізнаєтесь.

Що, якщо бізнес надто складний для одного дерева? Тоді у вас, ймовірно, дві окремі business units. Намалюйте два дерева + portfolio-summary вгорі. Силою натягувати одне дерево на multi-business компанію — це і дає кошмар крос-функціональних inputs.

Чим це відрізняється від OKR? OKR — це commitments; KPI-дерево — каузальна структура під ними. OKR без дерева — wishful. Дерево без OKR — описове. Потрібні обидва, але дерево перше.

Чи потрібен data warehouse? Ні. Перша версія будується у таблиці з ваших операційних систем. Warehouse стає корисний, коли хочете автоматизувати Plan → Fact → Gap propagation тижнево.

Як щодо leading indicators? Шар-3 inputs — це і є ваші leading-індикатори, за дизайном. Драйвери — mid-cycle; north star — lagging. Дерево дає каскад leading-to-lagging за конструкцією.

Висновок

KPI-дерево — структура, що перетворює стратегію зі слайду на операційну систему. North star зверху. Драйвери всередині. Inputs внизу — owned одною командою, рухаються тижнево, механічно пояснюють батька.

Зробіть чернетку. Запустіть AI-критик. Шипніть першу версію цього кварталу й рефайніть квартально.

Якщо хочете систему, що автоматично показує Plan → Fact → Gap на кожному шарі — дивіться, як працює 7-денна діагностика на https://aiadvisoryboard.me/?lang=en.