Глава 19. Организационная трансформация маркетинговой системы

Вводный аппарат

В предыдущих главах была последовательно построена архитектура коммерческого управления маркетингом. Глава 17 определила экономическую основу системы: инвестиции, затраты, вклад в результат (Contribution), дополнительную ценность (Incremental Value), экономику единицы, клиента и мощности, риск-скорректированную ценность, технологическую и портфельную экономику. Глава 18 сформировала аналитическую архитектуру, связывающую коммерческую реальность с управленческим решением:

Коммерческая реальность → Данные и наблюдения → Доказательства → Аналитика → Решение → Действие → Результат → Обучение.

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

Организационный разрыв

Во многих компаниях маркетинг уже обладает значительной частью необходимых инструментов: стратегией, бюджетом, CRM, аналитикой, рекламными платформами, контакт-центром, отделом продаж, BI и регламентами. Однако наличие этих элементов ещё не означает наличия целостной operating model.

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

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

между хорошо работающими функциями отсутствует архитектура совместной работы.

Что понимается под организационной трансформацией

Под организационной трансформацией маркетинговой системы будем понимать:

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

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

Поэтому:

организационная структура является только одной из форм закрепления operating model, но не самой operating model.

Нормативная архитектура MOS

MOS сохраняет только три уровня:

Marketing Strategy — стратегия маркетинга;
Marketing Governance — система правил, стандартов, полномочий и механизмов управленческого контроля;
Marketing Operations — операционное исполнение.

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

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

Организационная архитектура главы строится вокруг полной коммерческой цепочки:

Market → Demand → цепочка создания маркетинговой ценности → MQL → Lead Lifecycle Management → SQL → Sales Operations → Opportunity → Commercial Progression → Deal → Deal Handoff → OWNER_ACCEPTED → Ownership Episode → New Demand Episode.

цепочка создания маркетинговой ценности содержит только четыре уровня: Brand Creation, Demand Stimulation, Commercial Presence и Lead Acquisition. Его результатом является MQL. Lead Lifecycle Management преобразует MQL → SQL. Sales Operations начинается только после принятого SQL и обеспечивает дальнейшее коммерческое продвижение: SQL → Opportunity → Commercial Progression → Deal → Deal Handoff → OWNER_ACCEPTED.

При этом:

Deal не равен OWNER_ACCEPTED.

Управление владением начинается только после события OWNER_ACCEPTED. Возникновение повторного, дополнительного, replacement- или referral-спроса создаёт уже новый Demand Episode.

Центральная логика главы

Функциональная фрагментация → Единая архитектура коммерческих объектов → Сквозные процессы → Владение процессами и объектами → Права принятия решений → Управляемые межфункциональные передачи → Единые данные и аналитика → Технологическая поддержка → Организационные способности → Управленческий ритм → Обучение и изменение стандарта.

Место главы 19 в архитектуре книги

Глава 17 отвечает: какую экономическую ценность создаёт система?

Глава 18: как получить доказательство, объяснение и прогноз?

Глава 19: кто и каким образом должен использовать эти доказательства, принимать решения и обеспечивать исполнение?

Следующая глава 20 будет отвечать на вопрос: какими показателями, целями и контрольными коридорами должна управляться созданная система?

19.1. От организационной структуры к операционной модели

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

Два бизнеса могут иметь практически одинаковые организационные схемы и принципиально разные operating models. В одном случае решение принимается непосредственно владельцем процесса. В другом тот же вопрос проходит несколько согласований. В одной компании коммерческий объект имеет однозначного владельца. В другой после передачи между подразделениями на определённый период фактически остаётся ничейным.

Оргструктура показывает, где находятся люди. Operating model показывает, как организация создаёт результат.

Таблица 389. Организационная структура и операционная модель

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

Критерий	Организационная структура	Операционная модель
Главный вопрос	Кто кому подчиняется?	Как организация создаёт и управляет результатом?
Основная единица	Подразделение / должность	Процесс / объект / решение
Логика	Вертикальная	Сквозная
Ответственность	Внутри функции	За результат через функции
Основные связи	Административная подчинённость	Handoff, права решений, SLA
Данные	Часто сгруппированы по функциям	Организованы вокруг lifecycle объекта
Основной результат дизайна	Оргсхема	Воспроизводимый способ работы

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

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

Таблица 390. Функциональная и процессная ответственность

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

Измерение	Функциональная ответственность	Процессная ответственность
Основной объект	Функция	Сквозной процесс
Фокус	Люди, ресурсы, expertise	Flow и outcome
Административное управление	Да	Не обязательно
Бюджет	Обычно внутри функции	Может влиять, но не обязан владеть
Основная зона контроля	Работа подразделения	Межфункциональные границы
Подтверждённая передача	Участвует	Обеспечивает целостность
Риск	Локальная оптимизация	Ответственность без достаточных полномочий

Корректная последовательность проектирования: коммерческие объекты → процессы → ownership → права принятия решений → handoff → данные → технологии → capability → управленческий ритм → организационная структура.

19.2. Целевая организационная архитектура MOS

MOS определяет механизм, посредством которого маркетинг формирует стратегический выбор, устанавливает правила и организует исполнение. Его три уровня — Marketing Strategy, Marketing Governance и Marketing Operations — не являются организационными подразделениями.

Marketing Strategy отвечает прежде всего на вопрос: где и каким образом маркетинг должен создавать экономическую ценность?

Marketing Governance преобразует стратегический выбор в управляемую систему правил. Здесь определяются стандарты, определения, Decision Rights, ownership, ресурсные ограничения, правила данных, эскалация и change governance.

Marketing Operations обеспечивает фактическое выполнение кампаний, коммуникаций, lead acquisition, обработки коммерческих объектов и управленческих действий в пределах заданных правил.

Через все три уровня проходят данные, аналитика, технологии, экономика, люди, capability и transformation management. Они являются сквозными способностями MOS, а не отдельными уровнями.

Целевая логика замкнута: Marketing Strategy → Marketing Governance → Marketing Operations → Commercial Reality → Evidence & Analytics → Governance Decision → при необходимости Strategy Update.

В распределённом холдинге часть Governance может быть централизована на уровне группы компаний: MQL Standard, SQL Standard, классификация источников, архитектура данных, основные CRM-состояния. Исполнение при этом остаётся в кластерах, дилерских центрах, контакт-центре и продажах.

единый стандарт не требует единого места исполнения.

19.3. Владение процессами и коммерческими объектами

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

Необходимо различать функционального владельца (Functional Owner), владельца процесса (Process Owner) и владельца объекта (Object Owner).

Таблица 391. Типы владельцев

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

Тип владельца	Объект	Основная ответственность	Не является автоматически
Functional Owner	Функция	Люди, бюджет, capability	Ответственный за процесс
Ответственный за процесс	Сквозной процесс	Flow, handoff, ограничения, outcome	Руководителем всех участников
Object Owner	Конкретный объект	Следующее действие и состояние	Ответственный за процесс
Ответственный за данные	Данные	Смысл и качество	Analyst / Decision Owner
Decision Owner	Решение	Выбор и последствия	Ответственный за процесс
Technology Product Owner	Технологический продукт	Business value и развитие	Technical Owner

Functional Owner отвечает за способность функции выполнять свою работу. Process Owner отвечает за целостность сквозного процесса и его outcome через функциональные границы. Object Owner отвечает за конкретный коммерческий объект в его текущем состоянии.

Переход ownership должен происходить не в результате неформальной договорённости, а в результате определённого события. Например, MQL_SUBMITTED ≠ MQL_ACCEPTED.

Для каждого состояния полного коммерческого потока должен существовать однозначный operational owner. Process Owner должен видеть не только индивидуальные объекты, но и WIP, unassigned objects, waiting time, backlog и capacity.

19.4. Права принятия решений и архитектура ответственности

Назначение владельца процесса или объекта само по себе не создаёт управляемость. Следующим слоем operating model является архитектура прав принятия решений (Decision Rights Architecture).

Responsibility — обязанность выполнить действие. Accountability — ответственность за итоговый результат. Authority — полномочие принимать решения, изменять правила или распоряжаться ресурсами в пределах установленной области.

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

ответственность за outcome должна сопровождаться достаточными полномочиями для воздействия на его ключевые причины.

Для каждого существенного класса решений необходимо определить Decision Owner. Решение как процесс выглядит так: Signal → Data → Interpretation → Proposal → Decision → Execution → Control → Learning.

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

Таблица 392. Архитектура прав принятия решений

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

Элемент	Контрольный вопрос
Decision Domain	Какие решения входят в зону роли?
Decision Owner	Кто принимает окончательное решение?
Evidence Owner	Кто обеспечивает доказательство?
Proposal Owner	Кто формирует предложение?
Execution Owner	Кто исполняет решение?
Authority Limit	Где заканчиваются полномочия?
Time Window	В какой срок решение должно быть принято?
Escalation Path	Когда и куда передаётся вопрос?
Outcome Review	Кто проверяет результат решения?

Decision Reaction Delay повторно в главе 19 не определяется; используется соответствующая формула главы 18.

19.5. Управление межфункциональной передачей

Под межфункциональной передачей будем понимать формализованный переход operational ownership коммерческого объекта от одного владельца другому после выполнения установленного стандарта приёмки.

Критически важно: submission не означает acceptance.

Таблица 393. Стандарт межфункциональной передачи

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

Элемент	Что должно быть определено
Object	Что передаётся
Состояние	В каком состоянии находится объект
Sending Owner	Кто владеет до передачи
Readiness Standard	Когда объект готов к handoff
Minimum Data	Какие данные обязательны
Submission Event	Когда объект направлен на приёмку
Acceptance Criteria	Когда объект должен быть принят
Rejection Criteria	Когда допустим отказ
Receiving Owner	Кто получает ownership
Acceptance SLA	Время на решение о принятии
Action SLA	Время до первого требуемого действия
Return Reason	Почему объект возвращён
Rework Rule	Как исправляется недостаток
Escalation	Когда вопрос выходит за локальный уровень

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

Таблица 394. Типы Handoff Loss

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

Тип	Механизм	Возможный результат
Object Loss	Объект остаётся без владельца	Процесс прекращается
Time Loss	Длительное ожидание	Падает вероятность следующего перехода
Data Loss	Контекст передан неполно	Повторная квалификация
State Error	Неверное состояние объекта	Ошибочная маршрутизация
Доработка	Возврат на предыдущий этап	Рост Cycle Time
Intent Loss	Реакция слишком поздняя	Снижение коммерческой вероятности
Attribution Loss	Теряется история источника	Ошибка оценки маркетинга
Capacity Loss	Получатель перегружен	Очередь и нарушение SLA

Формула 341. Handoff Loss Rate

math-0430

Корректный rejection объекта, не соответствующего Acceptance Standard, не является автоматически организационной потерей.

Финальная sales boundary должна сохранять последовательность: Opportunity → Commercial Progression → Deal → Deal Handoff → OWNER_ACCEPTED.

19.6. Организационное трение и локальная оптимизация

Под Organizational Friction — организационным трением — будем понимать дополнительное время, работу и управленческие усилия, возникающие из-за несовершенной координации процессов, ответственности, данных, решений и технологий.

Таблица 395. Типы организационного трения

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

Тип	Проявление	Возможная причина
Waiting	Объект ждёт действия	Queue / unclear owner
Доработка	Работа выполняется повторно	Плохой handoff
Duplicate Approval	Решение согласуется несколько раз	Неясные Decision Rights
KPI Conflict	Функции оптимизируют разные outcomes	Несогласованные цели
Data Friction	Разные версии показателя	Нет Data Governance
Technology Friction	Ручной перенос данных	Legacy / integrations
Escalation Friction	Всё уходит выше	Недостаток authority
Capacity Friction	Bottleneck на одном участке	Несогласованная мощность
Standard Friction	Разные локальные правила	Нет единого Governance

Функция может улучшать собственный показатель и ухудшать общий outcome. Типовая последовательность: Functional Boundary → Local Metric → Local Accountability → Rational Local Behaviour → Negative External Effect → System Loss.

Желательное для системы поведение должно быть рациональным для её участников. Авторская концептуальная модель:

Поведение = Роль × Полномочия × Метрики × Инструменты × Управленческий контекст.

Это не математическое тождество.

Ручной контроль способен временно компенсировать дефекты, но часто скрывает слабую operating model.

19.7. Управленческий ритм и архитектура решений

Под управленческим ритмом (Management Cadence) будем понимать повторяющуюся во времени систему наблюдения, обсуждения, принятия решений и контроля результата на разных горизонтах управления.

Основной принцип: управленческая встреча существует ради решения, а не ради передачи информации.

Таблица 396. Управленческий ритм

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

Горизонт	Объект управления	Главный вопрос	Тип решений
Ежедневный	Exceptions, WIP, SLA, capacity	Что требует реакции сейчас?	Операционные
Еженедельный	Flow, conversion, cohorts, forecast	Где изменился процесс и почему?	Тактические
Ежемесячный	Экономика, ресурсы, constraints	Что системно влияет на результат?	Governance / ресурсные
Ежеквартальный	Strategy, standards, portfolio	Что изменить в архитектуре?	Стратегические

Таблица 397. Типы управленческих встреч

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

Формат	Основной объект	Требуемый результат
Daily Exception Review	Критические исключения	Немедленное действие
Weekly Flow Review	Сквозной коммерческий поток	Тактическое решение
Monthly Business Review	Экономика и ограничения	Ресурсное / Governance-решение
Quarterly Architecture Review	Стратегия и operating model	Архитектурное изменение
Операционный обзор собственника	Системные вопросы высокого уровня	Решение собственника / CEO

Owner Operating Review — авторская управленческая конструкция. Он не должен превращаться в последовательный отчёт директоров функций. Его объект — системные отклонения, ограничения, forecasts, риски и решения, требующие authority собственника или CEO.

19.8. Организация данных, аналитики и технологий

Современная operating model не может существовать отдельно от данных и технологий. Но сама по себе цифровизация не создаёт управляемость.

Нельзя начинать проектирование data architecture с вопроса: какие поля уже есть в CRM? Сначала необходимо определить коммерческий объект, его состояния, критические события, ownership, handoff и решения, которые должны приниматься.

Process → Object → State → Event → Data → Evidence → Decision.

Таблица 398. Роли данных, аналитики и технологий

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

Роль	Основной объект	Главная ответственность	Не является автоматически
Ответственный за данные	Бизнес-данные	Смысл, определение, качество	Аналитиком
Data Producer	Событие / запись	Корректное создание данных	Владельцем стандарта
Специалист по качеству данных	Качество данных	Соблюдение правил и контроль	Business Owner
Analyst	Подтверждающие данные	Measurement, diagnosis, forecast	Ответственный за процесс
Ответственный за процесс	Процесс	Flow и outcome	Ответственный за данные
Decision Owner	Решение	Выбор и последствия	Analyst
Technology Product Owner	Технологический продукт	Business value и развитие	Technical Owner
Technical Owner	Платформа	Архитектура, стабильность, безопасность	Business Owner

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

Качество данных является результатом совместной работы:

Process + Standard + Ownership + Technology + Control.

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

Теневая аналитика — локальные Excel, собственные выгрузки, персональные формулы и параллельные dashboard — может временно компенсировать недостаток официальной системы, но в зрелой operating model создаёт несколько версий истины, rework и Analytical Debt.

Для ключевых технологий необходимы Business Owner, Technology Product Owner, Technical Owner, SLA и change governance. Технологический backlog должен быть связан с бизнес-процессом и ожидаемым outcome.

19.9. Архитектура организационных способностей и развитие компетенций

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

Под capability понимается:

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

Marketing Transformation Capability Map

Карта включает восемь основных классов способностей:

стратегическую;
Governance;
операционную;
аналитическую;
экономическую;
технологическую;
трансформационную;
обучающую.

Таблица 399. Карта организационных способностей

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

Capability	Что организация должна уметь	Признак дефицита
Стратегическая	Делать осознанные market / portfolio choices	Стратегия сводится к плану активностей
Система управленческих решений	Создавать и изменять rules и standards	Все исключения решаются вручную
Операционная	Стабильно исполнять процесс	Высокая вариативность результата
Аналитическая	Measure, diagnose, forecast	Много отчётности, мало решений
Экономическая	Оценивать Contribution и incremental value	Доминируют локальные метрики
Технологическая	Развивать системы от process value	IT получает несвязанный request backlog
Трансформационная	Управлять переходом между состояниями	Много проектов без единой архитектуры
Обучающая	Превращать evidence в Standard Update	Ошибки регулярно повторяются

Таблица 400. Capability Gap

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

Capability	Текущее состояние	Целевое состояние	Разрыв	Механизм развития
Analytics	Отчётность по факту	Diagnosis + Forecast	Нет predictive capability	Data + methodology + practice
Process Management	Управление функциями	Process Ownership	Нет сквозной ответственности	Role + authority
Economics	Контроль расходов	Contribution-based decisions	Нет общей value model	Методология главы 17
Technology	Request-based IT	Product Ownership	Нет business ownership	Technology Product Owner
Learning	Разовые разборы	Standard Update loop	Learning не меняет process	Governance cadence

Training не равен Transformation. Capability существует тогда, когда знание поддержано ролью, authority, инструментом, process и управленческим ритмом.

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

19.10. Проектирование организационной структуры

Организационная структура является одним из результатов проектирования operating model.

После того как определены процессы, коммерческие объекты, ownership, Decision Rights, handoff, data, technology, capabilities и Management Cadence, можно решать, какие функции необходимы, что централизовать, что децентрализовать, где создать Shared Services, сколько нужно уровней управления и где должны находиться ключевые роли.

Таблица 401. Централизация и децентрализация

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

Измерение	Централизация предпочтительнее, когда…	Децентрализация предпочтительнее, когда…
Standards	Требуется единое определение	Нужна локальная адаптация
Expertise	Компетенция редкая	Контекст специфичен
Economics	Высок scale effect	Coordination Cost выше выгоды
Decisions	Высок системный риск	Критична скорость
Technology	Нужна единая architecture	Допустима контролируемая локальная гибкость
Data	Нужна единая семантика	Нужна глубокая local interpretation
Execution	Работа хорошо стандартизируема	Критична proximity to market

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

Shared Service и CoE не являются одним и тем же. Shared Service выполняет работу. CoE создаёт methodology, standards, knowledge и capability.

Ключевая роль должна описываться не только через список обязанностей, а через purpose, owned object / process, outcomes, Decision Rights, interfaces, required evidence и accountability. Такой подход сильнее традиционного job description.

Теневая организационная структура возникает, когда реальная система решений строится через личные договорённости, неформальных лидеров, мессенджеры и ручные эскалации, а формальная оргсхема не отражает фактическую operating model.

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

Commercial Objects → Processes → Ownership → Decision Rights → Handoff → Data → Technology → Capability → Management Cadence → Organizational Structure.

19.11. Архитектура программы трансформации

После определения целевой operating model возникает вопрос: как перейти от текущего состояния к целевому без распада управления и перегрузки организации?

Организационная трансформация должна управляться как:

единая архитектурная программа перехода между двумя состояниями operating model.

Transformation Backlog

Transformation Backlog — авторская конструкция книги: единый управляемый список архитектурных изменений, необходимых для перехода к целевой operating model.

Таблица 402. Transformation Backlog

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

Поле	Содержание
Transformation Item	Какое архитектурное изменение требуется
Problem	Какой разрыв устраняется
Current State	Как работает система сейчас
Target State	Как должна работать
Category	Process / Data / Technology / Role / Governance / Capability / Economics / Measurement
Owner	Кто отвечает за переход
Expected Effect	Что должно измениться
Dependencies	От чего зависит изменение
Подтверждающие данные	Чем подтверждена необходимость
Status	Текущее состояние

Transformation Item должен формулироваться как изменение состояния, а не как активность. Не «провести обучение MQL», а «обеспечить единое применение MQL Standard всеми целевыми подразделениями».

Transformation Portfolio

Transformation Portfolio — совокупность трансформационных инициатив, отобранных к реализации с учётом архитектурной значимости, dependencies, ожидаемого эффекта, риска, ресурсов, management bandwidth и IT capacity.

Таблица 403. Transformation Portfolio

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

Инициатива	Архитектурная значимость	Expected Effect	Dependencies	Resource Load	Риск	Приоритет
Единый MQL Standard	Высокая	Единая квалификация	Базовая	Низкая	Низкий	Высокий
CRM Event History	Высокая	Наблюдаемость lifecycle	Definitions	Средняя	Средний	Высокий
Handoff Governance	Высокая	Снижение потерь	Ownership	Средняя	Средний	Высокий
Прогноз	Высокая	Predictive Control	Event History	Высокая	Средний	После data foundation
Advanced Automation	Средняя	Масштабирование	Stable Process	Высокая	Высокий	После стандартизации

Иллюстративный пример.

Программа ограничивается не только деньгами. Критичны IT Capacity, Management Bandwidth, Change Capacity и Transformation WIP.

19.12. Волны, пилоты и последовательность изменений

Базовый принцип последовательности:

Definitions → Ownership → Handoff → Data Capture → Analytics → Decision Rhythm → Automation → Optimization.

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

Pilot

Пилот — способ проверить гипотезу изменения operating model в ограниченном scope.

Таблица 404. Стандарт пилота

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

Элемент	Содержание
Hypothesis	Какое изменение ожидается
Scope	Где проводится проверка
Исходный уровень	Как система работает до изменения
Intervention	Что именно меняется
Результат	Какой результат наблюдается
Success Criterion	По какому условию пилот признаётся успешным
Observation Period	За какой период оценивается
Решение	Scale / Redesign / Stop

Неуспешный пилот тоже создаёт ценность, если выявляет неверную гипотезу, missing dependency или capability gap и предотвращает дорогой rollout.

Transformation Wave

Transformation Wave — ограниченный пакет взаимосвязанных архитектурных изменений, совместное внедрение которых создаёт новую организационную capability.

Таблица 405. Волна трансформации

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

Волна	Архитектурная цель	Основные изменения	Результат
Wave 1	Управляемый MQL	Standard + Ownership + Handoff + Event Capture	Единый наблюдаемый MQL
Wave 2	Управляемый SQL	SQL Standard + Sales Handoff + Process Ownership	Наблюдаемый MQL → SQL
Wave 3	Сквозная аналитика	Cohorts + Bottleneck + Forecast	Evidence-based management
Wave 4	Decision Architecture	Cadence + Signals + Decision Log	Управляемая реакция
Wave 5	Automation	Routing + Alerts + Automation	Масштабирование стабильного процесса

Иллюстративная последовательность.

Волна не равна проекту. Она объединяет standard, ownership, handoff, data, technology, training и Management Cadence, если именно этот пакет создаёт новый operating capability.

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

Внедрение нового элемента ещё не доказывает изменение operating behaviour.

Implementation ≠ Adoption ≠ Outcome.

Формула 342. Adoption Rate

math-0431

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

Формула 343. Standard Compliance Rate

math-0432

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

Таблица 406. Метрики принятия и результата трансформации

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

Уровень	Что измеряется	Пример
Implementation	Создан ли новый элемент	CRM workflow доступен
Adoption	Используется ли	Доля объектов нового процесса
Compliance	Правильно ли используется	Доля объектов по standard
Process Performance	Изменился ли процесс	Cycle Time / rework
Commercial Outcome	Изменился ли коммерческий результат	Конверсия
Economic Outcome	Создана ли экономическая ценность	Contribution
Transformation Effect	Какая часть эффекта связана с изменением	Дополнительный эффект воздействия
Learning Closure	Изменился ли standard	Standard Update

Формула 344. Transformation Throughput

math-0433

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

Transformation Health Profile

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

Architecture Clarity;
Process Ownership;
Decision Rights;
Handoff Quality;
Data & Technology Readiness;
Capability;
Adoption;
Learning Closure.

Профиль не является maturity score и не должен сводиться к одному числу.

19.14. Институционализация: как изменение становится системой

Adoption означает: новая практика используется.

Institutionalization означает:

организация способна устойчиво воспроизводить её самостоятельно.

Типовая последовательность:

Transformation Project → Implementation → Adoption → Stabilization → Institutionalization → Normal Operating Model.

Таблица 407. Критерии институционализации

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

Измерение	Контрольный вопрос	Возможное доказательство
Process	Новый процесс стал нормативным?	Устойчивое фактическое использование
Ownership	Роли реально работают?	Решения owners
Полномочия по принятию решений	Решения принимаются на целевом уровне?	Журнал решений
Data	Данные формируются устойчиво?	Event History / quality
Technology	Платформа работает как production capability?	SLA / ownership
Management Rhythm	Процесс встроен в управление?	Normal Management Cadence
Capability	Организация работает самостоятельно?	Stable Role Performance
Legacy	Старый процесс выведен?	Retirement Evidence
Performance	Результат стабилен?	Устойчивая процессная динамика
Learning	Система умеет менять standard?	Standard Update

Одним из главных критериев институционализации является закрытие старого процесса.

New Standard Adoption требует Old Standard Retirement.

Если компания одновременно использует новую CRM, старый Excel, новый dashboard, прежний отчёт, новый workflow и сообщения в мессенджере, она фактически поддерживает несколько operating models.

Закрытие трансформации должно быть отдельным Governance decision. Не «прошёл срок проекта», а: достаточно ли evidence, чтобы признать новую практику normal operating model?

19.15. Интегрированная эталонная модель организационной трансформации

Теперь необходимо соединить все элементы главы в единую архитектуру.

Центральная авторская конструкция:

Marketing Operating Model Transformation

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

Модель включает восемь взаимосвязанных слоёв:

Architecture;
Process;
Ownership;
Decision Rights;
Data & Analytics;
Technology;
Capability;
Management Rhythm.

И замыкающий контур: Learning & Standard Update.

Architecture без Process остаётся концепцией. Process без Ownership создаёт ничейные зоны. Ownership без Decision Rights создаёт ответственность без полномочий. Decision Rights без Data создают слепые решения. Data без Process превращаются в отчётность. Technology без Standard автоматизирует хаос. Capability без организационного контекста остаётся индивидуальным знанием. Management Rhythm без Decision Rights превращается в совещания. Система без Learning постепенно устаревает.

Organizational Handoff Architecture

Вторая центральная авторская конструкция:

Object → Sending Owner → Acceptance Standard → Receiving Owner → Decision Rights → Data → SLA → Escalation → Outcome.

Transformation Control Loop

Третий интеграционный контур:

Target State → Transformation Backlog → Transformation Wave → Implementation → Adoption → Outcome → Evidence → Learning → Standard Update → Next Wave.

Три контура интегрированной модели

Контур 1. Коммерческий flow

Контур 2. Управленческий

Commercial Reality → Evidence → Analytics → Decision → Action → Outcome → Learning.

Контур 3. Трансформационный

Target State → Backlog → Wave → Implementation → Adoption → Outcome → Evidence → Learning → Standard Update → Next Wave.

Таблица 408. Интегрированная модель организационной трансформации

А. Слои Marketing Operating Model Transformation

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

Слой	Главный вопрос	Основной объект
Architecture	Что строим?	Target Operating Model
Process	Как движется ценность?	Commercial Flow
Ownership	Кто владеет?	Process / Object
Полномочия по принятию решений	Кто что решает?	Decision Domain
Data & Analytics	Что происходит и почему?	Подтверждающие данные
Technology	Чем поддерживается процесс?	Platform / Workflow
Capability	Умеет ли организация?	Organizational Capability
Management Rhythm	Когда принимаются решения?	Decision Cycle

Б. Сквозной механизм

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

Механизм	Главный вопрос	Основной объект
Подтверждённая передача	Как передаётся объект?	Functional Boundary

В. Контур изменения

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

Элемент	Главный вопрос	Основной объект
Transformation	Как меняется система?	Backlog / Wave
Adoption	Используется ли новое?	Behaviour
Institutionalization	Стало ли новое нормой?	Operating Model
Learning	Как система развивается?	Standard Update

Авторские конструкции главы 19

К центральным авторским конструкциям книги относятся:

Marketing Operating Model Transformation
Organizational Handoff Architecture
Handoff Loss
Organizational Friction
Decision Rights Architecture
Transformation Backlog
Transformation Portfolio
Transformation Wave
Capability Map
Transformation Control Loop
Owner Operating Review
Institutionalization Criteria

Вспомогательными понятиями являются Capability Gap, Capability Debt, Analytical Debt, Shadow Analytics, Shadow Organization, Transparency Cost, Learning Closure, Legacy Retirement и Transformation Closure.

Финальные выводы главы 19

Operating model первична относительно оргструктуры. Сначала проектируются объекты, процессы, ownership, права решений, handoff, данные и capability — затем структура.
Функциональная и процессная ответственность должны сосуществовать. Функции создают компетенции и ресурсы, Process Ownership обеспечивает сквозной outcome.
Каждый критический коммерческий объект должен иметь владельца. Отсутствие owner создаёт ничейные зоны и потери.
Accountability требует Authority. Ответственность без достаточных полномочий превращается в формальность и порождает постоянную эскалацию.
Handoff является самостоятельным объектом Governance. Submitted и Accepted — разные события; межфункциональная граница должна иметь стандарт, данные, SLA и escalation.
Локальная эффективность не гарантирует системный результат. Функция может улучшить собственный KPI и одновременно ухудшить поток, клиентский outcome или Contribution.
Management Cadence превращает evidence в решения. Совещание существует ради решения, а не ради передачи информации.
Данные и технологии должны поддерживать уже определённый процесс. Цифровизация не заменяет architecture, ownership и Governance.
Capability принадлежит организации, а не отдельному человеку. Знание становится capability только тогда, когда встроено в роль, процесс, инструменты, authority и ритм управления.
Implementation ≠ Adoption ≠ Outcome. Внедрение новой системы ещё не доказывает изменения поведения и тем более экономического эффекта.
Institutionalization требует retirement legacy. Новая модель не становится нормой, пока старая продолжает существовать как равноправная альтернатива.
Зрелая operating model должна уметь изменять собственные стандарты через learning. Финальный результат трансформации — не новая структура, а способность организации управляемо изменять саму себя.

Центральный вывод

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

В этот момент:

MOS перестаёт быть архитектурой на бумаге и становится организационной способностью.

Переход к главе 20

После главы 19 определено:

кто и как управляет системой.

Следующий вопрос:

какими показателями эта система должна управляться?

Необходимо определить, что является KPI, а что просто metric; какие показатели имеют target; где нужны control corridors; кто является owner показателя; как связать стратегические, процессные и функциональные показатели; как сочетать leading и lagging indicators; как не превратить KPI в механизм локальной оптимизации.

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