Глава 26. Масштабирование доказанной модели
Книга: «Новая архитектура маркетинга»
Авторы: Андрей Лапиков, Иван Куц
Введение
Предыдущая глава завершилась доказательством локальной модели. Компания уже не обсуждает, существует ли проблема и может ли выбранная гипотеза улучшить систему. Пилот дал ответ: причинный механизм работает, роли уточнены, обязательные данные определены, технологические требования понятны, экономика рассчитана, а решение о дальнейшем развёртывании принято.
Но успешный пилот ещё не делает новую модель нормой всей организации. Он доказывает работоспособность в ограниченном контуре — при конкретной команде, объёме, бренде, регионе и уровне управленческого внимания. При расширении эти условия меняются. Растёт число пользователей и объектов, появляются новые организационные особенности, увеличивается нагрузка на данные и технологии, а временные ручные решения перестают быть безобидными.
Поэтому масштабирование нельзя понимать как копирование пилота. Масштабируется не набор экранов CRM, не регламент и не организационная схема. Масштабируется доказанная операционная способность — способность системы устойчиво выполнять требуемую функцию через подтверждённый причинный механизм и создавать наблюдаемый коммерческий результат.
Основная логика главы:
В центре главы — пять вопросов. Что именно должно оставаться неизменным при расширении? Какие элементы можно адаптировать? Как отличить реальное воспроизводство модели от формального внедрения? Как управлять новыми ограничениями, возникающими из-за самого роста потока? И в какой момент программа масштабирования перестаёт быть проектом и становится обычной операционной системой компании?
26.1. Почему доказанная локальная модель ещё не является операционной нормой
Пилот отвечает на вопрос о работоспособности. Операционная норма требует ответа на другой вопрос: способна ли организация устойчиво воспроизводить эту работоспособность без специального режима.
Во время пилота система почти всегда находится в привилегированных условиях. Проектная команда внимательно наблюдает за каждым отклонением, руководители быстрее принимают решения, ошибки оперативно исправляются, а часть разрывов компенсируется вручную. Такой режим необходим для проверки гипотезы, но он не может быть постоянной архитектурой бизнеса.
При росте масштаба то, что было единичным исключением, превращается в поток. Один неправильный статус в CRM почти незаметен; сотни неправильных статусов разрушают аналитику. Один руководитель может лично проверить десяток спорных случаев; сеть подразделений создаёт тысячи событий, которые уже нельзя контролировать индивидуально. Локальная успешность поэтому не гарантирует организационной устойчивости.
Особенно опасна зависимость от сильных людей. Если модель работает только там, где находится конкретный руководитель, аналитик или участник проектной команды, организация доказала не способность системы, а способность отдельных людей компенсировать её слабость.
Зрелость проходит три состояния. Сначала подтверждается работоспособность: причинный механизм вообще создаёт результат. Затем проверяется воспроизводимость: тот же механизм работает в других организационных контекстах. И только после этого появляется операционная устойчивость — способность поддерживается штатными ролями, данными, технологией и регулярным управлением.
Именно переход от локальной доказанности к устойчивой воспроизводимости является задачей масштабирования.
26.2. Что именно масштабируется
Главная ошибка масштабирования — считать объектом развёртывания форму пилота.
Процесс не является самостоятельной способностью. Он лишь описывает последовательность действий. Регламент фиксирует правила, но сам по себе не создаёт требуемого поведения. CRM поддерживает маршруты, данные и контроль, но не заменяет причинный механизм. Организационная схема распределяет функции, но не объясняет, почему результат должен измениться.
Объектом масштабирования является операционная способность. В нашем контексте это способность коммерческой системы принимать и обрабатывать целевые лиды по установленной логике, поддерживать следующее действие, соблюдать временные нормативы, фиксировать события, управлять возвратами и переводить поток дальше по цепочке до сделки.
Средства реализации этой способности могут различаться. В одном дилерском центре функция принадлежит руководителю группы, в другом — отдельному координатору. Интерфейс может отличаться. SLA может иметь разное конкретное значение. Но если изменяется сама причинная логика, организация уже масштабирует не ту же модель, а другую.
Поэтому элементы пилота полезно делить на три группы. Первая — обязательные элементы способности: их нельзя произвольно менять. Вторая — настраиваемые элементы реализации: они могут учитывать контекст. Третья — временные пилотные решения: они использовались ради скорости проверки и не должны автоматически превращаться в корпоративный стандарт.
26.3. Ядро модели и контекстные настройки
Чтобы масштабировать способность без механического копирования пилота, необходимо разделить два слоя модели.
Ядро модели — элементы, обеспечивающие доказанный причинный механизм. К ним относятся обязательные события, правила перехода объекта, ответственность, принцип контроля, наличие следующего действия, фиксация причин возврата и другие условия, без которых модель перестаёт быть той же самой.
Контекстные настройки — элементы формы реализации. Конкретный норматив SLA может различаться в зависимости от продукта, режима работы или структуры команды. Конкретная должность владельца функции может отличаться. Справочник причин может иметь разную детализацию. Интерфейс и маршрут уведомлений также могут быть разными.
Ключевой вопрос при адаптации звучит так: изменяется ли форма реализации или причинный механизм? Если функция сохраняется, адаптация допустима. Если локальное изменение отменяет обязательное событие, убирает ответственность или разрушает контроль, речь уже идёт не о настройке, а об изменении ядра.
Практически полезно выделять ещё и временную зону — решения, допустимые в пилоте или первой волне, но не признанные частью стандарта. Например, ежедневная ручная сверка может временно компенсировать отсутствие интеграции. Она поддерживает способность, но не должна закрепляться как постоянный способ работы.
Изменение ядра требует более высокого уровня решения и, как правило, повторной проверки. Изменение контекстной настройки может происходить в рамках установленной модели управления версиями.
26.4. Воспроизводимость модели
Воспроизводимость — центральное понятие масштабирования. Она не означает, что каждое новое подразделение должно показать точно такую же цифру, как пилот.
Организационные контексты различаются: исходная дисциплина, структура команды, качество клиентской базы, бренд, регион, сезонность и локальная инфраструктура могут быть разными. Поэтому идентичность абсолютного результата не является обязательным условием. Важно, чтобы сохранялся причинный механизм и появлялось улучшение относительно собственной исходной базы.
В сквозном примере пилот завершился конверсией MQL → SQL на уровне 44%. В ДЦ А исходная конверсия составляла 30%, после развёртывания — 42%. В ДЦ Б — 23% и 40% соответственно. Цифры различаются, но направление и механизм эффекта воспроизводятся.
Оценивать воспроизводимость нужно на четырёх уровнях. Первый — соблюдение ядра: обязательные элементы действительно работают. Второй — промежуточный механизм: изменяются SLA, WIP, качество следующего действия, доля принятых SQL и другие характеристики процесса. Третий — коммерческий результат. Четвёртый — устойчивость: эффект не исчезает после снижения проектного внимания.
С каждой новой волной организация фактически расширяет область доказанной воспроизводимости. Сначала модель подтверждена в одном контексте. Затем — в двух-трёх отличающихся контурах. После этого становится понятнее, какие элементы являются действительно универсальными, а какие зависят от условий.
26.5. Кодификация доказанной модели
Доказанная модель не масштабируется, пока знание о ней находится только в голове проектной команды.
Кодификация — это перевод опыта пилота в стандарт, который можно передавать, применять, контролировать и изменять. При этом стандарт не должен превращаться в подробную инструкцию на каждый возможный случай. Его задача — зафиксировать причинную архитектуру способности.
Стандарт должен отвечать как минимум на следующие вопросы: какова цель способности; каким объектом управляет процесс; какие определения используются; какие элементы относятся к ядру; кто отвечает за ключевые решения; какие события обязательны; какие данные должны существовать; каковы нормативы; как обрабатываются исключения; какие метрики показывают работу механизма; как обнаруживаются нарушения; какие элементы разрешено адаптировать.
Особое значение имеет объяснение причинности. Если правило существует только в форме «делать так», локальные команды будут воспринимать его как административное требование и постепенно оптимизировать под себя. Если понятно, какую функцию правило выполняет и какое нарушение механизма происходит при его отмене, стандарт становится инструментом управления, а не бюрократическим документом.
Кодификация также должна снижать зависимость от отдельных людей. Новый руководитель или сотрудник должен получить модель через стандарт, систему данных, обучение и управленческий цикл, а не через устную передачу знаний от участника пилота.
Не все детали пилота должны попадать в стандарт. Временные таблицы, ручные сверки, обходные маршруты и специальные проектные совещания должны быть явно помечены как временные решения. Иначе компания «масштабирует» собственный технический долг.
26.6. Готовность подразделения к развёртыванию
Следующая ошибка — начинать развёртывание только потому, что подразделение включено в календарный план.
Готовность должна оцениваться относительно конкретной модели. Для одной способности критична точность идентификатора клиента, для другой — наличие определённой роли или интеграции. Поэтому универсальной «зрелости подразделения» недостаточно.
Практически готовность проверяется по пяти контурам: процесс, люди, данные, технологии и управление. При этом средний балл опасен. Высокая готовность по четырём направлениям не компенсирует отсутствие критического пятого элемента.
Принцип можно выразить так:
Это не арифметический способ расчёта итогового балла, а управленческий принцип ограничивающего фактора.
Разрывы следует делить на критические, устранимые в ходе запуска и некритические. Критический разрыв блокирует волну. Устранимый требует владельца и срока, но не обязательно останавливает запуск. Некритический может быть включён в последующее улучшение.
Важно не отбирать для первой волны только самые сильные подразделения. Такой выбор создаёт искусственно благоприятную картину и мало говорит о воспроизводимости. Но начинать с заведомо неготовых контуров также неправильно. Первая волна должна быть достаточно готовой для работы и одновременно достаточно контрастной, чтобы дать новые доказательства.
26.7. Проектирование волн развёртывания
Волна — это не просто очередная группа подразделений. Это управляемый контур расширения, в котором компания одновременно увеличивает охват и получает новые доказательства о модели.
Волна должна быть достаточно большой, чтобы создать новый уровень нагрузки, и достаточно ограниченной, чтобы сохранялась возможность диагностики. Если организация подключает слишком много контуров одновременно, ошибки, локальные особенности и инфраструктурные ограничения смешиваются. Команда видит ухудшение показателей, но уже не может понять его причину.
При проектировании волны учитываются готовность, представительность, контрастность условий, управляемость, экономическая значимость и доступная мощность команды развёртывания. Размер волны ограничивается не амбициями проекта, а пропускной способностью системы изменений.
Для каждой волны нужен паспорт: цель, состав подразделений, исходные показатели, обязательное ядро, допустимые настройки, риски, контрольные метрики, известные ограничения и условия завершения стабилизации.
Базовая логика развёртывания:
В автомобильном примере первая волна включает два новых дилерских центра, вторая — кластер, третья — сеть. При этом следующая волна начинается не автоматически по дате, а после принятия управленческого решения по предыдущей.
26.8. Первая волна масштабирования
Первая волна — первый настоящий тест модели вне пилотной среды. Её задача не повторить пилот, а проверить работу доказанного механизма в новых организационных условиях.
К началу волны должны существовать базовая линия, актуальная версия стандарта, назначенные владельцы, обученные роли, необходимые данные и минимально достаточная инфраструктура. Критерии оценки фиксируются заранее: иначе команда будет интерпретировать результат уже после его появления.
В автомобильном примере пилот имеет MQL → SQL 44%, принятие SQL 93%, покрытие следующим действием 93%, возвраты SQL 11%. В ДЦ А исходная MQL → SQL равна 30%, после стабилизации — 42%; принятие SQL 92%, следующее действие 94%, SLA 91%, ручная поддержка низкая. Контур можно считать стабилизированным.
В ДЦ Б исходная MQL → SQL равна 23%, после развёртывания — 40%; принятие SQL 89%, следующее действие 90%, SLA 78%, ручная поддержка высокая. Коммерческий эффект заметен, но операционная устойчивость ещё не достигнута.
Это важный результат: одинаковое ядро не должно давать идентичные цифры, но оно должно создавать объяснимое улучшение и становиться менее зависимым от проектного сопровождения.
Первая волна также уточняет стандарт. Часть локальных особенностей оказывается допустимой настройкой, часть — временным отклонением, часть — сигналом о недостатке самой модели. Поэтому переход от версии 1.0 к версии 1.1 — нормальный результат первой волны, если ядро не меняется произвольно.
26.9. Контроль соблюдения модели
При масштабировании необходимо разделить прогресс развёртывания и реальную работу по модели.
Можно подключить все подразделения, обучить сотрудников и настроить CRM, но при этом фактическая практика останется прежней. Поэтому охват не является доказательством масштабирования.
Один из базовых показателей:
Для его использования организация должна заранее определить, что считается обработкой по стандарту. Например, объект имеет корректный статус, владельца, обязательные данные, следующее действие, соблюдённый маршрут и необходимые события.
Контроль должен оценивать фактическое поведение, а не наличие документа или поля в системе. При этом не нужен один универсальный «балл соблюдения». Критические элементы ядра лучше контролировать отдельно: обязательное событие либо выполнено, либо нет.
Часть контроля должна быть автоматической: отсутствие следующего действия, нарушение SLA, незаполненное обязательное поле, конфликт статусов. Другая часть требует управленческого анализа — например, формально заполненное, но бессодержательное следующее действие.
Наконец, важно не путать ухудшение видимого показателя с ухудшением системы. После внедрения наблюдаемости организация часто впервые начинает видеть то, что раньше не учитывалось. Рост зарегистрированных возвратов или нарушений на старте может означать повышение прозрачности, а не деградацию работы.
26.10. Управление локальными отклонениями
Масштабирование неизбежно создаёт отклонения. Управленческая задача состоит не в том, чтобы запретить их все, а в том, чтобы различать их природу.
Отклонение — фактическая практика, выходящая за требования стандарта или допустимый диапазон контекстной настройки. Оно должно попадать в реестр с указанием подразделения, затронутого элемента, факта, причины, влияния на ядро, решения, владельца и срока пересмотра.
Полезно выделять три класса. Допустимое отклонение фактически является разрешённой вариацией и может быть переведено в контекстную настройку. Условно допустимое временно принимается при наличии причины, владельца и срока. Недопустимое разрушает ядро или создаёт неприемлемый риск и должно быть устранено.
Чем ближе отклонение к причинному ядру, тем выше должен быть уровень решения. Локальный руководитель может изменять форму исполнения в пределах разрешённых настроек, но не должен самостоятельно отменять обязательное событие или менять критерий квалификации SQL.
Особенно важны повторяющиеся отклонения. Если один и тот же запрос появляется в нескольких подразделениях, это уже не только локальная проблема. Он может показывать, что стандарт не учитывает значимый контекст или что сама модель требует новой версии.
Жизненный цикл отклонения поэтому замыкается в управленческий контур: выявление, классификация, решение, контроль, пересмотр. Этот контур превращает локальные исключения в источник развития модели.
26.11. От пилотных решений к промышленной инфраструктуре
Пилот оптимизируется под скорость проверки. Промышленная инфраструктура — под устойчивость, объём и сопровождение.
Во время пилота допустимы Excel, ручные выгрузки, чаты, локальные отчёты и ручное распределение. Эти решения позволяют быстро проверить причинную гипотезу, но их стоимость резко растёт вместе с масштабом.
Переход к промышленной инфраструктуре означает замену временных решений устойчивыми системными механизмами: ручной проверки — автоматическим контролем, выгрузок — интеграциями, локальной отчётности — BI, ручного распределения — маршрутизацией CRM, ручной сверки — валидацией данных.
Однако автоматизация не является самостоятельной целью. Сначала должна быть доказана способность и определён стандарт, затем формируются технологические требования. Автоматизация нестабильного процесса лишь ускоряет нестабильность.
Особое значение имеет архитектура данных: единые определения, справочники, идентификаторы, событийная модель, история изменений и определённый источник истины. В автомобильном бизнесе это требует согласования CRM, DMS, BI, CDP и других систем вокруг единой логики объекта и клиента.
При росте масштаба нужно учитывать не только функциональность, но и надёжность: что происходит при сбое интеграции, кто отвечает за восстановление, как фиксируется потеря события, каким образом предотвращается накопление скрытого технологического долга.
26.12. Новые ограничения масштаба
Успешное масштабирование почти всегда меняет структуру ограничений системы.
До пилота сквозной автомобильный пример выглядел так: 1000 MQL → 300 SQL → 150 Opportunity → 55 Deal. После пилота: 1000 MQL → 440 SQL → 181 Opportunity → 61 Deal.
MQL → SQL выросла с 30% до 44%. Объём SQL увеличился на 46,7%. Но Opportunity выросли только на 20,7%, а Deal — на 10,9%. Одновременно SQL → Opportunity снизилась с 50,0% до 41,1%.
Это не означает, что улучшение MQL → SQL было ошибочным. Оно проявило следующее ограничение. Система начала создавать больше SQL, чем следующий участок мог переработать с прежней эффективностью.
Общая закономерность:
Новое ограничение может возникнуть в мощности людей, технологиях, данных, управленческой пропускной способности или распределении ответственности. Поэтому после каждой волны необходимо искать не только достигнутый эффект, но и то, где теперь накапливается WIP, увеличивается цикл, растёт очередь решений или ухудшается конверсия следующего перехода.
Не каждое ограничение необходимо немедленно устранять. Оно должно оцениваться по влиянию на общий результат и стоимости решения. Но организация обязана видеть его до того, как следующая волна увеличит нагрузку ещё сильнее.
26.13. Экономика масштабирования
Даже доказанная и воспроизводимая модель не должна расширяться автоматически. Каждая волна требует ресурсов и поэтому должна иметь собственную экономическую логику.
Затраты полезно разделять на разовые и постоянные. К разовым относятся настройки CRM, интеграции, разработка, миграция, обучение и подготовка отчётности. К постоянным — сопровождение, BI, контроль качества, владельцы процессов и дополнительная инфраструктурная мощность.
Первая волна часто дороже следующих, потому что именно в ней создаётся общая инфраструктура. Поэтому экономику нельзя оценивать только по локальному результату одного подразделения. Часть вложений создаёт актив, который будет повторно использоваться дальше.
Коммерческий эффект необходимо считать относительно сценария без изменения:
Так исключается ошибочная атрибуция рыночного роста, сезонности или параллельных инициатив.
Итоговая экономическая конструкция:
Экономика масштабирования имеет ступенчатый характер. До определённого объёма существующая инфраструктура справляется. Затем требуется новый сервер, дополнительная команда поддержки, новая управленческая роль или расширение LLM. Поэтому стоимость следующей волны может как снижаться за счёт повторного использования инфраструктуры, так и резко возрастать при переходе нового порога мощности.
В расчёт также необходимо включать стоимость ручных компенсаций и управленческого внимания. Если модель создаёт эффект только за счёт ежедневных ручных сверок и постоянных эскалаций, её фактическая стоимость выше проектного бюджета.
Максимальный организационный охват не обязательно означает максимальный экономический эффект. Последние 10–20% сети могут требовать непропорционально дорогой интеграции или иметь слишком малый коммерческий потенциал. Поэтому решение о следующей волне должно основываться на предельной экономике именно следующего шага.
26.14. Контрольная точка каждой волны
Каждая волна должна завершаться управленческим решением, а не отчётом о выполненных мероприятиях.
Количество подключённых подразделений, обученных сотрудников и настроенных интеграций показывает прогресс проекта, но не готовность системы к следующему масштабу.
Для решения достаточно проверить несколько блоков: соблюдается ли ядро; стабилизировались ли ключевые показатели; снизилась ли зависимость от ручной поддержки; понятны ли новые ограничения; выдержит ли инфраструктура следующий объём; остаётся ли экономика положительной; используется ли актуальная версия стандарта.
Критические проблемы нельзя усреднять. Если пять контуров работают хорошо, но инфраструктура находится на пределе, средний «балл готовности» не имеет смысла. Один блокирующий фактор может остановить следующую волну.
После контрольной точки возможны разные решения: продолжить; продолжить с корректировкой; сначала стабилизировать; устранить ограничение; пересобрать часть модели; повторно проверить спорный элемент.
В автомобильном примере ДЦ А после первой волны стабилизирован: MQL → SQL 42%, принятие SQL 92%, следующее действие 94%, SLA 91%, ручная поддержка низкая. ДЦ Б показывает коммерческое улучшение до 40%, но SLA остаётся на уровне 78%, а ручная поддержка высока. Поэтому результат нельзя оценить одной метрикой: эффект подтверждён, но контур требует стабилизации.
Контрольная точка должна смотреть и вперёд. Если интеграция уже загружена на 80–85%, она может нормально выдерживать текущую волну, но стать новым ограничением при подключении кластера. Поэтому решение о продолжении включает прогноз следующего уровня нагрузки.
26.15. От развёртывания к операционной норме
Масштабирование заканчивается тогда, когда специальный режим перестаёт быть необходимым.
Пока модель зависит от проектной команды, отдельных совещаний, временной отчётности, ручных компенсаций и специальных ресурсов поддержки, она остаётся частью трансформационной программы. Операционная норма возникает тогда, когда те же функции выполняются штатными ролями и системами.
Переход включает несколько изменений. Проектный владелец уступает место постоянному владельцу модели. Специальный контроль становится регулярным управленческим циклом. Проектное обучение превращается в стандартный ввод в роль. Временные отчёты заменяются штатной аналитикой. Технологические решения передаются в постоянное сопровождение. Отклонения проходят нормативный маршрут. Бюджет внедрения сменяется эксплуатационными расходами.
Главный контрольный вопрос прост: сможет ли модель устойчиво работать, если специальная программа масштабирования будет закрыта? Если для нормальной работы всё ещё нужен проектный аналитик, ручная сверка или неформальная эскалация, часть способности ещё не встроена в организацию.
После перехода модель не должна застывать. Рынок, продукты, клиенты и технологии продолжают меняться. Поэтому зрелая операционная норма включает механизм управляемого изменения: данные и отклонения позволяют обнаруживать новое ограничение, формировать гипотезу, проверять изменение и создавать следующую версию модели.
Так масштабирование завершается, но развитие системы продолжается.
Заключение
Успешный пилот создаёт доказанную локальную способность. Масштабирование превращает её в свойство организации.
Для этого недостаточно распространить регламент, CRM-настройки или организационную схему. Компания должна отделить причинное ядро от контекстных настроек, кодифицировать доказанное знание, проверить воспроизводимость в новых условиях, разворачивать модель управляемыми волнами, контролировать фактическое соблюдение, управлять отклонениями, промышленно обеспечить данные и технологии, отслеживать перемещение ограничений и проверять экономику каждого нового масштаба.
Сквозной автомобильный пример показывает эту логику особенно ясно. До пилота поток составлял 1000 MQL → 300 SQL → 150 Opportunity → 55 Deal. После пилота — 1000 → 440 → 181 → 61. Улучшение MQL → SQL с 30% до 44% увеличило поток SQL почти на половину, но одновременно проявило новое ограничение на переходе SQL → Opportunity. Масштабирование поэтому не просто распространяет найденное улучшение — оно меняет конфигурацию всей системы.
Конечной точкой становится операционная норма: способность поддерживается штатными владельцами, регулярным управленческим циклом, промышленной инфраструктурой, стандартным обучением и системой работы с отклонениями.
Но операционная норма не является концом развития. Зрелая система должна сама создавать данные о собственных ограничениях и превращать их в новые гипотезы улучшения. На этом масштабирование как отдельная программа заканчивается и начинается постоянный цикл развития коммерческой системы.
Глоссарий главы 26
Адаптация модели — допустимое изменение контекстной реализации модели без изменения её причинного ядра.
Волна развёртывания — управляемая группа новых организационных контуров, в которых модель внедряется и проверяется одновременно.
Воспроизводимость — способность модели сохранять причинный механизм и создавать приемлемый результат в новых организационных условиях.
Готовность к развёртыванию — наличие минимально необходимых условий по процессам, людям, данным, технологиям и управлению для устойчивой работы модели.
Доказанная операционная способность — способность системы создавать требуемый результат через причинный механизм, подтверждённый пилотом.
Дополнительный GM1 — прирост валовой прибыли первого уровня относительно ожидаемого результата без изменения модели.
Контекстные настройки — элементы реализации модели, которые могут изменяться с учётом особенностей конкретного подразделения, продукта, региона или организационного контура.
Контрольная точка решения — момент после волны развёртывания, в котором принимается решение о продолжении, корректировке, стабилизации или пересмотре модели.
Кодификация модели — перевод доказанного знания о модели в формализованный стандарт, который можно передавать, применять, контролировать и изменять.
Локальное отклонение — фактическая практика, выходящая за требования стандарта или установленные границы допустимых настроек.
Операционная модель — архитектура процессов, ролей, данных, технологий и управления, обеспечивающая воспроизводство определённой операционной способности.
Операционная норма — состояние, при котором доказанная способность встроена в штатную работу организации и не зависит от специального проектного режима.
Операционная способность — устойчивое свойство системы выполнять определённую функцию через заданный причинный механизм и создавать наблюдаемый результат.
Пилот — ограниченный эксперимент, предназначенный для проверки причинной гипотезы и доказательства работоспособности модели.
Прогресс развёртывания — степень организационного охвата модели.
Промышленная инфраструктура — технологическая и информационная среда, способная устойчиво поддерживать модель при рабочем масштабе.
Развёртывание — практическое внедрение доказанной модели в новые организационные контуры.
Реестр отклонений — система учёта, классификации, анализа и контроля локальных отклонений от стандарта модели.
Ручная компенсация — временное ручное действие, заменяющее отсутствующий или недостаточно устойчивый процесс, технологию либо механизм управления.
Соблюдение модели — степень соответствия фактической практики обязательным элементам стандарта и ядра модели.
Стабилизация — период после запуска волны, в течение которого устраняются дефекты развёртывания, сокращаются временные компенсации и показатели выходят в устойчивый диапазон.
Стандарт модели — формализованное описание ядра, ролей, процессов, данных, нормативов, контрольных механизмов и допустимых контекстных настроек.
Технологический долг — накопленные временные технологические решения, повышающие стоимость сопровождения и ограничивающие дальнейшее масштабирование.
Узкое место — элемент системы, пропускная способность которого ограничивает общий поток или дальнейший рост результата.
Ядро модели — обязательные элементы операционной модели, обеспечивающие доказанный причинный механизм и не подлежащие произвольному локальному изменению.
Версия операционной модели — зафиксированное состояние стандарта, ядра и допустимых настроек модели на определённый момент времени.
Источник истины — система или набор данных, признанные нормативным источником для конкретного объекта, события или показателя.
Следующее действие — зафиксированный следующий шаг по конкретному коммерческому объекту с установленным сроком и ответственным.
SLA — норматив допустимого времени выполнения определённого действия или перехода между состояниями процесса.
WIP — объём объектов, одновременно находящихся в незавершённой работе внутри конкретного участка процесса.
MQL — маркетингово квалифицированный лид, соответствующий установленным критериям целевого обращения.
SQL — лид, квалифицированный для передачи в коммерческий процесс и дальнейшей работы продаж.
Opportunity — коммерческая возможность, перешедшая из стадии квалификации в активную работу по потенциальной сделке.
Deal — завершённая коммерческая сделка.