Середній час ремонту: розрахуйте MTTR і скоротіть втрати часу

Головна » Ресурси » Середній час ремонту: розрахуйте MTTR і скоротіть втрати часу

Орієнтовний час читання: 11 хвилин

Середній час ремонту (MTTR) — це середня тривалість визначеного процесу ремонту або відновлення після відмови обладнання. Щоб його розрахувати, підсумуйте тривалість зіставних завершених подій і поділіть суму на їхню кількість:

MTTR = сумарний час ремонту або відновлення ÷ кількість завершених подій

Те, який саме час ви вимірюєте, не менш важливо, ніж саме ділення. Заміна компонента може тривати 40 хвилин, тоді як верстат залишається недоступним три години. Корисний звіт чітко показує цю різницю: служба технічного обслуговування може вдосконалювати потрібний етап процесу, а виробництво — планувати роботу з урахуванням фактично доступних потужностей.

MTTR допомагає аналізувати минулі відмови. Він не показує, коли буде усунуто поточну несправність. Очікуваний час повернення обладнання до роботи має ґрунтуватися на актуальній оцінці служби технічного обслуговування. Якщо ця оцінка змінюється, зміни мають відображатися й у графіку виробництва. SkyPlanner враховує оновлену доступність верстата у спільному графіку, тож ви бачите вплив на замовлення клієнтів без ручної перебудови всіх пов’язаних черг.

Спочатку визначте, який проміжок часу вимірює ваш MTTR

Абревіатуру MTTR використовують для позначення середнього часу ремонту, повернення до роботи або відновлення, але ці назви не обов’язково означають однакові проміжки часу. У термінології надійності IEC для MTTR вживається поняття середнього часу відновлення. Звіт, який враховує лише активні ремонтні роботи, відповідає на вужче питання, ніж звіт, що охоплює також очікування фахівця або запасної частини.

У прикладі виробничого звіту в цьому посібнику MTTR вимірює весь час від відмови обладнання до підтвердження його готовності до виробництва. Відлік не зупиняється під час затримок реагування, діагностики, очікування, ремонту, випробувань і всіх обов’язкових процедур допуску до роботи. Час активного ремонту ми обліковуємо окремо.

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

За три години простою активний ремонт може займати значно менше часу

Уявімо, що обробний центр вийшов з ладу о 08:00, а об 11:00 його було допущено до виробничої роботи. У записі про цю подію виділено такі етапи:

Етап	Проміжок часу	Тривалість
Очікування реагування служби технічного обслуговування	08:00–08:30	30 хвилин
Діагностика	08:30–08:50	20 хвилин
Очікування потрібної деталі	08:50–09:50	60 хвилин
Безпосереднє виконання ремонту	09:50–10:30	40 хвилин
Перевірка працездатності	10:30–10:40	10 хвилин
Обов’язкові перевірки для допуску до виробничої роботи	10:40–11:00	20 хвилин
Повна тривалість відновлення	08:00–11:00	180 хвилин

У цьому прикладі окремий показник активного ремонту охоплює діагностику, безпосереднє виконання ремонту та перевірку працездатності: 20 + 40 + 10 = 70 хвилин. Повна тривалість відновлення становить 180 хвилин. Обидва значення правильні — вони відповідають на різні питання.

Це розмежування показує, де саме потрібні зміни. Удосконалення заміни компонента, яка триває 40 хвилин, не усуне годину очікування деталі. І навпаки: краща забезпеченість деталями не розв’яже проблему складної діагностики.

У прикладі ці етапи йдуть послідовно. У реальній ситуації деякі роботи можуть виконуватися паралельно. Враховуйте фактичний час лише один раз: якщо два фахівці працюють разом 40 хвилин, це не означає 80 хвилин простою. Людино-години можуть бути корисними для аналізу витрат на технічне обслуговування, але їх не можна ототожнювати з фактичним часом недоступності верстата.

Не враховуйте в тривалості події не пов’язані з нею втрати часу

Подія завершується, коли верстат відповідає погодженим умовам повернення до роботи, а не коли хтось згодом закриває наряд на ремонт. Якщо верстат готовий об 11:00, але матеріал для наступного замовлення з’явиться лише опівдні, ця додаткова година — затримка через матеріали, а не ще одна година відновлення.

Так само планове технічне обслуговування, звичайне переналагодження та очікування оператора не стають автоматично ремонтом для усунення відмови. Обліковуйте ці втрати часу у відповідних категоріях, а не включайте кожну хвилину простою до MTTR. Цей звіт вимірює відновлення після визначеної відмови обладнання, а не всі простої на підприємстві.

Виберіть зіставні завершені події

Почніть з одного верстата або групи справді зіставного обладнання з подібними типами відмов. І проста заміна датчика, і капітальний ремонт можуть бути обґрунтовано включені до розрахунку. Але якщо усереднити їх, не показавши склад вибірки, можна приховати проблему, яку потрібно розв’язати.

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

Застосовуйте те саме правило щомісяця та зберігайте первинні записи. Зокрема:

• Використовуйте один ідентифікатор події для однієї неусунутої відмови. Кілька сигналів тривоги, залучених фахівців або завдань у наряді на ремонт не обов’язково означають кілька відновлень.
• Не залишайте незавершені події поза увагою. Якщо ремонт ще триває наприкінці місяця, остаточна тривалість відновлення невідома. Окремо показуйте поточний статус і час, що минув від початку події; не враховуйте її як завершений ремонт тривалістю нуль годин.
• Перевіряйте часові позначки. Час внесення запису не обов’язково збігається з часом відмови, реагування чи відновлення. Якщо час відмови невідомий, вкажіть наявний час її виявлення, а не вигадуйте раніший.
• Чітко зазначайте, що виключено з розрахунку. Пояснюйте відсутні часові позначки, скасовані записи та категорії подій, які не враховуються. Не вилучайте тривалий ремонт, що відповідає умовам вибірки, лише тому, що він погіршує середній показник.

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

Приклад розрахунку MTTR

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

Завершена подія	Повний час від відмови до готовності до виробництва	Час активного ремонту
A	90 хвилин	60 хвилин
B: приклад 08:00–11:00	180 хвилин	70 хвилин
C	150 хвилин	110 хвилин
D	420 хвилин	240 хвилин
Разом	840 хвилин	480 хвилин

Основний розрахунок:

MTTR за повним часом відновлення = 840 хвилин ÷ 4 випадки = 210 хвилин, або 3,5 години.

Окремо розрахуємо середній час активного ремонту:

480 хвилин ÷ 4 випадки = 120 хвилин, або 2 години.

Якщо вказати «MTTR: 2 години» без уточнення, що йдеться лише про активний ремонт, виміряний повний час відновлення в цьому прикладі буде занижено. Якщо ж указати 3,5 години без визначення інтервалу, читачеві доведеться здогадуватися, що саме ви врахували.

Перш ніж додавати тривалості, переведіть їх в однакові одиниці вимірювання. Дев’яносто хвилин — це 1,5 години, а не 0,90 години. Якщо жодного відновлення, що відповідає критеріям обліку, не завершено, середнє значення для цієї групи визначити неможливо. Укажіть нульову кількість випадків, а середнє позначте як недоступне, замість того щоб записувати MTTR у нуль хвилин.

Щоб отримати показник для групи обладнання, додайте тривалості всіх урахованих випадків і поділіть суму на їхню загальну кількість. Не обчислюйте просте середнє з показників окремих верстатів, якщо кількість ремонтів на них різна. Зберігайте деталізацію за верстатами й типами відмов, щоб загальний показник не приховав серйозної проблеми на окремій ділянці.

Який MTTR можна вважати добрим?

Добрий результат означає поліпшення процесу відновлення, який має практичне значення й вимірюється за незмінними правилами, без шкоди для необхідного кінцевого результату. Єдиного цільового значення в годинах, доречного для будь-якого виробничого обладнання та будь-якого типу відмов, не існує.

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

Розглядайте середнє разом із кількістю випадків, загальними втратами часу, тривалістю кожного випадку та етапами, на яких виникають затримки. У прикладі з чотирма випадками повні тривалості за зростанням становлять 90, 150, 180 і 420 хвилин. Медіана дорівнює 165 хвилинам, а середнє — 210 хвилинам. Останній, довший випадок варто дослідити, а не видаляти, щоб зрівняти ці показники.

Сам по собі MTTR також нічого не говорить про частоту відмов верстата. Середній час між відмовами, або MTBF, характеризує час роботи на одну відмову для ремонтопридатного обладнання. Часті короткі та рідкісні тривалі відмови потребують різних заходів із поліпшення, навіть якщо загальні втрати часу виявляються подібними.

Найважливіше: 3,5 години — це не прогноз тривалості наступного ремонту. Для поточної несправності можуть знадобитися інша деталь, інший фахівець або інша перевірка. Використовуйте історію подібних випадків як основу для обговорення, а потім попросіть службу технічного обслуговування надати поточну оцінку та визначити час її наступного перегляду.

Скорочуйте саме ті затримки, через які виробництво не може відновити роботу

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

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

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

Якщо найбільше часу забирає очікування запчастин, з’ясуйте, яка деталь була потрібна, як її визначили та чому її не було в наявності. Цільове поліпшення доступності або ідентифікації критично важливих запчастин може бути кориснішим, ніж зберігання запасів усіх деталей. У прикладі з тригодинним відновленням 60-хвилинне очікування запчастини — очевидний привід для аналізу, а не доказ того, що певна політика управління запасами вже виправдана.

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

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

Оновлюйте виробничий план у міру зміни ситуації з ремонтом

Удосконалювати процес відновлення обладнання на майбутнє — одне завдання. Забезпечувати виконання поточних зобов’язань перед клієнтами — інше. Виробництво не може чекати середнього показника за підсумками місяця, щоб вирішити, що запускати далі.

Уявіть, що служба технічного обслуговування спочатку очікує повернення обробного центру до роботи об 11:00. Після повторної оцінки цей час переносять на 14:00. Історичний MTTR не змінився, але змінилася потужність, доступна для замовлень у черзі. Одне замовлення після механічної обробки ще потребує контролю, а альтернативний центр уже завантажений роботою для іншого клієнта.

SkyPlanner APS враховує цю зміну потужності у взаємопов’язаному виробничому графіку. Зафіксуйте погоджений зі службою технічного обслуговування період недоступності як виняток для робочого центру. Коли очікуваний час повернення до роботи зміниться, оновіть часовий інтервал і перерахуйте графік. Arcturus — ШІ для календарного планування у SkyPlanner — переплановує ті технологічні операції, на які вплинула зміна і які доступні для планування. При цьому він враховує зафіксовану потужність, налаштовані вами виробничі ресурси, залежності між операціями, пріоритети й блокування. Отримана послідовність відображається на діаграмі Ганта.

Якщо повернення до роботи очікується о 14:00, перевірте, чи залишиться після обробки завдань із черги достатньо часу на контроль і доставку. Якщо операцію можна перенести на відповідний альтернативний виробничий ресурс, перевірте також наявні зобов’язання на ньому. Для вже розпочатої роботи потрібне окреме рішення про відновлення виконання: перерахунок черги не замінює перевірки стану перерваного виробничого завдання.

Це зменшує обсяг ручного перепланування взаємозалежних черг і дає чіткішу основу для рішень щодо строків доставки. За поточну оцінку відновлення відповідає служба технічного обслуговування. Виробничі пріоритети визначаєте ви. Arcturus розраховує графік для всіх пов’язаних завдань, тож вам не доводиться окремо коригувати список робіт кожного верстата.

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

Дізнайтеся, як одна тривала поломка впливає на строки доставки

Корисний звіт MTTR показує, що саме вимірювали, які випадки сформували середнє значення та з чого починати поліпшення. Корисний виробничий план показує, що робити, поки триває поточний ремонт. Пов’язавши ці рішення, ви не дасте якісному аналізу технічного обслуговування залишитися лише окремою цифрою в місячному звіті.

SkyPlanner інтегрується з будь-якою ERP- або MES-системою через відкритий REST API, тож взаємопов’язане календарне планування може спиратися на ваші наявні дані про замовлення та виробництво.

Замовте демонстрацію SkyPlanner і підготуйте приклад однієї нещодавньої поломки, переглянутий очікуваний час повернення обладнання до роботи та замовлення клієнтів, що проходять через цей виробничий ресурс. Попросіть показати, які операції в черзі зміщуються, що відбувається з подальшими операціями та які обіцяні строки доставки потребують уваги. Якщо спершу хочете ознайомитися самостійно, спробуйте SkyPlanner із демонстраційними даними й подивіться, як зміна потужності перебудовує графік.