После первой выгрузки подрядчик говорит: «данные не готовы». Звучит как приговор проекту, а на деле за этой фразой стоят очень разные вещи — от недели работы до отдельного проекта перед ИИ. Разберем, какие дефекты в данных 1С и CRM встречаются чаще всего, что каждый из них делает с ИИ-проектом, как найти их до старта и сколько стоит ремонт.
Три разных диагноза под одной фразой
Первое, что стоит спросить у подрядчика: что именно не готово. Ответов бывает три, и стоят они очень по-разному.
- Данных нет или к ним нет доступа. Нужное не записывается вовсе, лежит в почте и таблицах на личных дисках или система не отдает выгрузку.
- Данные есть, но грязные: дубли, пропуски, разнобой в справочниках, противоречия между системами.
- Данные чистые, но не подходят для задачи: нет истории, нет правильных ответов для обучения, период слишком короткий.
Первый диагноз решается организационно, иногда — изменением процесса. Второй — инженерной работой над конвейером данных. Третий — временем: историю нельзя купить, ее можно только начать собирать.
Дефект первый: дубли в справочниках
Самый частый случай. Один контрагент живет в трех карточках: ООО «Ромашка», «Ромашка» ООО и Romashka LLC. Одна позиция номенклатуры записана десятком способов. Для модели это разные сущности: история клиента разорвана на куски, статистика по товару занижена.
В нашем проекте для производителя ферросплавов одна позиция существовала в десятках написаний у разных поставщиков. Нормализация наименований и единый справочник продукции стали частью решения, а уже поверх них работало сопоставление по химическому составу, фракции и показателям качества. Подготовка отчета сократилась с нескольких дней до 30 минут, маржа по ключевым контрактам выросла на 5–7%.
Сложность в том, что дубли нельзя сливать вслепую. Позиции, различающиеся одним параметром, выглядят как дубли, но это разные марки с разной ценой. Поэтому автоматическое сведение работает только для очевидных случаев, а спорные подтверждает аналитик.
Дефект второй: свободный текст вместо полей
Поле «Комментарий» в CRM служит статусом, причиной отказа и датой следующего звонка одновременно. Формально данные есть, на деле они в тексте, и каждый менеджер пишет по-своему. Модель, обученная на таких полях, учится на шуме.
Здесь как раз пригодится языковая модель: она извлекает из комментариев причину отказа или дату в отдельное поле, а специалист выборочно проверяет результат. Но параллельно стоит починить источник: добавить в карточку поле со списком значений, чтобы новые записи приходили чистыми. Иначе извлечение придется повторять бесконечно.
Дефект третий: системы противоречат друг другу
Сделка в CRM закрыта как успешная, а оплаты в 1С нет. Отгрузка проведена в учете, а в CRM заказ все еще «в работе». Для отчета это неприятность, для бота, который отвечает клиентам о статусе заказа, — прямая ошибка: он сообщит то, чего не было.
Проверяется это сверкой: берут одни и те же объекты в двух системах за период и считают долю расхождений по статусам, суммам и датам. Если расхождений много, сначала договариваются, какая система главная для каждого поля, и только потом строят что-то поверх.
Дефект четвертый: история перезаписана
Большинство систем хранит текущее состояние: цену, ответственного, статус. Старое значение перезаписывается. Для прогноза и любой модели, которая учится на прошлом, нужно состояние на дату — что было известно в момент решения.
Без снимков модель при обучении видит будущее. Например, учится предсказывать уход клиента по полю «статус», в котором уже записано «ушел». На истории она показывает блестящий результат, в эксплуатации — никакой.
Что делать: начать ежедневно сохранять снимки состояния прямо сейчас — история появится через несколько месяцев. А пока использовать то, что датировано по своей природе: документы, проводки, журналы изменений, если система их ведет.
Дефект пятый: поля, которые меняли смысл
До прошлого года поле «Регион» означало адрес доставки, потом — юридический адрес. Категории товаров перекроили при переходе на новую конфигурацию. Единицу измерения сменили со штук на упаковки. Модель, обученная на всем периоде, выучит смесь двух разных процессов.
Такие вещи знают только люди, которые работают с системой. Поэтому на диагностике мы спрашиваем не только о структуре данных, но и об истории: что менялось в процессе, в учете и в самой системе за последние два-три года.
Дефект шестой: пропуски, тестовые и удаленные записи
Массовые пропуски в главном признаке обесценивают выборку сильнее, чем ее малый размер. К ним добавляются тестовые записи вроде «Тест Тестович» с суммой 1 ₽, документы, помеченные на удаление, но не удаленные, и задвоенные загрузки.
По отдельности каждый из этих дефектов мелкий. Вместе они дают цифры, которые не сходятся с отчетами бухгалтерии, и доверие к модели теряется раньше, чем она успевает принести пользу.
Дефект седьмой: даты, которым нельзя верить
В учете есть две даты: когда событие произошло и когда его внесли. Документ проводят задним числом, отгрузки оформляют в конце месяца пачкой, филиалы в разных часовых поясах закрывают день в разное время. Для отчета это мелочь, для прогноза спроса — сдвиг продаж между неделями и месяцами.
Модель, обученная на дате ввода, учится предсказывать работу бухгалтерии, а не поведение покупателей. Поэтому на проверке отдельно смотрят, какая дата в каком поле лежит и как часто документы вводят с опозданием.
Как проверить данные до старта
Быстрый взгляд на выгрузку занимает день-два. Полная проверка со сверкой систем и разговорами с владельцами процессов — около недели. Мы делаем ее до обсуждения архитектуры, в таком порядке.
- Получить выгрузку за период — обычную, со всем мусором, а не отобранную.
- Посчитать заполненность важных полей и долю дублей в справочниках.
- Сверить одни и те же объекты между системами: статусы, суммы, даты.
- Расспросить владельцев процессов, что менялось в учете и в системах.
- Проверить, хранится ли история или только текущее состояние.
- Оценить, есть ли правильные ответы для обучения: решения, отметки, исправления.
Результат — список дефектов с оценкой по каждому: блокирует проект, чинится по ходу или не мешает. Последняя категория важна не меньше первых двух.
Практический прием: попросите выгрузку не только из систем, но и из таблиц, которые сотрудники ведут рядом с ними. Если отдел параллельно с CRM ведет свой Excel, там часто лежат данные, которых нет в системе, и подключать их придется в первую очередь.
Какие дефекты можно не трогать
Чинить все подряд — дорогой способ отложить проект. Дефект стоит исправлять, если он попадает в данные, на которых модель учится или по которым принимает решение. Опечатки в адресах не мешают прогнозу спроса, а дубли номенклатуры мешают. Пропуски в поле, которое модель не использует, можно оставить как есть.
Полезный вопрос к каждому дефекту: что сломается в задаче, если его не исправить? Если ответа нет, дефект подождет.
Чинить в источнике или по дороге
Исправлять можно в двух местах. В источнике — в самой 1С или CRM: слить дубли, сделать поля обязательными, поменять порядок ввода. Или по дороге — в конвейере данных, который забирает данные из систем и очищает их перед витриной.
Исправление в источнике чище, но медленнее: нужны владельцы систем, изменения процессов и обучение сотрудников. Исправление по дороге быстрее, но лечит последствия, а не причину. Обычно делают оба: конвейер — сразу, источник — постепенно. Сами источники мы не меняем, а только читаем из них. Правки в 1С и CRM вносят ваши администраторы.
Какая система главная для каждого поля
Когда системы противоречат друг другу, спор о том, чьи данные правильные, решают не голосованием, а правилом: для каждого поля назначают систему-источник. Например, реквизиты контрагента и оплаты берут из учетной системы, контактные лица, этап сделки и историю общения — из CRM, остатки — из складской системы, если она отдельная.
Правило записывают в документ, и конвейер данных следует ему: при расхождении берет значение из главной системы, а само расхождение отправляет в отчет для разбора. Без такого правила каждый отчет и каждая модель выбирают источник по-своему, и цифры снова расходятся.
Как устроен конвейер, который чистит данные
Данные из CRM, учетной системы и файлов собираются в хранилище в три слоя. Сырой слой хранит все как есть, и к нему всегда можно вернуться, чтобы пересчитать. Слой ядра содержит очищенные данные без дублей, с едиными справочниками. Витрины собраны под конкретные задачи: отчет, прогноз, модель.
На каждом прогоне работают автоматические проверки качества: заполненность, отсутствие дублей, допустимые значения, совпадение сумм с источником. Мы собираем их на Great Expectations или Soda. Если источник изменился или пришла аномалия, проверка останавливает загрузку и сообщает об этом раньше, чем грязная запись попадет в отчет или в модель.
Главное свойство такого конвейера: правило очистки пишут один раз, и оно работает на каждой новой загрузке. Ручная чистка выгрузки, сделанная для пилота, через месяц устаревает.
Персональные данные: что сделать до выгрузки
В CRM почти всегда есть персональные данные: имена, телефоны, переписка. Прежде чем передавать выгрузку подрядчику, решите, нужны ли они задаче. Для прогноза и сегментации обычно хватает обезличенных идентификаторов, а имена и телефоны можно заменить кодами.
Еще надежнее не передавать данные вовсе. Конвейер разворачивают в вашем контуре, на ваших серверах или в российском облаке, и данные не покидают периметр. Мы работаем именно так, а доступы выдаем по ролям.
Что каждый диагноз делает со сроками
- Нет доступа: недели на согласования. Тестовый доступ к корпоративной системе иногда получают дольше, чем идет сама разработка, поэтому запрашивать его надо в первый же день.
- Данные грязные: обычно к плану добавляется прототип конвейера на 2–4 недели — до модели или параллельно с ней.
- Нет истории: месяцы. Ее либо восстанавливают по документам, если они датированы, либо начинают копить и возвращаются к модели позже.
Диагноз и его влияние на срок стоит получить от подрядчика в первую же неделю. Если о данных вспомнили на втором месяце проекта, проверку просто пропустили.
Сколько стоит и сколько занимает
Прототип конвейера — 2–4 недели, от 600 тыс. ₽: подключаем основные источники и собираем первую витрину с проверками качества. Оценку полного проекта даем после диагностики, когда видны состав, объем и состояние источников. Сильнее всего цену двигают пять вещей.
- Число источников и есть ли у них API или доступ к базе.
- Объем дублей в справочниках и нужна ли ручная проверка спорных слияний.
- Нужно ли восстанавливать историю по документам.
- Сколько систем противоречат друг другу и решено ли, какая из них главная.
- Сколько данных лежит в файлах на личных дисках и в почте.
Условный пример для сравнения. Два источника — 1С и CRM, у обоих есть API, дубли только в справочнике контрагентов, история не нужна: это прототип на нижней границе срока. Пять источников, включая таблицы на личных дисках, без API и с историей, которую надо восстанавливать по документам: это отдельный проект перед ИИ, и честнее назвать его так сразу.
Кто нужен с вашей стороны
Три роли. Администратор каждой системы выдает доступы и объясняет, где что хранится. Владелец процесса знает, что означают поля и что менялось в учете. Ответственный за данные после запуска следит за отчетами о качестве и решает, что делать с расхождениями.
Последняя роль часто остается пустой. Тогда конвейер работает, а отчеты о расхождениях никто не читает, и через полгода данные снова не готовы.
Когда порядок в данных важнее ИИ
Иногда после проверки честный вывод такой: первым этапом должна стать не модель, а данные. Это не провал проекта. Единая витрина сама по себе приносит пользу: цифры в отчетах сходятся, споры о том, чьи данные правильные, заканчиваются, а следующая ИИ-задача стартует на подготовленной основе.
Проект можно остановить на этом этапе, и это нормальная точка выхода. Хуже, когда данные чинят внутри ИИ-проекта молча: сроки срываются, а бюджет уходит на работу, которую никто не планировал.
Коротко
- Фраза «данные не готовы» означает один из трех диагнозов: нет доступа, данные грязные или не подходят для задачи. Уточняйте, какой именно.
- Самые частые дефекты: дубли в справочниках, свободный текст вместо полей, противоречия между системами, перезаписанная история.
- Полная проверка данных занимает около недели и делается до обсуждения архитектуры.
- Чинят не все подряд, а то, что ломает задачу: в конвейере сразу, в источнике постепенно.
- Прототип конвейера — 2–4 недели, от 600 тыс. ₽.
- Иногда правильный первый этап — данные, а не модель.