Автоматизацию стоит начинать с описания конкретной операции, а не с выбора ИИ или системы. Между поступлением заявки и готовым результатом могут быть проверки, согласования и ситуации, которые нельзя обработать по обычному маршруту. Их важно сделать видимыми до обсуждения решения.
Для первого разбора достаточно четырёх частей: вход, решение, исключение и результат. Рассмотрим их на примере регистрации заявки на ремонт. Это возможный сценарий пилота, а не описание выполненного внедрения.
1. Вход: что запускает работу
Укажите, откуда поступает заявка, какие сведения и документы нужны для её регистрации и кто проверяет полноту данных.
Важно описать не только привычный канал поступления, но и систему-источник. Если документы и сведения находятся в разных местах, это нужно учитывать при оценке задачи. Доступность API или выгрузок проверяется отдельно.
2. Решение: по какому правилу движется заявка
Опишите, как назначаются исполнитель и статус. Какие условия можно сформулировать однозначно? Какие вопросы требуют решения ответственного специалиста?
На карте полезно разделить действие по установленному правилу и профессиональное суждение. Само наличие ИИ не снимает необходимости определить ответственного за проверку.
3. Исключение: что происходит вне обычного маршрута
Не указан объект, отсутствует документ, сведения противоречат друг другу — для таких ситуаций нужен отдельный порядок действий.
Зафиксируйте, когда обработку следует остановить, кому передать вопрос и какие данные запросить. Исключение должно иметь понятный маршрут, а не оставаться неопределённым «разберёмся вручную».
4. Результат: что считается завершением операции
Для регистрации заявки результатом может быть заполненная карточка с документами, назначенным исполнителем и статусом. Это не означает, что сам ремонт уже выполнен: границы операции нужно назвать точно.
Укажите, где фиксируется результат и кто проверяет его корректность. Так у пилота появится конкретный предмет проверки.
Как перейти от карты к пилоту
Для первого этапа можно ограничиться одним участком и одним типом операции. В сценарии регистрации заявки полезность можно оценивать по времени регистрации и поиска, полноте карточки и доле исправлений. Исходные значения и критерии пилота следует согласовать заранее, а не заменять обещанием экономии.
До оценки также нужны владелец процесса, качество исходных документов, разрешённые данные, требования к размещению и безопасности, а также проверяющий специалист. Возможность интеграции с 1С, ERP, ТОиР или MES зависит от обследования.
Такая карта помогает обсудить задачу, ограничения и первый этап. Она не является проектом автономного управления оборудованием и не заменяет утверждённые производственные инструкции или решение ответственного специалиста.
Напишите «ЗАВОД» — разберём одну повторяющуюся операцию.