Стратегическое планирование при развитом руководстве данных
В конце каждого года начинается период годового стратегического планирования. Этот период важен для определения траектории развития бизнеса. Однако этот процесс часто сталкивается с системными ограничениями, источник которых кроется в местах, которые либо сложно признавать, либо дорого исправлять. То есть либо в людях, либо в данных, на основе которых принимаются решения.
Отделы продукта защищают дорожные карты, маркетинг расписывает кампании, финансы сводят десятки таблиц, закупки строят прогнозы по сырью. Каждый замкнулся в своем эксель-файле, рождая цифры, основанные на «опыте», «ощущениях рынка» и устаревших отчетах прошлого квартала. Интуиция становится главным советником, а спешка заставляет закрывать глаза на неточности. Результат? К марту план начинает расходиться с фактом, к июню эти расхождения приходится «объяснять», а к сентябрю стратегия года безнадежно устаревает.
Но возможен философский и архитектурный переворот в подходе к планированию. Это не про создание еще одного отчета. Это про построение единой, достоверной, живой системы координат для всего бизнеса, в которой годовой план становится производной от проверенных фактов и четких моделей.
Важно понимать, что эта статья описывает целевое состояние и возможности, которые открываются при уже функционирующей и зрелой инфраструктуре управления данными. Управление данными это сложная организационно-техническая трансформация. Эволюционный путь со своими волнами, целевыми показателями и постепенной пользой для бизнеса. Здесь мы описываем не «как начать», а «что вы сможете делать, когда основа будет построена».
Почему традиционное планирование терпит неудачу?
Прежде чем говорить о решении, опишем саму проблему. Традиционный процесс построения бюджета и стратегии страдает от пяти системных проблем:
- Семантический разрыв, а не просто «разные метрики». Проблема не в том, что отделы считают по-разному, а в отсутствии формальной онтологии предметной области. В ERP «клиент» — это платёжеспособное юридическое лицо, в CRM — точка контакта для продаж, в аналитике — абстрактный идентификатор для расчёта LTV. При планировании эти сущности должны быть сопоставлены через универсальный ключ (например, D-U-N-S Number или внутренний Global Party ID), что невозможно без MDM. Реальный ущерб кроется не во времени на согласование, а в систематической ошибке в моделях (например, переоценка LTV из-за неконсолидированной истории взаимодействий).
- Изоляция данных как следствие организационной структуры (закон Конвея). Архитектура систем повторяет структуру отделов. Планы закупок не стыкуются с прогнозами продаж не из-за «плохой коммуникации», а потому что модель данных производства (BOM — Bill of Materials) в PLM/ERP и модель данных продаж в CRM существуют в разных системах координат. DG это механизм преодоления закона Конвея через создание сквозных доменных моделей данных (например, единой модели «Продукт» по всем департаментам).
- «Проклятие исторических данных»: регрессия к среднему как стратегический тупик. Планирование «от достигнутого» — это частный случай аналитической ловушки, когда данные есть, но контекст их генерации утерян. Рост на 15% в прошлом году мог быть вызван разовой маркетинговой акцией, а не трендом. Без Data Lineage, показывающего, как операционные события (акция) превратились в агрегированную метрику (рост продаж), любая экстраполяция ошибочна. Нужны не просто исторические данные, а информация о контексте их создания.
- Ручная консолидация — симптом отсутствия Data Pipeline как сервиса. Процесс планирования это, по сути, запуск распределённого ETL-пайплайна, где люди выступают в роли ненадёжных интеграционных шин. Решение не в автоматизации сбора Excel или отдельных систем, а в создании управляемого канала данных (Data Pipeline) для планирования, где:
- Источники — операционные системы с определённым SLA по актуальности.
- Трансформации — формализованные бизнес-правила из глоссария DG.
- Приёмник — специализированная CPM-система (Anaplan, Oracle Hyperion), работающая уже с готовыми к употреблению данными.
- Невозможность моделирования — это провал архитектуры аналитического слоя. Отсутствие «единой версии правды» здесь будет следствием того, что аналитический слой построен как набор изолированных витрин (Data Marts), а не как общая семантическая модель (Common Semantic Layer) на базе Kimball, Data Vault или аналогов. Для сценарного моделирования нужна не просто связь сущностей, а возможность выполнить «что, если»-запрос к этой модели, что требует её построения в in-memory или columnar СУБД с поддержкой сложных джойнов.
Что нужно построить на самом деле
MDM не должен выступать только справочником, это система записи о ключевых сущностях (System of Record).
Идея в том, что MDM должен предоставлять не только «золотую запись», но и полную историю её изменений (temporal data model) и граф связей (например, «клиент → заказы → продукты → компоненты → поставщики»). Для планирования критически важна возможность получить не только актуальное состояние, но и тренд изменения атрибутов (например, динамика цены поставщика).