MOS для управления бизнесом

Практическое руководство для собственников и топ-менеджеров.

Андрей Лапиков, DBA · Иван Куц

Советник.Эксперт · 2026

Открывайте раздел по задаче: архитектура — 05–12; диагностика — 13–20; цели и планирование — 21–28; ответственность — 29–34; регулярное управление — 35–41; экономика — 42–48; данные — 49–52; внедрение — 53–58. Готовые формы — 59–64.

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

I. Архитектура MOS — 05–12

II. Диагностика бизнеса — 13–20

III. Цели и планирование — 21–28

IV. Ответственность — 29–34

V. Регулярное управление — 35–41

VI. Экономика MOS — 42–48

VII. Данные и технологии — 49–52

VIII. Внедрение MOS — 53–58

IX. Рабочие приложения — 59–64

Управленческий вопрос: почему отделы выполняют свои KPI, а компания — нет?

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

Действия: 1) зафиксировать общую цель; 2) описать коммерческий поток; 3) сопоставить локальные и сквозные KPI; 4) назначить владельцев интерфейсов; 5) проверять эффект решений.

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

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

Marketing Governance: распределение ответственности, правила принятия решений, стандарты KPI, контроль интерфейсов и экономических ограничений.

Marketing Operations: исполнение, измерение, обнаружение отклонений и корректирующие действия.

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

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

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

Проверка: на каждый приоритет стратегии приходится KPI, владелец и ресурс; каждое существенное отклонение получает решение и дату проверки.

Пример: цель 100 сделок не является планом маркетинга, пока не рассчитаны SQL, MQL, ресурсы и мощность продаж.

1. Brand Creation: сформирован выбор. 2. Demand Stimulation: активирован спрос. 3. Commercial Presence: предложение доступно в момент выбора. 4. Lead Acquisition: зарегистрирована самостоятельная потребность (LeadID), выполнен стандарт MQL. 5. LLM: принятый MQL развивается до SQL. 6. Sales Operations: принятый SQL проходит Opportunity и коммерческое продвижение до Deal и передачи. 7. Owner Management: после OWNER_ACCEPTED управляется эпизод владения и распознаётся новый спрос.

Первые четыре преобразования — MVC. Семь преобразований не равны трём уровням MOS.

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

Не сводить всю цепочку к одной числовой воронке: Brand Creation и Demand Stimulation требуют собственных показателей выбора и спроса, а Owner Management — отдельной экономики клиентской базы.

Решение: утвердить паспорта выходных результатов по семи преобразованиям.

MVC: выбор, спрос, присутствие, LeadID и квалификация до MQL.

LLM: после MQL_ACCEPTED развитие потребности до SQL; передача завершена событием SQL_ACCEPTED.

Sales Operations: SQL_ACCEPTED → Opportunity → Commercial Progression → Deal → Deal Handoff.

Owner Management: начинается событием OWNER_ACCEPTED, ведёт Ownership Episode и выявляет новую самостоятельную потребность.

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

LeadID обозначает отдельную потребность; один клиент может иметь несколько потребностей. MQL и SQL — состояния квалификации, а не новые клиенты. Opportunity — объект работы продаж; DealID — признанная сделка; Ownership Episode — отношение идентичность × продукт × период владения.

MVC → LLM: MQL_ACCEPTED. LLM → Sales: SQL_ACCEPTED. Sales → Owner: OWNER_ACCEPTED.

Отправка ≠ приёмка. Новая самостоятельная потребность создаёт новый LeadID; реактивация незавершённой сохраняет прежний.

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

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

Решение: провести аудит MQL_ACCEPTED, SQL_ACCEPTED, OWNER_ACCEPTED; исключить автоматическое «закрытие» объекта только из-за смены статуса.

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

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

Запросить за сопоставимые периоды: рынок и долю; затраты и источники; уникальные LeadID и MQL; SQL_ACCEPTED; Opportunity, визиты и сделки; маржу и переменные затраты; повторные сделки и события владения.

Проверка данных: определения, дедупликация, время фиксации, источники, когорты. При разрывах отмечать «не измеряется», а не подставлять догадки.

Результат: карта данных и перечень вопросов, требующих дополнительной проверки.

Постройте поток по когортам: зарегистрированные LeadID → MQL_ACCEPTED → SQL_ACCEPTED → Opportunity → Deal → OWNER_ACCEPTED. Визит — важная операция Sales Operations, но не универсальная обязательная стадия всех продаж.

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

Решение: выбрать переходы для проверки причин.

Демонстрация: 800 принятых MQL; 40% становятся принятыми SQL (320). При достижимой конверсии 50% — 400 SQL. Если SQL → Deal = 25%, потенциал 100 вместо 80 сделок, то есть +20.

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

Не называйте +20 гарантией: это условный прирост при неизменных остальных параметрах.

У отдела привлечения выполнен план LeadID; контакт-центр обработал обращения в SLA; продажи сохранили конверсию SQL → Deal — но нужный объём SQL_ACCEPTED не получен. Локальные «зелёные» KPI не компенсируют дефицит результата на интерфейсе.

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

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

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

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

Пример: увеличение SQL бессмысленно, если мощности продаж не позволяют принять дополнительные Opportunity.

Решение: утвердить очередность по ожидаемому чистому эффекту и исполнимости, не по числу обращений к руководству.

Нормативные стадии: 1. Фрагментарная; 2. Формализованная; 3. Наблюдаемая; 4. Управляемая; 5. Экономически управляемая; 6. Предиктивная; 7. Адаптивная.

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

Решение: определить целевой профиль зрелости, а не требовать немедленно «седьмую стадию» везде.

Минимальная запись: ID проблемы; наблюдаемое отклонение; данные; причина/гипотеза; предполагаемый экономический эффект; действие; владелец решения; срок; статус; проверка.

Причина не подтверждена? Первое действие — проверка гипотезы, а не наказание исполнителя. Закрытие выполнения и подтверждение эффекта — разные события.

Решение: один сквозной реестр для руководителей контуров и операционного штаба.

Демонстрация: целевой рынок 2 000 автомобилей в месяц, желаемая доля 5% → 100 сделок. При 250 000 ₽ валовой маржи на сделку — 25 млн ₽ валовой маржи, не чистой прибыли.

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

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

Демонстрация: цель 100 сделок, SQL_ACCEPTED → Deal 25%, MQL_ACCEPTED → SQL_ACCEPTED 50%, LeadID → MQL_ACCEPTED 80%. Требуется 400 SQL, 800 MQL и 1 000 LeadID. При предельной оценке 3 000 ₽/LeadID расходы только на получение лидов составят 3 млн ₽.

Не приравнивайте это к полной стоимости MOS: добавьте расходы квалификации и продаж. Проверьте изменение CPL при росте закупки и мощности.

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

Демонстрация: 2,4 млн ₽ бюджета получения лидов / 3 000 ₽ = 800 LeadID; × 80% = 640 MQL; × 50% = 320 SQL; × 25% = 80 сделок.

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

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

Top-down = 100 сделок; Bottom-up = 80; GAP = 20. Оцените альтернативы: дополнительный качественный спрос, рост MQL → SQL, рост SQL → Deal, устранение задержек.

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

Решение: выбрать пакет изменений с общей моделью эффекта или изменить цель.

Top-down отвечает: какие ресурсы нужны? Bottom-up: какой результат достижим? GAP: что изменить?

Порядок: (1) исходные предпосылки; (2) расчёт обратной цепочки; (3) расчёт прямой цепочки; (4) совместный сценарий; (5) проверка экономики и мощностей; (6) утверждение.

Один согласованный набор определений и конверсий; версии предпосылок сохраняются.

Верхний уровень: сделки, вклад в покрытие, экономическая ценность клиентской базы. Под ним — LeadID, MQL_ACCEPTED, SQL_ACCEPTED, Opportunity, Deal, приёмка в Owner и события нового спроса. По каждому переходу — объём, конверсия, время, стоимость.

Сделки ≈ SQL_ACCEPTED × конверсия в Deal; вклад в покрытие = сделки × вклад на сделку при сопоставимой структуре продаж.

Решение: убрать KPI, не связанные с управляющим воздействием или результатом.

MVC: необходимый объём квалифицированного MQL и ресурсы. LLM: необходимый SQL_ACCEPTED с установленными SLA. Sales Operations: Opportunity, Deal и передача в Owner. Owner Management: действующая база, удержание, эпизоды владения и создаваемый новый спрос — отдельный план без двойного счёта.

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

Решение: один согласованный план со сквозным владельцем и пересмотром прогноза.

Проверить шесть ограничений: рынок и спрос; стоимость масштабирования; нормативные конверсии; время обработки; мощности продаж и товар; достаточность маржинального вклада.

Для каждого записать «выполняется / под угрозой / не выполняется», доказательство и действие.

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

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

Для активного объекта обязательны назначенный владелец, следующее действие и дата.

Решение: не приравнивать должностной план руководителя к автоматическому владению всеми объектами и переходами.

Data Owner: определение и качество данных. Decision Owner: полномочие принять конкретное решение. Technology Product Owner: развитие технологической функции. Они не заменяют Process Owner.

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

Решение: утвердить карту полномочий и эскалации.

Используйте RACI для решений, а не только для отделов: утверждение MQL Standard; приёмка SQL; распределение бюджетов; пересмотр плана; изменение CRM-статусов; подтверждение эффекта.

Для решения — один A, один или несколько R, необходимые C и I. Убедитесь, что A обладает полномочием.

Решение: утвердить матрицу на межфункциональном комитете.

При переходе MQL → LLM, SQL → Sales или Deal → Owner требуются стандарт готовности, срок, принятие и журнал результата. Смена статуса не заменяет MQL_ACCEPTED, SQL_ACCEPTED, OWNER_ACCEPTED.

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

Решение: внедрить контроль неподтверждённых и просроченных передач.

Типовые споры: «некачественный лид», «продажи не приняли SQL», «сделка закрыта, владелец не принят», «отчёты расходятся».

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

Решение: если договориться нельзя, передать вопрос Decision Owner с полномочием над затронутым интерфейсом.

Проведите тест на пяти реальных объектах: LeadID, MQL, SQL, Deal, Ownership Episode. Для каждого найдите текущего Object Owner, следующее действие, срок, Process Owner и подтверждённую историю передач.

Критерий: не обнаружены бесхозные объекты или «приёмки задним числом».

Решение: пробелы перенести в реестр операционных нарушений.

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

Частота зависит от скорости процесса и стоимости задержки.

Решение: назначить владельца каждого цикла и исключить дублирующие совещания.

Панель исключений: новые LeadID, MQL_ACCEPTED, SQL_ACCEPTED, просрочки приёмки, Opportunity, Deal, фактический маржинальный вклад, критические возвраты.

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

Решение: утвердить пороги вмешательства, а не требовать полного доклада по всем метрикам ежедневно.

30 минут (пример): 0–5 — отклонения; 5–10 — прошлые решения; 10–20 — подтверждённые причины и гипотезы; 20–27 — решения, владельцы, сроки; 27–30 — способ проверки эффекта.

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

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

Пример: MQL_ACCEPTED → SQL_ACCEPTED упал с 50% до 40%. Вместо требования «увеличить звонки» штаб поручает проверить когорты, пропуски SLA, причины дисквалификации и нагрузку LLM.

Проверка выполнена? Тогда выбирается конкретное исправление и целевой показатель.

Решение: отдельно фиксировать диагностическую гипотезу, корректирующее действие и доказательство эффекта.

60 минут (пример): 10 мин — экономика и доля; 10 — прогноз; 15 — ограничения; 15 — решения о ресурсах; 10 — ответственность и контроль.

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

Выход: утверждённые изменения и обновлённый прогноз.

Статусы: Назначено → В работе → Выполнено → Эффект проверен → Закрыто. Негативный или неподтверждённый эффект возвращает проблему в управленческий цикл.

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

Решение: не принимать «исполнено» как синоним «помогло».

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

Порядок: измерить отклонение, проверить временный/структурный характер, пересчитать Bottom-up, определить GAP, оценить альтернативы, утвердить прогноз и ресурсное решение.

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

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

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

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

CPL = релевантные затраты на привлечение / число уникальных лидов. Стоимость MQL, SQL и сделки считают со строго указанным составом затрат. CAC должен относиться именно к новым клиентам.

Пример: 3 млн ₽ рекламы / 1 000 LeadID = 3 000 ₽ за лид; при 100 сделках 30 000 ₽ рекламных затрат на сделку, не полная стоимость продажи.

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

800 MQL, 40% переходят в SQL, достижимый ориентир 50%: +80 SQL. При 25% SQL → Deal возможно +20 сделок. Если вклад одной дополнительной сделки до затрат мероприятия 150 000 ₽, условный дополнительный вклад = 3 млн ₽.

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

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

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

Демонстрация: привлечение: 1,6−1,0=0,6 млн ₽; LLM: 1,2−0,4=0,8; продажи: 1,5−0,6=0,9. Это независимые условные сценарии; при совместном запуске пересчитайте их взаимное влияние.

Решение: финансировать эффективный пакет, устраняющий ограничение потока.

Успешная сделка не равна передаче в Owner. После OWNER_ACCEPTED фиксируется Ownership Episode: клиент, продукт, начало и история владения, сервисные и коммерческие события.

Повторная покупка, замена, дополнительная покупка и рекомендация могут сформировать новый Demand Episode с новым LeadID. Оценка LTV требует горизонта, вероятностей, вкладов и затрат, а не суммы выручки.

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

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

Проверка: какая комбинация параметров делает чистый эффект отрицательным? В каких точках вложение нужно остановить?

Решение: утвердить финансовый лимит, стоп-условия и дату пересчёта.

Формула: E = ΔQ × C − ΔK, где ΔQ — дополнительное число сделок; C — вклад на сделку до расходов, учитываемых в ΔK; ΔK — дополнительные затраты мероприятия.

Пример: 20 × 150 000 − 800 000 = 2,2 млн ₽. Оцените вклад внешних факторов и устойчивость прироста.

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

Минимум: Identity, Product, LeadID, MQL/SQL states, Opportunity, DealID, Deal Handoff, OWNER_ACCEPTED, Ownership Episode, New Demand Episode. Объект хранит идентификатор, текущее состояние, владельца, следующее действие и историю событий.

Одна Identity может иметь несколько LeadID; реактивация прежней незавершённой потребности сохраняет LeadID.

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

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

Если маркетинг считает 1 200 событий обращения, а продажи — 950 уникальных LeadID, это не автоматическая ошибка: единицы учёта разные.

Решение: согласовать словарь и проводить регулярную сверку перед совещаниями.

CRM ведёт объекты и операции; телефония фиксирует контакты; аналитика объединяет события и экономику; автоматизация контролирует сроки; ИИ помогает прогнозировать и выделять аномалии.

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

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

Каждое требование оформлять по схеме: проблема; объект; событие; бизнес-правило; владелец; исключение; контрольный KPI; критерий приёмки; экономическая оценка.

Пример: при отсутствии SQL_ACCEPTED по истечении SLA инициировать уведомление владельцу процесса; не переводить ответственность автоматически.

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

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

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

Дни 1–30: диагностика и постановка пилота. 31–60: стандарты, данные, приёмка, контроль и первые коррекции. 61–90: экономическая проверка, решение о масштабе и план дальнейшего внедрения.

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

Решение: утвердить контрольные точки и ответственных.

Неделя 1: владельцы, границы пилота. Неделя 2: события и показатели. Неделя 3: ограничения и экономический потенциал. Неделя 4: целевая модель, паспорт пилота.

Результат: подтверждённые исходные когорты, критерии приёмки объектов, прогноз эффекта и план ресурсов.

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

Внести стандарты передачи; назначить владельцев объектов; обеспечить события MQL_ACCEPTED / SQL_ACCEPTED / OWNER_ACCEPTED, если затронуты пилотом; открыть KPI и реестр; проводить штаб и проверять решения.

Результат: работает замкнутый цикл; отклонения обнаруживаются раньше потери результата.

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

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

Решение: масштабировать, продлить пилот с новой гипотезой, изменить подход или остановить.

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

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

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

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

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

Отметки: □ подтверждено □ частично □ отсутствует. Приложить документ или пример события.

Выход: три первоочередных управленческих разрыва и владельцы проверки.

Период: ______. Рынок / доля: план ___, факт ___, прогноз ___. MQL_ACCEPTED ___ / ___ / ___. SQL_ACCEPTED ___ / ___ / ___. Opportunity ___ / ___ / ___. Deal ___ / ___ / ___. Вклад в покрытие ___ / ___ / ___. Расходы ___ / ___ / ___. Сигналы нового спроса ___ / ___ / ___.

Главное отклонение: _____. Причина или гипотеза: _____. Решение и владелец: _____. Дата проверки: _____.

Колонки: результат преобразования; объект; KPI и формула; план; Process Owner; Object Owner на соответствующей стадии; Data Owner; источник; период; эскалация.

Обязательны строки: MVC / MQL_ACCEPTED; LLM / SQL_ACCEPTED; Sales / Deal и OWNER_ACCEPTED; Owner / Ownership Episode и New Demand Episode.

Проверка: назначены владельцы всех критических решений и событий.

Дата ______, период ______, председатель ______.

Отклонение / источник данных: ______. Подтверждённая причина или гипотеза: ______. Диагностическая проверка либо корректирующее действие: ______. Владелец: ______. Срок: ______. Целевой KPI: ______. Дата проверки: ______.

Прошлые решения: выполнено? эффект подтверждён?

Эскалация: кому передано, срок решения.

Сценарий: _____. Период: _____. Дополнительные сделки ΔQ: _____. Вклад до расходов мероприятия C: _____. Дополнительные затраты ΔK: _____.

E = ΔQ × C − ΔK = _____.

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

Решение: □ утвердить □ уточнить □ отклонить. Контрольная дата: _____.

• □ Есть единая коммерческая цель.
• □ Определены три уровня управленческих решений.
• □ Описаны семь преобразований.
• □ У четырёх контуров есть владельцы.
• □ Передачи подтверждены событиями.
• □ Объекты не остаются без владельцев.
• □ Есть сопоставимые KPI.
• □ Согласованы Top-down/Bottom-up/GAP.
• □ Оценивается вклад в покрытие.
• □ Регулярные решения проверяются по эффекту.
• □ Клиентские эпизоды и новый спрос учитываются без двойного счёта.
• □ Пилоты масштабируются только после проверки.

Главное ограничение: _____. Следующее решение: _____. Владелец/срок: _____.