Зробіть роботу критичного обслуговування вимірюваною до масштабування
Почніть із процесу, який сьогодні дає збій (сповіщення, реагування, виконання, документування), на ваших критичних активах. Моніторинг стану додається лише там, де справді є датчики й достатньо часу спостереження, а прогнозування відмов заявляється лише там, де є розмічена історія відмов.
Оцінити мої критичні активиПоговорити з виробничим інженеромЦе саме та проблема, яку вам треба розв’язати?
- Обробка поломок тримається на телефонних дзвінках і дошці, тому час реагування невідомий.
- Превентивні плани існують на папері й непомітно зриваються, щойно виробництво стає завантаженим.
- Та сама відмова повторюється, і ніхто не може це довести, бо історія записана в зошитах.
- Запчастин бракує саме в момент, коли вони потрібні технікові.
Основний співрозмовник: Керівник служби ремонту · Менеджер з надійності · Директор заводу · Головний інженер · Менеджер з операційної досконалості
Що доведе цей PoC
Рекомендовані межі пілота
- Обрані критичні активи, тобто ті, чия відмова справді зупиняє виробництво.
- Одна ремонтна бригада з процесом відмов і сповіщень, яким вона користується сьогодні.
- Превентивні плани, наряди й, де це доречно, запчастини за ними.
- Ієрархія активів, критичність та наявна історія відмов.
- Датчики лише для погоджених сценаріїв моніторингу стану, ніколи як загальне припущення.
Що працюватиме під час PoC
Як проходить цей PoC
Терміни типові й не гарантовані. Графік подовжують: відсутні або неповні дані, погодження з безпеки та мережі, строки постачання обладнання, збір зразків, доступ для монтажу, план виробництва, доступ до тестового середовища ERP і час, потрібний вашій команді на оцінку результатів.
Незапланована зупинка не передбачається. Будь-яке вікно монтажу або контрольована перерва узгоджуються з вами заздалегідь і плануються навколо виробництва.
Як вимірюватиметься успіх
| Показник | Як його визначено | Звідки береться значення | Тип |
|---|---|---|---|
| Час від сповіщення до реагування | Час від повідомлення про відмову до її прийняття техніком, виміряний на пілотних активах. | Дані платформи MSF | Операційний |
| MTTR | Середній час ремонту для пілотних активів за живий період, за визначенням, погодженим на етапі обстеження. | Дані платформи MSF | Операційний |
| Базове значення MTBF | Середній час між відмовами, встановлений для пілотних активів за це вікно спостереження. Це базове значення, і ціль за ним не ставиться. | Погоджене базове вимірювання | Операційний |
| Частка аварійної роботи | Частка годин обслуговування, витрачених на незаплановану роботу порівняно із запланованою. | Дані платформи MSF | Операційний |
| Дотримання превентивного графіка | Частка належної превентивної роботи, виконаної у своєму вікні, та прострочений беклог на кінець періоду. | Дані платформи MSF | Операційний |
| Повнота документування | Частка нарядів, закритих із зафіксованою причиною, дією та запчастинами (порожні закриття не враховуються). | Дані платформи MSF | Прийняття користувачами |
| Повторні відмови | Відмови на тому самому активі й з тією самою причиною в межах періоду. Вони доводять, що виправлення не втримало. | Дані платформи MSF | Операційний |
| Час випередження сигналу | Лише там, де датчики входять до меж: час між сигналом стану та подією, про яку він попереджав, із окремим підрахунком хибних сигналів. | Дані датчика, лічильника або пристрою | Технічний |
До початку впровадження MSF і ваша команда узгоджують, як рахується кожен показник, звідки береться базове значення, які дані виключено та який результат обґрунтовує рішення про тиражування. Ця сторінка перелічує, що вимірюється; конкретні цільові значення фіксуються в письмових межах PoC.
Що надаєте ви
- Ієрархію активів, ранжування критичності та наявну історію відмов у будь-якій формі.
- Поточні плани обслуговування, показання лічильників і дані про запчастини там, де це доречно.
- Ролі техніків, покриття змін і пристрої, якими вони реально користуватимуться.
- Правила доступу та охорони праці для будь-якого монтажу датчиків у межах.
Хто що робить
Meta Smart Factory надає
- Обстеження та модерацію визначення меж
- Налаштування рішення під погоджені межі
- Роботи з інтеграції та підключення в цих межах
- Обладнання MSF, зазначене в пропозиції
- Навчання користувачів пілота
- Визначення KPI та метод валідації
- Ведення звернень і підтримку під час пілота
- Підсумковий звіт про результати та проєкт тиражування
- Налаштовану структуру активів, превентивні плани та мобільне виконання нарядів для пілотної бригади.
- Чесну класифікацію того, які сценарії моніторингу стану наявні дані справді можуть підтримати.
Ви надаєте
- Призначеного бізнес-власника та призначеного технічного власника
- Своєчасний доступ до користувачів, лінії, обладнання та погоджених систем
- Достовірний опис процесу та нормативно-довідкових даних
- Доступ до мережі, живлення, монтажу та допуски з охорони праці
- Документацію з ERP, PLC і від постачальників та фахівців, які її знають
- Репрезентативні зразки або історичні дані
- Підтвердження, що базове значення чесне
- Зворотний зв’язок і рішення про приймання
- Техніків, які користуватимуться системою під час реальних поломок. Самого навчання недостатньо.
- Будь-яку наявну історію відмов, навіть неповну: вона визначає, що можна стверджувати.
Визначається в письмовій пропозиції
- Панельні ПК, планшети, сервери та сервери з GPU
- Камери, об’єктиви, освітлення та корпуси
- Сканери, принтери, RFID-пристрої, лічильники та датчики
- Відрядження, монтаж, перевезення, митні платежі та місцеві електромонтажні роботи
- Оренда чи купівля обладнання
- Чи зараховується вартість PoC у тиражування
Комерційні умови, право власності на обладнання, відрядження, обсяг інтеграції та можливе зарахування у вартість тиражування визначаються в письмовій пропозиції щодо PoC. Вони не однакові для всіх продуктів, і ця сторінка їх не обіцяє.
Що ви отримаєте наприкінці
- Живий процес обслуговування, яким користується ваша бригада на реальних поломках.
- Налаштовану ієрархію активів, критичність і превентивні плани.
- Панель порівняння базового значення з пілотним періодом за погодженими визначеннями KPI.
- Висновки з датчиків та оцінку базового рівня даних там, де моніторинг стану входив до меж.
- Звіт про критичність і прогалини: що пілот не зміг охопити і чому.
- План тиражування для решти активів і бригад.
Умови, винятки та межі
Цей PoC залежить від
- Доступність техніків протягом живого періоду, включно зі змінами, у яких справді трапляються поломки.
- Для моніторингу стану: безпечні точки монтажу датчиків і достатньо часу спостереження, щоб це мало сенс.
Не входить до цього PoC
- Очищення даних активів по всьому заводу та оцифрування історичних записів.
- Закупівля запчастин і впровадження складу належать до WMS PoC.
Там, де розмічена історія відмов або достатньо даних спостереження не існує, цей PoC позиціонується як моніторинг стану, виявлення аномалій і створення базового рівня даних. Прогнозуванням відмов він не називається. Твердження про прогноз без відмов, на яких можна вчитися, є лише сподіванням.
Продовжити, скоригувати або зупинити: точка рішення
Часті запитання
Чи можна довести предиктивне обслуговування в PoC?
Лише там, де існує достатньо розміченої історії відмов і достатньо довге вікно спостереження, і обидва перевіряються до того, як щось обіцяється. Там, де їх бракує, чесна програма зводиться до моніторингу стану плюс побудови бази даних, що зробить прогнозування можливим пізніше.
Чи потрібні нам датчики?
Не для процесної половини цього PoC, у якій сидить більшість вимірюваної цінності. Датчики додаються для конкретних сценаріїв моніторингу стану, погоджених на етапі обстеження, на конкретних активах, для конкретного питання.
Наша історія відмов у зошитах. Це перешкода?
Ні, і це дуже поширено. Це обмежує лише твердження про прогнозування. Виміряти реагування, дотримання графіка й повторні відмови все одно можна. PoC починає структуровану історію, яка знадобиться для майбутнього предиктивного кроку.
Як ви чесно вимірюєте MTTR проти нашого поточного числа?
Погоджуючи визначення на етапі обстеження, включно з тим, що вважається початком, а що завершенням, і які зупинки виключено. Дві організації можуть вимірювати MTTR трьома різними способами; порівняння чесне лише тоді, коли обидві сторони користуються одним і тим самим.
Пов’язані продукти та програми PoC
Замовити цей Proof of Concept
Опишіть межі, які ви маєте на увазі, і ми повернемося з письмовим планом PoC: що підключається, що надаєте ви, як вимірюється успіх і який вигляд має рішення наприкінці.