Данные, а не модель: где на самом деле уходит бюджет

До 60% времени проекта тратится на подготовку данных. Доступ, качество, полнота, история.

Что произошло

Когда компания планирует бюджет ИИ-проекта, основная доля ожиданий — и опасений — связана с моделью: какую выбрать, сколько стоит, справится ли. По факту проектов картина другая. До 60% времени проекта уходит на подготовку данных: получение доступа, очистку, восстановление полноты, накопление истории. Модель — та часть, которая за последние годы стала самой предсказуемой: открытые модели закрывают большинство задач, а выбор между ними — вопрос недель, не месяцев.

Сдвиг произошёл незаметно. Раньше данные были побочным продуктом учётных систем, и их было достаточно для отчётности: сумма, дата, контрагент. Для ИИ этого мало. Модели нужен не факт, а контекст: что происходило до, что после, кто принял решение и почему, какие были альтернативы. Учётные системы этого не хранят, потому что их проектировали для другого.

В результате бюджет, спланированный вокруг модели, оказывается спланирован вокруг меньшей части работы. Большая часть — данные — обнаруживается по ходу, и именно она определяет сроки, стоимость и вероятность того, что проект вообще дойдёт до результата.

Где на самом деле уходит время

Доступ: данные есть, но не у проекта

Первое препятствие — не отсутствие данных, а невозможность их получить. Данные лежат в системах, которые принадлежат разным подразделениям, обслуживаются разными подрядчиками и защищены разными регламентами. Чтобы получить выгрузку из ERP, нужна заявка, согласование владельца системы, согласование безопасности, оценка нагрузки на продуктивную базу. Каждый шаг занимает время, и при нескольких источниках это складывается в месяцы — до того, как кто-либо посмотрел на содержимое.

Дополнительный слой — технический. Выгрузка «раз в месяц вручную в таблицу» непригодна для промышленной системы; нужен регулярный канал: реплика, витрина, поток событий через Kafka или аналог. Его нужно спроектировать, согласовать с администраторами систем-источников, протестировать под нагрузкой. Это ИТ-работа в чистом виде, и она не имеет отношения к ИИ, но без неё ИИ-проект не начинается.

Качество: поля заполнены, но не тем

Второе препятствие — содержимое. Поле «причина обращения» заполнено в каждой записи, но в заметной доле случаев выбрана первая позиция справочника, потому что оператору так быстрее. Поле «дата завершения» проставлена задним числом при закрытии периода. Поле «ответственный» содержит давно уволившегося сотрудника, потому что при передаче дел никто не переназначил. Для отчётности это терпимо: суммы сходятся. Для модели это шум, который она выучит как закономерность.

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

Модель не отличает закономерность процесса от закономерности заполнения формы. Она выучит обе.

Полнота: процесс живёт в мессенджерах

Третье препятствие — самое недооценённое. Значительная часть решений в компании принимается не в системах, а в переписке, на созвонах и в личных договорённостях. Согласование скидки, перенос срока поставки, решение о замене поставщика — в системе появляется результат, но не путь к нему. Модель, обученная на данных из системы, видит следствие без причины и не может воспроизвести логику, потому что логика нигде не зафиксирована.

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

История и сезонность: год — это минимум

Четвёртое препятствие — глубина. Для многих задач модели нужен полный цикл: годовая сезонность, цикл сделок, цикл обслуживания оборудования. Если система внедрена меньше года назад, а до неё была другая с иной структурой данных, истории для обучения нет. Её можно попытаться восстановить из старой системы — это миграция с маппингом полей, сверкой и неизбежными потерями. Или подождать, пока история накопится, — и тогда честный срок проекта сдвигается на год.

Здесь есть неочевидное следствие: если решение о накоплении истории не принято сегодня, через год ситуация не изменится. Данные, которые не собираются сейчас, не появятся задним числом. Поэтому даже при отсутствии готового ИИ-проекта запуск сбора данных по приоритетным процессам — рациональное вложение: оно создаёт возможность, которой иначе не будет.

Единый источник: три версии одной цифры

Пятое препятствие проявляется на стыке. Выручка по данным ERP, выручка по данным CRM и выручка по данным BI отличаются, и каждое подразделение уверено, что права его цифра. Различия объяснимы: разные моменты признания, разные курсы, разные фильтры. Но для модели три версии одного показателя означают, что признак не определён. Проект останавливается на согласовании того, какая цифра является истиной, — и это согласование может занять больше времени, чем построение модели.

Единый источник истины — не хранилище, а договорённость: для каждого показателя определено, откуда он берётся, как считается и кто за него отвечает. Хранилище лишь фиксирует договорённость технически. Следующий уровень — витрина признаков: слой, в котором признаки для моделей считаются один раз, документируются и переиспользуются между проектами. Без неё каждый новый проект заново проходит путь от сырых данных к признакам, и те же 60% времени тратятся повторно.

Четыре измерения готовности данных сведены в таблицу:

Измерение	Вопрос, на который нужен ответ	Где ломается	Кто отвечает
Доступ	Можно ли получать данные регулярно и автоматически	Согласования, нагрузка на продуктив, ручные выгрузки	ИТ, владельцы систем
Качество	Отражают ли значения полей реальность	Мотивация ввода, отсутствие контроля	Владелец процесса
Полнота	Зафиксированы ли решения, а не только результаты	Решения вне систем, мессенджеры	Владелец процесса
История	Есть ли полный цикл процесса	Смена систем, короткий срок сбора	ИТ и владелец процесса совместно

Как это выглядит на практике

Производственная компания, прогноз потребности в запчастях. Проект планировался на квартал. Первые недели ушли на получение доступа к системе ТОиР и складской системе — это разные подрядчики с разными окнами обслуживания. Затем выяснилось, что заявки на запчасти оформлялись в системе после фактической выдачи со склада, датой закрытия месяца. Реальные даты потребности жили в журнале мастера участка — бумажном. Проект перестроили: первым этапом стало оформление заявки в момент возникновения потребности, с планшета на участке. Модель обучили через два квартала, когда накопилась история с реальными датами.

Сеть клиник, прогноз загрузки и неявок. Данные о записях были полными, но история — короткой: медицинская информационная система была заменена год назад, а данные из прежней перенесли только по действующим пациентам. Сезонность по одному году не восстанавливалась. Решение: модель запустили в ограниченном режиме на короткой истории, параллельно восстановив агрегированные данные из старой системы по помесячной загрузке — не по пациентам, а по потоку. Этого оказалось достаточно для сезонной поправки.

Дистрибьютор, условия для клиентов. Скидки согласовывались в переписке между менеджером и руководителем; в CRM попадал итог. Модель, обученная на итогах, воспроизводила решения без понимания, почему одному клиенту дали больше, другому меньше. Проект остановили и начали с изменения процесса: заявка на скидку с обоснованием оформляется в CRM, там же согласуется. Через два квартала накопилось достаточно данных, чтобы модель предлагала условия с объяснением.

Во всех трёх случаях первый проект оказался не ИИ-проектом, а проектом по изменению процесса и сбору данных. И это правильная последовательность.

Что это значит для российской компании

Контур и 152-ФЗ определяют архитектуру данных. Для регулируемых отраслей персональные данные не могут покидать контур, а значит, витрина данных и признаков строится внутри, на инфраструктуре компании. Это увеличивает ИТ-составляющую проекта: нужны собственные хранилища, потоки, разграничение доступа. Стек для этого существует и зрел: PostgreSQL как основа хранилища, Kafka как шина событий, отечественные и open-source BI для витрин. Вопрос не в наличии технологий, а в наличии людей, которые их поддерживают.

Импортозамещение создало разрывы в истории. Многие компании заменили учётные системы за последние годы, и история осталась в старых системах, зачастую без поддержки. Восстановление истории — отдельный этап, который нужно закладывать в план, если модель требует сезонности или длинных циклов.

Дата-инженеры — более дефицитный ресурс, чем специалисты по моделям. Рынок труда предлагает больше людей, умеющих обучать модели, чем людей, умеющих построить надёжный конвейер данных из десятка унаследованных систем. Планируя команду, нужно исходить из того, что основная работа — инженерная.

Первый проект часто должен быть ИТ-проектом. Сбор данных, единый источник, витрина — это инфраструктура. Она не даёт эффекта в отчётности сама по себе, и её сложно защитить перед бюджетным комитетом как ИИ-инициативу. Но без неё все последующие ИИ-проекты будут заново тратить те же 60% времени. Честная постановка — «мы строим основание, на котором будут стоять следующие проекты» — это аргумент для бюджета.

Что делать: пошагово

Проведите аудит данных под конкретную задачу, а не в целом. Возьмите один процесс, который собираетесь улучшать, и ответьте на четыре вопроса: где лежат данные, можно ли их получить регулярно, насколько они точны, есть ли история за полный цикл. Результат — карта разрывов с оценкой трудоёмкости их закрытия.
Убедитесь, что процесс измеряется. Если показатель, который вы хотите улучшить, сейчас не фиксируется в системе с нужной детализацией, начните с измерения. Без базовой линии не будет ни модели, ни оценки эффекта.
Перенесите решения в систему. Определите, какие решения по процессу принимаются вне систем, и создайте для них минимальную форму фиксации: заявка, обоснование, согласование. Это меняет работу людей, поэтому нужен владелец процесса с полномочиями.
Постройте регулярный канал данных. Замените ручные выгрузки на автоматические: реплика, поток, витрина. Согласуйте с владельцами систем-источников нагрузку и окна. Это ИТ-задача, и её нужно ставить как ИТ-задачу с ИТ-сроками.
Договоритесь о едином источнике для ключевых показателей. Для каждого показателя, который участвует в задаче, зафиксируйте определение, источник и ответственного. Разногласия между подразделениями решаются на этом этапе, а не в ходе проекта.
Начните витрину признаков с первого проекта. Признаки, рассчитанные для первой модели, документируйте и храните так, чтобы следующий проект мог их переиспользовать. Это небольшая дополнительная работа сейчас и значительная экономия потом.
Запустите накопление истории по приоритетным процессам, даже если модель пока не планируется. Определите несколько процессов, где ИИ вероятен в горизонте двух лет, и обеспечьте сбор данных по ним уже сейчас.

Типичные ошибки

Выбор модели до аудита данных. Команда начинает с сравнения моделей. Почему это проблема: модель — наименее рискованная часть, а данных для неё может не оказаться. Что вместо: аудит данных первым, выбор модели — после того, как понятно, что есть.

Очистка вместо изменения процесса ввода. Данные вычищают перед обучением, а процесс продолжает порождать те же ошибки. Почему это проблема: через квартал модель работает на данных, которых не видела при обучении. Что вместо: изменить контроль на входе, очистку рассматривать как разовую меру для истории.

Выгрузки вместо каналов. Данные для пилота получают вручную. Почему это проблема: при переходе в эксплуатацию канала нет, и проект останавливается на интеграции. Что вместо: строить канал с первого дня, пусть в минимальном виде.

Игнорирование сезонности. Модель обучают на полугодовой истории. Почему это проблема: она не видела другого сезона и будет ошибаться предсказуемо. Что вместо: восстанавливать историю или честно ограничивать область применения.

Витрина «потом». Признаки считаются внутри каждого проекта заново. Почему это проблема: работа дублируется, определения расходятся, результаты разных моделей несопоставимы. Что вместо: минимальная витрина с первого проекта.

Данные как задача ИТ без владельца процесса. ИТ строит конвейер, но качество ввода определяет операционное подразделение. Почему это проблема: конвейер переносит мусор быстрее. Что вместо: владелец процесса отвечает за качество ввода, ИТ — за доставку.

Как понять, что вы на верном пути

Для задачи составлена карта данных: источник, способ доступа, оценка качества, глубина истории.
Целевой показатель процесса измеряется в системе, базовая линия известна.
Решения по процессу фиксируются в системе с обоснованием, а не только результатом.
Данные поступают автоматическим каналом, а не ручными выгрузками.
Для ключевых показателей есть единое определение и ответственный, с которым согласны все подразделения.
Признаки первой модели задокументированы и доступны для следующих проектов.
Доля времени на подготовку данных в плане проекта заложена явно, а не спрятана в «разработке».
Запущен сбор данных по процессам, где ИИ планируется в горизонте двух лет.

Вопросы, которые нам задают

Можно ли начать с модели на тех данных, что есть, и параллельно улучшать данные?

Можно, если это осознанное решение с ограниченными ожиданиями: модель на слабых данных покажет, где именно данные слабы, и это полезная диагностика. Нельзя, если результат такой модели планируется выдать за промышленный. Практика: короткий диагностический прогон — да, обещание эффекта — нет.

Стоит ли покупать готовую платформу данных или строить на open-source?

Зависит от команды. Платформа снижает трудоёмкость старта, но привязывает к вендору и требует лицензий, что в закрытом контуре и при импортозамещении становится риском. Open-source стек — PostgreSQL, Kafka, инструменты оркестрации — зрел и поддерживаем, но требует инженеров. Если инженеров нет и нанять их не удаётся, платформа с поддержкой оправдана. Если есть — собственный стек гибче и дешевле в эксплуатации.

Как обосновать бюджет на сбор данных, если эффекта в отчётности он не даст?

Как инфраструктуру: с указанием проектов, которые она сделает возможными, и оценкой того, сколько каждый из них потеряет времени без неё. Несколько проектов, каждый из которых тратит квартал на подготовку одних и тех же данных, против одного основания с переиспользованием — это арифметика, понятная бюджетному комитету.

Кто должен владеть данными — ИТ или бизнес?

Разделение простое: бизнес отвечает за смысл и качество ввода, ИТ — за хранение, доставку и доступ. Данные, за которые не отвечает бизнес, будут плохими; данные, которые не доставляет ИТ, будут недоступными. Практически это означает, что у каждого ключевого показателя есть два ответственных — владелец определения и владелец канала, — и оба названы по должностям в документе, который подписан до старта проекта.