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

Глава 30. Внедрение новой архитектуры маркетинга: от текущей системы к действующей MOS

Введение

К этому моменту архитектура MOS уже определена как сквозная коммерческая система, связывающая рынок, спрос, обращения, коммерческие объекты, продажи, передачу автомобиля, владение, данные, экономику и управление.

Но наличие архитектуры ещё не означает, что она действует.

Между концепцией и работающей системой остаётся главный практический вопрос:

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

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

Поэтому внедрение MOS должно происходить одновременно в двух плоскостях:

управление текущей деятельностью ∥ управление изменением системы.

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

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

Архитектурно её можно представить как:

С п о с о б н о с т ь = П р о ц е с с + П р а в и л о + О т в е т с т в е н н о с т ь + Д а н н ы е + И н с т р у м е н т + К о м п е т е н ц и я + К о н т р о л ь

Это не математическая формула, а схема полноты способности.

Из неё следует ещё один принцип:

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

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

Трансформация не должна начинаться с вопроса «какую CRM нам внедрить?» или «какой отчёт построить?». Правильный вопрос другой:

какое ограничение мешает существующим элементам коммерческой системы работать как единой архитектуре?

Общая логика главы:

Т е к у щ е е   с о с т о я н и е → Д и а г н о с т и к а → О г р а н и ч е н и е → Ц е л е в а я   с п о с о б н о с т ь → Т р а н с ф о р м а ц и о н н ы й   р а з р ы в → И з м е н е н и е → П и л о т → П о д т в е р ж д е н и е → С т а н д а р т → М а с ш т а б и р о в а н и е → С т а б и л и з а ц и я → Н о в о е   о г р а н и ч е н и е

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

Н а б л ю д е н и е → О г р а н и ч е н и е → Г и п о т е з а → И з м е н е н и е → П р о в е р к а → С т а н д а р т → Н о в о е   н а б л ю д е н и е

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

30.1. Почему новую архитектуру нельзя внедрить проектом

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

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

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

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

Проект создаёт результат. Архитектура должна создавать воспроизводимость

Можно завершить проект внедрения CRM. Но нельзя считать сформированной способность управлять LeadID только потому, что система запущена.

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

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

Следовательно, необходимо различать:

П р о е к т н ы й   р е з у л ь т а т

и

И з м е н ё н н у ю   с п о с о б н о с т ь   с и с т е м ы

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

Формальная готовность и фактическое изменение

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

Но реальная работа может оставаться прежней. Менеджеры продолжают использовать параллельные таблицы. Подразделения по-разному понимают лид. Статусы меняются формально. Новые поля CRM заполняются только ради контроля.

Инструменты новые. Поведение системы прежнее.

Результат трансформации — новое устойчивое поведение

Корректный критерий:

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

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

Р е з у л ь т а т   т р а н с ф о р м а ц и и = У с т о й ч и в о   в о с п р о и з в о д и м а я   н о в а я   п р а к т и к а

MOS меняет управленческое поведение

Для менеджера изменение означает не просто появление нового поля в CRM, а то, что активный SQL всегда должен иметь:

В л а д е л е ц + С л е д у ю щ е е   д е й с т в и е + С р о к

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

Проекты остаются частью трансформации

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

какую способность системы он помогает сформировать?

MOS нельзя «установить»

Методологически точнее говорить:

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

Т е к у щ е е   с о с т о я н и е → Ц е л е в о е   с о с т о я н и е → У п р а в л я е м ы й   п е р е х о д → С т а б и л и з а ц и я → Р а з в и т и е

30.2. Точка старта: диагностика фактической системы

Любая трансформация начинается с ответа на вопрос:

как система работает сейчас?

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

Диагностика MOS должна установить, как она работает фактически.

Описанная, наблюдаемая и фактически исполняемая система

Полезно различать три уровня.

Описанная система — регламенты, инструкции, методологии, официальные процессы.

Наблюдаемая система — данные, события, временные метки, CRM, телефония, отчётность.

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

О п и с а н н а я   с и с т е м а ≠ Н а б л ю д а е м а я   с и с т е м а ≠ Ф а к т и ч е с к и   и с п о л н я е м а я   с и с т е м а

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

Традиционный аудит часто оценивает маркетинг, ЦКР, продажи, сервис и аналитику по отдельности. MOS требует смотреть на движение объекта:

О б р а щ е н и е → L e a d I D → M Q L → S Q L → В и з и т → С д е л к а

Проблема может существовать не внутри функции, а между функциями.

Семь контуров диагностики

  1. Объекты — одинаково ли определяются клиент, обращение, LeadID, MQL, SQL, сделка, OwnershipID.
  2. Процессы — где объект ждёт, возвращается, передаётся вручную, теряется.
  3. Ответственность — можно ли определить «кто? что? когда?».
  4. Данные — сохраняются ли идентификаторы, события, история, временные метки.
  5. Экономика — разделяются ли новое привлечение, реактивация и новые циклы существующих клиентов.
  6. Управление — существует ли замкнутый цикл решений.
  7. Автоматизация — что поддерживается системой, а что компенсируется вручную.

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

Д и а г н о с т и ч е с к и й   в ы в о д = Д а н н ы е + Н а б л ю д е н и е + П р о в е р к а   п р о ц е с с а

Агрегированные показатели необходимо дополнять трассировкой реальных LeadID.

Диагностика не должна превращаться в оценку персонала

Последовательность анализа:

С и с т е м а → П р о ц е с с → У с л о в и е → Д е й с т в и е → И с п о л н и т е л ь

а не наоборот.

Таблица 470. Диагностика фактического состояния MOS

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

Контур Что проверяем Типовые признаки разрыва
Объекты единообразие определений разные трактовки LeadID, MQL, SQL
Процессы фактическое движение объектов ручные обходы, возвраты, зависания
Ответственность наличие владельца и следующего действия объект существует, но действие никому не принадлежит
Данные событийность и история перезапись статусов, отсутствие временных меток
Экономика разделение когорт и методик смешение нового привлечения и реактивации
Управление замкнутость цикла решений есть отчёт, но нет действия и проверки
Автоматизация соответствие технологии процессу CRM не поддерживает реальную логику

Итог диагностики — карта фактического состояния. Она ещё не отвечает на вопрос, что исправлять первым.

30.3. Ограничивающий контур как точка приложения изменений

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

Главный вопрос:

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

Именно его будем называть ограничивающим контуром.

Ограничение не равно слабому месту

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

С л а б о е   м е с т о ≠ О г р а н и ч и в а ю щ и й   к о н т у р

Ограничение существует только относительно цели

Ц е л ь → Т р е б у е м ы й   п о т о к → Ф а к т и ч е с к и й   п о т о к → О г р а н и ч е н и е

Нужно анализировать контур, а не отдельный показатель

Если падает MQL → SQL, причина может быть до перехода, внутри перехода или после него.

Поэтому анализируется:

В х о д → П р а в и л о → О б р а б о т к а → П е р е д а ч а → Р е з у л ь т а т

Ограничение проявляется там, где локальное улучшение перестаёт улучшать систему

Например:

L e a d I D ↑→ Н а г р у з к а ↑→ T T C ↑→ К в а л и ф и к а ц и я ↓→ S Q L ≈ c o n s t

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

Место проявления и место причины могут различаться

М е с т о   п р о я в л е н и я ≠ М е с т о   п р и ч и н ы

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

От наблюдения к ограничению

Н а б л ю д е н и е → Г и п о т е з а → П р о в е р к а → О г р а н и ч е н и е

Таблица 471. Карта ограничивающего контура

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

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

30.4. Целевая операционная модель MOS

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

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

как должен работать данный контур после устранения текущего ограничения?

Базовая конструкция целевого состояния

О б ъ е к т + С т а д и я + С о с т о я н и е + П р а в и л о + В л а д е л е ц + С л е д у ю щ е е   д е й с т в и е + С р о к + Д а н н ы е + К о н т р о л ь

Это архитектурный шаблон, а не расчётная формула.

Начинать нужно с объекта

О б ъ е к т → С о б ы т и е → П р а в и л о → Д е й с т в и е

Стадия и состояние — разные сущности

О б ъ е к т = С т а д и я + С о с т о я н и е

Например:

S Q L + О т л о ж е н н ы й

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

К т о ? + Ч т о ? + К о г д а ?

Время является частью процесса

П р о ц е с с = П о с л е д о в а т е л ь н о с т ь + В р е м я

Данные должны позволять проверить исполнение

П р а в и л о → С о б ы т и е → И з м е р и м ы й   к о н т р о л ь

История должна накапливаться событиями

С о с т о я н и е t + 1 = С о с т о я н и е t + С о б ы т и е

Не автоматизировать до проверки логики

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

Таблица 472. Паспорт целевого состояния

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

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

30.5. Разрыв между текущей и целевой системой

После описания фактического и целевого состояния появляется непосредственный объект трансформации:

различие между тем, как система работает сейчас, и тем, как она должна работать после изменения.

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

Трансформационный разрыв не является экономической потерей

Т р а н с ф о р м а ц и о н н ы й   р а з р ы в ≠ Э к о н о м и ч е с к а я   п о т е р я

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

И он не равен коммерческому разрыву

Коммерческий разрыв показывает различие между ожидаемым и фактическим результатом. Трансформационный — какой способности системе не хватает.

Основные типы трансформационных разрывов

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

Разрывы образуют зависимости

Н е т   е д и н о г о   L e a d I D → Д у б л и → Н е к о р р е к т н о е   к о л и ч е с т в о   л и д о в → И с к а ж ё н н ы й   C P L

Таблица 473. Карта трансформационных разрывов

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

Элемент Текущее состояние Целевое состояние Тип разрыва
Определение разные трактовки единый стандарт методологический
Процесс зависит от сотрудника единая последовательность процессный
Ответственность размыта один владелец организационный
Данные неполная история событийная модель информационный
Мощность не хватает ресурса достаточная пропускная способность ресурсный
Компетенция правило не воспроизводится устойчивое исполнение компетентностный
Инструмент система не поддерживает правило техническая поддержка технологический

30.6. Архитектура изменений: не проекты, а способности

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

Основная единица — способность системы устойчиво выполнять требуемую управленческую функцию.

Пример: «доработать CRM» — проектная формулировка. «Единообразно различать новый LeadID, дубль, реактивацию и новый коммерческий цикл» — способность.

Архитектурная схема:

С п о с о б н о с т ь = П р о ц е с с + П р а в и л о + О т в е т с т в е н н о с т ь + Д а н н ы е + И н с т р у м е н т + К о м п е т е н ц и я + К о н т р о л ь

Один проект может создавать несколько способностей, а одна способность — требовать нескольких проектов:

1   п р о е к т → N   с п о с о б н о с т е й
1   с п о с о б н о с т ь → N   п р о е к т о в

Способности образуют зависимости:

Е д и н ы й   L e a d I D → К о р р е к т н ы й   L L M → А н а л и т и к а   к о н в е р с и й → Э к о н о м и к а   п р и в л е ч е н и я

или:

И с т о р и я   с о б ы т и й → И з м е р е н и е   в р е м е н и → К о н т р о л ь   S L A → У п р а в л е н и е   T T C

Состояния способности:

  • определена;
  • реализована;
  • используется;
  • воспроизводится;
  • встроена в управление.

Таблица 474. Паспорт способности

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

Элемент Содержание
Способность что система должна уметь
Связанное ограничение какую причину устраняет
Объект чем управляет
Правило какое поведение требуется
Процессы где способность используется
Ответственность кто владеет
Данные что требуется
Инструменты чем поддерживается
Компетенции что должны уметь сотрудники
Контроль как определяется качество
Критерий готовности когда способность считается созданной
Связь с результатом на что должна влиять

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

30.7. Приоритизация изменений

Ограничивающий контур уже определён. Теперь нужно выбрать первую интервенцию внутри него.

Например, если ограничение находится в MQL → SQL, возможные причины могут быть связаны с определением MQL, маршрутизацией, мощностью ЦКР, приоритизацией, временем реакции или качеством данных.

Приоритизация строится на четырёх критериях.

1. Причинность

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

2. Зависимости

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

3. Проверяемость

Г и п о т е з а → И з м е н е н и е → Р е з у л ь т а т → Р е ш е н и е

4. Реализуемость

Можно ли безопасно начать изменение доступными ресурсами и в обозримом горизонте.

Таблица 475. Приоритизация трансформационных изменений

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

Критерий Главный вопрос
Причинность изменение воздействует на подтверждённую причину или только на симптом?
Зависимости какие способности должны существовать раньше?
Проверяемость можно ли быстро и надёжно проверить гипотезу?
Реализуемость можно ли безопасно начать изменение сейчас?

Не следует сводить критерии к одному псевдоточному рейтингу.

Портфель полезно разделять на зоны: сейчас, следующее, позже, гипотезы.

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

30.8. Пилот как управляемый эксперимент

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

Пилот — не уменьшенная копия проекта, а управляемый эксперимент.

Он должен ответить:

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

Базовая логика

Г и п о т е з а → И з м е н е н и е → Н а б л ю д а е м о е   п о в е д е н и е → Р е з у л ь т а т

Один пилот должен иметь одну основную причинную гипотезу.

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

Г и п о т е з а + К о н т у р + К о г о р т а + И з м е н е н и е + М е т р и к а + П е р и о д + К р и т е р и й   р е ш е н и я

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

Базовый уровень и контроль

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

Простая разница «до/после» показывает наблюдаемое изменение, но сама по себе не доказывает причинный эффект.

Три уровня метрик

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

Экономическая атрибуция проводится отдельно по правилам раздела 30.12.

Критерии успеха и остановки

Они должны определяться до запуска пилота. Исключения — часть результата пилота.

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

Решение по итогам

М а с ш т а б и р о в а т ь
Д о р а б о т а т ь   и   п о в т о р и т ь
И з м е н и т ь   г и п о т е з у
О с т а н о в и т ь

или оставить локально.

Таблица 476. Карточка пилота

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

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

30.9. Переход без остановки действующего бизнеса

После успешного пилота новая способность ещё не стала частью нормальной операционной системы.

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

На определённый период возникают:

С т а р а я   м о д е л ь ∥ Н о в а я   м о д е л ь

Четыре механизма перехода

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

Способы переключения: одномоментный, поэтапный, когортный.

Момент переключения должен быть наблюдаемым событием.

Защита исторической сопоставимости

Если меняются LeadID, стадии, статусы, критерии квалификации или методология KPI, нужно различать:

М е т о д о л о г и я д о

и

М е т о д о л о г и я п о с л е

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

Временные решения допустимы

Но должны иметь:

П р и ч и н а + В л а д е л е ц + С р о к + У с л о в и е   в ы х о д а

Старый процесс должен быть выведен из эксплуатации

П и л о т → П е р е х о д → П е р е д а ч а → О т к л ю ч е н и е   с т а р о г о → Ш т а т н а я   э к с п л у а т а ц и я

30.10. Владельцы трансформации и архитектура ответственности

После передачи новой способности в эксплуатацию критично определить, кто отвечает за неё дальше.

Базовая архитектура включает четыре уровня:

  1. функциональный владелец;
  2. сквозной владелец;
  3. владелец следующего действия;
  4. владелец трансформационного контура.

Функциональный владелец

Ф у н к ц и о н а л ь н ы й   в л а д е л е ц = Л ю д и + Р е с у р с ы + К о м п е т е н ц и и + С т а н д а р т   ф у н к ц и и

Сквозной владелец

С к в о з н о й   в л а д е л е ц = Ц е п о ч к а + С т ы к и + О г р а н и ч е н и я + С к в о з н о й   р е з у л ь т а т

Владелец следующего действия

К т о ? + Ч т о ? + К о г д а ?

Если объект существует, но у него нет следующего действия и владельца, он находится вне управляемого процесса.

Владелец трансформационного контура

Отвечает за переход:

Т е к у щ е е   с о с т о я н и е → Ц е л е в о е   с о с т о я н и е

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

Главный принцип

О т в е т с т в е н н о с т ь ↔ П о л н о м о ч и я

Ответственность без права воздействовать на процесс — это не полноценное управление.

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

Совместная работа не означает коллективную ответственность.

Ответственность должна следовать за объектом:

П р е д ы д у щ и й   в л а д е л е ц → С о б ы т и е   п е р е д а ч и → Н о в ы й   в л а д е л е ц

Передача ответственности должна быть наблюдаемым событием.

30.11. Управленческий ритм трансформации

Назначение владельцев ещё не создаёт управление.

Управленческий ритм — повторяющийся механизм превращения наблюдения в действие.

П л а н → Ф а к т → П р о г н о з → О т к л о н е н и е → Р е ш е н и е → В л а д е л е ц → С р о к → П р о в е р к а

Ритм должен соответствовать скорости процесса

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

Три горизонта

Операционный — поток и исключения. Что требует действия сейчас?

Трансформационный — способность. Что мешает новой модели стать рабочей?

Стратегический — архитектура и ограничения. Что необходимо изменить следующим?

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

Горизонт Объект Основной вопрос
Операционный поток и исключения что требует действия сейчас?
Трансформационный способность что мешает новой модели стать рабочей?
Стратегический архитектура и ограничения что изменить следующим?

Управление должно начинаться с отклонения, а не с презентации.

Факт без прогноза заставляет управлять прошлым.

Повторяющееся исключение становится сигналом трансформации:

П о в т о р я ю щ е е с я   и с к л ю ч е н и е → Г и п о т е з а   о   с и с т е м н о м   р а з р ы в е → Д и а г н о с т и к а → Т р а н с ф о р м а ц и о н н о е   и з м е н е н и е

Решение должно становиться управляемым объектом:

Р е ш е н и е + В л а д е л е ц + С р о к + К р и т е р и й   п р о в е р к и

Нужно различать исполнение и эффект:

И с п о л н е н и е ≠ Э ф ф е к т

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

30.12. Экономика трансформации

Любое изменение в MOS должно в конечном счёте отвечать на вопрос:

создало ли оно экономическую ценность для компании?

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

1. Операционный эффект

Сократился TTC, снизилась доля объектов без действия, улучшилось соблюдение SLA, уменьшилось количество дублей.

2. Коммерческий эффект

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

3. Экономический эффект

Изменился GM1, стоимость процесса, LTV или другой финансовый результат.

О п е р а ц и о н н ы й   э ф ф е к т ≠ К о м м е р ч е с к и й   э ф ф е к т ≠ Э к о н о м и ч е с к и й   э ф ф е к т

Причинная цепочка

И з м е н е н и е   с п о с о б н о с т и → И з м е н е н и е   п о в е д е н и я → И з м е н е н и е   к о м м е р ч е с к о г о   р е з у л ь т а т а → Д о п о л н и т е л ь н ы й   G M 1 → Ч и с т ы й   э ф ф е к т

Формула 381. Стоимость нового привлечения

C P L = Р а с х о д ы   н а   н о в о е   п р и в л е ч е н и е Н о в ы е   у н и к а л ь н ы е   L e a d I D

Формула 382. Стоимость реактивации

С т о и м о с т ь   р е а к т и в а ц и и = З а т р а т ы   н а   р е а к т и в а ц и ю Р е а к т и в и р о в а н н ы е   L e a d I D

Формула 383. Структура сделок по когортам

С д е л к и о б щ и е = С д е л к и н о в о е   п р и в л е ч е н и е + С д е л к и р е а к т и в а ц и я + С д е л к и с у щ е с т в у ю щ и е   к л и е н т ы

Формула 384. Ожидаемый GM1 объекта на стадии

О ж и д а е м ы й   G M 1 с т а д и и = P ( С д е л к а | С т а д и я ) × G M 1 с д е л к и

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

Формула 385. Дополнительный GM1

Д о п о л н и т е л ь н ы й   G M 1 = Д о п о л н и т е л ь н ы е   с д е л к и × С р е д н и й   G M 1 с д е л к и

Формула 386. Чистый экономический эффект

Ч и с т ы й   э ф ф е к т = П о д т в е р ж д ё н н ы й   д о п о л н и т е л ь н ы й   G M 1 − Д о п о л н и т е л ь н ы е   з а т р а т ы

Коммерческий разрыв не равен экономической потере

К о м м е р ч е с к и й   р а з р ы в ≠ Э к о н о м и ч е с к а я   п о т е р я

без подтверждённого механизма.

Инфраструктурная ценность

Единый LeadID, событийная история, единая модель состояний, OwnershipID и архитектура данных могут быть предпосылками будущего эффекта и не требуют фиктивного ROI.

Полная стоимость изменения

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

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

Уровни уверенности

  • подтверждённый эффект;
  • аналитическая оценка;
  • гипотеза.

Таблица 477. Карточка экономики трансформации

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

Параметр Что фиксируется
Изменение какая способность изменилась
Базовый сценарий что произошло бы без изменения
Когорта какие объекты анализируются
Операционный эффект что изменилось в процессе
Коммерческий эффект что изменилось в цепочке
Дополнительные сделки причинно подтверждённый результат
Дополнительный GM1 финансовый результат
Единовременные затраты стоимость перехода
Постоянные затраты стоимость эксплуатации
Чистый эффект результат после затрат
Уровень уверенности подтверждён / оценка / гипотеза

30.13. Масштабирование проверенной модели

Успешный пилот подтверждает работоспособность новой способности в ограниченном контуре.

Масштабирование должно доказать её воспроизводимость.

П и л о т → Р а б о т о с п о с о б н о с т ь
М а с ш т а б и р о в а н и е → В о с п р о и з в о д и м о с т ь

Масштабировать нужно стандарт

Стандарт способности определяет минимум: объект, правило, ключевые события, ответственность, следующее действие, сроки, данные, контроль, основные исключения.

Архитектурное ядро и адаптивный слой

Е д и н ы й   с т а н д а р т = А р х и т е к т у р н о е   я д р о + Д о п у с т и м а я   а д а п т а ц и я

К ядру относятся определения объектов, идентификаторы, логика стадий и состояний, обязательные события, принципы ответственности и методология KPI.

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

Масштабирование волнами

В о л н а 1 → В о л н а 2 → В о л н а 3

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

Не следует использовать только лучшие команды: сильная команда может вручную компенсировать недостатки архитектуры.

Проверка мощности

Пилот при 50 объектах в день не доказывает работоспособность при 5000.

Нужно проверить организационную, техническую и управленческую пропускную способность.

Дефект модели и дефект внедрения

Результат может ухудшиться потому, что модель неверна, или потому, что она плохо внедрена.

Локальные отклонения полезно классифицировать:

  1. ошибка исполнения;
  2. объективная локальная особенность;
  3. дефект стандарта.

Версионирование

Ключевые стандарты полезно версионировать при изменениях определений, правил, KPI и моделей данных.

Формула 387. Экономика масштабирования

Ч и с т ы й   э ф ф е к т м а с ш т а б = П о д т в е р ж д ё н н ы й   э ф ф е к т м а с ш т а б − З а т р а т ы м а с ш т а б

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

30.14. Стабилизация: когда новая архитектура становится нормой

После масштабирования способность формально присутствует во всей организации. Но это ещё не означает, что она стала нормой.

Главный вопрос стабилизации:

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

В н е д р е н о ≠ С т а б и л и з и р о в а н о

Снижение зависимости от проектного контроля

Е ж е д н е в н ы й   к о н т р о л ь → П е р и о д и ч е с к и й   к о н т р о л ь → К о н т р о л ь   п о   о т к л о н е н и я м

Если качество резко падает при снижении поддержки, способность ещё не устойчива.

Управление по исключениям

С п л о ш н о й   к о н т р о л ь → У п р а в л е н и е   п о   и с к л ю ч е н и я м

Старая практика должна перестать быть рабочей альтернативой

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

Устойчивость во времени и при нагрузке

t 1 → t 2 → t 3

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

И с к л ю ч е н и е → К л а с с и ф и к а ц и я → П р а в и л о

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

О р г а н и з а ц и о н н а я   с п о с о б н о с т ь ≠ Н а в ы к   о д н о г о   ч е л о в е к а

Критерий выхода из трансформационного режима

Способность стабилизирована, если она:

  1. работает без постоянного участия проектной команды;
  2. имеет постоянного владельца;
  3. контролируется преимущественно по исключениям;
  4. сохраняет качество во времени;
  5. выдерживает вариативность нагрузки;
  6. не требует старой практики как основной опоры;
  7. сохраняет ожидаемый коммерческий и экономический результат.

30.15. MOS как постоянно развивающаяся операционная система

Стабилизация завершает конкретный цикл внедрения, но не завершает развитие MOS.

Рынок, спрос, продукты, каналы, поведение клиентов, экономика и технологии меняются. Следовательно, состояние, которое сегодня является целевым, со временем снова становится текущим.

Зрелая MOS должна уметь не только работать, но и изменять саму себя.

Постоянный цикл развития

Н а б л ю д е н и е → О г р а н и ч е н и е → Г и п о т е з а → И з м е н е н и е → П р о в е р к а → С т а н д а р т → Н о в о е   н а б л ю д е н и е

Главная метаспособность зрелой MOS:

система умеет обнаруживать собственные ограничения и управляемо перестраивать себя.

Постоянное развитие не означает постоянную перестройку

Нужно различать обычную вариативность и устойчивое системное ограничение.

Стабильное ядро и изменяемый слой

M O S = С т а б и л ь н о е   я д р о + А д а п т и в н ы й   о п е р а ц и о н н ы й   с л о й

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

Быстрее могут меняться процессы, сценарии, SLA, алгоритмы приоритизации, интерфейсы, автоматизация и инструменты.

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

А р х и т е к т у р а → П р а в и л о → П р о ц е с с → Д а н н ы е → Т е х н о л о г и я

AI особенно полезен тогда, когда существуют:

К а ч е с т в е н н ы е   о б ъ е к т ы + И с т о р и я + С о с т о я н и я + С о б ы т и я + Э к о н о м и к а

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

Но AI не отменяет определение объекта, ответственность, причинность и экономическую проверку.

От наблюдения прошлого — к прогнозу и действию

Р е т р о с п е к т и в н о е   у п р а в л е н и е → Т е к у щ е е   у п р а в л е н и е → П р о г н о з н о е   у п р а в л е н и е

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

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

Л о к а л ь н а я   э ф ф е к т и в н о с т ь ≠ С и с т е м н а я   э ф ф е к т и в н о с т ь

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

Г и п о т е з а + К о н т е к с т + И з м е н е н и е + Р е з у л ь т а т + В ы в о д

В итоге MOS переходит от целевой архитектуры к эволюционной:

С и с т е м а t → С и с т е м а t + 1 → С и с т е м а t + 2 → …

Заключение

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

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

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

Именно поэтому внедрение MOS начинается не с выбора технологий и не с перечня инициатив.

Оно начинается с понимания фактической системы:

Ф а к т и ч е с к о е   с о с т о я н и е → О г р а н и ч е н и е → Ц е л е в о е   с о с т о я н и е

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

Т е к у щ е е   с о с т о я н и е → Т р а н с ф о р м а ц и о н н ы й   р а з р ы в → Ц е л е в о е   с о с т о я н и е

Проекты создают отдельные элементы. Способность объединяет их в работающий механизм.

Любое изменение остаётся гипотезой до проверки:

Г и п о т е з а → П и л о т → Н а б л ю д е н и е → Р е ш е н и е

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

Новая архитектура требует новой ответственности:

О т в е т с т в е н н о с т ь ↔ П о л н о м о ч и я

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

П л а н → Ф а к т → П р о г н о з → О т к л о н е н и е → Р е ш е н и е → В л а д е л е ц → С р о к → П р о в е р к а

Изменение должно доказывать экономическую ценность:

И з м е н е н и е   с п о с о б н о с т и → И з м е н е н и е   п о в е д е н и я → К о м м е р ч е с к и й   р е з у л ь т а т → Д о п о л н и т е л ь н ы й   G M 1 → Ч и с т ы й   э ф ф е к т

Пилот ещё не является масштабом. Масштабирование должно доказать воспроизводимость:

П и л о т → С т а н д а р т → В о л н ы → М а с ш т а б

Масштабирование ещё не означает завершение. Последняя проверка — стабилизация:

У с и л е н н ы й   к о н т р о л ь → У п р а в л е н и е   п о   и с к л ю ч е н и я м → Н о в а я   н о р м а

Но MOS не имеет конечной точки. После устранения одного ограничения возникает следующее.

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

Д и а г н о с т и к а → О г р а н и ч е н и е → Ц е л ь → Р а з р ы в → С п о с о б н о с т ь → П р и о р и т е т → П и л о т → П е р е х о д → О т в е т с т в е н н о с т ь → У п р а в л е н и е → Э к о н о м и к а → М а с ш т а б и р о в а н и е → С т а б и л и з а ц и я → Э в о л ю ц и я

MOS становится действующей архитектурой тогда, когда организация умеет:

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

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

Глоссарий главы 30

Адаптивный операционный слой — часть MOS, которая может изменяться в зависимости от контекста подразделения, канала или бизнес-модели.

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

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

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

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

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

Диагностика фактического состояния — исследование того, как коммерческая система реально работает, а не только того, как она описана.

Карта трансформационных разрывов — структурированное сопоставление текущего и целевого состояния системы.

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

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

Критерий остановки пилота — заранее установленное условие прекращения или приостановки пилота.

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

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

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

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

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

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

Сквозной владелец — управленческая роль, отвечающая не за отдельную функцию, а за прохождение результата через несколько функций.

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

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

Стандарт способности — минимально необходимое описание того, как способность должна работать.

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

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

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

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

Уровень уверенности экономического эффекта — характеристика степени доказанности финансового результата: подтверждённый эффект, аналитическая оценка или гипотеза.

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

Чистый экономический эффект — финансовый результат трансформации после учёта дополнительных затрат.

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

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

Ключевые формулы главы 30

  1. C P L = Р а с х о д ы   н а   н о в о е   п р и в л е ч е н и е Н о в ы е   у н и к а л ь н ы е   L e a d I D
  2. С т о и м о с т ь   р е а к т и в а ц и и = З а т р а т ы   н а   р е а к т и в а ц и ю Р е а к т и в и р о в а н н ы е   L e a d I D
  3. С д е л к и о б щ и е = С д е л к и н о в о е   п р и в л е ч е н и е + С д е л к и р е а к т и в а ц и я + С д е л к и с у щ е с т в у ю щ и е   к л и е н т ы
  4. О ж и д а е м ы й   G M 1 с т а д и и = P ( С д е л к а | С т а д и я ) × G M 1 с д е л к и
  5. Д о п о л н и т е л ь н ы й   G M 1 = Д о п о л н и т е л ь н ы е   с д е л к и × С р е д н и й   G M 1 с д е л к и
  6. Ч и с т ы й   э ф ф е к т = П о д т в е р ж д ё н н ы й   д о п о л н и т е л ь н ы й   G M 1 − Д о п о л н и т е л ь н ы е   з а т р а т ы
  7. Ч и с т ы й   э ф ф е к т м а с ш т а б = П о д т в е р ж д ё н н ы й   э ф ф е к т м а с ш т а б − З а т р а т ы м а с ш т а б
В этой главе
  1. Введение
  2. 30.1. Почему новую архитектуру нельзя внедрить проектом
  3. 30.2. Точка старта: диагностика фактической системы
  4. 30.3. Ограничивающий контур как точка приложения изменений
  5. 30.4. Целевая операционная модель MOS
  6. 30.5. Разрыв между текущей и целевой системой
  7. 30.6. Архитектура изменений: не проекты, а способности
  8. 30.7. Приоритизация изменений
  9. 30.8. Пилот как управляемый эксперимент
  10. 30.9. Переход без остановки действующего бизнеса
  11. 30.10. Владельцы трансформации и архитектура ответственности
  12. 30.11. Управленческий ритм трансформации
  13. 30.12. Экономика трансформации
  14. 30.13. Масштабирование проверенной модели
  15. 30.14. Стабилизация: когда новая архитектура становится нормой
  16. 30.15. MOS как постоянно развивающаяся операционная система
  17. Заключение
  18. Глоссарий главы 30

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

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