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