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

Я регулярно слышу от руководителей примерно одну и ту же фразу: "У нас уже есть платформа данных, мы в прошлом году внедрили X." X - это может быть облачное хранилище, инструмент для ETL, BI-система или всё сразу. И когда начинаешь разбираться, оказывается, что платформы нет. Есть набор инструментов, которые установлены, но не связаны в единую систему управления данными.

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

Что отличает платформу от набора инструментов

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

Платформа данных - это когда:

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

Если хоть один из этих пунктов вызывает неловкость - скорее всего, речь идёт о наборе инструментов.

Почему это важно именно сейчас

В 2025 году разговор о платформе данных нельзя отделить от разговора об ИИ. Большинство ИИ-проектов, которые сейчас обсуждаются на уровне руководства, упираются в один и тот же вопрос: откуда возьмутся данные для обучения или работы модели?

Если ответ звучит как "надо собрать из нескольких систем и почистить", это значит, что фундамент для ИИ ещё не готов. Модель можно купить или арендовать. Данные в нужном качестве и структуре - нет.

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

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

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

Зависимость от конкретных людей. Когда уходит аналитик, который "знал, как работает выгрузка", - всё ломается. Это признак того, что знание о данных не задокументировано и не автоматизировано.

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

Как начать, не переделывая всё сразу

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

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

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

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

Вопросы для оценки текущего состояния

Если вы хотите быстро понять, где находится ваша компания, задайте эти вопросы своей команде:

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

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