Разговор о проекте обычно начинается с задачи: хотим прогнозировать спрос, ловить отток, проверять качество на линии камерой. Через месяц выясняется, что данных под задачу либо нет, либо они непригодны, и вместо обещанной модели команда полгода занимается нормализацией справочника номенклатуры. Проект при этом уже оплачен и защищён перед собственником как проект про искусственный интеллект.
Обидно здесь то, что почти всё это было видно заранее. Пригодность данных проверяется одной выгрузкой и часом работы — не требуется ни аналитика в штате, ни специальных инструментов. Достаточно уметь считать строки и задавать неудобные вопросы про то, кто и когда заполняет каждое поле.
Ниже — порядок проверки, по которому мы сами оцениваем задачу до того, как назвать срок и цену. Он одинаково полезен и когда вы выбираете подрядчика, и когда решаете делать своими силами: в обоих случаях цена ошибки на этом шаге измеряется месяцами.
Три вопроса, и порядок здесь важен
Вопросов ровно три, и они идут последовательно. Каждый следующий имеет смысл, только если на предыдущий ответ положительный. Нарушение порядка — типичная причина, по которой обследование данных растягивается на месяц вместо трёх дней.
- 1Есть ли данные вообще. Не «есть ли база», а фиксируется ли в принципе то событие, которое вы хотите предсказывать или проверять. Хотите прогноз оттока — где отмечен факт ухода клиента? Если нигде, у вас есть только косвенный признак «не покупал четыре месяца», и его придётся сначала превратить в определение, а потом защищать перед коммерческим директором. Хотите контроль качества камерой — сколько у вас фотографий брака? В девяти случаях из десяти брак есть, а снимков нет: дефектную деталь отправляют в переплавку, а не в фотостудию.
- 2Доступны ли они технически. Данные могут существовать и быть недостижимыми: лежать в регистре 1С без внешнего доступа, в облачной CRM, где API открывается на тарифе вдвое дороже, у оператора телефонии со сроком хранения записей 30 дней, в почтовом ящике уволившегося сотрудника. Отдельная и очень частая история — данные в отчётах, которые собираются руками: они есть в виде готовых сводок за месяц, но исходных строк, из которых сводки получились, не сохраняет никто.
- 3Достоверны ли они. Совпадает ли запись с тем, что происходило физически. Статус «отгружено» проставляют пачкой в пятницу вечером за всю неделю. Время звонка в CRM — это время, когда менеджер вспомнил его завести. Себестоимость поправили после закрытия периода. Формально данные есть и они полные, фактически по ним нельзя восстановить последовательность событий — а именно последовательность и нужна модели.
Попросите ИТ-специалиста или подрядчика по учётной системе сделать одну вещь: выгрузку нужной таблицы за 24 месяца в CSV. Не витрину, не отчёт — сырые строки со всеми полями. Если выгрузка приходит за день, технический вопрос снят. Если на неё нужна неделя согласований и доработка на стороне вендора за 180 000 ₽ — это уже часть бюджета проекта, и её лучше увидеть до подписания договора, а не после.
Сколько истории нужно под конкретную задачу
Универсального ответа «нужно много данных» не существует — требования отличаются на порядок в зависимости от того, что именно вы строите. Половина задач автоматизации вообще не требует истории: роботу на входящей линии, напоминанию об оплате или проверке договора нужен актуальный регламент, а не архив за три года.
| Задача | Сколько истории нужно | Минимальный объём и условие |
|---|---|---|
| Правила: маршрутизация, напоминания, проверки, роботы | История не нужна | Нужны актуальный справочник и письменный регламент, а не архив |
| Классификация обращений и документов | 3–6 месяцев | 300–500 размеченных примеров на каждый класс; если классов больше 15 — сначала укрупнить |
| Прогноз оттока клиентов | 12 месяцев | Не менее 300 состоявшихся уходов и письменное определение, что считается уходом |
| Прогноз спроса и запасов | 18 месяцев, лучше 24–36 | Два прохода через один и тот же сезон; по позиции не меньше 60 недель с ненулевыми продажами |
| Контроль качества компьютерным зрением | Истории нет, нужны снимки | 300–500 кадров на каждый тип дефекта, снятых на рабочей камере при рабочем освещении |
Логика цифр простая. Восемнадцать месяцев для спроса — это не красивое число, а требование увидеть один и тот же месяц дважды: иначе модель не отличит сезонный провал от падения продаж. Триста уходов для оттока — это про то, что редкое событие нужно показать алгоритму достаточное число раз: если за год ушли 40 клиентов, никакая модель не научится, зато сегментация вручную вполне справится. Сотни кадров на дефект — потому что каждый тип брака выглядит по-разному, и класс, представленный десятью снимками, система будет уверенно пропускать. И отдельно про камеру: снимки с телефона мастера не заменяют кадры с производственной камеры — свет, ракурс и резкость другие, модель обучится на них и на линии не заработает.
Четыре болезни, которые видно в первый день
Данных обычно хватает по объёму — проблемы в качестве. Четыре диагноза покрывают подавляющее большинство случаев, с которыми мы сталкиваемся на обследовании.
- Дубли. Один клиент живёт четырьмя карточками: телефон записан через +7 и через 8, почта в разном регистре, компания заведена как ООО Ромашка и как Ромашка ООО. При расчёте оттока три карточки из четырёх выглядят ушедшими, при подсчёте среднего чека выручка размазывается. Лечится нормализацией по телефону, ИНН и почте — это день работы, если есть хоть один надёжный ключ, и отдельный проект, если ключа нет.
- Пропуски. Поле есть, но заполнено у 40% строк. Рабочее правило: признак, заполненный реже чем в 70% строк, в модель не идёт. Хуже другое — пропуски почти никогда не случайны. Если менеджеры указывают источник заявки только по крупным сделкам, то данные систематически смещены, и модель выучит не поведение клиентов, а привычки менеджеров.
- Ручные правки задним числом. Даты отгрузки проставлены пачкой в конце месяца, суммы поправлены после закрытия периода, статусы сделок приведены в порядок перед отчётом собственнику. В итоге в базе аккуратная картина, которой в реальном времени никогда не существовало.
- Разные справочники в разных системах. В 1С позиция называется Смеситель К-12, на сайте — Смеситель Kxx-12, у поставщика это артикул 4512, а в отчётах отдела продаж — просто смеситель. Пока нет таблицы соответствия, любая сквозная аналитика — фикция. По нашей практике сшивка справочника на 8–12 тысяч позиций занимает от 2 до 6 недель и должна идти отдельной строкой бюджета, а не считаться подготовкой к проекту.
Модель показывает 94% точности на исторических данных и 61% в эксплуатации. Причина почти всегда одна: в обучающую выгрузку попало поле, которое заполняется после того момента, когда модель должна дать ответ. Причина отказа, дата закрытия сделки, итоговая сумма отгрузки, отметка о возврате. Алгоритм честно нашёл закономерность — только пользоваться ею в бою невозможно, потому что в момент прогноза этого поля ещё нет. Проверка на каждое поле в выгрузке: в какой момент оно получает финальное значение? Если позже точки принятия решения — поле выкидывается, даже если оно самое информативное. Особенно если оно самое информативное.
Проверка за час: восемь запросов к одной выгрузке
Нужна выгрузка сырых строк за 12–24 месяца и любой инструмент, который умеет группировать и считать — от сводных таблиц до пары SQL-запросов. Порядок действий такой.
- 1Число строк по месяцам. График должен быть ровным с понятной сезонностью. Провал в апреле означает переезд на новую систему, потерянный кусок или смену методики — и границу, левее которой данные брать нельзя.
- 2Доля пустых значений по каждому полю. Столбец с 15% заполнения — не признак, а надежда. Отложите такие поля сразу, чтобы не спорить о них потом.
- 3Уникальность идентификатора: количество строк против количества различных id. Расхождение означает либо дубли, либо то, что вы выгрузили не то, что думали.
- 4Дубли по бизнес-смыслу. Нормализуйте телефон до десяти цифр, почту до нижнего регистра, ИНН до цифр — и посчитайте различных клиентов заново. Разница между двумя числами и есть цена вашего справочника.
- 5Минимумы и максимумы по датам и суммам. Даты в будущем, 1900 год, отрицательные количества, чек в сорок раз выше медианы — каждая такая строка означает либо ошибку ввода, либо процесс, о котором вам не рассказали.
- 6Число различных значений в полях-справочниках. Если в поле «источник заявки» 340 различных значений при двенадцати реальных каналах, поле заполняли текстом вручную, и его придётся приводить к списку.
- 7Двадцать случайных строк глазами. Возьмите двадцать записей и сверьте их с первичными документами и с людьми, которые их заводили. Это единственная проверка, которую нельзя сделать запросом, и именно она обычно приносит главную новость.
- 8Момент заполнения каждого поля. Спросите у того, кто работает в системе руками: когда сюда попадает окончательное значение — сразу, вечером, в конце месяца, при закрытии периода? Ответы записать рядом с названиями полей.
Такой результат — норма, а не катастрофа. По нашей практике после чистки остаётся 40–60% исходного объёма, и главная ценность расчёта не в проценте потерь, а в том, что он сделан за час и до подписания договора. Дальше разговор с подрядчиком становится предметным: вместо «сделайте нам прогноз спроса» вы говорите «у нас 16 месяцев пригодной истории, что из этого реально построить».
Что делать, если данных мало
Вывод «данных не хватает» не означает «автоматизация невозможна». Он означает, что нужно поменять задачу первого этапа. Вариантов, по сути, четыре, и они хорошо комбинируются.
| Ситуация | Что делать | Чего не ждать |
|---|---|---|
| История есть, но короткая — меньше полугода | Поставить сбор правильно: журнал событий с отметками времени, обязательные поля, единый справочник. Вернуться к задаче через 9–12 месяцев | Не рассчитывайте, что модель обучится на том, что есть: она обучится на шуме и будет уверенно ошибаться |
| Событие не фиксируется вообще | Сначала внедрить то, что создаёт данные: логирование звонков, распознавание документов, речевую аналитику, фотофиксацию на линии | Первый год такой проект окупается операционно, а не предсказаниями. Так его и защищайте перед собственником |
| Данных много, но они грязные | Выделить нормализацию в отдельный этап со своим сроком, бюджетом и приёмкой по измеримому критерию | Не ждите, что подрядчик приведёт в порядок справочник на 10 000 позиций внутри основного бюджета |
| Своих данных мало, задача типовая | Добрать внешними источниками: погода, производственный календарь, цены конкурентов, справочники контрагентов, отраслевые индексы | Внешние данные не заменяют собственную историю — они объясняют её колебания. Без своей базы прогнозировать нечего |
| Данных мало и в обозримом будущем не будет | Правила вместо модели: пороги, сегменты, сценарии, написанные вместе с сильными сотрудниками | Правила не станут точнее со временем сами. Зато они работают с первого дня и накапливают разметку |
Прототип на ваших данных — не опция, а условие сделки
Демонстрация подрядчика всегда работает. Она собрана на его данных, где справочник чистый, разметка полная, а сложные случаи в выборку не попали. Единственный способ узнать, есть ли сигнал в вашей базе, — запустить прототип на вашей выгрузке до того, как подписан основной договор. Разумная форма — платный пилот на 2–4 недели стоимостью 5–12% от бюджета проекта: сумма, которую не жалко потерять, и достаточная, чтобы подрядчик работал всерьёз.
- Критерий успеха записан до начала. Например: на отложенной выборке модель находит не менее 60% клиентов, ушедших в последние три месяца, при доле ложных срабатываний не выше 25%. Без записанного заранее числа итогом пилота всегда будут «интересные результаты, нужно ещё немного данных».
- Выборка для проверки отрезана по времени, а не случайно. Учимся на месяцах с первого по пятнадцатый, проверяем на шестнадцатом–восемнадцатом. Случайное перемешивание дат — тот же взгляд в будущее, только незаметный.
- Сравнение с простым решением обязательно. Модель сравнивается не с нулём, а с текущим порядком работы и с правилами на трёх признаках. Если разница в пределах пары процентов, честный вывод — брать правила.
- Данные передаются обезличенными и по договору. Обычно достаточно заменить имена, телефоны и адреса на идентификаторы: для обучения важны связи, а не персональные данные конкретных людей.
- Отрицательный результат оплачивается так же, как положительный. Ответ «в ваших данных сигнала нет» стоит 300 000 ₽ и экономит 3 000 000 ₽. Подрядчик, который не готов такой ответ произнести, найдёт сигнал в любом случае.
И последнее наблюдение, из-за которого стоит проходить всю эту процедуру всерьёз. Обследование данных почти всегда меняет исходную задачу. Приходят за прогнозом спроса, а выясняется, что половина срывов поставок объясняется не спросом, а отсутствием единого справочника между складом и закупками — и правильный первый проект стоит вчетверо дешевле и делается за месяц. Это не поражение, а лучшее, что может случиться с бюджетом на автоматизацию.
Модель не создаёт информацию, которой нет в данных. Если решение невозможно принять, глядя на выгрузку внимательным взглядом аналитика, алгоритм в ней тоже ничего не найдёт — он лишь сделает незнание быстрым и уверенным.
