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