Сбор данных для автоматизации: что подготовить до начала проекта

01Почему порядок в данных решает больше, чем выбор программы

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

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

02Карта источников: где на самом деле живут ваши данные

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

Бытовой пример из торговой компании: цены — в таблице снабженца, скидки — в переписке директора с менеджерами, условия доставки — в старом файле на диске и частично в голове логиста, фотографии товаров — в телефоне маркетолога. Пока это не записано, каждый новый сотрудник учится методом расспросов. Карта источников впервые делает проблему видимой.

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

03

Опись — это следующий шаг после карты: вы просматриваете каждый материал и ставите ему статус. Статусов достаточно три: «можно опираться», «нужно обновить», «выбросить или убрать из работы». Не стремитесь прочитать всё досконально. Задача описи — отделить надёжное от мусора и назначить, кто обновит сомнительное.

Во время описи обязательно находятся дубли. Типичная находка: прайс на диске, прайс в почте и прайс в мессенджере — и все три немного разные. Правило: дубли убираются из рабочих мест, остаётся один главный файл с понятным названием и датой. Остальные переносятся в архив, чтобы никого не соблазняли. Это занимает час, а спасает от месяцев путаницы.

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

04Проверочные примеры: двадцать случаев, которые покажут правду

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

В набор специально добавляют сложные случаи. Клиент пишет с ошибками и без знаков препинания. В одном сообщении два вопроса: про цену и про сроки. Просит посчитать нестандартный комплект. Уточняет условия для другого города. Спрашивает про скидку, которой нет в прайсе. Если проверять только на простых примерах, первая же неделя реальной работы разочарует.

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

Читайте также: Пилот ИИ: как проверить результат до большого запуска

05Наведение порядка: что чистим в первую очередь

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

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

Чистку ограничивают по времени: три-пять дней на материалы одного процесса. Не пытайтесь заодно переписать все регламенты компании. Отмечайте найденные проблемы за пределами пилота отдельным списком «на потом». Цель чистки — рабочий набор для проверки, а не идеальный архив.

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

06Исключения: что помощнику трогать запрещено

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

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

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

Читайте также: Как выбрать процесс для автоматизации

07Доступы: кому что можно видеть и трогать

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

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

Отдельно договариваются о каналах: через какую почту и какие мессенджеры идёт работа, кто подключает помощника к ним, где хранятся пароли и ключи. Самодеятельное подключение «давайте я быстро привяжу свой личный аккаунт» запрещают: при увольнении сотрудника доступы должны остаться у компании, а не уйти вместе с ним.

08Обновления: кто и как держит данные свежими

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

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

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

Читайте также: Этапы внедрения ИИ: от задачи до рабочей системы

09Передача материалов в проект: как принимается готовность

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

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

Частые вопросы

Источники

• NIST AI Risk Management Framework — управление данными и рисками
• NIST AI RMF Playbook — практические шаги по данным и контролю