Глава 21. Практическое внедрение новой архитектуры

Книга: «Новая архитектура маркетинга»
Авторы: Андрей Лапиков, Иван Куц

Введение

К этому моменту новая архитектура маркетинга уже описана как целостная коммерческая система: от рынка и формирования спроса до MQL, LLM, Sales Operations, сделки, владения и нового эпизода спроса. Однако наличие методологии ещё не означает, что организация умеет по ней работать. Между правильно построенной концепцией и устойчиво работающей системой существует отдельная управленческая задача — практическое внедрение.

Трансформация проходит внутри действующего бизнеса. Компания не может остановить продажи, маркетинг, контактный центр, сервис и финансовые процессы на несколько месяцев, чтобы затем «запустить новую модель». Старые и новые правила определённое время сосуществуют. Возникают временные роли, параллельные процессы, ручные сверки, переходные KPI и ограничения данных. Поэтому переход нельзя описывать как простое движение As Is → To Be.

В рамках этой главы используется следующая конструкция:

Текущее состояние → Архитектура перехода → Целевое состояние.

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

Важно различать пять состояний изменения:

1. Концепция — мы понимаем, как должна работать система.
2. Проектирование — определены объекты, процессы, роли, данные и правила.
3. Внедрение — новый механизм физически создан и запущен.
4. Принятие — организация действительно начала работать по новым правилам.
5. Стабилизация — новая модель воспроизводится без постоянного проектного давления.

Только после пятого состояния можно говорить о новой операционной системе.

В рамках этой книги используется авторская модель «Контур внедрения новой архитектуры»:

Диагностика → Целевая архитектура → Разрыв → Приоритеты → Дорожная карта → Владельцы → Реализация → Контроль → Экономический эффект → Обучение → Следующий цикл.

Этот контур не является одноразовым проектом. Он должен повторяться. Иначе компания однажды перестраивает процессы, но со временем снова накапливает разрывы.

Второй ключевой принцип главы — внедрять не всю идеальную архитектуру сразу, а сначала создавать минимально жизнеспособные управленческие контуры. Такой контур должен включать как минимум: коммерческий объект, единое определение, владельца, данные, KPI, сигнал, права принятия решений и регулярный управленческий обзор.

Третий принцип — масштабировать только доказанное изменение:

Пилот → Подтверждение → Стандарт → Масштабирование.

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

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

21.1. От методологии к работающей коммерческой системе

Методология отвечает на вопрос, как система должна быть устроена. Реальная компания отвечает на другой вопрос: как эта система должна работать каждый день. Между этими уровнями находится внедрение.

Методология может быть логически безупречной и при этом не менять поведение сотрудников. Можно описать MQL Standard, назначить Process Owner, настроить CRM и построить дашборд, но если сотрудники продолжают квалифицировать лиды по старым правилам, руководители не используют KPI для решений, а handoff остаётся неформальным, архитектура существует только на бумаге.

Поэтому важно различать результаты трёх уровней:

Delivery → Adoption → Business Effect.

Delivery показывает, создано ли решение.
Adoption показывает, стало ли оно фактически использоваться.
Business Effect показывает, изменился ли коммерческий результат.

Проект может быть завершён на 100%, но adoption может оставаться низким. В этом случае трансформация не состоялась.

Таблица 409. Проект внедрения и трансформация коммерческой системы

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

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

Формула 352. Уровень принятия нового стандарта

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

Ключевой объект контроля — не количество обученных сотрудников, а доля реальных коммерческих объектов, прошедших новый процесс.

Работающая система должна воспроизводить цикл:

Объект → Состояние → Сигнал → Решение → Действие → Результат → Обучение.

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

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

21.2. Диагностика текущего состояния

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

Например, симптомом может быть низкая конверсия MQL в SQL. Причины могут быть разными: неясное определение MQL, слабая маршрутизация, перегруженный WIP, отсутствие SLA, некорректная приёмка, плохие данные. Если бороться только с симптомом, можно улучшить показатель на короткий период, но система вернётся к прежнему состоянию.

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

Формула 353. Разрыв трансформации

Для измеримых показателей разрыв может быть количественным. Для организационных конструкций — концептуальным: например, отсутствие Process Owner, Customer ID или Deal Handoff.

Таблица 410. Диагностическая карта коммерческой системы

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

Диагностика должна охватывать всю цепочку, а не только маркетинг или продажи. В LLM проверяются MQL Standard, дедупликация, маршрутизация, SLA, WIP, qualification, recycling и SQL Standard. В Sales Operations — Opportunity, стадии, ageing, pipeline, прогноз, экономика, скидки и Deal Handoff. В Owner Management — OWNER_ACCEPTED, onboarding, сервис, F&I, удержание и повторный спрос. В данных — ID, определения, timestamps, источники и качество. В управлении — владельцы процессов, объектов, данных и решений.

Таблица 411. Текущее состояние → разрыв → целевое состояние

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

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

Результат диагностики должен связывать:

Наблюдение → Причина → Архитектурный разрыв → Коммерческая потеря → Экономическое последствие.

21.3. Стратегические цели трансформации

После диагностики организация должна определить не список проектов, а стратегические цели трансформации. Цель — это требуемое изменение результата, а не инструмент.

Формулировка «внедрить CRM» не является стратегической целью. Целью может быть сокращение коммерческих потерь между MQL и Deal, рост доли повторного спроса, повышение Contribution, ускорение коммерческого цикла или снижение зависимости собственника от ручного контроля.

Полезная логика:

Стратегическая цель → Коммерческий результат → Архитектурное изменение.

У каждой цели должна быть причинная гипотеза. Например: если компания формализует Accepted SQL и уменьшит потери на handoff между LLM и Sales Operations, то качество Opportunity portfolio должно стать более устойчивым. Но такая связь остаётся гипотезой до проверки данными.

Цели удобно разделять на три уровня:

1. Стратегический результат — что должно измениться для бизнеса в целом.
2. Коммерческий результат — какая часть цепочки должна работать иначе.
3. Архитектурный результат — какие объекты, процессы, данные и роли необходимо изменить.

Трансформация должна учитывать три пула спроса: новый, накопленный и повторный. Поэтому цели не должны сводиться только к увеличению нового lead flow. Иногда наибольший эффект находится в уже накопленном спросе или в эпизодах владения.

Важно различать рост и устранение потерь. Дополнительная ценность может возникать из новых возможностей или из сокращения уже существующих потерь. В зрелых компаниях второй источник часто не менее значим.

Цели должны иметь временной горизонт и ограничивающие показатели. Например, рост конверсии нельзя считать успешным, если одновременно резко падает маржа, растут скидки, отмены или cycle time.

Финальная связка раздела:

Цель → Результат → Механизм → Архитектура → Инициатива.

Только после этого можно проектировать To Be.

21.4. Проектирование целевой архитектуры

Целевая архитектура не должна быть красивой картой функций. Она должна описывать реальный operating mechanism и отвечать на вопросы: что является объектом, в каком состоянии он находится, кто им владеет, какие данные его описывают, какой сигнал требует решения и кто вправе это решение принять.

Целевой дизайн должен включать следующие слои:

• коммерческий поток;
• объекты;
• состояния и переходы;
• handoff;
• роли и владение;
• права принятия решений;
• данные;
• экономику;
• KPI;
• технологическую поддержку.

Общая модель handoff:

Handoff = Object + Acceptance Criteria + Responsibility + Time.

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

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

Коммерческий объект + Определение + Владелец + Данные + KPI + Сигнал + Права принятия решений + Регулярный управленческий обзор.

Если хотя бы один элемент отсутствует, управляемость остаётся неполной. Например, MQL может быть хорошо определён, но без владельца сигнала отклонение в MQL→SQL будет лишь наблюдаться. Или Process Owner может существовать, но без данных и Decision Rights его роль будет номинальной.

Технология должна следовать за архитектурой:

Процесс → Данные → Решение → Технология.

Автоматизация неопределённого процесса лишь ускоряет воспроизводство неопределённости.

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

Целевая архитектура не должна смешиваться с планом перехода. To Be описывает, как должна работать система. Архитектура перехода — как компания туда попадёт.

21.5. Архитектура спроса: новый, накопленный и повторный спрос

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

1. Новый спрос — возникает на рынке и проходит MVC.
2. Накопленный спрос — уже был создан или частично оплачен, но не реализован.
3. Повторный спрос — возникает внутри Ownership Episode и преобразуется в New Demand Episode.

Формула 354. Доступный коммерческий спрос

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

Это управленческая модель, а не простая арифметическая сумма записей. Требуются Customer ID, Demand Episode и дедупликация.

Накопленный спрос особенно важен. Closed Lead, Lost Opportunity или deferred contact не всегда означают уничтоженный спрос. Часть объектов может быть recoverable и должна переходить в nurture, recycling или reactivation. Поэтому:

Closed ≠ Demand Destroyed.

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

Таблица 412. Три источника коммерческого спроса

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

Customer не равен Demand Episode. Один человек может иметь несколько эпизодов спроса во времени и по разным продуктам. Именно поэтому базы контактов недостаточно — нужна архитектура спроса.

Практическая последовательность внедрения:

Demand Definition → Demand Episode → Identity → State → Owner → Process → KPI → Automation.

21.6. Внедрение цепочка создания маркетинговой ценности

цепочка создания маркетинговой ценности (MVC) реализуется как единый поток из четырёх уровней:

Создание бренда → Стимулирование спроса → Коммерческое присутствие → Привлечение лидов → MQL.

Четыре уровня не должны превращаться в четыре изолированных подразделения. Они образуют одну систему преобразования спроса.

На каждом уровне необходимо определить: объект, вход, действие, выход, данные, KPI, владельца и handoff.

Таблица 413. Карточка внедрения MVC

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

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

Важно сохранять принцип:

Тип обращения — не этап воронки, а способ входа клиента в коммерческую систему.

Lead Acquisition должен различать Interaction, Contact, Lead и MQL. Несколько взаимодействий не должны автоматически создавать несколько уникальных лидов.

Ключевая граница:

MVC заканчивается на MQL.

Дальше начинается LLM.

21.7. Внедрение Lead Lifecycle Management

Lead Lifecycle Management начинается после сформированного MQL и заканчивается принятым SQL:

MQL → LLM → SQL → Accepted SQL.

LLM — это не «обработка лидов» и не работа контактного центра как подразделения. Это управление жизненным циклом коммерческого объекта.

В минимальный LLM-контур входят:

• MQL Standard;
• правило приёмки;
• дедупликация;
• маршрутизация;
• SLA;
• WIP;
• квалификация;
• nurture;
• recycling;
• loss architecture;
• SQL Standard;
• Accepted SQL.

Таблица 414. Карточка внедрения LLM

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

SLA должен измеряться не только средним временем. Полезны медианы, перцентили, доля объектов внутри SLA и overdue population. WIP необходимо контролировать как поток: если входящий объём систематически превышает пропускную способность, незавершённая работа растёт.

Для передачи между LLM и Sales Operations используется показатель успешности handoff.

Формула 355. Доля успешных передач

Низкий HSR означает, что формальная передача существует, но следующий контур не принимает объект.

Nurture и recycling нельзя смешивать с terminal loss. Потенциально восстанавливаемые объекты становятся частью накопленного спроса.

21.8. Внедрение Sales Operations

Sales Operations начинается после принятого SQL:

Accepted SQL → Opportunity → Commercial Progression → Deal → Deal Handoff.

Главным управленческим объектом становится не активность продавца, а Opportunity — конкретная коммерческая возможность.

Практическое определение Opportunity должно связывать Customer, Demand Episode, Commercial Intent, Owner и Next Action. Стадия должна отражать реальное коммерческое продвижение, а переход — подтверждаться evidence и exit criteria.

Таблица 415. Карточка внедрения Sales Operations

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

Каждая активная Opportunity должна иметь следующее действие и срок. Pipeline — это не все открытые записи CRM, а управляемый портфель коммерческих возможностей.

Прогноз не равен плану. План задаёт желаемое состояние; forecast показывает ожидаемый результат на основании текущего портфеля и фактического продвижения.

Экономика сделки должна включать Contribution, маржу и контроль скидок. Рост конверсии без guardrails может ухудшить ценность бизнеса.

Критически важно:

Deal ≠ OWNER_ACCEPTED.

Между ними существует Deal Handoff — формальная передача данных, обязательств и контекста в контур Owner Management.

21.9. Внедрение Owner Management

Deal не является конечной точкой коммерческой системы. После завершения сделки должен возникнуть новый управленческий объект — Ownership Episode.

Нормативная цепочка:

Deal → Deal Handoff → OWNER_ACCEPTED → Ownership Episode.

OWNER_ACCEPTED означает, что клиент, продукт и сделка идентифицированы, контекст передан, а ответственность за дальнейший lifecycle принята.

Основной объект Owner Management:

Identity – Product – Ownership Episode.

Таблица 416. Карточка внедрения Owner Management

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

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

Replacement Signal не является SQL. Нельзя использовать упрощение Owner → SQL или Owner → Opportunity. Корректный путь:

Ownership Episode → Demand Signal → New Demand Episode.

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

21.10. Customer ID и единая архитектура данных

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

Базовый принцип:

Commercial Object → Identifier → Data → System.

Customer ID — устойчивый внутренний идентификатор клиента. Телефон и email являются атрибутами и могут изменяться.

Таблица 417. Сквозная архитектура идентификаторов

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

Нормативная цепочка:

Customer ID → Demand Episode ID → Lead ID → Opportunity ID → Deal ID → Product ID + Ownership Episode ID.

Для каждого объекта требуется авторитетный источник данных и Data Owner. Data Owner отвечает за бизнес-смысл определения, допустимые значения, качество и разрешение конфликтов. ИТ обеспечивает хранение и техническую передачу, но не должно единолично определять бизнес-смысл коммерческих объектов.

Особое значение имеет история событий: object + state + timestamp. Только так можно анализировать реальные переходы и строить когорты.

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

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

21.11. Роли, владельцы и новая организационная модель

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

Традиционная функциональная структура распределяет ответственность по подразделениям: маркетинг, контактный центр, продажи, сервис, ИТ, финансы. Но коммерческий объект проходит через несколько функций. Если никто не отвечает за поток целиком, на стыках возникает структурная неопределённость.

Поэтому необходим переход:

Функциональная ответственность → Сквозное владение.

Таблица 418. Роли трансформации

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

Функциональный руководитель отвечает за capability: людей, компетенции, ресурсы и качество исполнения. Process Owner отвечает за flow и end-to-end результат. Эти роли дополняют друг друга.

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

Object Owner отвечает за определение коммерческого объекта, допустимые состояния и критерии перехода. Data Owner — за смысл и качество данных. Decision Owner — за решение после управленческого сигнала.

Transformation Office — временная конструкция. Его функции: архитектурная целостность, зависимости, roadmap, контроль решений, экономический эффект и эскалация. Целевое состояние:

Офис трансформации → Постоянные владельцы процессов.

21.12. Экономика трансформации и бюджет

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

Ключевой вопрос — не только «сколько стоит проект», но и какую дополнительную ценность должна создать изменённая архитектура.

Цепочка:

Investment → Architectural Change → Behavioral Change → Commercial Effect → Economic Value.

Первый элемент экономики — baseline, или базовый уровень. Он фиксирует исходное состояние конкретного объекта изменений.

Формула 356. Дополнительная экономическая ценность

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

Таблица 419. Run the Business и Change the Business

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

Не каждая инициатива должна иметь самостоятельный ROI. Customer ID, Data Governance или Process Ownership могут быть обеспечивающими capability. Их эффект проявляется через последующие коммерческие изменения.

Для инициатив с достаточно измеримой причинной связью используется:

Формула 357. ROI трансформации

Приоритизация не должна сводиться только к ROI. Также важны архитектурная критичность, зависимости, срочность, риск и сложность.

Нужно учитывать Cost of Inaction — стоимость сохранения текущих потерь. Нередко отказ от изменений дороже самого проекта.

21.13. KPI трансформации и Transformation Control

Бизнес-KPI показывают результат коммерческой системы. Transformation KPI показывают, изменилась ли сама система.

Нужно одновременно видеть пять уровней:

Delivery → Adoption → Process Effect → Business Effect → Economic Effect.

Таблица 420. Business KPI и Transformation KPI

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

Сам dashboard ничего не меняет. Нужен управленческий цикл:

KPI → Control Corridor → Signal → Decision → Change → Evidence.

Каждый критический сигнал должен иметь Decision Owner. Красный статус не является провалом — провалом является ситуация, когда отклонение не замечено или не приводит к решению.

Таблица 421. Профиль состояния трансформации

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

Лучше видеть профиль, чем искусственно сворачивать всё в один maturity score.

21.14. Дорожная карта трансформации на 12 месяцев

Дорожная карта должна управлять не календарём задач, а последовательностью изменения коммерческой системы.

Общий принцип:

Последовательность + Параллельность + Зависимости.

Таблица 422. Дорожная карта трансформации на 12 месяцев

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

Сроки иллюстративны. Последовательность определяется архитектурной готовностью, а не только датой.

На этапе 0 формируются baseline, definitions, владельцы и pilot priorities. На этапе 1 стабилизируются критические handoff, SLA, WIP и данные текущего потока. На этапе 2 интегрируются MVC, LLM и Sales Operations. На этапе 3 замыкается Deal Handoff → OWNER_ACCEPTED → Ownership Episode. На этапе 4 развиваются прогнозирование, capacity management, automation и causal analytics.

Roadmap включает несколько параллельных потоков: коммерческую архитектуру, данные, владельцев, KPI, технологии и adoption.

Таблица 423. Портфель трансформационных инициатив

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

Transformation Backlog — не task list. Он является портфелем архитектурных изменений.

Масштабирование строится по принципу:

Пилот → Подтверждение → Стандарт → Масштабирование.

Таблица 424. Критерии пилотирования и масштабирования

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

Нельзя масштабировать дефект. Если пилот выявил слабую data quality, неустойчивый KPI или отсутствие adoption, сначала необходимо скорректировать архитектуру.

21.15. От проекта трансформации к постоянно развивающейся системе

Transformation Project по определению временный. Operating System должна работать постоянно. Поэтому конечная цель программы — сделать специальный режим трансформации ненужным.

После завершения основной программы должны остаться Process Owners, Object Owners, Data Owners, Decision Owners, KPI, Decision Rights, management cadence и архитектура данных.

Критерий зрелости можно сформулировать просто:

Что произойдёт, если завтра убрать проектную команду?

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

Зрелая система должна уметь не только соблюдать стандарт, но и пересматривать его на основании данных.

Цикл развития:

Commercial Reality → Signal → Decision → Change → Result → Learning → New Standard.

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

Непрерывное совершенствование не равно постоянной нестабильности. Целевая модель:

Stable Standard + Controlled Learning.

Изменение должно проходить через гипотезу, пилот, evidence и решение.

По мере стабилизации Transformation Review должен переходить в обычный Operating Review, а часть Transformation KPI — исчезать или превращаться в Process KPI.

Технологии также должны войти в нормальный цикл: коммерческая потребность → изменение процесса → изменение технологии. AI может усиливать прогнозирование, anomaly detection, prioritization и Next Best Action, но не заменяет владельца процесса и Decision Rights.

Финально коммерческая система состоит из двух взаимосвязанных петель.

Петля создания ценности:

Demand → MQL → SQL → Opportunity → Deal → Ownership → New Demand.

Петля развития системы:

Reality → Signal → Decision → Change → Result → Learning → New Standard.

Итоговые выводы главы

1. Трансформация начинается с диагностики, а не с технологии.
2. Стратегическая цель предшествует перечню проектов.
3. Целевая архитектура предшествует дорожной карте.
4. Между As Is и To Be всегда существует архитектура перехода.
5. Нельзя автоматизировать неопределённый процесс.
6. Архитектурные зависимости определяют последовательность внедрения.
7. Нельзя масштабировать непроверенный процесс.
8. Владение процессом является необходимым условием устойчивости.
9. Transformation KPI не заменяют бизнес-результат.
10. Каждая существенная инициатива должна иметь экономическую гипотезу.
11. Офис трансформации является временной конструкцией.
12. Конечная цель трансформации — не завершить проект, а создать систему, способную развивать себя дальше.

Финальный критерий:

New Standard → Adoption → Stable Operation → Economic Result → Learning → Next Improvement.

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

Цель трансформации — не закончить проект изменений, а создать систему, которая способна дальше изменять себя сама.

Реестр формул

1. Формула 353. Gap = Target State - Current State.
2. Формула 354. Demand_available = Demand_new + Demand_accumulated + Demand_repeat.
3. Формула 352. Adoption Rate = Objects processed under new standard / Eligible objects.
4. Формула 355. HSR = Accepted Handoffs / Total Handoffs.
5. Формула 356. Incremental Value = Economic Result_after - Baseline.
6. Формула 357. Transformation ROI = (Incremental Value - Transformation Cost) / Transformation Cost.

Реестр таблиц

1. Таблица 409. Проект внедрения и трансформация коммерческой системы.
2. Таблица 410. Диагностическая карта коммерческой системы.
3. Таблица 411. Текущее состояние → разрыв → целевое состояние.
4. Таблица 412. Три источника коммерческого спроса.
5. Таблица 413. Карточка внедрения MVC.
6. Таблица 414. Карточка внедрения LLM.
7. Таблица 415. Карточка внедрения Sales Operations.
8. Таблица 416. Карточка внедрения Owner Management.
9. Таблица 417. Сквозная архитектура идентификаторов.
10. Таблица 418. Роли трансформации.
11. Таблица 419. Run the Business и Change the Business.
12. Таблица 420. Business KPI и Transformation KPI.
13. Таблица 422. Дорожная карта трансформации на 12 месяцев.
14. Таблица 423. Портфель трансформационных инициатив.
15. Таблица 424. Критерии пилотирования и масштабирования.
16. Таблица 421. Профиль состояния трансформации.