Найти процесс, который стоит менять первым

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

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

Составьте карту потерь

Проведите с командой разбор обычной недели. Где повторно вводят данные? Где ждут согласования? Какие документы возвращаются? Для каждой операции соберите примеры и длительность, включая ожидание и исправления. Не принимайте фразу «это занимает весь день» за замер.

Затем разделите время выполнения и календарную задержку. Генерация документа за минуту не устранит два дня ожидания подписи. Если узкое место находится после выбранной операции, локальное ускорение может лишь увеличить очередь.

Отличайте правила от интерпретации

Когда операция определяется устойчивым правилом, её часто лучше выполняет обычная автоматизация: вычисление суммы, перенос поля, проверка обязательного реквизита. Языковая модель полезна там, где нужно работать с разнообразным текстом, извлекать смысл или готовить связный черновик.

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

Модель 02 · матрица отбора

Развернуть ↗Поделиться ↗

EVOLVIN MEDIA / ПРАКТИКА

Начинайте с повторяемой задачи с низкой ценой ошибки

Повторяемость: разовая → регулярная; Цена ошибки: высокая сверху, низкая снизу

1. 01

   Разовая + высокий риск

   Сначала человек и диагностика

2. 02

   Повторяемая + высокий риск

   Только подготовка, с проверкой

3. 03

   Разовая + низкий риск

   Личный инструмент, без проекта

4. 04

   Повторяемая + низкий риск

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

Первый пилот выбирают по цене ошибки, а не по модности ИИ.

Переслать мысль с карточкой ↗

Как читать схему

Матрица помогает обсуждать задачу. До отбора обязательны владелец процесса, разрешённые данные и проверяемый результат; положение в матрице не является оценкой реальных проектов.

Вертикальная версия для телефона. Полную композицию можно открыть кнопкой «Развернуть».

Используйте отбор с запретами

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

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

Учебный выбор компании

У «Контур-Сервиса» есть история заявок и утверждённый каталог услуг. Компания выбирает подготовку черновика брифа по входящему обращению. На выходе нужны предмет запроса, отсутствующие сведения и следующий ответственный. Цена и обязательства в объём не входят.

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

Паспорт на одну страницу

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

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

Рабочий разбор: переписать начало процесса

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

Теперь можно собрать примеры, определить обязательные поля и назвать принимающего. Следующая проверка — есть ли такие обращения в достаточном количестве и занимают ли они существенную долю времени. Если поток мал, даже удачное решение может не оправдать сопровождения.

Не бойтесь сделать первый процесс уже первоначальной идеи. Узкая граница позволяет видеть причину успеха и ошибки. Когда команда научится принимать результат, можно обоснованно решить, подходит ли тот же механизм соседним задачам.