Новая архитектура
маркетинга
Содержание книги

Глава 25. Пилотирование и проверка гипотез

Введение

Целевая операционная модель, спроектированная в предыдущей главе, описывает, как должна работать система: какие процессы должны существовать, какие роли отвечают за переходы, какие данные необходимо фиксировать, какие технологические компоненты обеспечивают исполнение и какие правила управления удерживают конструкцию в рабочем состоянии.

Но логически непротиворечивая архитектура ещё не является доказательством её работоспособности.

Даже хорошо спроектированная модель может не дать ожидаемого эффекта по нескольким причинам: причинная гипотеза может быть неверной; реальная среда может отличаться от проектных предпосылок; сотрудники могут работать не по новой модели; данные могут оказаться недостаточными; изменение одного участка может лишь перенести ограничение дальше по коммерческому потоку.

Поэтому между проектированием и масштабированием должен существовать отдельный этап — пилотирование и проверка гипотез.

Логика главы:

Ц е л е в а я   м о д е л ь → Г и п о т е з а → П и л о т → Д о к а з а т е л ь с т в а → Р е ш е н и е

Пилот в этой логике — не уменьшенная версия внедрения и не «пробный запуск». Это инструмент снижения неопределённости перед следующим уровнем инвестиций.

Его задача — проверить, действительно ли изменение целевой модели создаёт требуемую способность системы и приводит к ожидаемому коммерческому результату.

В этой главе используется единый сквозной пример автомобильного холдинга. Пилот проводится в одном территориальном кластере, охватывает два автомобильных бренда, цифровые и телефонные лиды, функцию LLM, отдел продаж и существующую CRM. Проверяется способность системы лучше квалифицировать активный спрос, передавать его между LLM и продажами и не терять эпизоды спроса на стыках.

25.1. Почему целевую модель необходимо проверять

Архитектура отвечает на вопрос:

как должна быть устроена система?

Пилот отвечает на другой вопрос:

работает ли спроектированная причинная логика в реальной среде?

Это принципиально разные задачи.

Целевая модель может быть методологически правильной, но фактический результат будет зависеть от реального поведения людей, качества данных, ограничений текущей инфраструктуры, объёма потока, сезонности, состава спроса и множества других факторов.

Поэтому проектное решение до проверки следует рассматривать как гипотезу о будущей способности системы.

В автомобильном холдинге можно логически предположить, что:

  • единый стандарт MQL уменьшит вариативность квалификации;
  • обязательное следующее действие сократит число объектов без движения;
  • подтверждаемая передача SQL снизит потери на стыке LLM → отдел продаж;
  • единая событийная история повысит наблюдаемость коммерческого потока.

Все эти утверждения звучат убедительно. Но до проверки они остаются предположениями.

Главная функция пилота — снизить стоимость ошибки до масштабного внедрения.

Если крупная трансформация запускается сразу на всю организацию, цена неверной гипотезы резко возрастает: растут затраты на технологии, обучение, изменение регламентов, перестройку ролей и интеграции. Ограниченный пилот позволяет получить доказательства раньше.

Отсюда первый принцип главы:

чем выше стоимость следующего решения, тем выше требования к доказательствам перед ним.

25.2. Что такое пилот и чем он не является

Пилот — это ограниченная по масштабу, но целостная проверка причинной гипотезы о работе новой операционной модели.

Он должен одновременно содержать:

  • гипотезу;
  • ограниченный контур;
  • конкретное воздействие;
  • наблюдение;
  • критерии;
  • решение по результатам.

Пилот не следует путать с другими форматами.

Таблицу можно прокручивать по горизонтали.

Формат Главный вопрос Объект Результат
Проверка концепции Можно ли это реализовать? техническая или функциональная реализуемость решение реализуемо / нереализуемо
A/B-тест Какой вариант даёт лучший результат? отдельное воздействие сравнение вариантов
Технический запуск Работает ли решение технически? система или функция решение запущено
Пилот операционной модели Создаёт ли новая модель требуемую способность и результат? целостный фрагмент операционной модели доказательства
Внедрение Как сделать принятое решение нормой? организационная система устойчивый рабочий процесс

Пилот требует повышенной наблюдаемости. На время проверки компания может использовать более частый контроль, дополнительные проверки данных, ручные сверки и отдельные журналы отклонений. Но эти элементы не обязательно должны становиться частью будущей операционной нормы.

Поэтому пилот — временный исследовательский режим системы, а не её окончательная форма.

25.3. От архитектуры к проверяемой причинной гипотезе

Проверять архитектуру целиком невозможно. Её необходимо разложить на причинные утверждения.

Базовая конструкция:

И з м е н е н и е → М е х а н и з м → Э ф ф е к т → М е т р и к а

Например:

Если сделать следующее действие обязательным для каждого активного эпизода спроса, то уменьшится количество объектов без продолжения, снизится возраст незавершённой работы и сократится длительность перехода MQL → SQL.

Здесь:

  • изменение — обязательное следующее действие;
  • механизм — активный объект не остаётся без продолжения;
  • эффект — меньше зависших эпизодов;
  • метрика — возраст WIP и длительность MQL → SQL.

Рабочая матрица гипотез для сквозного пилота:

Таблицу можно прокручивать по горизонтали.

Архитектурное изменение Предполагаемый механизм Ожидаемый эффект Показатель
Единый стандарт MQL единые правила квалификации снижение вариативности доля объектов, соответствующих стандарту
Обязательное следующее действие у активного эпизода есть продолжение меньше объектов без движения покрытие следующим действием
SLA первого контакта уменьшается задержка реакции меньше потерь свежего спроса время до первого контакта
SQL Sent → SQL Accepted передача становится подтверждаемой меньше потерь на стыке доля принятых SQL
Причины возврата ошибки передачи становятся наблюдаемыми выше качество квалификации доля возвратов SQL
Customer ID взаимодействия связываются в один контекст меньше дублей доля идентифицированных клиентов
Событийная история появляется наблюдаемость движения выше управляемость потока полнота истории событий

Хорошая гипотеза должна быть опровержимой. Если любое наблюдаемое состояние можно объяснить как «успех», пилот теряет смысл.

25.4. Иерархия гипотез

Для сложной операционной модели одной гипотезы недостаточно.

Необходимо различать три уровня:

С и с т е м н а я   г и п о т е з а → Г и п о т е з ы   с п о с о б н о с т е й → О п е р а ц и о н н ы е   г и п о т е з ы

Системная гипотеза описывает общий коммерческий эффект.

Для автомобильного пилота:

Формализация квалификации и передачи активного спроса между маркетингом, LLM и продажами уменьшит потери эпизодов спроса, ускорит коммерческий поток и повысит MQL → SQL без критического ухудшения SQL → Deal.

Гипотезы способностей объясняют, какие механизмы должны создать этот эффект.

Например:

  • единая квалификация;
  • управляемое следующее действие;
  • подтверждаемая передача SQL;
  • наблюдаемая событийная история.

Операционные гипотезы описывают первые наблюдаемые изменения:

  • доля возвратов SQL снизится;
  • доля принятых SQL вырастет;
  • возраст WIP уменьшится;
  • длительность MQL → SQL сократится.

Таблицу можно прокручивать по горизонтали.

Уровень Гипотеза Что наблюдаем
Системная новая модель сокращает потери и ускоряет поток MQL → SQL, SQL → Deal, длительность цикла
Способность единый стандарт MQL повышает качество квалификации соответствие стандарту, возвраты
Операционная ошибочных MQL становится меньше ошибки квалификации
Способность следующее действие снижает скрытые потери объекты без движения, WIP
Операционная покрытие следующим действием растёт доля объектов со следующим действием
Способность подтверждаемая передача снижает потери на стыке принятие SQL
Операционная возвратов SQL становится меньше доля возвратов

Такая декомпозиция позволяет понять не только получен ли результат, но и почему он получен или не получен.

25.5. Контур пилота

Пилот должен быть ограничен по масштабу, но не разрушать целостность проверяемой способности.

Если проверить только отдельную функцию CRM, невозможно сделать вывод о способности коммерческого потока. Если проверить только действия одного сотрудника, вывод будет зависеть от конкретного исполнителя. Если включить слишком много подразделений, пилот потеряет управляемость.

Поэтому контур следует проектировать как минимально достаточный фрагмент реальной системы.

В сквозном примере контур включает:

Таблицу можно прокручивать по горизонтали.

Измерение Пилотный контур
Территория один кластер
Бренды два бренда
Тип спроса цифровые и телефонные лиды
Функции маркетинг, LLM, отдел продаж
Участок потока MQL → SQL с наблюдением до Deal
Объект активный эпизод спроса
Система существующая CRM
Изменения стандарт MQL/SQL, паспорт лида, следующее действие, SLA, подтверждаемая передача
Исключения сервис, F&I, автомобили с пробегом, другие кластеры
Владелец руководитель пилота
Период определяется длительностью цикла и объёмом наблюдений

Целостность способности обеспечивается сочетанием процесса, ролей, данных, технологий и правил управления. Ограничение масштаба не должно превращать проверку системы в проверку отдельного инструмента.

25.6. Исходная база и контекст

Без исходной базы невозможно понять, изменилось ли поведение системы.

Но исходная база — это не одна цифра за прошлый месяц. Она должна отражать типичное состояние процесса и его естественную вариативность.

Для сквозного примера фиксируется единая база:

Таблицу можно прокручивать по горизонтали.

Показатель Исходная база
MQL → SQL 34%
Медианная длительность MQL → SQL 9,2 часа
Покрытие следующим действием 69%
Доля принятых SQL 68%
Доля возвратов SQL 19%
Медианный возраст WIP 3,8 дня
SQL → Deal 14%
Полная событийная история 57%

Наблюдаемое изменение:

Н а б л ю д а е м о е   и з м е н е н и е = Р е з у л ь т а т   п и л о т а − Р е з у л ь т а т   и с х о д н о й   б а з ы

Но:

Н а б л ю д а е м о е   и з м е н е н и е ≠ П р и ч и н н ы й   э ф ф е к т

Причина проста: одновременно с пилотом могут измениться рынок, цены, наличие автомобилей, рекламная активность, действия дистрибьютора, мотивация продавцов, состав команды или конкурентная среда.

Поэтому вместе с исходной базой фиксируется реестр сопутствующих факторов:

Таблицу можно прокручивать по горизонтали.

Фактор До пилота Во время пилота Возможное влияние
Рыночный спрос стабилен вырос изменение входящего потока
Цена без изменений без изменений минимальное
Наличие ограниченное улучшилось возможный рост Deal
Реклама базовый уровень бюджет увеличен изменение количества и качества лидов
Состав команды стабилен часть сотрудников отсутствовала изменение нагрузки
Конкуренты стандартная активность акция конкурента возможное снижение конверсии

Задача пилота не в том, чтобы исключить весь контекст, а в том, чтобы сделать его видимым.

25.7. Конструкция доказательства

Не существует одного универсального способа доказать эффект пилота.

Метод сравнения должен соответствовать характеру гипотезы, доступному объёму данных и цене ошибки.

Таблицу можно прокручивать по горизонтали.

Условия Конструкция доказательства
Стабильный процесс, низкое влияние внешних факторов до / после
Нужно проверить устойчивость несколько когорт
Есть похожий объект сопоставимая группа
Можно сохранить независимую группу без воздействия контрольная группа
Изменение распространяется постепенно последовательный запуск
Воздействие локально и группы можно корректно разделить A/B-тест
Система сложная комбинация методов

В автомобильном примере базовая конструкция может включать:

  • сравнение до / после;
  • несколько последовательных когорт;
  • сопоставимый кластер или бренд;
  • анализ защитных показателей downstream.

Например:

M Q L → S Q L п и л о т : 34 % → 44 %
M Q L → S Q L с о п о с т а в и м ы й   о б ъ е к т : 35 % → 37 %

Такое сравнение не создаёт абсолютного экспериментального доказательства, но существенно усиливает причинный вывод по сравнению с простым «до / после».

Сила доказательства должна быть пропорциональна масштабу следующего решения.

25.8. Система показателей пилота

Для оценки пилота недостаточно одного коммерческого KPI.

Необходимо различать четыре группы показателей:

Таблицу можно прокручивать по горизонтали.

Группа Главный вопрос Пример
Показатели соблюдения модели Работает ли система по новым правилам? покрытие следующим действием
Показатели механизма Изменилось ли предполагаемое поведение? время до первого контакта, возраст WIP
Итоговые показатели Возник ли коммерческий результат? Deal, Win Rate, GM1
Защитные показатели Не ухудшилось ли соседнее звено? SQL → Deal, возвраты

Один из ключевых показателей исполнения:

Д о л я   р а б о т ы   п о   н о в о й   м о д е л и = О б ъ е к т ы ,   о б р а б о т а н н ы е   п о   н о в о й   м о д е л и В с е   о б ъ е к т ы   п и л о т н о г о   к о н т у р а

Если новая модель используется только в 40% случаев, отсутствие эффекта нельзя автоматически интерпретировать как провал гипотезы.

Рабочий набор показателей сквозного пилота:

Таблицу можно прокручивать по горизонтали.

Группа Показатель Что показывает
Соблюдение стандарт MQL используется ли единая квалификация
Соблюдение покрытие следующим действием есть ли продолжение у активного эпизода
Соблюдение соблюдение SLA выполняется ли норматив времени
Механизм время до первого контакта скорость реакции
Механизм возраст WIP скрытые задержки
Механизм доля принятых SQL качество передачи
Механизм доля возвратов SQL качество квалификации
Итоговый MQL → SQL результат изменяемого участка
Итоговый SQL → Deal проходит ли качество дальше
Итоговый GM1 экономический результат
Защитный SQL → Deal не снизилось ли качество SQL
Защитный качество данных не ухудшилась ли дисциплина системы

Критерий успеха задаётся до начала интерпретации:

К р и т е р и й = П о к а з а т е л ь + П о р о г + П е р и о д   н а б л ю д е н и я

Универсальных порогов не существует. Они зависят от исходной базы, вариативности и бизнеса.

Системное условие:

У с п е х   п и л о т а = У л у ч ш е н и е   ц е л е в о г о   п о к а з а т е л я ∧ О т с у т с т в и е   к р и т и ч е с к о г о   н а р у ш е н и я   з а щ и т н ы х   п о к а з а т е л е й

25.9. Когорты, время и зрелость результата

Коммерческий результат созревает не мгновенно.

Лид, вошедший в систему вчера, нельзя сравнивать по Deal с лидом, который находится в работе 30 дней.

Поэтому анализ должен учитывать возраст когорты.

Д л и т е л ь н о с т ь   ц и к л а = В р е м я   в ы х о д а − В р е м я   в х о д а

Пример:

Таблицу можно прокручивать по горизонтали.

Когорта Возраст наблюдения MQL → SQL SQL → Deal Статус
До пилота 30+ дней 34% 14% завершена
Пилот 1 30 дней 42% 15% завершена
Пилот 2 21 день 44% 14% почти завершена
Пилот 3 7 дней 41% — незрелая

Продолжительность пилота определяется:

  • длительностью коммерческого цикла;
  • объёмом наблюдений;
  • вариативностью процесса;
  • требуемой силой доказательств.

Поэтому правило «пилот всегда длится 30 дней» методологически неверно.

25.10. Ошибка модели, ошибка конструкции или ошибка исполнения

Если ожидаемый эффект не появился, это ещё не означает, что целевая модель неверна.

Нужно последовательно проверить три класса причин:

  1. неудовлетворительное исполнение — система фактически не работала по новой модели;
  2. ошибка конструкции пилота — способ проверки не позволял получить достаточные доказательства;
  3. ошибка гипотезы — новая модель соблюдалась, но предполагаемый механизм не проявился.

Диагностическая матрица:

Таблицу можно прокручивать по горизонтали.

Соблюдение модели Механизм Итоговый результат Интерпретация
низкое нет эффекта нет эффекта сначала исправить исполнение
высокое нет эффекта нет эффекта проверить гипотезу и конструкцию
высокое есть эффект нет результата результат не созрел или возникло новое ограничение
высокое есть эффект есть результат гипотеза получает подтверждение
низкое есть эффект есть результат причинный вывод слабый

Для интерпретации полезно дополнительно фиксировать журнал отклонений.

Таблицу можно прокручивать по горизонтали.

Дата Отклонение Масштаб Возможное влияние
05.09 не фиксировался SQL Accepted 6 часов искажение времени принятия
09.09 отсутствовали сотрудники LLM одна смена рост времени до контакта
14.09 изменена логика обязательного поля весь поток изменение соблюдения модели
18.09 акция бренда бренд A изменение качества спроса

Пилот должен быть версионируемым: если правила менялись внутри периода, необходимо понимать, какая версия модели дала какой результат.

25.11. Перенос ограничения и побочные эффекты

Даже успешный пилот может не улучшить систему равномерно.

После устранения одного ограничения поток упирается в следующее.

О г р а н и ч е н и е t → В о з д е й с т в и е → Н о в о е   о г р а н и ч е н и е t + 1

В сквозном примере до пилота основная проблема находилась на участке MQL → SQL.

После улучшения квалификации и передачи SQL объём передаваемого потока вырос. В результате новым ограничением стал участок:

S Q L → O p p o r t u n i t y

Единая количественная модель:

До пилота

1000   M Q L → 340   S Q L → 170   O p p o r t u n i t y → 48   D e a l

После пилота

1000   M Q L → 440   S Q L → 181   O p p o r t u n i t y → 61   D e a l

При этом:

M Q L → S Q L : 34 % → 44 %
S Q L → D e a l : 14 , 1 % → 13 , 9 %

То есть качество SQL по конечной конверсии существенно не ухудшилось, но участок SQL → Opportunity начал ограничивать рост.

Таблицу можно прокручивать по горизонтали.

Участок До пилота После пилота Интерпретация
MQL → SQL ограничение улучшен ограничение ослаблено
Передача SQL нестабильна улучшена способность подтверждается
SQL → Opportunity приемлемо ухудшилось новое ограничение
WIP продаж умеренный растёт формируется очередь
Opportunity → Deal стабильно стабильно значимого изменения пока нет

Это важный системный результат: пилот не «устраняет все проблемы», а меняет карту ограничений.

25.12. Экономика пилота

Операционное улучшение должно быть связано с экономикой.

Основная логика:

Д о п о л н и т е л ь н ы й   р е з у л ь т а т = Р е з у л ь т а т   п и л о т а − О ж и д а е м ы й   р е з у л ь т а т   б е з   и з м е н е н и я
Э к о н о м и ч е с к и й   э ф ф е к т = Д о п о л н и т е л ь н ы й   р е з у л ь т а т − Д о п о л н и т е л ь н ы е   з а т р а т ы

Экономическая карта:

Таблицу можно прокручивать по горизонтали.

Уровень Показатель Экономический смысл
Операционный время до первого контакта снижение потерь свежего спроса
Поток MQL → SQL увеличение квалифицированного потока
Поток SQL → Opportunity проверка качества дополнительного потока
Коммерческий Сделка дополнительные сделки
Финансовый GM1 дополнительный маржинальный результат
Затраты стоимость пилота цена проверки
Будущие затраты стоимость расширения следующий уровень инвестиций
Риск предотвращённая ошибка ценность снижения неопределённости

В сквозном примере:

48 → 61   D e a l

Наблюдаемая разница:

+ 13   D e a l

Если средний GM1 на сделку составляет 110 000 ₽:

13 × 110 000 = 1 430 000   ₽

При дополнительных затратах на пилот 650 000 ₽:

1 430 000 − 650 000 = 780 000   ₽

Но эти 780 000 ₽ нельзя автоматически считать доказанным причинным эффектом. Необходимо скорректировать результат на ожидаемую базу и сопутствующие факторы.

Отдельную ценность имеет и снижение неопределённости. Если пилот предотвращает дорогое масштабирование ошибочной модели, он создаёт ценность даже при слабом прямом краткосрочном эффекте.

25.13. Паспорт пилота и досье доказательств

До запуска пилота компания должна зафиксировать его паспорт.

Таблицу можно прокручивать по горизонтали.

Поле Содержание
Проблема какой разрыв проверяется
Исходная база состояние до воздействия
Системная гипотеза какой системный эффект ожидается
Гипотезы способностей какие способности проверяются
Причинный механизм почему изменение должно дать эффект
Контур пилота где проходит проверка
Объект что движется через поток
Воздействие какие элементы меняются
Показатели соблюдения применяется ли модель
Показатели механизма изменилось ли поведение
Итоговые показатели создан ли коммерческий результат
Защитные показатели что не должно ухудшиться
База сравнения с чем сравниваем
Период сколько наблюдаем
Владелец кто отвечает
Ограничения что снижает силу доказательств
Критерии решения при каких результатах принимается решение

По завершении пилота формируется досье доказательств.

Оно должно содержать четыре слоя:

  • операционные доказательства;
  • коммерческие доказательства;
  • экономические доказательства;
  • архитектурные доказательства.

Важно разделять:

факт → интерпретацию → вывод

Например:

Факт: MQL → SQL вырос с 34% до 44%.

Интерпретация: рост сопровождался улучшением соблюдения модели, снижением возвратов и сокращением длительности MQL → SQL.

Вывод: гипотеза о способности новой квалификации и передачи улучшать ранний участок потока получает поддержку.

Досье доказательств должно быть воспроизводимым: другой руководитель должен иметь возможность понять, на каких данных и допущениях принято решение.

25.14. Контрольная точка решения

Пилот не должен завершаться формулировкой «успешно / неуспешно».

Его выход — управленческое решение.

Базовые варианты:

Таблицу можно прокручивать по горизонтали.

Доказательства Интерпретация Решение
механизм и результат подтверждены, защитные показатели в норме модель работоспособна масштабировать
механизм проявляется, но конструкция требует доработки гипотеза перспективна скорректировать и повторить
ранние показатели положительные, поздние ещё не созрели данных недостаточно продолжить наблюдение
модель соблюдается, но механизм не проявляется гипотеза слаба остановить или переформулировать
нарушены защитные показатели системный риск остановить
исполнение недостаточно гипотеза не проверена исправить исполнение и повторить

Сила доказательств должна соответствовать:

  • объёму следующих инвестиций;
  • масштабу организационного изменения;
  • необратимости решения;
  • риску для коммерческого потока.

Отсутствие доказательства эффекта не тождественно доказательству отсутствия эффекта. Но и «пока не доказано» не должно автоматически превращаться в решение масштабировать.

25.15. От доказательства к следующему этапу

Пилот завершается не окончанием календарного периода, а моментом, когда компания получила достаточно доказательств для следующего управленческого решения.

До этого целевая модель остаётся проверяемой гипотезой.

После пилота часть её элементов может получить новый статус:

доказанная локальная способность.

Выходом пилота должен быть не набор улучшенных KPI, а пакет проверенного знания.

В него входят:

  1. Подтверждённые гипотезы
    Какие причинные связи получили поддержку.

  2. Проверенная конфигурация модели
    Какие поля, статусы, правила, SLA и переходы оказались необходимы.

  3. Требования к данным
    Какие данные действительно нужны для работы способности.

  4. Технологические требования
    Какие автоматизации и интеграции связаны с устойчивостью результата.

  5. Требования к ролям
    Кто владеет MQL, принимает SQL, управляет возвратами и контролирует WIP.

  6. Условия работоспособности
    В каком объёме потока, при каком уровне соблюдения модели и при каких данных способность показала результат.

  7. Новые ограничения
    Как изменилась карта узких мест после воздействия.

  8. Экономическая модель
    Какой дополнительный результат наблюдался, сколько стоил пилот и какой диапазон будущих затрат ожидается.

Ключевое различие:

Л о к а л ь н а я   д о к а з а н н о с т ь ≠ А в т о м а т и ч е с к а я   у н и в е р с а л ь н о с т ь

Пилот доказывает способность в определённых условиях.

Поэтому после пилота необходимо отделить:

Ядро модели

То, что должно сохраняться:

  • единое определение MQL;
  • подтверждаемая передача SQL;
  • обязательность следующего действия;
  • событийная история;
  • единая логика ответственности.

Контекстные настройки

То, что может адаптироваться:

  • конкретный SLA;
  • состав обязательных полей;
  • маршрут эскалации;
  • распределение ролей между локальным и центральным уровнями.

Кроме того, необходимо выявить ручные механизмы, которые были нужны только для наблюдения за пилотом: ежедневный аудит, временные таблицы, ручные выгрузки, персональные напоминания. Они не должны автоматически становиться частью постоянной операционной модели.

В сквозном автомобильном примере подтверждены:

  • единая квалификация MQL;
  • обязательное следующее действие;
  • подтверждаемая передача SQL;
  • кодифицированные причины возврата.

Операционно:

П о к р ы т и е   с л е д у ю щ и м   д е й с т в и е м : 69 % → 93 %
Д о л я   п р и н я т ы х   S Q L : 68 % → 93 %
Д о л я   в о з в р а т о в   S Q L : 19 % → 11 %
Д л и т е л ь н о с т ь   M Q L → S Q L : 9 , 2 → 5 , 1   ч а с а
П о л н о т а   с о б ы т и й н о й   и с т о р и и : 57 % → 94 %

Коммерчески:

M Q L → S Q L : 34 % → 44 %

при практически стабильном:

S Q L → D e a l : 14 , 1 % → 13 , 9 %

Новое ограничение:

S Q L → O p p o r t u n i t y

Таким образом, целевая модель переходит из проектного состояния в состояние доказанной локальной модели.

Это ещё не корпоративная операционная норма. Но это уже достаточная основа для следующего уровня решения.

Заключение

Целевая операционная модель сама по себе ещё не является доказательством того, что система начнёт работать лучше.

До проверки она остаётся системой причинных предположений.

Первый итоговый принцип главы:

целевая модель до проверки является гипотезой.

Пилот переводит проектное предположение в операционное знание.

Второй принцип:

пилот проверяет причинную связь, а не факт запуска инструмента или регламента.

Технический запуск, обучение или изменение CRM ещё не доказывают работоспособность модели. Проверке подлежит цепочка:

И з м е н е н и е → М е х а н и з м → Э ф ф е к т → М е т р и к а

Третий принцип:

доказательство должно быть многослойным.

Ни один KPI не способен доказать работоспособность сложной операционной модели. Решение должно опираться одновременно на операционные, коммерческие, экономические и архитектурные доказательства.

Четвёртый принцип:

снижение неопределённости является самостоятельным результатом пилота.

Отрицательный результат может предотвратить более дорогую ошибку масштабирования.

Поэтому конечная логика главы выглядит так:

И н в е с т и ц и я → С п о с о б н о с т ь → Ц е л е в а я   м о д е л ь → Г и п о т е з а → П и л о т → Д о к а з а т е л ь с т в а → Р е ш е н и е

В сквозном примере автомобильного холдинга пилот подтвердил способность новой модели ускорять MQL → SQL и сокращать операционные потери без критического ухудшения SQL → Deal. Одновременно обнаружено новое ограничение на участке SQL → Opportunity.

Система не стала «идеальной». Изменилась структура её ограничений.

Именно это и является ценностью пилота: компания получает более точную карту работы коммерческой системы и основание для следующего уровня инвестиций.

Следующий управленческий вопрос:

как превратить подтверждённую локальную модель в устойчивую операционную норму всей организации?

Рабочий глоссарий

Таблицу можно прокручивать по горизонтали.

Термин Рабочее определение
Пилот Ограниченная по масштабу, но целостная проверка причинной гипотезы о том, что изменение целевой операционной модели создаёт требуемую способность и приводит к ожидаемому коммерческому результату.
Причинная гипотеза Проверяемое предположение о том, что конкретное изменение через определённый механизм приведёт к ожидаемому эффекту.
Системная гипотеза Гипотеза верхнего уровня о том, как новая операционная модель должна изменить коммерческий результат системы в целом.
Гипотеза способности Предположение о том, что определённый элемент целевой модели создаёт конкретную способность системы.
Операционная гипотеза Предположение о конкретном наблюдаемом изменении процесса.
Исходная база Зафиксированное состояние пилотного контура до воздействия.
Воздействие Конкретное изменение процесса, роли, данных, технологии или правил управления.
Механизм Причинный путь, через который воздействие должно изменить поведение системы.
Наблюдаемое изменение Разница между результатом пилота и исходным состоянием.
Причинный эффект Изменение результата, которое можно обоснованно связать с проверяемым воздействием.
Контур пилота Организационные, территориальные, продуктовые, процессные, временные и информационные границы проверки.
Сопоставимая группа Объект, близкий к пилотному по существенным характеристикам и используемый как дополнительная база сравнения.
Контрольная группа Сопоставимая группа, на которую воздействие не распространяется.
Когорта Группа объектов, объединённых общим моментом или условием входа в наблюдение.
Длительность цикла Время между входом объекта в состояние и выходом из него.
WIP Объём незавершённой работы — количество объектов в процессе.
Возраст WIP Время нахождения незавершённых объектов в текущем состоянии.
Показатель соблюдения модели Метрика фактического использования новых правил.
Доля работы по новой модели Доля объектов пилотного контура, реально обработанных по новой логике.
Показатель механизма Метрика, показывающая, возникло ли предполагаемое изменение поведения системы.
Итоговый показатель Метрика коммерческого или экономического результата.
Защитный показатель Метрика, контролирующая отсутствие критического ухудшения соседнего участка.
Критерий успеха Сочетание показателя, порога и периода наблюдения.
Сопутствующий фактор Изменение контекста, способное повлиять на наблюдаемый результат независимо от пилота.
Побочный эффект Изменение другой части системы вследствие пилотного воздействия.
Новое ограничение Участок, который становится главным узким местом после ослабления предыдущего.
Ошибка модели Ситуация, когда модель соблюдается, но предполагаемый механизм не создаёт ожидаемого эффекта.
Ошибка конструкции пилота Ситуация, когда способ проверки не позволяет получить достаточные доказательства.
Дополнительный результат Разница между результатом пилота и ожидаемым результатом без изменения.
Дополнительный GM1 Дополнительный маржинальный результат первого уровня, связанный с эффектом пилота.
Досье доказательств Структурированный набор операционных, коммерческих, экономических и архитектурных доказательств.
Паспорт пилота Документ, фиксирующий до запуска проблему, гипотезы, контур, воздействие, показатели и критерии.
Контрольная точка решения Формализованный момент оценки доказательств и принятия решения.
Доказанная локальная модель Версия целевой операционной модели, работоспособность которой получила достаточное подтверждение в определённом пилотном контуре.

Нормативные сокращения

В главе сохраняются без перевода:

MOS, MVC, MQL, SQL, CRM, DMS, BI, CDP, API, SLA, KPI, CPL, CPS, GM1, LTV, WIP, ROI, F&I, LLM.

Для нормативных этапов коммерческого потока сохраняются:

Opportunity, Deal.

При первом употреблении:

Lead Lifecycle Management (LLM) — управление жизненным циклом лида.

Ключевые различия

К л и е н т ≠ Э п и з о д   с п р о с а
О б р а щ е н и е ≠ Л и д
L e a d ≠ M Q L
M Q L ≠ S Q L
П и л о т ≠ В н е д р е н и е
П р о в е р к а   к о н ц е п ц и и ≠ П и л о т
Н а б л ю д а е м о е   и з м е н е н и е ≠ П р и ч и н н ы й   э ф ф е к т
С о б л ю д е н и е   м о д е л и ≠ Э ф ф е к т и в н о с т ь   м о д е л и
Н е з а в е р ш ё н н ы й   о б ъ е к т ≠ П р о и г р а н н ы й   о б ъ е к т
Л о к а л ь н о е   у л у ч ш е н и е ≠ С и с т е м н о е   у л у ч ш е н и е

Конец главы 25

В этой главе
  1. Введение
  2. 25.1. Почему целевую модель необходимо проверять
  3. 25.2. Что такое пилот и чем он не является
  4. 25.3. От архитектуры к проверяемой причинной гипотезе
  5. 25.4. Иерархия гипотез
  6. 25.5. Контур пилота
  7. 25.6. Исходная база и контекст
  8. 25.7. Конструкция доказательства
  9. 25.8. Система показателей пилота
  10. 25.9. Когорты, время и зрелость результата
  11. 25.10. Ошибка модели, ошибка конструкции или ошибка исполнения
  12. 25.11. Перенос ограничения и побочные эффекты
  13. 25.12. Экономика пилота
  14. 25.13. Паспорт пилота и досье доказательств
  15. 25.14. Контрольная точка решения
  16. 25.15. От доказательства к следующему этапу
  17. Заключение
  18. Рабочий глоссарий

Поиск по книге

Поиск по заголовкам, тексту и таблицам.