BI мертв, да здравствует BI!
Настоящим узким местом никогда не был анализ.
Делиться

За десять лет работы с данными я неоднократно наблюдал одно и то же повторение:
- Крупная технологическая компания сталкивается с техническим или технологическим ограничением.
- Они решают эту проблему внутри компании, используя новое программное обеспечение/парадигму (разработанную с учетом их масштаба, ограничений и инженерной культуры).
- Они пишут об этом. (и, возможно, если все сложится удачно, откроют исходный код).
- Пара инженеров основала компанию по продаже управляемой версии.
- Спустя несколько лет, к лучшему или к худшему, остальная часть отрасли перенимает эту технологию.
Примеров множество: Airbnb писала об Airflow в 2015 году; концепция Modern Data Stack возникла из волны публикаций о внутренних платформах данных в Uber, Netflix и других компаниях; а dbt превратилась из внутреннего инструмента в де-факто стандарт того, как команды, работающие с данными, моделируют данные сегодня. Иногда инструмент работает без проблем, иногда — только в той среде, для которой он был создан, но закономерность сохраняется.
Каждый цикл становился возможным благодаря решению фундаментальных проблем или широкому распространению ресурсов. Распределенные вычисления положили начало эре Hadoop, а затем дешевое облачное хранилище и развитие инструментов самообслуживания открыли путь к современной архитектуре обработки данных (MDS).
Однако в эпоху MDS узким местом были не технические аспекты, а аналитические возможности человека: какие вопросы задавать, где (и как) искать ответы и как эти ответы связаны с желаемыми бизнес-результатами. Никакое количество дополнительных данных или вычислительных мощностей не могло решить эту проблему, как мы коллективно доказали, выпустив тысячи и тысячи моделей dbt без каких-либо конкретных бизнес-результатов. Какое-то время это казалось неразрешимым ограничением, с которым нам придется смириться.
Затем появились агенты искусственного интеллекта и перевернули всё с ног на голову. Впервые возможность задавать вопросы, анализировать данные и находить ответы больше не зависит от количества аналитиков, которых вы можете нанять, или от количества панелей мониторинга, которые вы можете создать. Анализ, мой дорогой специалист по данным, больше не является узким местом .
Это значит, что новый цикл уже начался.
OpenAI, Meta и ClickHouse (и многие другие) за последние несколько месяцев опубликовали подробные статьи о том, как они отказываются от аналитики, ориентированной на панели мониторинга, в пользу агентов искусственного интеллекта в качестве основного механизма потребления данных, полностью меняя привычный нам процесс бизнес-аналитики. Эта тенденция знакома, но прежде чем делать очевидный вывод («Бизнес-аналитика мертва, будущее за агентами ИИ»), стоит задать более тонкий вопрос: как должен выглядеть мир с бесплатным и неограниченным анализом? К какой модели нам следует стремиться?
Что вообще было не так с бизнес-аналитикой?
Типичный рабочий процесс в сфере бизнес-аналитики всегда выглядел следующим образом:
- Бизнес-пользователю необходимо ответить на вопрос.
- Они ищут подходящую панель мониторинга, обнаруживают, что её не существует, и отправляют запрос.
- Они ждут две недели, пока команда обработки данных это сделает. (Кто сказал «узкое место»?)
- К тому моменту, когда панель мониторинга запускается, пользователи либо уже переключаются на что-то другое, либо бегло просматривают её, не замечая никаких существенных изменений. (Трудно измерить влияние на бизнес, когда его нет.)
Основная проблема описанного выше рабочего процесса (и того, как мы подходили к бизнес-аналитике на протяжении десятилетий) заключается в том, что он построен вокруг вопросов, которые уже были заданы. В конце концов, информационная панель — это ответ на вопрос, который кто-то задавал в определенный момент времени, зафиксированный на графике (и, вероятно, уже неактуальный).
Ещё большее разочарование вызывает то, что я бы назвал проблемой закрытого окна. В инструменте бизнес-аналитики вы можете увидеть лишь часть происходящего — «Корпоративные пользователи стали меньше взаимодействовать с этой функцией», — но вы никогда не увидите полную картину. Что ещё изменилось для корпоративных пользователей? Что они делают вместо этого? Что изменилось в самой функции? Инструмент может показать вам только то, что кто-то уже решил измерить. Он не может выявить то, о чём никто не подумал спросить.
ИИ-агенты представляют собой реальное улучшение в этом отношении. Новое поколение (например, то, что разработали Meta, OpenAI и ClickHouse) выходит далеко за рамки преобразования текста в SQL: эти агенты могут ориентироваться в бизнес-контексте, рассуждать на основе документации и кода и отвечать за несколько секунд/минут на сложные вопросы, на решение которых аналитику потребовались бы дни.
Но я думаю, что мы оптимизируем не на том уровне. Все эти передовые улучшения находятся на этапе «как мне ответить на этот вопрос?». Вопрос, предшествующий ему — «какой вопрос мне вообще следует задавать?» — по-прежнему полностью остается на усмотрение пользователя.
Проблема, которая еще не решена: какие вопросы мне вообще следует задавать?
Когда я был руководителем отдела продуктов в Sifflet, платформе для мониторинга данных, мы постоянно сталкивались с одним и тем же неожиданным явлением: клиенты использовали наши функции оповещений для отслеживания бизнес-показателей (например, сигналов оттока клиентов, изменений спроса и операционных аномалий). Эти оповещения не имели никакого отношения к мониторингу конвейеров данных или выявлению проблем с качеством данных — их единственная цель заключалась в том, чтобы понять, какие показатели меняются в бизнесе и стоит ли реагировать на эти изменения.
Что особенно поражало, так это то, что у этих клиентов были зрелые инструменты бизнес-аналитики, специализированные аналитические команды и инфраструктура отчетности, которой позавидовало бы большинство компаний. Это были не какие-то амбициозные стартапы без ресурсов, но они все равно разрабатывали продукт для мониторинга данных, чтобы получить то, чего не могли дать ни один из этих инструментов: систему, которая отслеживала их данные по тысячам таблиц и сообщала им — без запроса — когда происходило что-то действительно важное.
Они не злоупотребляли нашим продуктом. Они создавали, используя то, чего еще не существовало, — то, что было найдено на их основе.
Итак, как же на самом деле должна выглядеть новая модель?
Отвечать на вопросы быстрее никогда не было самой сложной задачей. Настоящая проблема всегда заключалась в начальном этапе: в понимании того, какие вопросы действительно стоит задавать.
Для решения этой задачи требуется работать на совершенно другом уровне: не на уровне запросов, не на уровне визуализации, а на уровне бизнес-целей . И как бы невероятно это ни звучало, это вполне осуществимо уже сегодня.
Как это выглядит на практике
Компания А (представим, что это SaaS-компания) определяет три вещи:
- Их основная бизнес-цель: сохранение чистой выручки (NRR).
- Показатели, определяющие это: использование функций в зависимости от уровня учетной записи, объем заявок в службу поддержки, частота входов в систему и т. д.
- Данные, отражающие вышеуказанные показатели.
Для обработки таких данных требуются очень доступные инструменты: несколько файлов Markdown, дерево метрик (в любом формате, от dbt YAML до естественного языка) и указатели на соответствующие таблицы.
Теперь представьте, как их команда разработчиков отслеживает внедрение функций сегодня: у них есть удобная, фильтруемая и красивая панель мониторинга, которая показывает внедрение по когортам/уровням/географическим регионам. Но она не показывает, что у всех компаний с самым низким уровнем внедрения есть общая черта в их CRM: это компании среднего размера, закрывшиеся в четвертом квартале, когда конкретная команда продаж занималась адаптацией новых клиентов. Эта проблема с адаптацией, которая не имеет ничего общего с продуктом или его функциями, никогда не отобразится на существующей панели мониторинга.
Ни один аналитик не создал панель мониторинга для этой корреляции, потому что ни одному аналитику не пришло в голову связать данные об использовании продукта с данными об атрибуции отдела продаж. Никто не задал правильный вопрос, потому что никто не знал, что это правильный вопрос .
Однако агент, действующий, исходя из четко определенной цели, а не из конкретного вопроса, поступил бы именно так. Поскольку NRR является результатом, который стоит защищать, у агента есть основания одновременно анализировать данные о продукте, записи в CRM и историю адаптации — и основания выявлять закономерности, о которых никто не подумал спросить.
Вот модель: задайте намерение один раз, а затем позвольте системе наблюдать и выявлять то, что важно, без каких-либо запросов.
Уровень бизнес-намерений
Очевидный вопрос заключается в том, что отличает значимый сигнал (то есть «то, что имеет значение») от шума. В конце концов, усталость от оповещений погубила не одно поколение инструментов мониторинга, и никто не хочет создавать следующую жертву этой тенденции. Ответ (к счастью) заключается не в более умном детекторе, а в контексте .
Важность того, чтобы сигнал привлек внимание, заключается в его связи с тем, что вы уже говорили о своей заинтересованности. Снижение количества входов в систему само по себе ничего не значит, но такое же снижение показателя, влияющего на удержание клиентов, — это проблема, о которой кому-то нужно знать. (И знать об этом нужно сегодня, а не на следующем обзоре панели мониторинга.)
Все необходимые компоненты для создания этого уже существуют:
- Бизнес-контекст хранится в Notion или Confluence.
- Определения метрик хранятся в семантическом слое или файлах Markdown.
- Смысл данных заключен в вашем каталоге и кодовой базе.
- Оркестрация осуществляется с помощью dbt или Airflow.
В отдельности ничто из этого не ново. Не хватало лишь связующего звена: агента, который бы объединял все это, осуществлял автономный мониторинг и выявлял важные моменты еще до того, как кто-либо подумает спросить.
К слову, именно это и пытались собрать воедино клиенты Sifflet с помощью инструмента мониторинга данных: у них были компоненты, но не хватало того, что связывало бы их воедино и определяло их цель.
Бизнес-аналитика эпохи дашбордов имела правильную цель (получить преимущество от данных), но неправильный формат вывода: она была создана для мира, где человек открывает браузер, смотрит на график и решает, что он означает. Однако оказывается, что существование этого мира было лишь следствием узкого места, связанного с бизнес-целями, и вся ценность заключается в предварительном этапе: куда смотреть и что искать?
Что будет дальше?
Публикации Meta, OpenAI и ClickHouse — это самый явный сигнал о начале нового цикла. И если эта тенденция сохранится, то то, что сегодня используют внутри нескольких технологических компаний, через три года станет отраслевым стандартом.
Но хотя нынешняя волна блестяще решает задачу самостоятельной аналитики (любой вопрос, который вы задумали, получает ответ быстрее и с большим контекстом, чем любая панель мониторинга), более глубокий вопрос: «На что мне вообще следует обращать внимание?», остается открытым. Тот, кто на него ответит, не просто создаст лучший инструмент бизнес-аналитики. Он определит, что значит быть компанией, ориентированной на данные, в эпоху агентов.
Именно для этого и стоит строить.
Махди Карабибен Посмотреть все работы Махди Карабибена
Источник: towardsdatascience.com
Похожие записи
Похожие записи
По сообщениям, духовный преемник Titanfall от 1047 Games будет называться Empulse.
19.05.2026
Учёные создали процессор, имитирующий работу мозга
01.04.2026
«Сионистская банда угонщиков»: как евреи попытались захватить Ан-2, чтобы сбежать из СССР
16.06.2025Подписка на рассылку
Получайте свежие новости и идеи на почту. Без спама — только самое интересное.
Нажимая «Подписаться», вы соглашаетесь с политикой конфиденциальности.
