Commercial control tower для CEO/CMO/CFO: один экран, который должен быть

Где живут коммерческие данные сейчас

В большинстве телекомов коммерческая картина видна через несколько источников.

Маркетинг показывает свой дашборд — кампании, конверсия, охват, отклик.

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

Retention имеет свой — churn, удержания, отказы.

Customer care имеет свой — звонки, NPS, время разрешения.

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

Network ops имеют отдельный дашборд технических метрик.

Каждый источник имеет свои числа, свою логику расчётов, свои горизонты. Когда CEO нужно понять «как идут продажи», он получает разные ответы от разных команд. Когда CFO нужно объяснить совету директоров «почему ARPU стагнирует», ему приходится сводить версии вручную. Когда CMO нужно решить «сколько вложить в digital-канал», он опирается на маркетинговый дашборд, который другим командам кажется чрезмерно благоприятным.

Это не «нет данных». Это противоположное — слишком много данных без общей основы.

Что значит control tower предметно

Commercial control tower — это не «ещё один дашборд». Это архитектурное решение, которое:

Имеет один набор цифр. Все ключевые метрики (ARPU, базы, retention, churn, продажи, маржа) определены однажды и считаются однажды. Каждая команда видит одни и те же цифры.

Real-time или near-real-time. Не «обновляется на следующий день», а сводки на текущее состояние. Это позволяет принимать решения быстрее.

Drill-down. От верхнего уровня (общий revenue) можно опускаться к под-сегментам (revenue по сегментам, по регионам, по продуктам, по каналам).

Cross-functional. Видны связи между метриками — например, как изменения в маркетинге отражаются на retention, как изменения в network experience отражаются на churn.

Action-oriented. Не просто дашборд, а ссылки на действия — увидел проблему, сразу видишь, кто owner и какие шаги доступны.

Без хотя бы трёх из пяти этих характеристик «control tower» остаётся очередным дашбордом.

Что обычно мешает построить

Проект кажется «BI-инициативой». В реальности это не BI — это перестройка коммерческой operating model. BI без operating model — это фейковый control tower.

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

Master definitions нет. ARPU считается тремя командами по-разному. CFO считает по биллингу, маркетинг — по выручке, зачисленной клиенту, финансовое планирование — по выручке за вычетом скидок. Без согласия на определение control tower не строится.

Vendor preferences. Разные команды используют разные инструменты — SAS, Power BI, Tableau, кастомные. Перевод на один инструмент политически сложен.

Фундамент данных. Master customer ID, event-level data, real-time pipeline — без этого control tower не работает технически.

Совет директоров не видит ROI. «Зачем тратить год на дашборд» — частый вопрос. Ответ — это не дашборд, это операционная дисциплина. Но это сложная продажа.

Что должно быть в control tower

Top-level revenue view. Общая выручка, по сегментам, по продуктам, по регионам. С drill-down.

Active base view. Размер активной базы по сегментам, динамика, чистый прирост.

Churn view. Добровольный churn, недобровольный, причины (топ 5-10 reason codes), churn по сегментам, MNP-отток и приток.

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

Margin view. Маржа по сегментам и продуктам, не только выручка. Часто отсутствует — выручка измеряется, маржа нет, и решения принимаются на выручке.

Customer satisfaction. NPS по сегментам, тренды жалоб.

Network impact. Корреляция между качеством сети и churn, продажами по регионам.

Marketing efficiency. Расходы по каналам, attribution-aware результаты, ROI по кампаниям.

Без любого из этих элементов картина неполная. Без всех вместе сложно принимать информированное решение.

Реалистичный roadmap построения

Control tower занимает 12-18 месяцев. Поэтапно.

Месяцы 1-3. Фундамент. Master definitions для всех ключевых метрик. Совет директоров утверждает. Политически тяжёлый этап.

Месяцы 4-9. Сборка ядра. Top-level views — revenue, базы, churn. Основные элементы. Real-time или near-real-time pipeline.

Месяцы 10-15. Расширение. Margin views, customer satisfaction, network impact. Drill-down capabilities.

Месяцы 16-18. Операционная дисциплина. Еженедельный обзор, на котором C-level смотрит control tower. Решения принимаются на его данных, не на параллельных отчётах.

К 18-му месяцу control tower работает как слой принятия коммерческих решений. Команды могут продолжать использовать свои операционные дашборды, но C-level и стратегические решения делаются на единых данных.

Что часто идёт не по плану

Сборка дашборда без master definitions. Получается красивый интерфейс, который показывает разные числа в зависимости от того, какие данные в него закладывают.

Vendor lock-in. Один вендор строит control tower, и через 3-5 лет смена вендора занимает столько же месяцев, сколько изначальная сборка.

Избегание тяжёлых тем. Control tower показывает только pretty picture, опускает маржу, churn по причинным сегментам и другие неудобные правды. Это вред — control tower должен показывать проблемы, не только успех.

Без операционной дисциплины. Control tower собран, но C-level продолжает использовать параллельные отчёты от команд. Это значит, control tower эффективно не используется, и инвестиция не возвращается.

Real-time на всех метриках. Не все метрики нужны real-time. Маржа может быть ежемесячной. NPS — ежеквартальным. Real-time только там, где имеет смысл — sales activity, system incidents, large changes.

Когда не стартовать control tower

Если фундамент данных rough — master ID нет, события не унифицированы, source-системы сильно фрагментированы — control tower выше фундамента. Сначала фундамент.

Если C-level не committed на 12-18 месяцев инвестиции — стартовать после commitment, не до.

Если нет центральной функции Data Office или эквивалента — нет owner ни определений, ни сборки, ни операций.

Если организация в острой фазе RFP по биллингу или CRM — control tower на меняющихся underlying-системах нестабилен.

Если конкурентная среда требует сегодня же решений и нет 12 месяцев — фокус на быстрых победах, control tower позже.

Что обсудить на committee

Какие 3-5 цифр различаются между видами разных команд? Это и есть entry point.

Кто committed на то, что master definitions метрики X будут такими-то? Без этого commitment не запустится.

Готов ли C-level смотреть один дашборд вместо нескольких параллельных? Это поведенческое обязательство.

Какие пробелы в фундаменте данных блокируют control tower? И каков timeline их закрытия?

Какой 18-месячный бюджет нужен и есть ли он?

Что может сделать SamaraliSoft

Commercial Control Tower Architecture — аудит текущего состояния коммерческого измерения (где разрозненность, какие проблемы), сборка рамки master definitions, дизайн архитектуры control tower с 7-9 ключевыми views, blueprint data pipeline и real-time компонента, организационный дизайн операционной дисциплины и поэтапный rollout с пилотом на нескольких коммерческих views.

Внутренние ссылки

• /insights/telecom-subscriber-intelligence-operating-model/ — operating model
• /architecture/telecom-around-core-architecture/ — слой вокруг core
• /insights/telecom-sales-attribution/ — attribution
• /insights/telecom-retention-economics/ — retention economics

Источники

• Digital Government Portal — digital infrastructure UZ
• UzDaily — рынок телекома Центральной Азии
• Министерство цифровых технологий — телеком в УЗ
• MNP.UZ — портабельность