Руководитель отдела хочет сократить время подготовки ответа клиенту. Менеджер открывает заказ в учетной системе, ищет условия обслуживания, проверяет переписку и составляет сообщение. ИИ может помочь на одном из этих шагов. Сначала стоит выяснить, какой шаг занимает время и по каким признакам команда примет результат.
Аудит перед внедрением ИИ превращает такое желание в ограниченный проект. У заказчика остаются описание процесса, карта источников, перечень проверок и основание для решения о пилоте. Эти материалы пригодятся при сравнении подрядчиков и при работе собственной команды.
Ниже предложен способ обследовать один процесс. Пример сервисной компании методический: его участники и условия придуманы для объяснения подхода.
Начните с одного рабочего действия
Попросите сотрудника показать последний обычный запрос и один сложный. Пусть он проходит знакомый путь: открывает программы, сверяет сведения, уточняет детали у коллеги, принимает решение. Запишите каждое действие и причину обращения к другому источнику. Такой разбор раскрывает устройство работы точнее общего списка пожеланий.
Для первого обследования удобно выбрать действие с ясным началом и концом. Например, запрос о статусе заказа начинается с обращения клиента и заканчивается подтвержденным ответом менеджера. Продажа, сопровождение договора и обслуживание клиента целиком охватывают множество разных решений. Их можно рассмотреть позже, когда станет понятен первый участок.
В записи процесса должны появиться конкретные люди. Руководитель определяет полезный результат. Сотрудник показывает ежедневную работу и проверяет примеры. Владелец учетной системы объясняет поля, доступы и обновления. Разработчик оценивает способы соединить эти части.
Зафиксируйте, что происходит сегодня
До выбора модели соберите исходное измерение. В нашем примере полезно записывать время поиска сведений, подготовки текста, проверки и исправления. Отдельно отметить ожидание ответа другого отдела. При таком разделении станет видно, какую часть работы вообще может изменить будущая система.
Период наблюдения должен охватывать обычную нагрузку и характерные исключения. Его длительность команда выбирает по частоте обращений. Для каждого случая сохраните тип запроса, использованные источники, итоговое действие и причину исправления. Персональные сведения замените разрешенными обозначениями до передачи материалов участникам исследования.
Google в инженерном руководстве по машинному обучению рекомендует заранее проектировать метрики и начинать с простого решения. Для заказчика это полезный ориентир: сначала договориться, какой результат измеряется, затем сравнивать способы его получить. Рекомендации Google для ML-проектов.
Заполните паспорт пилота
Таблицу можно перенести в рабочий документ и обсудить на встрече. В правой колонке приведен методический пример, который показывает желаемую конкретность ответа.
| Поле | Вопрос к команде | Пример заполнения |
|---|---|---|
| Пользователь | Кто выполняет действие? | Менеджер сопровождения заказов. |
| Начало процесса | Что запускает работу? | Клиент спрашивает о готовности своего заказа. |
| Результат | Что получает пользователь? | Черновик ответа со статусом и ссылкой на источник. |
| Источник фактов | Где проверяется статус? | Карточка заказа в учетной системе. |
| Источник объяснений | Где описаны условия? | Утвержденный регламент обслуживания. |
| Действие человека | Что решает сотрудник? | Сверяет сведения и отправляет сообщение клиенту. |
| Границы пилота | Какие случаи рассматриваем? | Один отдел, один тип обращения, согласованные статусы. |
| Исходный способ | С чем сравниваем? | Текущий поиск и подготовка ответа менеджером. |
| Ошибки | Что требует исправления? | Чужой заказ, устаревший статус, обещание другого срока. |
| Приемка | Что проверяем? | Факты, ссылки, время полной обработки и объем исправлений. |
| Владелец | Кто принимает решение? | Руководитель сопровождения вместе с владельцем системы. |
Пустая ячейка становится вопросом обследования. Если у одного статуса два толкования, сначала договоритесь о его смысле. Если сотрудник узнает срок только по телефону, определите, где этот срок будет фиксироваться. Эти сведения помогают уточнить состав работ и условия приемки пилота.
Проверьте данные на реальных примерах
Для каждого поля паспорта найдите пример источника. Откройте заказ, регламент и итоговое сообщение. Сверьте идентификаторы, дату обновления и право сотрудника видеть сведения. Затем повторите проверку для сложного случая: частичная отгрузка, несколько заказов одного клиента, изменение срока после последнего ответа.
На этом этапе нужен небольшой набор примеров с понятными пояснениями. Его объем определяют разнообразие процесса и цена ошибки. Каждый пример должен помогать ответить на конкретный вопрос. Выбирайте файлы по проверочным ситуациям и сохраняйте ожидаемый результат рядом с исходными сведениями.
Разделите сведения для настройки и для итоговой проверки. В проверочную часть включите обычные обращения, спорные формулировки и ситуации, где требуется участие руководителя. Сохраните объяснение правильного действия. Позже оно поможет разбирать причины расхождения.
Сравните несколько способов решить задачу
После обследования могут появиться разные варианты. Единая карточка статуса ускорит поиск. Правила подготовят стандартный ответ для определенного события. Языковая модель поможет составить текст по выбранным сведениям. Поиск по документам пригодится, когда сотрудник задает вопросы к большому набору инструкций.
Для каждого варианта запишите, какую часть процесса он меняет, какие источники использует и сколько проверки остается человеку. Такой список помогает отделить пользу интерфейса, интеграции и модели. В смете эти части тоже стоит видеть раздельно.
При ограниченном доступе к данным первый этап может состоять из подготовки выгрузки и словаря полей. Если источники уже согласованы, команда может перейти к сравнению решений на проверочном наборе. Масштаб подготовки следует из выбранного действия.
Договоритесь о решении после пилота
Критерии приемки задаются до разработки. Удобно разделить их на четыре группы: верность результата, поведение в исключениях, труд сотрудника и условия эксплуатации. Порог каждой метрики выбирает владелец процесса вместе с командой проекта. Для финансово значимой ошибки и стилистической правки нужны разные решения.
Предусмотрите три исхода: переход к рабочему запуску, дополнительный ограниченный эксперимент, завершение исследования с сохранением выводов. У каждого исхода должны быть понятные основания. Например, полезный черновик при долгой ручной проверке требует пересмотра состава ответа, а проблема сопоставления клиентов требует работы со справочником.
Сам отчет аудита стоит принимать по комплекту материалов. Заказчик получает схему процесса, паспорт пилота, образцы источников, список пробелов, способ измерения и варианты следующего этапа. Сроки и бюджет привязываются к этим работам. Результат обследования должен позволять продолжить проект с ясным пониманием задачи.
Как подготовиться к разговору с разработчиком
Соберите описание одного рабочего действия, перечень программ, несколько разрешенных примеров и человека, который знает процесс. Добавьте два вопроса: что сотрудник делает слишком долго и какую ошибку компания считает существенной. Этого достаточно для первого предметного обсуждения.
В DZ Board публично показаны связанные роли, допуски и рабочие экраны. Этот опыт помогает обсуждать устройство процесса и ответственность участников. Для ИИ-проекта к такой основе добавляются проверка модели и критерии конкретного сценария.
Обсудить разработку ИИ-системы можно с описания выбранного процесса. Если основной вопрос связан с разрозненными действиями и источниками, полезно начать с автоматизации рабочего участка. В первом сообщении укажите пользователя, исходные системы и желаемый результат.