Неможливо побачити прогрес виробничих операцій на заводі: як розбивають бізнес-процеси, як збирають дані про хід роботи та як це пов’язано з виробничими накладними?

Вступ: чому «доска прогресу» на стіні цеху завжди на два дні випереджає систему

Увійшовши до заводу, що займається механічною обробкою, помічаєш, що на стіні конференц-зали висить біла дошка, на якій розташовані різнокольорові нотатки, кожна з яких містить номер виробничого замовлення, поточний технологічний процес та номер верстату. Кожного вечора черговий менеджер змінює ці нотатки. На наступний ранок директор приходить у цех і питає: «Чи виконано вчора всі замовлення?» Директор цеху дістає ту дошку й, звужуючи очі, перераховує нотатки.

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

Це не виняток лише для одного заводу. У наших спостереженнях цехи різного масштабу — від невеликих майстерень із десятком працівників до великих заводів з тисячами співробітників — стикалися з подібними проблемами:

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

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

Нижче ми розглянемо, як треба проектувати та впроваджувати таку систему, щоб біла дошка на стіні поступово стала зайвою.

01 Як розкласти бізнес: розрізати «прогрес» на найменші збираємі дії

Багато проектів одразу записують «прогрес технологічного процесу» як один поле. Насправді «прогрес технологічного процесу» — це складний стан:на якому робочому місці знаходиться замовлення,хто саме виконує роботу,скільки вже виконано,скільки робочого часу витрачено,чи відповідає якість вимогам,чи всі матеріали на місці. Ці шість параметрів треба збирати окремо, не поєднуючи в один показник.

Ось як це розкладається конкретно:

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

Розкладіть ці шість параметрів у окремі «потоки подій», а не в одну групу станів. Події — це хронологічний запис: хто, коли, на якому верстаті, до якого етапу дійшло, які аномалії виникли — все фіксується. Стан — це вигляд, що виводиться з потоку подій;станові поля не можна заповнювати вручну.

02 Як проектувати: чітко окреслити ролі, процеси, дані та кордони інтерфейсу

Найпоширеніший помилковий підхід на стадії проектування — «створити додаток, де люди будуть заповнювати дані», але через два роки операційна система виявляється лише зі сторінкою входу та порожнім полем паролю. Проблема в невідповідності ролей та кордонів.

Проектування ролей

У цеху є чотири категорії людей, і кожна з них користується іншим інтерфейсом:

• Робітники: використовують термінал на робочому місці або планшет із великими кнопками, бачать лише «моє поточне замовлення» — три кнопки: початок, пауза, завершення. Жодних таблиць на екрані.
• Начальник виробничого відділу: використовує телефон або дошку у цеху, бачить стан усіх робочих місць своєї зміни, за 2 хвилини може визначити, «де застрягло».
• Диспетчер або планувальник: використовує ПК, бачить гант-графік та список аномалій усіх робочих місць заводу, основна увага — коригування графіку та реакція на аномалії.
• Якість або технологія: окремий доступ, бачить відсоток відповідності під час первинної перевірки, частоту переробок, тренд 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, не проводить розпізнавання зображень, адже при перебої мережі на майданчику будь-яке зображення стане непридатним.
• Ваги/лічильник/світловий бар'єр: вагування матеріалів, підрахунок деталей, безпечний світловий бар'єр — усі передають сигнал через PLC до 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%.

Коли ці три показники досягнуті, стіна з білою дошкою лишається порожньою, і тоді можна вважати, що справді виконано завдання з управління прогресом.