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

Глава 24. Проектирование целевой модели

Введение

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

Между деньгами и результатом находится система.

Можно увеличить рекламный бюджет, но не получить дополнительного количества качественных MQL, если компания не умеет корректно фиксировать источники спроса и квалифицировать обращения. Можно увеличить поток лидов, но не получить роста продаж, если между маркетингом, Lead Lifecycle Management (LLM) и отделом продаж отсутствуют единые правила передачи и обработки спроса. Можно внедрить CRM, интеграционную платформу или систему бизнес-аналитики, но не получить управляемости, если не определены состояния коммерческого потока, владельцы процессов, нормативы времени, правила принятия решений и единые показатели.

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

Д е н ь г и ⇏ Р е з у л ь т а т .
И н в е с т и ц и и → С п о с о б н о с т и → И з м е н е н и е   к о м м е р ч е с к о г о   п о т о к а → Р е з у л ь т а т .

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

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

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

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

П р о г н о з → Р а з р ы в → И н в е с т и ц и о н н а я   п о т р е б н о с т ь .

Глава 24 продолжает её:

И н в е с т и ц и о н н а я   п о т р е б н о с т ь → Т р е б у е м ы е   с п о с о б н о с т и → Ц е л е в а я   о п е р а ц и о н н а я   м о д е л ь .

Под целевой операционной моделью (Target Operating Model, TOM; далее — целевая модель) будем понимать согласованную архитектуру способностей, процессов, ролей, данных, технологий, показателей и правил управления, необходимую для устойчивого производства требуемого коммерческого результата.

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

24.1. Зачем компании целевая модель

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

На практике именно здесь возникает один из наиболее существенных рисков трансформации.

Компания уже понимает:

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

Но она ещё не ответила на вопрос:

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

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

И н в е с т и ц и я ≠ С п о с о б н о с т ь .

Правильная логика:

И н в е с т и ц и о н н а я   п о т р е б н о с т ь → П р о е к т и р о в а н и е → Т р е б у е м а я   с п о с о б н о с т ь → К о м м е р ч е с к и й   р е з у л ь т а т .

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

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

Во всех случаях цель формально одна:

+ 15 %   с д е л о к .

Но требуемые изменения системы различаются.

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

Т р е б у е м ы й   р е з у л ь т а т → Т р е б у е м о е   и з м е н е н и е   п о т о к а → Т р е б у е м ы е   с п о с о б н о с т и → И з м е н е н и я   с и с т е м ы .

Целевая модель отвечает не на вопрос «что купить?», а на вопрос «что система должна уметь?»

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

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

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

Р ы н о к → С п р о с → M Q L → S Q L → К о м м е р ч е с к а я   в о з м о ж н о с т ь → С д е л к а → В л а д е л е ц → Н о в ы й   э п и з о д   с п р о с а .

Особенно важны границы функций:

M a r k e t i n g ↔ L L M ↔ S a l e s ↔ O w n e r M a n a g e m e n t .

В рассматриваемом автомобильном холдинге существуют маркетинг, контакт-центр, отделы продаж, CRM, DMS, телефония, сайты и классифайды. Однако разные определения лида, неполный Customer ID, неодинаковые стандарты MQL/SQL, отсутствие обязательного следующего действия и слабая связь CRM с DMS делают коммерческий поток фрагментированным.

24.2. Карта способностей целевой системы

Для определения того, что именно система должна уметь делать устойчиво, используется карта способностей (Capability Map).

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

Необходимо различать несколько уровней.

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

Уровень Вопрос Пример
Функция Что необходимо делать? квалифицировать спрос
Способность Что система должна уметь устойчиво? квалифицировать MQL по единому стандарту
Процесс Как это выполняется? последовательность квалификации
Роль Кто отвечает? специалист LLM
Технология Чем поддерживается? CRM
Ф у н к ц и я → С п о с о б н о с т ь → П р о ц е с с → Р о л ь → О р г а н и з а ц и о н н о е   р а з м е щ е н и е .

Способность не равна подразделению и не равна технологии.

Формула 374. Способность системы

С п о с о б н о с т ь i = f ( Л ю д и i , П р о ц е с с i , Д а н н ы е i , Т е х н о л о г и и i , У п р а в л е н и е i ) .

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

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

Контур Ключевая способность Критический объект Результат
Marketing Strategy интерпретировать рынок и распределять ресурсы Прогноз управленческое решение
Создание бренда управлять восприятием бренда Brand предпочтение
Стимулирование спроса формировать и активировать спрос Спрос прирост спроса
Коммерческое присутствие обеспечивать доступность предложения Offer доступное предложение
Привлечение лидов превращать интерес в идентифицированный спрос эпизод спроса Lead / MQL
LLM управлять состоянием спроса эпизод спроса SQL
Операционное управление продажами развивать коммерческую возможность Коммерческая возможность Сделка
Управление отношениями с клиентом после покупки управлять ценностью после сделки Customer / Owner новый спрос
Система управленческих решений поддерживать стандарты и решения Standard / Metric управляемость
Data сохранять объекты и события Customer ID / Event достоверное состояние

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

Условная шкала зрелости способности:

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

24.3. Принципы проектирования целевой модели

  1. От результата к архитектуре
К о м м е р ч е с к и й   р е з у л ь т а т → К о м м е р ч е с к и й   п о т о к → С п о с о б н о с т и → П р о ц е с с ы → Р о л и → Д а н н ы е → Т е х н о л о г и и .

  1. Достаточность вместо идеальности. Целевая модель должна быть минимально достаточной для устойчивого производства требуемого результата.

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

  3. От потока ценности, а не от подразделений.

  4. Интерфейсы проектируются так же тщательно, как внутренние процессы.

  5. Функция предшествует организационной единице.

  6. Данные являются частью процесса.

  7. История важнее одного текущего статуса.

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

Б и з н е с - а р х и т е к т у р а → А р х и т е к т у р а   д а н н ы х → Т е х н о л о г и ч е с к а я   а р х и т е к т у р а .

  1. Наблюдаемость проектируется сразу.

  2. Критические объекты должны иметь владельцев.

  3. Слои модели должны быть совместимы.

  4. Переход должен идти через работоспособные состояния.

  5. Существенные изменения являются гипотезами до получения доказательств.

24.4. Проектирование целевого коммерческого потока

Основной поток:

Р ы н о к → С п р о с → L e a d → M Q L → S Q L → К о м м е р ч е с к а я   в о з м о ж н о с т ь → С д е л к а → В л а д е л е ц → Н о в ы й   э п и з о д   с п р о с а .

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

Объектом сквозного потока является конкретный эпизод спроса, связанный с Customer ID.

Паспорт критического перехода:

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

Поле Содержание
Исходное состояние MQL
Целевое состояние SQL
Объект эпизод спроса
Событие подтверждение квалификации
Критерий выполнен SQL Standard
Владелец определённая роль
SLA норматив перехода
Данные обязательный набор
Следующее действие передача в продажи
KPI конверсия / время / качество

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

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

С д е л к а → В л а д е л е ц → Н о в ы й   э п и з о д   с п р о с а .

24.5. Процессы и интерфейсы между функциями

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

Критические интерфейсы:

M a r k e t i n g ↔ L L M ↔ S a l e s ↔ O w n e r M a n a g e m e n t .

Дополнительно:

M a r k e t i n g ↔ F i n a n c e , C o m m e r c i a l S y s t e m ↔ I T / D a t a .

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

Интерфейс Объект Критерий Получатель Контроль
Marketing → LLM Lead / эпизод спроса готов к квалификации LLM полнота / скорость
LLM → Sales SQL Критерии SQL Sales принятие / SLA
Sales → Owner сделка / клиент сделка завершена Управление отношениями с клиентом после покупки полнота передачи
Owner → New Demand новый эпизод триггер спроса Marketing / LLM реактивация
Marketing ↔ Finance инвестиции / результат согласованная экономика Finance / Marketing GM1 / эффект
Business ↔ IT/Data бизнес-требование утверждённая архитектура IT/Data реализуемость

Для критических передач необходимо различать:

П е р е д а н → П р и н я т .

Например:

S Q L S e n t → S Q L A c c e p t e d .

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

24.6. Роли, владельцы и организационная архитектура

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

Ф у н к ц и я → С п о с о б н о с т ь → П р о ц е с с → Р о л ь → О т в е т с т в е н н о с т ь → О р г а н и з а ц и о н н о е   р а з м е щ е н и е .

Роль и должность — не одно и то же. Один сотрудник может выполнять несколько ролей, а одна роль — распределяться между несколькими сотрудниками.

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

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

Тип владельца Ответственность
Владелец процесса работоспособность процесса
Владелец данных определение и качество данных
Владелец метрики методика расчёта
Владелец системы технологическая работоспособность
Владелец решения право принять управленческое решение

Одна способность может пересекать несколько подразделений. Например, качество MQL зависит от маркетинга, LLM, продаж, данных и CRM.

Распределённая способность не должна означать распределённую безответственность.

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

O n e A c t i v e O b j e c t ⇒ O n e C u r r e n t O w n e r .

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

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

Ключевой вопрос не «централизовать или децентрализовать?», а:

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

24.7. Governance целевой модели

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

Governance целевой модели связывает:

О т в е т с т в е н н о с т ь → П р а в а   р е ш е н и я → К о н т р о л ь → Э с к а л а ц и ю .

Критическими объектами управления являются:

  • MQL Standard;
  • SQL Standard;
  • Customer ID;
  • паспорт лида;
  • справочник источников спроса;
  • KPI Dictionary;
  • Forecast;
  • Marketing Investment Portfolio;
  • правила SLA;
  • маршрутизация.

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

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

Объект Владелец Право решения Ритм контроля Эскалация
Критерии MQL владелец стандарта изменить критерии регулярно / по событию коммерческий контур
Критерии SQL владелец стандарта изменить правила перехода регулярно коммерческий контур
Customer ID владелец данных изменить стандарт идентификации по качеству данных Data Governance
Source Dictionary маркетинговые данные изменить классификатор по необходимости Marketing Governance
Прогноз владелец прогноза изменить методику регулярный цикл руководство
KPI Dictionary владелец метрик изменить методику расчёта по версии Система управленческих решений

Стандарт должен иметь жизненный цикл:

С о з д а н и е → У т в е р ж д е н и е → И с п о л ь з о в а н и е → К о н т р о л ь → П е р е с м о т р .

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

П о к а з а т е л ь → П о р о г → Р е ш е н и е → Д е й с т в и е .

Governance не должен превращаться в бюрократию. Уровень решения должен соответствовать риску и масштабу воздействия.

24.8. Архитектура клиентских и коммерческих данных

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

Ключевая информационная связь:

И с т о ч н и к → В з а и м о д е й с т в и е → Э п и з о д   с п р о с а → К о м м е р ч е с к о е   с о с т о я н и е → С д е л к а → В л а д е л е ц .

Базовая объектная модель различает три уровня:

C u s t o m e r I D → D e m a n d E p i s o d e I D → L e a d P a s s p o r t .

Customer ID

Отвечает на вопрос:

кто этот клиент?

Это устойчивый внутренний идентификатор, связывающий различные технические идентификаторы и взаимодействия.

Эпизод спроса

Отвечает:

какое конкретное коммерческое намерение этого клиента развивается?

Один Customer ID может иметь несколько эпизодов спроса: покупка автомобиля, Trade-in, страхование, сервис, повторная покупка.

Паспорт лида

Паспорт лида (Lead Passport) — операционное представление текущего состояния конкретного эпизода спроса.

Он может включать:

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

Дедупликация должна работать на двух уровнях:

  1. это тот же клиент или другой;
  2. это новый эпизод спроса или продолжение существующего.

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

И с т о ч н и к   с п р о с а ≠ Р а з м е щ е н и е ≠ К а н а л   в з а и м о д е й с т в и я ≠ Т о ч к а   о б р а щ е н и я .

Последнее касание не должно подменять историю происхождения спроса.

Ключевые нормативные источники данных могут выглядеть так:

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

Объект Нормативный источник
Customer ID CRM / клиентский слой
Сделка DMS
GM1 финансовая система
Звонок телефония
Коммерческий статус CRM / LLM
Сервисное событие DMS / сервис
Маркетинговые расходы финансовый и рекламный контур

Для активного эпизода должно выполняться:

A c t i v e D e m a n d E p i s o d e ⇒ N e x t A c t i o n .

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

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

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

Формула 375. Событийный переход

S t a t e t → E v e n t t S t a t e t + 1 .

Состояние отвечает на вопрос «где находится объект сейчас?», событие — «что произошло?».

Минимальная структура критического события:

  • объект;
  • дата и время;
  • тип события;
  • предыдущее состояние;
  • новое состояние;
  • участник;
  • владелец;
  • результат;
  • причина, если применимо.

Пример:

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

Событие Предыдущее состояние Новое состояние
квалификация завершена Lead MQL
потребность подтверждена MQL SQL
визит состоялся SQL коммерческая возможность
сделка завершена коммерческая возможность Сделка
пауза активное состояние Pause
реактивация Pause активное состояние

История должна позволять восстановить путь:

S 0 → E 1 S 1 → E 2 . . . → E n S n .

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

O w n e r A → T r a n s f e r O w n e r B .

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

Событийная модель необходима для:

  • SLA;
  • длительности цикла;
  • анализа WIP;
  • когорт;
  • прогнозирования;
  • причин потерь;
  • восстановления фактического коммерческого пути.

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

24.10. Технологическая архитектура

Технологический слой проектируется после бизнес-архитектуры и архитектуры данных:

Б и з н е с - а р х и т е к т у р а → А р х и т е к т у р а   д а н н ы х → Т е х н о л о г и ч е с к а я   а р х и т е к т у р а .

CRM, DMS, телефония, BI, CDP, интеграционные платформы и AI не являются целевой моделью. Они являются средствами реализации уже определённых процессов, объектов и правил.

Логический технологический контур:

И с т о ч н и к и → И н т е г р а ц и я → К л и е н т с к а я   и   к о м м е р ч е с к а я   м о д е л ь → О п е р а ц и о н н ы е   с и с т е м ы → А н а л и т и к а → П о д д е р ж к а   р е ш е н и й .

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

Слой Назначение Примеры
Источники создание взаимодействий и событий сайт, телефония, классифайды
Интеграция обмен и синхронизация API / интеграционный слой
Клиентская модель единые объекты и идентификаторы Customer ID / Demand Episode
Операционные системы ежедневная работа CRM, DMS
Аналитика наблюдаемость BI
Поддержка решений прогноз / рекомендации модели и алгоритмы
C R M ≠ C o m m e r c i a l S y s t e m .

CRM является одним из компонентов коммерческой системы.

Для автомобильного бизнеса особенно важна связь CRM и DMS:

D e m a n d E p i s o d e → D e a l → D M S   T r a n s a c t i o n .

И обратно:

D M S   S e r v i c e E v e n t → O w n e r S t a t e → N e w D e m a n d T r i g g e r .

Автоматизация должна следовать после стандартизации:

С т а н д а р т и з и р о в а т ь → С т а б и л и з и р о в а т ь → А в т о м а т и з и р о в а т ь .

Принцип технического сбора:

О д н о   с о б ы т и е → О д н а   ф и к с а ц и я → М н о г о к р а т н о е   и с п о л ь з о в а н и е .

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

24.11. KPI, SLA и наблюдаемость целевой модели

Целевая модель становится управляемой только тогда, когда её состояние можно наблюдать.

Наблюдаемость строится через цепочку:

П р о ц е с с → С о с т о я н и е → П о к а з а т е л ь → П о р о г → Д е й с т в и е .

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

Показатели результата

  • Deal;
  • GM1;
  • выручка;
  • валовая маржа;
  • повторные сделки.

Показатели потока

  • MQL;
  • SQL;
  • коммерческие возможности;
  • конверсии переходов;
  • время до первого контакта;
  • длительность цикла;
  • WIP;
  • возраст состояния.

Показатели качества системы

  • покрытие Customer ID;
  • полнота паспорта лида;
  • покрытие следующим действием;
  • точность определения источника;
  • индекс качества данных;
  • точность прогноза.

Основные показатели:

T i m e T o C o n t a c t = T i m e F i r s t C o n t a c t − T i m e L e a d C r e a t e d .
C y c l e T i m e M Q L → S Q L = T i m e S Q L − T i m e M Q L .
W I P i ( t ) = К о л и ч е с т в о   а к т и в н ы х   о б ъ е к т о в   в   с о с т о я н и и i .
N e x t A c t i o n C o v e r a g e = А к т и в н ы е   э п и з о д ы   с   н а з н а ч е н н ы м   с л е д у ю щ и м   д е й с т в и е м В с е   а к т и в н ы е   э п и з о д ы .
C u s t o m e r I D C o v e r a g e = Э п и з о д ы   с   к о р р е к т н ы м   C u s t o m e r I D Э п и з о д ы ,   т р е б у ю щ и е   и д е н т и ф и к а ц и и .

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

A g e i > S L A i → S i g n a l → A c t i o n .

Компактная матрица наблюдаемости:

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

Показатель Что показывает Объект Управленческая реакция
Время до контакта скорость реакции Lead перераспределение
Cycle Time скорость перехода эпизод спроса поиск ограничения
WIP незавершённый поток состояние балансировка нагрузки
Next Action Coverage управляемость объектов активный спрос восстановление действий
Source Accuracy качество происхождения спроса источник корректировка данных
Forecast Accuracy качество прогноза Прогноз пересмотр модели

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

24.12. Разрыв способностей и карта изменений

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

Формула 376. Разрыв способности

C a p a b i l i t y G a p i = T a r g e t C a p a b i l i t y i − C u r r e n t C a p a b i l i t y i .

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

Разрыв может находиться:

  • в людях;
  • в компетенциях;
  • в процессе;
  • в данных;
  • в технологии;
  • в Governance;
  • в интерфейсе;
  • в пропускной способности.

Формула 377. Ограничение пропускной способности

П р о п у с к н а я   с п о с о б н о с т ь   с и с т е м ы ≤ min ( М о щ н о с т ь 1 , М о щ н о с т ь 2 , . . . , М о щ н о с т ь n ) .

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

После определения разрыва каждый элемент можно отнести к одной из пяти категорий:

  1. сохранить;
  2. улучшить;
  3. создать;
  4. заменить;
  5. устранить.

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

Способность Текущее состояние Целевое состояние Основной разрыв Изменение
Customer ID несколько идентификаторов единый объект данные / интеграция создать
MQL разные критерии единый стандарт процесс / Governance улучшить
SQL локальные определения единый стандарт интерфейс улучшить
Следующее действие необязательно обязательно процесс / технология создать
Источник спроса last-click история происхождения данные заменить
Прогноз ручной скользящий процесс / данные улучшить
Параллельная отчётность несколько форм единая модель дублирование устранить

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

Связь с инвестиционной архитектурой:

И н в е с т и ц и я → И з м е н е н и е   с п о с о б н о с т и → И з м е н е н и е   п о т о к а → К о м м е р ч е с к и й   р е з у л ь т а т .

24.13. Минимально достаточная целевая модель

Полная целевая модель может включать большой набор изменений. Реализовывать их одновременно не всегда рационально.

Минимально достаточная целевая модель (Minimum Viable Target Model) — минимальный набор взаимосвязанных способностей, процессов, ролей, данных, технологий и правил управления, при котором новый коммерческий контур уже способен работать как целостная система.

М и н и м а л ь н а я ≠ М и н и м а л ь н о   д о с т а т о ч н а я .

Ключевой принцип:

M i n i m u m S c o p e + M a x i m u m C o h e r e n c e .

Лучше выбрать небольшой участок коммерческого потока и построить его целостно, чем изменить большое количество элементов фрагментарно.

Минимальный контур обычно должен включать:

  1. определённый объект;
  2. нормативные состояния;
  3. критерии переходов;
  4. владельцев;
  5. интерфейсы;
  6. обязательные данные;
  7. ключевые события;
  8. SLA;
  9. наблюдаемость;
  10. Governance.

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

  • единый MQL Standard;
  • единый SQL Standard;
  • Demand Episode ID;
  • паспорт лида;
  • обязательное следующее действие;
  • владельцев;
  • SLA;
  • передачу и принятие;
  • причины возврата;
  • базовые KPI.

Формула 378. Экономическая достаточность способности

О ж и д а е м а я   с и с т е м н а я   ц е н н о с т ь i ≥ С т о и м о с т ь   ж и з н е н н о г о   ц и к л а i .

Это архитектурный критерий, а не универсальная финансовая формула.

Паспорт минимально достаточной модели:

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

Поле Содержание
Коммерческая проблема что ограничивает результат
Целевой поток какой участок изменяется
Способности что необходимо создать
Объект чем управляем
Стандарты какие нормативы используются
Владельцы кто отвечает
Данные обязательный минимум
События что фиксируется
SLA что контролируется
KPI как измеряется
Технологии чем поддерживается
Система управленческих решений как принимаются решения

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

24.14. Дорожная карта переходных состояний

Целевая модель не должна внедряться одним скачком.

Т е к у щ е е   с о с т о я н и е → П е р е х о д н о е 1 → П е р е х о д н о е 2 → Ц е л е в о е   с о с т о я н и е .

Переходное состояние — не этап проекта. Это реально работоспособная конфигурация системы после определённого набора изменений.

Каждое состояние должно:

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

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

Например, при создании способности управлять MQL → SQL одновременно меняются процесс, роли, данные, CRM, SLA и KPI.

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

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

Слой T0 T1 T2 Целевое состояние
Объект спроса разрозненные лиды эпизод спроса единая сквозная история полный жизненный цикл
MQL/SQL разные определения единые стандарты автоматизированный контроль адаптивное управление
Данные фрагменты обязательный минимум интегрированная история единый слой
Передача ручная формализованная автоматизированная по исключениям
KPI локальные MQL → SQL Lead → Deal полный коммерческий цикл
Прогноз ручной базовый скользящий прогноз динамический
Управление отношениями с клиентом после покупки отдельно без изменений частичная связь единый цикл

Временное решение допустимо, временное значение объекта — нет.

T e m p o r a r y I m p l e m e n t a t i o n ≠ T e m p o r a r y M e a n i n g .

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

24.15. От целевой модели к пилоту

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

Формула 379. От архитектуры к доказательствам

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

Каждый существенный элемент новой архитектуры содержит предположение.

Например:

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

Архитектурное решение должно переводиться в проверяемую гипотезу:

И з м е н е н и е → М е х а н и з м → О ж и д а е м ы й   э ф ф е к т → М е т р и к а .

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

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

Результатом пилота должны стать:

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

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

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

Заключение

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

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

Первый принцип:

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

И н в е с т и ц и я → И з м е н е н и е   с п о с о б н о с т и → И з м е н е н и е   к о м м е р ч е с к о г о   п о т о к а → К о м м е р ч е с к и й   р е з у л ь т а т .

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

Третий вывод: целевая модель должна быть экономически достаточной, а не максимально сложной.

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

На примере автомобильного холдинга общий переход можно представить так:

Ф р а г м е н т и р о в а н н а я   с и с т е м а → Е д и н ы й   C u s t o m e r I D → Э п и з о д   с п р о с а → Е д и н а я   м о д е л ь   с о с т о я н и й → Ф о р м а л и з о в а н н ы е   и н т е р ф е й с ы → С о б ы т и й н а я   и с т о р и я → С к в о з н а я   н а б л ю д а е м о с т ь → З а м к н у т ы й   к о м м е р ч е с к и й   ц и к л .

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

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

Финальная логика главы:

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

Следующая глава — «Пилотирование и проверка гипотез» — должна ответить на вопрос: как правильно спроектировать проверку, сформулировать гипотезы, определить критерии успеха и принять решение о дальнейшем масштабировании.

Рабочий глоссарий главы 24

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

Термин Рабочее определение
Целевая операционная модель согласованная архитектура способностей, процессов, ролей, данных, технологий, показателей и правил управления, необходимая для устойчивого производства требуемого коммерческого результата
Способность системы устойчивая возможность выполнять определённую функцию с требуемым качеством, скоростью и результатом
Карта способностей карта требуемых способностей маркетингово-коммерческой системы
Разрыв способности различие между текущим и требуемым состоянием способности
Текущее состояние фактическая архитектура и уровень работоспособности системы
Целевое состояние требуемая конфигурация системы
Переходное состояние работоспособная промежуточная конфигурация между текущим и целевым состоянием
Минимально достаточная целевая модель минимальный целостный набор элементов, при котором новая архитектура уже способна работать как система
Customer ID единый идентификатор клиента
Эпизод спроса (Demand Episode) отдельное коммерчески значимое проявление спроса конкретного клиента
Паспорт лида (Lead Passport) операционное представление текущего состояния эпизода спроса
Lead идентифицированное обращение / объект верхней части коммерческого потока
MQL маркетингово квалифицированный лид
SQL коммерчески квалифицированный лид
Коммерческая возможность (Opportunity) конкретно развиваемая возможность совершения сделки
Сделка (Deal) завершённый коммерческий результат соответствующего цикла
Интерфейс процесса формализованная точка передачи объекта, состояния, данных и ответственности между функциями
Владелец процесса роль, отвечающая за работоспособность процесса
Владелец данных роль, отвечающая за определение и качество данных
Владелец метрики роль, отвечающая за методику расчёта показателя
Владелец системы роль, отвечающая за технологическую работоспособность
Владелец решения роль, обладающая правом принять определённое управленческое решение
Следующее действие обязательное следующее управляемое действие для активного эпизода спроса
SLA норматив времени и/или качества выполнения перехода или процесса
WIP объём незавершённой работы — количество объектов в активной обработке
Длительность цикла (Cycle Time) время прохождения определённого участка коммерческого потока
Время до первого контакта (Time-to-Contact) время от создания лида до первого квалифицированного контакта
Справочник источников спроса нормативная классификация источников, размещений, каналов и точек обращения
Событие зафиксированный факт, который изменяет или подтверждает состояние объекта
Скользящий прогноз регулярно обновляемый прогноз на основе актуального состояния коммерческого потока
Индекс качества данных интегральная оценка полноты, корректности, согласованности и своевременности данных
Контур пилота ограниченная область системы, выбранная для проверки ключевых гипотез целевой модели

Паспорт целевой модели / Target Model Canvas

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

Блок Контрольный вопрос
Коммерческий результат Что система должна производить?
Ключевые разрывы Что сегодня препятствует результату?
Требуемые способности Что компания должна уметь?
Коммерческий контур Где находится способность?
Процессы Как должен работать поток?
Роли Кто отвечает?
Интерфейсы Где передаются объект, данные и ответственность?
Данные Какие объекты и события нужны?
Технологии Чем поддерживается процесс?
KPI и SLA Как наблюдается состояние?
Система управленческих решений Кто принимает решения и меняет правила?
Ограничения Что ограничивает реализацию модели?
Инвестиции Какой ресурс требуется?
Пилот Что необходимо проверить первым?

Формульный аппарат главы 24

Формула 380. Целевая модель

Ц е л е в а я   м о д е л ь = f ( С т р а т е г и я , К о м м е р ч е с к и е   т р е б о в а н и я , Т е к у щ е е   с о с т о я н и е , О г р а н и ч е н и я ) .

Формула 374. Способность системы

С п о с о б н о с т ь i = f ( Л ю д и i , П р о ц е с с i , Д а н н ы е i , Т е х н о л о г и и i , У п р а в л е н и е i ) .

Формула 376. Разрыв способности

C a p a b i l i t y G a p i = T a r g e t C a p a b i l i t y i − C u r r e n t C a p a b i l i t y i .

Формула 375. Событийный переход

S t a t e t → E v e n t t S t a t e t + 1 .

Формула 377. Ограничение пропускной способности

П р о п у с к н а я   с п о с о б н о с т ь   с и с т е м ы ≤ min ( М о щ н о с т ь 1 , … , М о щ н о с т ь n ) .

Формула 378. Экономическая достаточность способности

О ж и д а е м а я   с и с т е м н а я   ц е н н о с т ь i ≥ С т о и м о с т ь   ж и з н е н н о г о   ц и к л а i .

Формула 379. От архитектуры к доказательствам

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

Формат: A5, вертикальная композиция, светлый фон; основной текст чёрный / тёмно-серый; синий — архитектура; зелёный — целевое состояние и рабочая способность; красный — разрыв, риск или отсутствующая способность.

В этой главе
  1. Введение
  2. 24.1. Зачем компании целевая модель
  3. 24.2. Карта способностей целевой системы
  4. 24.3. Принципы проектирования целевой модели
  5. 24.4. Проектирование целевого коммерческого потока
  6. 24.5. Процессы и интерфейсы между функциями
  7. 24.6. Роли, владельцы и организационная архитектура
  8. 24.7. Governance целевой модели
  9. 24.8. Архитектура клиентских и коммерческих данных
  10. 24.9. Событийная модель и история состояний
  11. 24.10. Технологическая архитектура
  12. 24.11. KPI, SLA и наблюдаемость целевой модели
  13. 24.12. Разрыв способностей и карта изменений
  14. 24.13. Минимально достаточная целевая модель
  15. 24.14. Дорожная карта переходных состояний
  16. 24.15. От целевой модели к пилоту
  17. Заключение
  18. Рабочий глоссарий главы 24
  19. Паспорт целевой модели / Target Model Canvas
  20. Формульный аппарат главы 24

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

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