Реальный пример того, как амбициозный, качественный Key Result компании превращается в конкретную, регулярно отслеживаемую метрику, — история OKR браузера Google Chrome под руководством Сундара Пичаи (описана Джоном Дорром в книге «Measure What Matters», 2018). В 2008 году команда Chrome поставила Objective «создать браузер нового поколения для веб-приложений» с Key Result «20 миллионов активных пользователей за 7 дней к концу года» — и не дотянула, набрав меньше 10 миллионов. В 2009-м цель подняли до 50 миллионов — достигли около 37-38 миллионов, снова промах. В 2010-м, финальном году этого цикла Objective, планку подняли до 100 миллионов — и Chrome вырос до 111 миллионов пользователей, впервые перевыполнив план. Ключевой урок для каскадирования: сам Key Result компании («20/50/100 миллионов пользователей») оставался качественным индикатором амбиции, а не операционной метрикой — команде пришлось перевести его в конкретные, регулярно отслеживаемые операционные показатели (скорость привлечения новых пользователей по неделям, удержание, повторная активация «уснувших» пользователей через специальные уведомления), которые реально можно было контролировать понедельно, а не ждать годового отчёта, чтобы узнать, попали в цель или нет.
Каскадирование целей от OKR к KPI — это техника перевода амбициозного, часто качественного Key Result компании в конкретные, операционные, регулярно отслеживаемые метрики (KPI) на уровне отделов, которые в сумме или как факторы формируют движение к результату верхнего уровня, не превращаясь при этом в механическое дробление одной цифры на всех поровну.
OKR отвечает на вопрос "куда мы хотим прийти в этом цикле", KPI отвечает на вопрос "что именно каждый отдел должен контролировать каждую неделю, чтобы это произошло" — смешение этих двух ролей в одной метрике создаёт путаницу и в целеполагании, и в операционном контроле.
Происхождение и исследовательская база
Практика каскадирования — не авторская методология одного человека, а результат совмещения двух independently развитых систем: OKR (популяризирована Джоном Дорром в книге «Measure What Matters», 2018, на основе практики Intel и Google) как инструмента целеполагания на уровне компании, и KPI как более раннего, устоявшегося с 1990-х инструмента операционного контроля на уровне подразделений. Задача каскадирования — соединить их так, чтобы KPI отделов были не изолированной системой, а прямым, прослеживаемым вкладом в Key Results компании.
Ключевые идеи и принципы
Принцип: Не деление поровну, а определение фактора влияния
Прежде чем назначить отделу KPI, нужно явно определить, через какой конкретный фактор этот отдел влияет на Key Result компании — например, Key Result "NPS вырос с 40 до 60" может декомпозироваться через фактор "скорость решения обращений" для службы поддержки и через фактор "качество онбординга" для продуктовой команды одновременно, а не через одинаковую долю прироста NPS для всех.
Принцип: Проверка зоны контроля
Каскадированный KPI имеет смысл только если отдел реально может на него влиять своими действиями — KPI, назначенный отделу, но фактически зависящий от факторов вне его контроля, демотивирует и создаёт ложное ощущение ответственности без реальных рычагов.
Принцип: KPI — операционная метрика с более короткой периодичностью, чем OKR
Если OKR обычно пересматривается раз в квартал, каскадированный KPI отслеживается чаще (еженедельно или ежемесячно) — это даёт возможность заметить отклонение и скорректировать курс до того, как квартальный Key Result окажется под угрозой.
Принцип: Обратная трассируемость: от KPI отдела обратно к цели компании
Сотрудник, выполняющий свой KPI, должен понимать, к какому Key Result компании и через какой конкретно фактор он ведёт — без этой обратной связи KPI превращается в изолированную операционную метрику, оторванную от смысла стратегии.
Ограничения, слепые зоны и критика
Не каждый Key Result компании естественно раскладывается на чёткие факторы по отделам — для качественных, кросс-функциональных Key Results (например, связанных с культурой или репутацией) прямое каскадирование в отдельские KPI может быть искусственным.
Излишне жёсткое каскадирование "сверху вниз" рискует превратить OKR (задуманный как инструмент амбициозного, частично недостижимого целеполагания) в систему обязательных KPI-показателей с санкциями за невыполнение — это меняет саму природу инструмента и снижает готовность ставить действительно амбициозные цели.
Каскадирование требует регулярной актуализации — если Key Result компании меняется по итогам квартального пересмотра OKR, а каскадированные KPI отделов не пересматриваются синхронно, отделы продолжают оптимизировать метрики, утратившие связь с реальным приоритетом.
Типовые ошибки
Ошибка 1: Key Result компании делится поровну между отделами без анализа реального фактора влияния.
Формально красивое деление на бумаге не отражает, кто на самом деле определяет движение к результату.
Как избежать: для каждого Key Result явно определять конкретный фактор влияния каждого отдела, а не делить итоговое число поровну.
Ошибка 2: отделу назначается KPI, на который он фактически не может повлиять своими действиями.
Возникает ощущение несправедливой ответственности без реальных рычагов воздействия на показатель.
Как избежать: явно проверять каждый каскадированный KPI на принадлежность к зоне реального контроля отдела перед его назначением.
Ошибка 3: OKR превращается в жёсткую систему обязательных KPI с санкциями за невыполнение, теряя природу амбициозного целеполагания.
Команды перестают ставить по-настоящему смелые Key Results, опасаясь последствий их недостижения.
Как избежать: явно разделять роль OKR (амбициозное целеполагание, частичное недостижение — норма) и роль каскадированных KPI (операционный контроль с более строгими ожиданиями).
Ошибка 4: каскадированные KPI не пересматриваются при изменении Key Result компании.
Компания меняет фокус по итогам квартального пересмотра OKR, но отделы продолжают отслеживать прежние KPI, утратившие связь с актуальным приоритетом.
Как избежать: при каждом квартальном пересмотре OKR синхронно пересматривать весь каскад KPI, а не только верхний уровень.
Ошибка 5: сотрудник не видит связи между своим ежедневным KPI и целью компании.
Без явной обратной трассируемости KPI воспринимается как изолированное требование сверху, а не как часть осмысленного движения к результату — это снижает вовлечённость сильнее, чем сам факт наличия метрики.
Как избежать: делать связь «мой KPI → Key Result компании» видимой и явной для каждого сотрудника, а не только для тех, кто участвовал в постановке каскада.
Главное, что нужно знать
Каскадирование — не механическое деление числа Key Result поровну, а определение конкретного фактора влияния каждого отдела.
Каскадированный KPI имеет смысл только в зоне реального контроля отдела.
KPI отслеживается чаще, чем квартальный OKR, позволяя вовремя заметить и скорректировать отклонение.
Каждый сотрудник должен видеть обратную трассируемость — как его KPI связан с Key Result компании.
План внедрения
Шаг 1: определить отделы-факторы влияния
Шаг 1: для каждого Key Result компании определить, какие отделы реально влияют на результат и через какой конкретный фактор.
Шаг 2: сформулировать и проверить каскадированный KPI
Шаг 2: для каждого отдела сформулировать каскадированный KPI и проверить его на принадлежность к зоне реального контроля.
Шаг 3: установить периодичность отслеживания
Шаг 3: установить периодичность отслеживания KPI (еженедельно/ежемесячно), более частую, чем квартальный цикл OKR.
Далее: синхронный пересмотр каскада
Далее: Поддержание и обновление. При каждом квартальном пересмотре OKR синхронно пересматривать каскадированные KPI отделов, чтобы они не оторвались от актуальных приоритетов.
Как реализовать этот план с помощью фрейма «Каскадирование целей (OKR → KPI)» в OrgDevTools
Фрейм устроен как Key Result компании сверху (единое текстовое поле) и карточки отделов ниже — каждая с полем фактора влияния, каскадированным KPI, целевым значением и явным чекбоксом «в зоне контроля».
Шаг 1 — поле «Какой фактор Key Result формирует этот отдел». Отдельное текстовое поле, физически предшествующее полю KPI, — структура фрейма не даёт сформулировать KPI отдела раньше, чем назван конкретный фактор влияния (защита от ошибки 1, если KR делится поровну без анализа).
Шаг 2 — чекбокс «в зоне контроля». Явный булев переключатель на каждой карточке отдела, который меняет цвет подписи (зелёный/красный) — вердикт фрейма отдельно считает KPI вне зоны контроля и предупреждает о риске, если такие есть (техническая защита от ошибки 2).
Итоги. Вердикт фрейма явно считает отделы «без KPI» и «вне зоны контроля» раздельно, не позволяя считать декомпозицию завершённой, пока оба счётчика не обнулятся, — а сама визуальная стрелка «↓ декомпозиция ↓» между Key Result и карточками отделов делает обратную трассируемость видимой прямо в интерфейсе (защита от ошибки 5).