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

Глава 31. MOS как операционная система коммерческого развития компании

Введение

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

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

В результате возникает принципиальный вопрос:

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

Ответом становится MOS — операционная система коммерческого развития компании.

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

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

Р е к л а м а → Л и д о г е н е р а ц и я → У п р а в л е н и е   с п р о с о м → К о м м е р ч е с к а я   с и с т е м а → M O S

На каждом шаге расширяется объект управления.

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

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

В наиболее компактном виде архитектуру MOS можно представить так:

M O S = К о м м е р ч е с к а я   а р х и т е к т у р а + Д а н н ы е + Э к о н о м и к а + О т в е т с т в е н н о с т ь + У п р а в л е н и е + П о с т о я н н о е   у л у ч ш е н и е

Это архитектурная модель, а не математическая формула.

Главный вопрос финальной главы:

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

31.1. От маркетинговой функции к архитектуре коммерческого развития

Традиционная организационная модель разделяет коммерческую деятельность между функциями.

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

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

Качественная рекламная кампания не гарантирует результат, если обращения долго обрабатываются. Большое количество MQL не создаёт сделки, если переход к SQL не управляется. Высокая конверсия продаж не создаёт максимальный LTV, если отношения заканчиваются после передачи продукта.

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

Функция может быть локальной. Результат всегда сквозной.

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

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

Таблица 478. От функционального маркетинга к MOS

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

Функциональная модель Архитектура MOS
Управление маркетинговыми активностями Управление коммерческими способностями
Основной объект — канал или кампания Основной объект — коммерческий поток и его объекты
Ответственность ограничена функцией Ответственность связана со сквозным результатом
Оптимизация локальных KPI Оптимизация результата системы
Данные преимущественно для отчётности Данные как история поведения системы
CRM поддерживает отдельные процессы CRM исполняет согласованную архитектуру
Улучшения реализуются отдельными проектами Улучшение встроено в регулярное управление

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

Сначала определяется:

О п р е д е л е н и е → А р х и т е к т у р а → П р о ц е с с → И н с т р у м е н т

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

31.2. Компания как система коммерческих потоков

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

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

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

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

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

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

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

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

MOS тем самым меняет объект управленческого внимания:

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

31.3. Объектная архитектура как фундамент MOS

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

Поэтому фундамент MOS — объектная архитектура.

ClientID

Идентификатор клиента как субъекта отношений с компанией.

Один ClientID может иметь несколько LeadID, DealID и OwnershipID.

LeadID

Идентификатор конкретной самостоятельной коммерческой потребности.

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

DealID

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

OwnershipID

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

EventID

Идентификатор зафиксированного события. EventID фиксирует то, что произошло с объектом или вокруг объекта.

Таблица 479. Основные объекты MOS

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

Объект Что представляет Когда возникает
ClientID Клиента как субъекта отношений При идентификации клиента
LeadID Самостоятельную коммерческую потребность При возникновении потребности
DealID Конкретную сделку При формировании сделки
OwnershipID Контекст владения продуктом После передачи продукта
EventID Зафиксированный факт При наступлении события

Событие, состояние и изменение состояния

Эти понятия нельзя смешивать.

Событие — факт того, что произошло.

Например: клиент ответил на звонок, заполнена форма, состоялся визит, отправлено предложение.

Состояние — текущее положение объекта.

Например: новый LeadID, MQL, SQL, пауза.

Изменение состояния — переход объекта из одного состояния в другое.

Поэтому:

С о б ы т и е ≠ И з м е н е н и е   с о с т о я н и я

Не каждое событие должно переводить объект в новое состояние.

Корректная архитектурная логика:

С о б ы т и е + У с л о в и е   п е р е х о д а → И з м е н е н и е   с о с т о я н и я

Таблица 480. Событие, состояние, изменение состояния и действие

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

Сущность Основной вопрос Пример
Событие Что произошло? Клиент ответил на звонок
Состояние Где находится объект? MQL
Изменение состояния Что изменилось? MQL → SQL
Следующее действие Что необходимо сделать? Назначить визит
Владелец Кто отвечает? Сотрудник ЦКР
Срок Когда? До 14:00

31.4. От воронки к коммерческому жизненному циклу

Воронка остаётся полезной моделью. Она позволяет видеть преобразование потока:

L e a d I D → M Q L → S Q L → С д е л к а

Но она описывает только ограниченный фрагмент отношений.

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

Поэтому MOS рассматривает воронку внутри более длинного коммерческого жизненного цикла.

Новая потребность и реактивация

Если прежняя потребность не завершена и клиент снова возвращается к ней:

Р е а к т и в а ц и я → С у щ е с т в у ю щ и й   L e a d I D

Идентичность потребности сохраняется.

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

Н о в а я   п о т р е б н о с т ь → Н о в ы й   L e a d I D

даже если речь идёт о том же ClientID.

31.5. Семь архитектурных контуров MOS

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

В MOS выделяются семь архитектурных контуров.

Важно: это не стадии зрелости и не организационные подразделения. Они отвечают на вопрос:

Что должна уметь коммерческая система?

1. Создание бренда

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

2. Стимулирование спроса

Активация существующей или формирование потенциальной потребности.

3. Коммерческое присутствие

Способность быть доступным клиенту в момент поиска и выбора.

4. Привлечение лидов

Захват возникшей потребности и создание LeadID.

Первые четыре контура образуют:

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

5. Управление жизненным циклом лида

LLM сопровождает развитие LeadID и включает квалификацию, развитие потребности, коммуникации, следующие действия, паузу, реактивацию и переход к SQL.

LLM не является отдельной линейной стадией.

Упрощённо его роль может быть показана:

M Q L ⟶ L L M S Q L

6. Управление продажами

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

7. Управление отношениями с клиентом после покупки

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

Таблица 481. Семь архитектурных контуров MOS

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

Контур Основная задача Ключевой результат
Создание бренда Формировать смысл и предпочтение Предпосылка спроса
Стимулирование спроса Активировать потребность Интерес
Коммерческое присутствие Быть доступным в момент выбора Возможность контакта
Привлечение лидов Захватить потребность LeadID
Управление жизненным циклом лида Развивать и квалифицировать SQL
Управление продажами Преобразовать SQL в сделку DealID, GM1
Управление отношениями с клиентом после покупки Развивать отношения после сделки Удержание, новый цикл, LTV

31.6. Данные как память коммерческой системы

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

Обычный отчёт даёт снимок. История даёт возможность восстановить поведение.

Поэтому развитие данных можно представить так:

О т ч ё т → И с т о р и я → Н а б л ю д а е м о с т ь → П р и ч и н н ы й   а н а л и з → П р о г н о з → Д е й с т в и е

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

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

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

31.7. Экономика коммерческого потока

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

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

C P L n e w = C a c q , n e w N L e a d I D , n e w

где C a c q , n e w — расходы на новое привлечение, а N L e a d I D , n e w — новые уникальные LeadID.

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

Формула 389. Стоимость сделки

C o s t D e a l = C a c q + C c o m m e r c i a l N D e a l

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

Формула 390. Ожидаемая экономическая ценность состояния

E ( G M 1 ∣ S i ) = P ( D e a l ∣ S i ) × E ( G M 1 D e a l ∣ S i )

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

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

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

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

Поэтому:

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

Формула 391. Потенциальный экономический резерв

P o t e n t i a l   G M 1 = N B a s e × Δ C R × G M 1 D e a l

До доказательства причинности это только оценка потенциального резерва.

Формула 392. Подтверждённый чистый экономический эффект

Ч и с т ы й   э ф ф е к т = Δ G M 1 − Δ C c o m m e r c i a l − C i m p l e m e n t a t i o n

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

Формула 393. LTV на горизонте нескольких коммерческих циклов

L T V n e t = ∑ k = 1 n ( G M 1 k − C c o m m e r c i a l , k ) − C r e t e n t i o n − C a c q , i n i t i a l

Конкретный состав GM1 и затрат должен быть согласован с финансовой методологией компании.

Таблица 482. Уровни экономики коммерческого потока

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

Уровень Основной вопрос
Новое привлечение Сколько стоит новый LeadID?
Коммерческий процесс Сколько стоит довести поток до сделки?
Состояние Какова ожидаемая экономическая ценность объекта?
Ограничение Какой потенциальный резерв связан с разрывом?
Изменение Каков подтверждённый чистый эффект?
Отношения Какова ценность клиента на горизонте циклов?

31.8. От функциональных KPI к сквозным результатам

MOS не отменяет функциональные показатели. CPL, TTC, MQL, SQL, конверсии, визиты, сделки, GM1 и LTV остаются необходимыми.

Но локальный показатель не должен интерпретироваться изолированно.

Например: CPL снизился, объём лидов вырос, но качество упало, переход MQL → SQL ухудшился, продажи не выросли, GM1 снизился.

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

Поэтому:

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

Управленческая логика:

Л о к а л ь н ы й   п о к а з а т е л ь → П е р е х о д → С к в о з н о й   р е з у л ь т а т → Э к о н о м и ч е с к и й   э ф ф е к т

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

Ранние и опережающие показатели

Ранний показатель просто возникает раньше конечного результата.

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

Поэтому:

Р а н н и й ⇏ О п е р е ж а ю щ и й

31.9. Архитектура ответственности

Сквозной коммерческий результат создаётся многими функциями. Поэтому одной функциональной ответственности недостаточно.

MOS разделяет как минимум три уровня.

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

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

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

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

Он не является линейным руководителем всех функций.

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

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

Отвечает за конкретное действие в отношении конкретного объекта в конкретный срок.

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

O b j e c t I D + С о с т о я н и е + С л е д у ю щ е е   д е й с т в и е + В л а д е л е ц + С р о к

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

Таблица 483. Три уровня ответственности

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

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

31.10. CRM как операционный слой MOS

CRM занимает важное место в MOS, но не является самой MOS.

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

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

А р х и т е к т у р а → П р а в и л а → П р о ц е с с → Д а н н ы е → C R M

MOS определяет объекты, состояния, события, правила переходов, критерии MQL и SQL, владельцев, SLA и правила эскалации.

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

Таблица 484. Разделение MOS и CRM

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

MOS определяет CRM обеспечивает
Объекты Хранение и идентификацию
Состояния Отображение
Критерии переходов Исполнение переходов
События Регистрацию истории
Следующее действие Постановку задачи
Владельца Назначение
SLA Контроль срока
Эскалацию Уведомление и маршрутизацию

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

MOS требует не одной системы, а согласованной объектной и событийной архитектуры между системами.

31.11. Автоматизация и искусственный интеллект: усиление, а не замена архитектуры

Когда объекты, правила и ответственность определены, появляется основа для технологического усиления.

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

Автоматизация

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

Искусственный интеллект

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

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

Плохая архитектура, усиленная автоматизацией или ИИ, становится масштабированной плохой архитектурой.

Поэтому порядок остаётся:

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

Минимальные критерии готовности к ИИ

  1. Определены устойчивые коммерческие объекты.
  2. Разделены события и состояния.
  3. Существует временная история.
  4. Известны критерии результата.
  5. Есть достаточно наблюдений.
  6. Определено конкретное решение, которое должен улучшать ИИ.
  7. Назначен владелец этого решения.
  8. Можно измерить экономический эффект.
  9. Приемлема цена ошибочного решения.

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

31.12. Собственник как архитектор коммерческой системы

По мере развития MOS меняется роль собственника.

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

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

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

Высший уровень должен концентрироваться на четырёх задачах.

1. Определение системного ограничения

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

2. Оценка экономической значимости

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

3. Разрешение конфликтов локальных оптимумов

Задача собственника — не определить «кто прав», а выбрать решение, которое улучшает систему в целом.

4. Распределение ресурсов

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

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

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

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

Таблица 485. Изменение роли собственника

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

Незрелая система Зрелая MOS
Контролирует отдельные действия Контролирует системные ограничения
Запрашивает множество отчётов Использует сквозной контекст
Лично разрешает операционные конфликты Определяет правила и эскалации
Ускоряет проблемный участок Назначает владельца и полномочия
Бюджетирует преимущественно по функциям Направляет ресурсы на способности и ограничения
Реагирует на прошлый результат Использует прогноз
Компенсирует систему собой Развивает способность системы работать самостоятельно

31.13. MOS как развивающаяся система

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

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

Здесь возникает отдельная модель — семь стадий зрелости MOS.

Она не совпадает с семью архитектурными контурами.

Архитектурные контуры отвечают:

Что должна уметь система?

Стадии зрелости отвечают:

Насколько хорошо она этим управляет?

1. Фрагментарная стадия

Результат создаётся через отдельные функции и персональные договорённости.

2. Формализованная стадия

Определены объекты, правила, роли, переходы и SLA.

3. Наблюдаемая стадия

Компания способна восстановить фактическую историю поведения коммерческих объектов.

4. Управляемая стадия

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

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

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

6. Предиктивная стадия

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

7. Адаптивная стадия

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

Таблица 486. Семь стадий зрелости MOS

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

Стадия Ключевая способность
Фрагментарная Создавать результат через отдельные функции
Формализованная Работать по единым правилам
Наблюдаемая Видеть фактическое поведение
Управляемая Выявлять и устранять ограничения
Экономически управляемая Приоритизировать по экономическому эффекту
Предиктивная Оценивать вероятное будущее
Адаптивная Управляемо изменять архитектуру

Профиль зрелости MOS

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

Поэтому правильнее говорить не об одном «уровне компании», а о профиле зрелости MOS.

Архитектурно:

П р о ф и л ь   з р е л о с т и   M O S = А р х и т е к т у р н ы е   к о н т у р ы × С т а д и и   з р е л о с т и

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

Практический вопрос:

Какой разрыв зрелости в каком контуре сегодня ограничивает коммерческий результат?

31.14. Границы MOS

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

Это неверно.

MOS имеет широкую, но определённую область ответственности.

Состав коммерческого контура MOS

В него входят пять областей:

  1. работа с рынком и MVC;
  2. управление жизненным циклом лида;
  3. управление продажами;
  4. управление отношениями с клиентом после покупки;
  5. сквозной управленческий слой.

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

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

Но она не подменяет соответствующие системы управления.

Если:

Н е т   п р о д у к т а → П о т е р я н н а я   с д е л к а

или:

П е р е г р у ж е н   с е р в и с → С н и ж е н и е   у д е р ж а н и я

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

Влияние не означает владение.

Таблица 487. MOS и соседние системы управления

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

Система Что получает или формирует MOS Что остаётся у владельца системы
Стратегия Коммерческие приоритеты Выбор рынков и бизнес-моделей
Управление продуктом Обратная связь и коммерческий эффект Создание продукта
Финансы Экономические определения Полный финансовый контур
HR Требования к ролям и способностям Управление персоналом
IT Бизнес-требования Техническая архитектура
Операционная деятельность Коммерческий эффект ограничений Физическое исполнение

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

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

31.15. MOS как операционная система коммерческого развития

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

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

MOS — не расширенный маркетинг

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

Маркетинг остаётся профессиональной функцией. Управление продажами — отдельной коммерческой способностью. Управление отношениями с клиентом после покупки — отдельным контуром. CRM — технологическим слоем. Финансы — самостоятельной системой.

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

От функций к способностям

Организационная структура отвечает:

Кто выполняет работу?

MOS отвечает:

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

От статистики к объектам

MOS заменяет обезличенную массу обращений на управляемую объектную модель: ClientID, LeadID, DealID, OwnershipID, события, состояния и действия.

От воронки к жизненному циклу

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

От отчётности к памяти

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

От бюджета маркетинга к экономике потока

Компания начинает считать не только стоимость привлечения, но и стоимость движения, стоимость сделки, GM1, экономический резерв, подтверждённый эффект и LTV.

От локальных KPI к причинной системе показателей

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

От функциональной ответственности к многослойной

Функциональный владелец отвечает за способность. Сквозной владелец — за поток. Владелец следующего действия — за конкретное исполнение.

От CRM как проекта к CRM как среде исполнения

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

От автоматизации к усиленной архитектуре

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

От ручного контроля к системному управлению

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

От внедрения к развитию

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

Именно поэтому постоянное улучшение является частью архитектуры.

Итоговая архитектурная модель

M O S = К о м м е р ч е с к а я   а р х и т е к т у р а + Д а н н ы е + Э к о н о м и к а + О т в е т с т в е н н о с т ь + У п р а в л е н и е + П о с т о я н н о е   у л у ч ш е н и е

Если отсутствует коммерческая архитектура — непонятен объект управления.

Если отсутствуют данные — система не имеет памяти.

Если отсутствует экономика — невозможно определить ценность изменений.

Если отсутствует ответственность — решение не превращается в действие.

Если отсутствует управление — отклонение не приводит к изменению.

Если отсутствует постоянное улучшение — система постепенно перестаёт соответствовать рынку.

Таблица 488. Итоговый переход к MOS

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

Было MOS
Маркетинг как отдельная функция Маркетинг как часть коммерческой архитектуры
Каналы и активности Коммерческие способности
Агрегированные обращения Идентифицированные коммерческие объекты
Воронка Коммерческий жизненный цикл
Отчётность История и наблюдаемость
Локальные KPI Сквозная система показателей
Бюджет маркетинга Экономика коммерческого потока
Функциональная ответственность Многослойная ответственность
CRM как центр изменений CRM как слой исполнения
Ручной контроль Управление по правилам и исключениям
Разовые проекты улучшения Постоянный цикл развития

Заключение

В начале книги вопрос звучал относительно привычно:

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

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

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

Ответом становится MOS.

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

В такой системе:

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

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

Финальный тезис книги:

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

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

MOS

Операционная система коммерческого развития компании.

Коммерческая архитектура

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

Коммерческий контур MOS

Область непосредственного управления MOS: работа с рынком и MVC, LLM, управление продажами, управление отношениями с клиентом после покупки и сквозной управленческий слой.

Архитектурные контуры MOS

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

MVC

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

LLM

Управление жизненным циклом лида. Не является отдельной линейной стадией.

Банк накопленного спроса

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

ClientID

Идентификатор клиента.

LeadID

Идентификатор конкретной самостоятельной коммерческой потребности.

DealID

Идентификатор конкретной сделки.

OwnershipID

Идентификатор контекста владения продуктом.

EventID

Идентификатор зафиксированного события.

Событие

Факт того, что произошло.

Состояние

Текущее положение коммерческого объекта.

Изменение состояния

Переход объекта из одного состояния в другое.

Реактивация

Возобновление работы с прежней незавершённой потребностью при сохранении существующего LeadID.

Новая потребность

Самостоятельная коммерческая задача, создающая новый LeadID.

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

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

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

Владелец целостности потока, переходов, правил и системных ограничений.

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

Ответственный за конкретное действие над конкретным объектом в установленный срок.

Наблюдаемость

Способность восстановить фактическое поведение коммерческих объектов во времени.

Коммерческий разрыв

Наблюдаемое отличие факта от целевого или потенциального состояния.

Экономический резерв

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

Подтверждённый экономический эффект

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

CPL

Стоимость нового привлечения в согласованных границах расчёта.

TTC

Время до контакта или другого определённого коммерческого действия.

MQL

Состояние или квалификационный статус LeadID, соответствующий согласованным маркетинговым критериям.

SQL

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

GM1

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

LTV

Экономическая ценность отношений с клиентом на горизонте нескольких коммерческих циклов.

CRM

Технологический операционный слой исполнения коммерческой логики MOS.

Искусственный интеллект

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

Семь стадий зрелости MOS

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

Профиль зрелости MOS

Совокупность стадий зрелости отдельных архитектурных контуров MOS.

Ограничение

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

Управление по ограничениям

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

Сквозной управленческий слой

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

Граница MOS

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

Постоянное улучшение

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

В этой главе
  1. Введение
  2. 31.1. От маркетинговой функции к архитектуре коммерческого развития
  3. 31.2. Компания как система коммерческих потоков
  4. 31.3. Объектная архитектура как фундамент MOS
  5. 31.4. От воронки к коммерческому жизненному циклу
  6. 31.5. Семь архитектурных контуров MOS
  7. 31.6. Данные как память коммерческой системы
  8. 31.7. Экономика коммерческого потока
  9. 31.8. От функциональных KPI к сквозным результатам
  10. 31.9. Архитектура ответственности
  11. 31.10. CRM как операционный слой MOS
  12. 31.11. Автоматизация и искусственный интеллект: усиление, а не замена архитектуры
  13. 31.12. Собственник как архитектор коммерческой системы
  14. 31.13. MOS как развивающаяся система
  15. 31.14. Границы MOS
  16. 31.15. MOS как операционная система коммерческого развития
  17. Заключение
  18. Глоссарий главы 31

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

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