Почему 70% ценности не требуют полноценной команды data science.
Первая и вторая части описали рамку и движок. Ни то ни другое ничего не стоит без ответа на вопрос, который любой руководитель задаёт третьим: кто это построит и нужно ли нанимать команду data science?
Ответ в основном отрицательный, и денежный довод здесь сильнее технического.
Инструменты — по тому, что они реально позволяют
| Уровень | Инструменты | До чего действительно дотягивается | Кто |
|---|---|---|---|
| Вручную | Excel, сводные таблицы, «Поиск решения» | Описание, локализация, простое «что если», простые правила | Любой сильный аналитик |
| Родной BI | Power BI, Tableau, Qlik, ThoughtSpot | Декомпозиция, ключевые факторы, топ-сегменты, прогноз, аномалии, «что если» | BI-аналитик |
| Low-code | KNIME, Dataiku, Alteryx, RapidMiner | Процессы, выявление аномалий, ML, SHAP, скоринг, причинное предсказание | Продвинутый аналитик |
| AutoML | Azure AutoML, H2O, Dataiku AutoML | Предсказание, прогнозирование, важность признаков | Продвинутый аналитик, младший DS |
| SQL и Python | SQL, PyOD, ruptures, SHAP, DoWhy/EconML, OR-Tools | Свои базы, обход срезов, причинная работа, оптимизация | DS, инженер аналитики |
| Enterprise | Платформы поставщиков | Сквозной процесс, оповещения, оптимизация | Зрелые организации |
| LLM-копайлот | ChatGPT, Copilot, KNIME K-AI | Черновики SQL и DAX, чек-листы по графам, пересказы, метки доказательности | Аналитик, под правилами |
Одна поправка к тому, как обычно подают последнюю строку: LLM-копайлот — не отдельный слой доказательности. Это ускоритель, лежащий поперёк всех остальных. Он двигает вас быстрее вдоль строки, но не двигает вниз по таблице. Если считать его отдельной ступенью, команда получает прекрасно оформленный причинный анализ, в котором эффект никогда не был идентифицирован.
Что обычный BI-аналитик может без посторонней помощи
Этот список я положила бы перед скептически настроенным финансовым директором, потому что он длиннее, чем кто-либо ожидает.
Сам, без специалиста по данным:
- корректная таблица фактов магазин × SKU × неделя, база и разрыв в продажах;
- анализ вкладов, деревья декомпозиции, ключевые факторы влияния, топ-сегменты;
- процесс в KNIME для аномалий и SHAP;
- оценка возможностей и расчёт недополученных продаж;
- рекомендации по правилам;
- метки доказательности на каждой находке;
- перепроверка находок на следующем периоде — самая дешёвая проверка из существующих.
С лёгкой проверкой со стороны data science:
- тесты Грейнджера, после аккуратной работы с сезонностью;
- простой эксперимент по магазинам, простая разность разностей;
- синтетический контроль или BSTS;
- причинное предсказание в low-code.
Никогда не выпускать без причинной экспертизы:
- граф PCMCI, поданный как доказанная причинность;
- наблюдательное двойное машинное обучение, причинные леса, инструментальные переменные, регрессионный разрыв, ступенчатая разность разностей;
- всё, где есть сильная каннибализация или взаимовлияние между единицами.
Ограничение здесь не Python. Каждый оценщик из третьего списка подключается одной строчкой импорта и вернёт уверенное число на любых данных, какие вы ему дадите. Ограничение в том, что математически корректный оценщик, применённый к данным, где эффект не идентифицирован, выдаёт неверный ответ с узким доверительным интервалом — и ничто в результате об этом не предупреждает.
AutoML и последние тридцать процентов
Стоит уточнить, что именно автоматические инструменты закрывают, а что нет.
- Языковые модели — настоящий помощник в причинной работе: превратить расплывчатый вопрос в воздействие, исход, единицу и время; набросать граф; задать вопросы про пропущенные переменные; заметить переменные, возникшие после воздействия; сгенерировать чек-лист и код. Судьёй они не являются.
- Azure AutoML и H2O — сильный предсказательный слой: классификация, регрессия, прогнозирование. Причинным дизайном они не являются и не претендуют.
- Dataiku Causal Prediction — ближайшее low-code предложение по причинности: выбираете исход и воздействие, получаете оценки прироста. Смешивающие факторы, перекрытие и взаимовлияние он за вас не проверит.
- DoWhy содержит правильную логику — смоделировать, идентифицировать, оценить, опровергнуть — и говорит об этом прямо. Но его гарантия звучит как «если этот граф верен, вот набор поправок и оценщик». Никогда — «ваш граф верен».
- KNIME K-AI генерирует процессы, визуализации и код по запросу. Отличные леса, но не проверяющий дизайн.
Вывод обобщается за пределы этого списка инструментов и переживёт его: последние двадцать-тридцать процентов — причинную проверку — автоматизации отдать нельзя. Всё, что до неё, отдать можно, и всё больше. Именно вокруг этого соотношения и стоит планировать наём.
Наём: небольшая способность, а не спаситель
Типичный провал — нанять «специалиста по данным, который разберётся». Нужна небольшая способность из пяти различимых ролей, причём не все обязаны быть на полной занятости, а одна может быть советником.
- Переводчик аналитики, руководитель коммерческой аналитики — вероятно, ключевой наём. Знает RGM, трейд-промо, управление категорией, разницу между sell-in и sell-out, дистрибуцию, доступность, данные сетей. Его работа — превращать бизнес-вопрос в воздействие, исход, единицу и время.
- Специалист по причинному выводу — часто на частичной занятости или советником. Графы, разность разностей, синтетический контроль, BSTS, склонности и DML, причинные леса, анализ чувствительности, взаимовлияние.
- Разведочный ML — выявление аномалий, базы на остатках, поиск срезов, SHAP, ранжирование, проверка устойчивости. Быть причинным экспертом не обязан.
- Инженер данных и аналитики — критичен и его регулярно недонанимают. Иерархии, промо-календарь, цена, запас, данные конкурентов, признаки со сдвигом, надёжность обновления.
- BI- и продуктовый инженер — превращает результат в рабочий процесс: оповещения, снимки доказательств, владелец и действие, путь обратной связи.
Задача для собеседования получше абстрактного упражнения по ML. Дайте кандидату таблицу магазин × SKU × неделя — продажи, цена, промо, выкладка, доступность, дистрибуция, регион, сеть, промо конкурента — и попросите: сформулировать бизнес-вопрос; выбрать воздействие, исход, единицу и время; набросать граф; назвать смешивающие факторы, медиаторы и коллайдеры; прямо сказать, на что контролировать нельзя; предложить маршрут от диагностики к причинности; описать, как он подаст результат коммерческому директору.
Красные флаги: «зальём всё в XGBoost, а SHAP покажет причинные факторы»; «DML сам разбирается с причинностью»; «граф нарисовала модель, значит, всё в порядке»; «контролируем на всё»; «Грейнджер доказывает причинность».
Зелёные флаги: «сначала давайте определим вмешательство»; «это переменная после воздействия, на неё контролировать нельзя»; «для общего и прямого эффекта нужны разные контроли»; «это связь, пока мы её не проверим».
Про стажёров и младших специалистов: используйте их как управляемую мощность для прототипов — сравнение алгоритмов поиска влияющих факторов, прототип недополученных продаж, оценка возможностей, библиотека причинных дизайнов, система меток доказательности. Не оставляйте их без рамки, иначе получите XGBoost плюс SHAP плюс причинный лес, непроверенные, в презентации.
Почему это более дешёвый путь
Три места, где деньги экономятся ещё до того, как хоть одна модель доедет до продакшена.
Вы не покупаете то, что вам не нужно. Если работу разложить как следует, первые 70% ценности дают корректная гранулярность, настоящая база, поиск срезов, связывание и оценка возможностей. Ничего из этого не является многомесячной консалтинговой программой. По большей части это грамотный аналитик, лицензия на BI и полгода.
Вы не ставите ложных показателей. Самая дорогая ошибка в этой области — требовать причинного доказательства от диагностической модели: получится либо выдуманный ответ, либо восемнадцатимесячный проект, заканчивающийся извинениями. Понимание ступеней доказательности — то, что не даёт заказать не то, и защита эта не стоит ничего, кроме общего словаря.
Вы покупаете внешнюю экспертизу по гораздо лучшей цене. Если ваша команда уже сделала инвентаризацию данных, определения метрик, карту сценариев использования, первый слой связей и черновой граф, то объём работ внешнего эксперта звучит как «проверьте этот дизайн и подтвердите три главных случая», а не «постройте всё с нуля». Это другой контракт и другое число в нём.
Версия для руководства:
Во многих FMCG-организациях 70% практической ценности не требуют полноценной команды data science. Они требуют дисциплинированной коммерческой аналитики: чистой гранулярности, согласованных баз, автоматического поиска срезов, обнаружения связей, оценки возможностей и решенческого процесса. Оставшиеся 30% — причинный вывод, дизайн экспериментов, продвинутый ML, оптимизация промышленного уровня — стоит покупать или нанимать выборочно, и только когда внутренняя команда понимает, что именно нуждается в экспертной проверке.
Отсюда следует вывод, антиконсалтинговый и, по-моему, всё же верный:
Первый проект по ИИ-аналитике в FMCG не должен быть внедрением от поставщика. Он должен быть внутренним упражнением по грамотности и определению границ.
Чего я сказать не могу
Деление 70 на 30 — это суждение, полученное разложением работы, а не измеренная величина, и точные числа я защищать не стану. Что я защищать буду, так это форму: дешёвый слой больше, чем подразумевает отраслевой маркетинг, а дорогой — уже и специализированнее, чем предполагает наём универсалов.
Публичные кейсы из FMCG и ритейла, которые подтверждают здесь осуществимость, — Store DNA у PepsiCo на Azure ML, примерно 2% приростных продаж на трейд-промо у McKinsey, цифры по недополученным продажам и восстановлению у NIQ, тесты причинного воздействия у Kroger и 84.51° — это заявления поставщиков или заказчиков. Они показывают, что такое построить можно. Ни один из них не публикует распределение воздействия, стандартные ошибки, предтренды, обработку перетоков или сырые данные, так что ни один не является независимо проверенным эффектом, и ни одно из их чисел я не стала бы использовать для расчёта бизнес-кейса.