Прогресс производственных операций на заводе не виден: как разбить бизнес‑процессы, как собирать данные о ходе выполнения и как синхронизировать их с рабочими заказами?

Начало: Почему «доска прогресса» на стене цеха всегда опережает систему ровно на два дня

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

В одном и том же заводе часто бывают две версии «прогресса»: одна — на белой доске со стикерами, другая — статусы рабочих заданий в ERP или MES. Первая отражает реальную картину на месте, вторая — цифры для бухгалтерии и клиентов. Не совпадение этих двух показателей — обычное дело, а их совпадение — уже новость.

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

• Производственный план не доходит до рабочего места: планировщик распределил в системе 30 рабочих заданий, но в цехе видят лишь 8, остальные «висят в системе».
• Прогресс определяется по телефонным звонкам: диспетчер за день делает десятки звонков с вопросом «Где сейчас эта работа?», а мастер тоже не помнит, на каком этапе находятся те или иные операции.
• Расход времени не совпадает с фактическим: учётчик заполняет отчёт каждые четыре часа, а перед окончанием смены просто добавляет недостающие данные; в итоге цифры отличаются от реального темпа на 20–40%.
• Аномалии никто не отслеживает: на одной операции три дня ждут сырьё, но никто этого не замечает; только когда клиент требует отгрузки, выясняется, что не хватает одной детали.

Проблема заключается не в том, что какое‑то ПО не используется, а в том, что между «на местах» и «системой» прерван процесс сбора данных. Белая доска на стене оказывается точнее ERP, потому что она находится прямо у станка и обслуживается теми, кто видит происходящее; тогда как ERP обычно проходит через три уровня: от мастера к старшему мастеру, затем к диспетчеру, и на каждом уровне данные заново вводятся, а значит, на каждом этапе может возникнуть задержка или ошибка.

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

01 Как разделить бизнес: разбить «прогресс» на минимальные измеряемые действия

Многие проекты сразу записывают «прогресс операции» в виде одного поля. На самом деле «прогресс операции» — это комплексное состояние:на какой рабочей позиции находится задание,кто его выполняет,сколько уже сделано,сколько часов потрачено,соответствует ли качество требованиям,всё ли сырьё на месте. Эти шесть аспектов необходимо фиксировать отдельно, нельзя объединять в одно поле.

Конкретно это выглядит так:

1. Рабочее место: каждый станок или рабочее место имеет уникальный номер; сканирование QR‑кода или карточки позволяет определить, чью работу сейчас выполняет данный станок.
2. Работник: каждое рабочее задание, начиная с этапа запуска, перехода и завершения, привязывается к конкретному номеру работника. Даже если работает ученик и мастер, именно мастер остаётся единственным регистратором.
3. Количество выполненных операций: на каждой операции проводится первичная проверка, контроль в процессе и подсчёт готовой продукции. Количество — это не состояние, его нужно обновлять нажатием кнопки или сканированием кода.
4. Фактическое время работы: разница во времени между началом и завершением операции (автоматически фиксируется), плюс временные паузы (ручное указание причины задержки).
5. Статус качества: три этапа записи — первичная проверка, контроль в процессе и окончательная проверка; результаты — «пригодно», «переработка» или «отбраковка» — движутся независимо, нельзя ограничиваться лишь процентом соответствия.
6. Сырьё в наличии: каждый материал из BOM подразделяется на три состояния — «в наличии», «недостаёт», «необходимо пополнить» — и связан с состоянием рабочего задания.

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

02 Как проектировать: чётко обозначьте роли, процессы, данные и границы интерфейса

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

Проектирование ролей

В цехе есть четыре категории людей, и каждая пользуется своим интерфейсом:

• Рабочий: использует терминал на рабочем месте с большими кнопками или планшет, видит только «моё текущее задание» — три кнопки: начать, приостановить, завершить. Таблицы на экране недопустимы.
• Бригадир: пользуется мобильным телефоном или доской в цехе, видит состояние всех рабочих мест своей смены и за две минуты определяет, где именно возникла проблема.
• Диспетчер или планировщик: работает на ПК, видит гантограмму и список аномалий всех рабочих мест завода, уделяя особое внимание корректировке графика и реагированию на отклонения.
• Отдел контроля качества или технологический отдел: отдельный вход, где можно увидеть процент успешной первичной проверки, уровень повторной обработки, тренд SPC;нельзя напрямую изменять статус рабочего задания, можно лишь вынести решение «остановить линию» или «разрешить выпуск».

Модель данных

Основные четыре таблицы, плюс несколько вспомогательных — этого вполне достаточно:

• work_order: основная таблица рабочего задания, связана с заказами продаж, планами и продукцией.
• work_order_route: технологическая маршрутная карта, где указано, сколько операций на каждом этапе.
• route_event: поток событий операций (основная ежедневная запись): кто, когда, на каком станке, на каком этапе.
• exception_log: журнал аномалий (недостаток материалов, поломка оборудования, возврат продукции по качеству).

Поля состояния (status、current_step、progress_pct) рассчитываются в реальном времени на основе route_event, их не сохраняют; сохраняются только события. Так, независимо от того, кто меняет рабочее задание, состояние всегда будет определяться потоком событий.

Границы интерфейса

Необходимо чётко обозначить границы трёх типов терминалов:

• Терминал на рабочем месте: сканирование → вызов рабочего задания → отображение технологии → большие кнопки «начать/приостановить/завершить»;запрещено заполнять любые числовые поля, все цифры автоматически вводятся PLC или сканером.
• Доска бригадира: сетчатый вид рабочих мест своей смены — зелёный — нормально, жёлтый — сверхнормативно, красный — аномалия. При нажатии на красный цвет сразу открывается подробная информация о журнале аномалий.
• Диспетчер ПК: Гантт‑диаграмма плюс загрузка ресурсов плюс очередь исключений, исключения обязательно должны быть выделены в отдельную очередь, нельзя смешивать их с основной гантт‑диаграммой, чтобы люди не «искали исключения».

03 Как разрабатывать: три рубежа — сбор данных, интерфейсы, приёмка

Основная задача на этапе разработки — «заставить рабочее место хотеть пользоваться». Чтобы рабочее место захотело пользоваться, необходимо, чтобы «достаточно было одного нажатия», а не «надо заполнить кучу полей». За этим стоят три рубежа.

Рубеж сбора данных

Сбор данных делится на три уровня:

• Прямой сбор с оборудования: станки с ЧПУ, термопластавтоматы, SMT подключаются по OPC UA или Modbus, сигналы о запуске/остановке, номер текущей программы и счётчики в реальном времени записываются в поток событий. Этот этап самый сложный, но наиболее ценный; сделав его один раз, можно больше не зависеть от ручного труда.
• Сканирование штрихкода плюс кнопка: на рабочих местах используется сканер штрихкодов (для материалов) + крупная кнопка (запуск/пауза/завершение). Сканер работает по USB HID, выводит строку, не использует OCR и распознавание изображений, ведь при наличии сетевого сбоя изображение сразу становится недействительным.
• Взвешивание/счёт/фотоэлектрический барьер: взвешивание материалов, подсчёт деталей, безопасный фотоэлектрический барьер — всё передаётся через сигналы ПЛК в формат OPC.

Три уровня совместно используют один сервис шлюза сбора данных; шлюз унифицирует различные протоколы в единый формат событий (JSON), записывает его в очереди сообщений (Kafka или RabbitMQ), а затем сервис подписки потребляет данные и записывает их в базу. Таким образом, при замене оборудования или изменении рабочего места достаточно обновить только шлюз, не переписывая основную бизнес‑систему .

Шлюз интерфейсов

Внешние интерфейсы делятся на две категории:

• Верхний уровень: ERP или MES отправляют рабочие задания, заказы на продажу, спецификации BOM. Это основной источник данных, наша система только читает, не пишет, чтобы избежать взаимного изменения статуса заданий двумя системами.
• Нижний уровень: финансовая система требует данные о рабочем времени и затратах; клиентская система — информацию о ходе поставки; система поставщиков — состояние комплектации. Нижний уровень использует «триггер событий» или «регулярное извлечение», запрещается обратное изменение статуса заданий в нашей системе.

Принципы проектирования интерфейсов: Поток событий только исходит, не поступает. Наша система является источником событий (истиной), внешние системы — подписчиками. Соблюдение этого правила гарантирует, что у нас всегда будет только одна версия правды о ходе выполнения.

Шлюз приемки

Приёмка — это не просто проверка работоспособности функций, а три вещи:

1. Подлинность данных: случайная выборка 5 рабочих заданий, сверка с белой доской или видеозаписью на месте, чтобы убедиться, что отклонение между системными данными и фактическими временами начала и окончания работ не превышает 5 минут.
2. Замкнутый цикл обработки异常ностей: создаётся ситуация недостатка материалов, проверяется весь процесс — от создания инцидента бригадиром, обработки диспетчером, закупки дополнительных материалов до восстановления рабочего места — всё фиксируется, и в течение 5 минут можно увидеть движение в очереди для обработки.
3. Сравнение тактовых норм: в течение недели непрерывно фиксируются фактические такты каждого рабочего места, сравниваются с технологическими нормами; если разница превышает 30%, автоматически формируется предупреждение.

Только после того как эти три пункта будут успешно пройдены, можно считать, что «ход выполнения операций действительно виден».

Заключение: порядок внедрения, риски и ключевые показатели

Проекты такого типа внедряются в три этапа, не стоит пытаться сделать всё сразу:

1. Первый этап (1–2 месяца): сначала устанавливаются рабочие терминалы и доски для бригадиров, охватывается лишь одна производственная линия. Цель — «80% заметок на белой доске должны автоматически синхронизироваться с системой».
2. Второй этап (2–3 месяца): добавляются ПК диспетчеров, очереди для обработки异常ностей и прямые закупки оборудования, охватываются все основные производственные линии завода. Цель — «на месте больше не нужно звонить, чтобы узнать о ходе выполнения».
3. Третий этап (по мере необходимости): подключение к ERP, финансовой и клиентской системам, оптимизация тактовых норм, анализ SPC. Этот этап не является обязательным; решение принимается после анализа обратной связи с производства после завершения первых двух этапов.

Распространённые риски:

• Сопротивление на месте: опасение быть под наблюдением, сравнением. Решение: интерфейс отображает только рабочее место, не показывает людей; показатели рассчитываются только на уровне бригады, без личных рейтингов.
• Пропуск при сборе данных: старое оборудование не имеет коммуникационных портов, поэтому приходится использовать сканеры штрих‑кодов. При приёмке необходимо удостовериться, что уровень пропусков не превышает 5%.
• Искажение данных о рабочем времени: операторы ради «набора цифр» многократно начинают и прекращают работу. Система фиксирует, если на одном и том же рабочем месте за 5 минут происходит несколько начинаний, и сразу относит это к числу аномалий.

Критерии оценки успешности проекта сводятся всего к трём показателям:

• Количество звонков диспетчеров: после запуска снижается более чем на 50%.
• Среднее время реагирования на аномалии: сокращено с часов до минут.
• Доступность информации о ходе выполнения для клиентов: жалобы на задержки поставок снижаются более чем на 30%.

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