Чому безперервне вдосконалення потребує кращих даних

Безперервне вдосконалення має створювати навчання, яке накопичується з часом. Однак на багатьох заводах робота з покращеннями досі спирається переважно на семінари, електронні таблиці, розрізнені звіти та те, що люди пам'ятають із попередньої зміни. Захід Kaizen може створити помітний прогрес, але через кілька тижнів ті самі втрати часто з'являються знову за трохи інших виробничих умов. Справа не завжди в якості ідеї покращення. Більша проблема в тому, що команди часто не можуть довести, чи справді контрзаходи спрацювали, де саме і за яких умов вони перестали працювати.

ЧОМУ ПОКРАЩЕННЯ KAIZEN ЧАСТО ЗНИКАЮТЬ
Семінар створює фокус на кілька днів. Команди картографують процес, визначають марнотратство, призначають дії, переміщують інструменти, змінюють контрольні списки або коригують передачі між ділянками. Потім повертається звичайний тиск виробництва. Майстер має ще одне термінове замовлення, технічна служба — ще одну несправність, планування змінює послідовність, а відділ якості відправляє на утримання ще одну партію. Дія щодо покращення лишається десь у файлі Excel або трекері проєктів, а не стає частиною операційного ритму. Тому важливе питання не в тому, чи була дія виконана, а в тому, чи справді покращилися виробничі умови.

PDCA ПОТРЕБУЄ СПРАВЖНЬОГО КРОКУ ПЕРЕВІРКИ
Plan, Do, Check, Act звучить просто, але багато організацій фактично працюють за схемою Plan, Do, Move On. PLAN має визначати перевірювану проблему, поточний стан, очікуване покращення та гіпотезу, що стоїть за контрзаходом. DO означає випробування контрзаходу за реальних виробничих умов із фіксацією достатнього контексту, щоб зрозуміти, що саме сталося. CHECK означає порівняння очікуваного результату з реальними виробничими доказами. ACT означає стандартизацію зміни, коли докази її підтверджують, або адаптацію, звуження чи скасування, коли не підтверджують.
• Чи справді зменшилися втрати?
• Чи проблема просто перемістилася в інше місце?
• Чи зміна підвищила доступність обладнання, але погіршила якість?
• Чи працює вона для різних виробів, бригад і змін?
• Чи вплинули на результат обслуговування, матеріали, планування або інша зміна процесу?
Один успішний виробничий запуск не є доказом. Безперервне вдосконалення потребує достатньої кількості доказів, щоб відрізнити відтворюване покращення від вдалої зміни.

GEMBA І ДАНІ ПОТРЕБУЮТЬ ОДИН ОДНОГО
Дані не замінюють Gemba. Оператори, майстри, технічні фахівці, планувальники та співробітники якості розуміють виробничі умови, які системи часто не можуть зафіксувати. Запис обладнання може показувати зупинку на десять хвилин, тоді як оператор знає, що зупинка сталася, бо компонент працював не так, звичайний маршрут матеріалу був заблокований або попередня зміна залишила станцію в незвичайному стані. Водночас само лише спостереження показує лише одну зміну, одну подію або одну версію проблеми. Пов'язані операційні дані дають змогу перевірити, чи повторюється спостереження в різних замовленнях, виробах, верстатах, змінах, партіях матеріалу та протягом довших періодів.

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

ПОЧИНАЙТЕ ІЗ ПИТАННЯ ПОКРАЩЕННЯ
Однією з найбільших помилок в аналітиці виробництва є початок із тих даних, які випадково доступні. Сучасна виробнича лінія може генерувати величезні обсяги інформації з PLC, датчиків, систем MES, ERP, систем якості, застосунків обслуговування та електронних таблиць. Більше даних автоматично не означає кращих рішень. Корисний процес покращення починається з виробничого питання, на яке команді справді потрібно відповісти.

Замість запитання «Які у нас є дані?» поставте питання «На яке виробниче питання ми намагаємося відповісти?» Твердження на кшталт «переналагодження триває занадто довго» все ще надто широке. Краще питання: чому час переналагодження суттєво варіюється для однієї й тієї самої родини виробів на одній лінії? Це одразу допомагає визначити контекст, який має значення.
• Попередній виріб
• Наступний виріб
• Виробниче замовлення
• Ресурс або лінія
• Конфігурація інструменту
• Матеріал
• Зміна або бригада
• Початок переналагодження
• Час перезапуску
• Перша прийнятна одиниця
• Стабільне виробництво
• Результати якості
• Аварійні сигнали верстата
Мета не в тому, щоб зібрати все. Мета — зібрати найменший набір фактів, здатних змінити рішення щодо покращення.

ERP ПОЯСНЮЄ ПЛАН
ERP надає комерційний і плановий контекст навколо виробництва. Він може показувати заплановані кількості, маршрути, зобов'язання перед клієнтами, потреби в матеріалах, пріоритет замовлень і задуману виробничу послідовність. Цей контекст важливий, бо виробничі умови постійно змінюються. Контрзахід може справді скоротити час переналагодження, тоді як показники доставки все одно погіршуються, бо змінився асортимент виробництва або планувальники запровадили частіші переходи між виробами.
Отже, ERP допомагає пояснити, що мало працювати, у якій послідовності, для якого попиту, з якими маршрутами та матеріалами. Але ERP переважно описує намір. Він не обов'язково описує те, що фізично відбулося на виробничій ділянці.

MES ПОЯСНЮЄ, ЩО ФАКТИЧНО ПРАЦЮВАЛО
Система управління виробничими процесами заповнює частину цього розриву. MES може надавати історію виконання замовлення, включно з фактичним початком і завершенням операції, виробленою кількістю, браком, утриманнями, доопрацюванням, ресурсами, транзакціями операторів, споживанням матеріалів, простежуваністю та кодами причин. Це дає змогу командам покращення пов'язувати втрати з реальними замовленнями та операціями, а не покладатися на пам'ять або середні добові значення.

Дані MES все ще потребують інтерпретації. Транзакції можуть вноситися із запізненням, різні бригади можуть по-різному використовувати коди причин, а мітка часу може відображати момент, коли оператор підтвердив дію, а не точний фізичний момент її здійснення. Система надає докази, але сенс їм надає процес.

ДАНІ ВЕРСТАТІВ І IoT ПОЯСНЮЮТЬ ФІЗИЧНИЙ ПРОЦЕС
Коли командам потрібно зрозуміти, що сталося всередині операції, стають важливими дані обладнання. Сигнали PLC та IoT можуть розкривати стани верстата, час циклів, аварійні сигнали, швидкість, температуру, тиск, блокування, навантаження двигунів, поведінку при перезапуску та час до стабільного виробництва. MES може показувати, що операція перезапустилася в певний час, тоді як дані обладнання пояснюють, що відбувалося протягом хвилин перед поверненням стабільного випуску.
• Повторювані аварійні сигнали
• Знижена швидкість після перезапуску
• Відновлення температури
• Ручні регулювання
• Блокування
• Нестабільні час циклів
Дані обладнання без виробничого контексту все ще можуть вводити в оману. Аварійний сигнал стає значно корисніший, коли його можна пов'язати із робочим замовленням, виробом, операцією, ресурсом, станом інструменту, матеріалом і результатом якості, що супроводжують подію.

ВИРОБНИЧА ДІЛЯНКА ДОДАЄ ЗМІСТУ
Оператори, технічні фахівці з обслуговування, майстри та співробітники якості заповнюють прогалини, які автоматизовані системи не можуть закрити. Код причини на кшталт «проблема з матеріалом» може описувати на практиці дуже різні ситуації. Матеріал міг надійти із запізненням, поводитися інакше, мати неправильну етикетку, бути пошкодженим або створити проблему на наступному етапі, яка стала видимою лише пізніше.

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

ПОТРІБНА СПІЛЬНА ЗАВОДСЬКА МОВА
ERP, MES, системи обслуговування, історики даних і електронні таблиці можуть по-різному описувати одну й ту саму виробничу подію. Одна система може називати ресурс «Лінія 3», інша — «LINE03», обслуговування може відстежувати кілька окремих активів усередині лінії, а історик усе ще може використовувати старий тег PLC.