Ключові параметри існують лише в голові одного людини
У списку найцінніших активів цеху ніколи не пишуть слова «старший майстер», але будь-який директор заводу, який працює на виробництві понад п’ять років, добре знає: саме два-три старих робітника часто забезпечують стабільність виробничої лінії. Як довго треба прогрівати верстат взимку, при якому тиску і кількості штампів з’являється потертість, які проблеми виникнуть, якщо цю партію матеріалу обробляти трохи швидше — всі ці відповіді немає ні в якому посібнику, вони лише у їхніх головах.
Проблеми концентруються в той тиждень, коли вони виходять на пенсію, звільняються або беруть довгий відпустку: ніхто не наважується запустити нову модель, однаковий матеріал при зміні зміни дає брак, а новачки, тримаючи паперовий інструктаж, просто розгублено стоять біля станка. Це не проблема ставлення співробітників, а те, що технологічні знання підприємства так і не перетворилися на актив, який можна зберігати, передавати та оцінювати. Паперові інструкції до роботи часто залишаються версіями трирічної давнини, які давно не відповідають тому, що справді виконується на майданчику.
Спочатку треба розрізнити, які бувають види досвіду
Якщо роздивитися досвід старих майстрів, то виявиться, що це три категорії речей, які потребують зовсім різного підходу:
- Тверді параметри: обороти, подача, температура, тиск, час. Такі знання найлегше закріпити; вони є структурованими даними і мають слідувати за процесом і обладнанням, а не за людиною.
- Правила оцінки: який звук свідчить про знос інструменту, яке відчуття вказує на аномалію матеріалу. Ці знання треба зберігати разом зі зразками дефектів, фотографіями та текстовими описами, перетворивши їх у пошукову базу випадків дефектів.
- Робочі звички: яку поверхню треба витерти першою, який еталон виміряти першим. Ці знання треба закріпити в стандарті роботи, чітко пояснюючи, чому так робиться; лише коли новачок розуміє причину, його дії не будуть помилковими.
Багато підприємств купують так звані системи управління знаннями, але вони не приживаються, бо не проводять такого розподілу: всі досвіди просто зберігаються як документи, і в результаті при пошуку видається сотні PDF-файлів, які ніхто на робочому місці не переглядає. Перший крок управління досвідом — класифікація, другий — зберігання.
Як проектувати дані
У плані системного проектування головне — зробити процес основним анкером для досвіду. Технологічний маршрут, картки процесів, таблиці параметрів, бази випадків дефектів повинні бути прив’язані до конкретного процесу, а через нього — до обладнання, форм і матеріалів. Такий підхід має кілька безпосередніх переваг: коли робітник сканує код, щоб увійти в певний процес, він бачить актуальну версію параметрів для цього процесу, не плутаючи документів; зміни параметрів мають проходити через версійний процес — хто змінив, чому, хто затвердив, з якої партії вони набувають чинності — все фіксується; база випадків дефектів з фотографіями та висновками дозволяє контролеру при виявленні аномалії одразу порівняти зі старими зразками, замість того, щоб телефонувати вже на пенсії старим майстрам.
Версійний менеджмент — це той елемент, який найчастіше недооцінюють. Технологічні параметри не є незмінними; капітальний ремонт обладнання, зміна постачальника матеріалів, нові вимоги клієнтів — все це вимагає коригування. Система має забезпечити, щоб кожна партія продукції могла бути зв’язана з тією версією, яка була чинною на момент виробництва; лише так можна встановити причину якщо виникне проблема якості.
Збирання даних має відбуватися у процесі роботи
Найбільший ворог закріплення досвіду — «потреба виділяти окремий час для запису». Будь-який підхід, що змушує робітників доповнювати дані після робочого дня, зазвичай втрачає силу уже через два тижні. Дієвий шлях — вбудувати збір даних у процес оформлення виробничих звітів: під час звітування про кількість відповідних деталей одразу ж перевіряють, чи збігаються поточні параметри з технологічною картою; при звітуванні про брак обов’язково вибирають код дефекту, а якщо є можливість зробити фото — додають його. Саме ці записи про процедуру реагування на аномалії є найціннішим джерелом правил оцінки — набагато достовірнішими, ніж «збірники досвіду», підготовлені організацією експертів на круглих столах.
Те ж стосується процесу навчання. Навчальний план для новачків розбивають на маленькі завдання за кожним процесом; для кожного процесу встановлюють, скільки деталей треба зробити разом з наставником, скільки — самостійно, і хто має підтвердити успішне виконання; стан виконання відображається в системі в режимі реального часу. Керівникові зміни більше не треба покладатися на пам’ять, щоб організувати навчання; на щотижневому звіті одразу видно, на якому процесі перебуває новачок, які типи операцій повторюються з помилками, і саме туди направляють навчальні ресурси.
На що звернути увагу під час розробки та приймання
На розробчому рівні найважливіші три моменти. По-перше, права доступу: право змінювати параметри має бути зосереджене на технологічному посадовому місці, оператори мають лише право перегляду та підтвердження виконання, щоб запобігти ситуації, коли «хто хоче, той і змінює». По-друге, інтерфейс: дані про процеси мають бути інтегровані в одну і ту ж інформаційну мережу, що й робочі замовлення, звіти та контроль якості, щоб не створювати черговий інформаційний островок, і тоді можна буде зв’язати всі етапи відстеження якості. По-третє, адаптація терміналів: робочі термінали мають враховувати масляні плями, рукавички та освітлення; там, де можна вирішити проблему скануванням або фізичними кнопками, не треба змушувати робітників друкувати.
При прийманні важливо не оцінювати, скільки документів було введено, а звернути увагу на чотири показники: наскільки скоротився період самостійного введення новачка на робоче місце, чи знизився відсоток браку на тому ж процесі, який відсоток виконання змінених параметрів, і який середній час реагування на аномалії. Лише коли ці чотири показники зміняться, можна сказати, що управління досвідом справді перейшло в систему, а не просто додалося ще один електронний шафчик для документів.
Рекомендації щодо порядку впровадження
Рекомендації щодо порядку впровадження не передбачають одразу перенести весь досвід заводу в систему. Спочатку виберіть один-два процеси, де втрати через брак найбільші, і запустіть першу версію, зібравши поточні параметри та базу випадків дефектів за останні півроку; коли цикл збору даних запрацює, тоді керівники змін можуть щомісяця доповнювати правила, виявлені в повсякденній роботі. Базу знань треба формувати поступово, а не складати відразу. Через три місяці підрахуйте вищезгадані чотири показники — чи варто розповсюджувати це на весь завод, і рахунок сам собою складеться.
База знань має також підключити обладнання та різні підрозділи заводу
Коли база знань перейде до другої стадії, найбільшу цінність мають дві напрямки розширення. Перший — підключення даних обладнання: після установки збиральних пристроїв на ключові верстати, дані про струм, вібрацію, фактичні обороти можуть бути прив’язані до хронології записів дефектів; таким чином, «слухові» судження старих майстрів мають шанс частково замінити сенсорні закономірності — яка форма струму відповідає дефекту потертості, — і це природно вимальовується зі збільшенням обсягу даних. Досвід перестає бути лише невимовними заповітами, він стає умовами, які можна вписати в правила попередження. Другий напрямок — використання на різних підрозділах: коли одна група відкриває заводи в двох місцях, технологічні документи часто зберігаються окремо, кожен змінює свої. Коли досвід зосереджений у системі за процесом, при запуску нового заводу можна безпосередньо перейняти всю історію параметрів і базу випадків дефектів для цього процесу, і звичайною є ситуація, коли період підйому скорочується на два-три місяці.
І навпаки: не варто занадто сильно проектувати, поки не пройдено ці два етапи. Спочатку треба запустити замкнутий цикл досвіду одного цеху, довести, що період адаптації новачків справді скоротився, і лише потім говорити про підключення обладнання та використання на різних підрозділах — тоді вклад і результати матимуть обґрунтування.