Основни изводи: Средното време за ремонт ( MTTR ) е ключовият показател за поддръжка с най-пряката и измерима връзка с възстановяването на приходите от производство. Всяка минута от средното време за ремонт (MTTR) е минута от загубена продукция.
Fabrico намалява MTTR чрез четири механизма: по-бързо откриване на повреди, предварително зареден контекст на активите за техниците, автоматична проверка на наличността на части и Fabrico Assistant, който отговаря на диагностични въпроси за секунди. Оперативният отдел отчита намаление на MTTR с 35, 55% в рамките на 90 дни след внедряването на Fabrico.
Средното време за ремонт (MTTR) е средното време от откриване на повреда в оборудването до възобновяване на производството. Звучи като показател за поддръжка. Всъщност е показател за приходи.
На производствена линия, генерираща 4000 долара на час, средно 90-минутен MTTR означава, че всяка повреда на оборудването струва 6000 долара загубено производство. Намаляването на MTTR от 90 минути на 45 минути спестява 3000 долара на повреда. За завод, който преживява 20 повредни събития на месец, това са 60 000 долара на месец възстановен производствен капацитет, 720 000 долара годишно, от подобрение на един показател.
И все пак, MTTR рядко се появява в производствените табла с важността, която заслужава. Той се проследява в CMMS като показател за оперативна поддръжка, отделен от данните за приходите от производство, което би направило финансовото му значение очевидно. Това отново е проблемът със силозите за данни: когато OEE и CMMS се намират в отделни системи, производствените разходи на MTTR остават невидими за хората, които финансират програмите за подобряване на поддръжката.
Fabrico прави видима връзката между MTTR и приходите, и предоставя специфичните инструменти, които систематично намаляват всеки компонент на MTTR.
MTTR не е единична метрика, това е сбор от четири отделни времеви периода, всеки с различни коренни причини и различни лостове за подобрение.
Време за откриване: Времето от възникване на повреда до откриването ѝ. В инсталации без OEE мониторинг в реално време, откриването зависи от наблюдението на оператора, което може да отнеме 5, 30 минути за повреди, които не произвеждат очевидни визуални или слухови сигнали.
OEE мониторингът на Fabrico открива промени в състоянието на машината за по-малко от 60 секунди от PLC сигнала, независимо дали някой наблюдава машината. Времето за откриване в инсталации, наблюдавани от Fabrico, е постоянно под 2 минути в сравнение с 15, 30 минути в инсталации, разчитащи на наблюдение от оператора.
Време за реакция: Времето от откриването на повреда до пристигането на техник при машината. В заводи без автоматизирано създаване на работни поръчки това включва телефонно обаждане от производството до поддръжката, ръчно създаване на работна поръчка и назначаване на диспечер, 15, 30 минути в повечето операции.
Fabrico създава работната поръчка CMMS автоматично в рамките на 60 секунди след откриване на повредата от OEE и незабавно изпраща мобилно известие до назначения техник. Времето за реакция намалява от 20, 30 минути на 2, 5 минути.
Време за диагностика: Времето, което техникът прекарва в диагностициране на основната причина след пристигането си при машината. Това е компонентът, който варира най-много - от 10 минути за познати, добре документирани повреди до 60+ минути за непознати повреди на сложно оборудване.
Fabrico атакува времето за диагностика чрез два инструмента: предварително заредения контекст на активите в работната поръчка (история на поддръжката, скорошни профилактични прегледи, тенденция на OEE за последните 14 дни) и Fabrico Assistant, който чете ръководството за машината и отговаря на диагностични въпроси директно в работната поръчка.
Време за ремонт: Действителното време, необходимо за извършване на ремонта, след като бъде установена основната причина. Този компонент до голяма степен се определя от сложността на ремонта и наличността на части.
Автоматичната проверка на частите на Fabrico, когато техник отвори работна поръчка, Fabrico показва дали необходимите части са на склад и къде се намират, елиминира забавянето при търсене на части, което добавя 20, 45 минути към времето за ремонт в заводи без видимост на наличностите в реално време.
Времето за диагностика е най-променливият и най-подобрим компонент на MTTR. Това е и компонентът, където разликата между опитен старши техник и младши техник е най-силно изразена.
Старшите техници диагностицират познати повреди бързо, защото са ги виждали и преди. Те знаят от опит, че натискането на код за грешка E42 на този конкретен модел означава, че оптичният енкодер се е отклонил, а последователността за нулиране е F3-F3-ENTER, последвана от проверка на фазата на контакти 7 и 8.
Младшите техници, които се сблъскват със същия код за грешка за първи път, могат да прекарат 45, 60 минути в ръководството, по телефона със старши техник или с линията за обслужване на производителя на машината.
Асистентът на Fabrico запълва тази празнина в опита. Когато техник отвори работна поръчка за машина с качена документация, той може директно да попита Асистента: „Какво означава код за грешка E42 на този модел и как да го изчистя?“
Асистентът прочита каченото ръководство за машината, не общи производствени знания, а действителната документация за конкретния модел машина, и предоставя директен, конкретен отговор с точната последователност за нулиране, частите, които може да са необходими, и съответните стъпки за безопасност от ръководството.
Тази реакция отнема по-малко от 10 секунди. Техник, който би отделил 45 минути за диагностициране на повреда, я отстранява за по-малко от 15 минути общо.
В екип по поддръжка от 15 души, обработващ 150 работни поръчки на месец, комбинираният ефект е значителен: дори ако 20% от работните поръчки включват кодове за грешки, които се възползват от насоките на Fabrico Assistant, и всяка от тях спестява 25 минути време за диагностика, това са 750 минути на месец - 12,5 часа - възстановен капацитет за поддръжка.
Най-недооцененият фактор за дългия MTTR е липсата на части. В производствени операции без интеграция на инвентара в реално време с CMMS, техник, който диагностицира повреда за 10 минути, може след това да прекара 30, 45 минути в потвърждение, че необходимата част е налична, да я намери в склада и да изчака, ако не е налична и трябва да бъде набавена.
Управлението на части на Fabrico предоставя две подобрения на тази последователност:
Проверка на части в работната поръчка: Когато техник отвори работна поръчка на Fabrico за конкретен актив, Fabrico проверява каталога с резервни части и показва състоянието на наличността на най-често срещаните резервни части за този тип актив.
Работна поръчка за подмяна на лагер на ред 3 на преса показва, че лагерът SKF 6205-2Z (най-често срещаната подмяна на този модел преса) има 4 бройки на склад в контейнер C7-14. Техникът знае, преди да напусне машината, дали ремонтът е изпълним с налични части.
Прогнозно потребление на части от графици за планиране на ремонт: CMMS на Fabrico резервира части, когато се генерира планирано планиране на ремонт, преди то да бъде изпълнено.
Тази прогнозна резервация предотвратява сценария, в който техник пристига на машина за планирано планиране на ремонт, само за да открие, че необходимите части са били използвани при авариен ремонт миналата седмица и не са били поръчани отново.
Наличността на части за планиране на ремонт в операции с резервация на части от Fabrico е постоянно над 95%.
Fabrico автоматично проследява MTTR, изчислен от времевия печат за откриване на повреда на OEE до времевия печат за затваряне на работната поръчка на CMMS, за всяко събитие на повреда на всеки наблюдаван актив. Това предоставя данни за MTTR на три нива:
Операциите, които внедряват интегрираните OEE и CMMS на Fabrico, постоянно отчитат намаление на MTTR с 35, 55% в рамките на 90 дни. Намаляването се дължи едновременно на всичките четири компонента на MTTR, по-бързо откриване, по-бърза реакция, по-кратко време за диагностика от Fabrico Assistant и по-малко забавяния на частите благодарение на интеграцията на инвентара в CMMS.
При производствена стойност от 4000 долара на час, 40% намаление на MTTR (средно време за ремонт) в завод с 20 аварии на месец се превръща в 48 000 долара на месец възстановен производствен капацитет, преди да се отчете подобрението в съответствието с изискванията за управление на производствения процес, което на първо място намалява честотата на авариите.
Намаляването на MTTR не е само за по-бързи ремонти. Това е първата стъпка в маховика на надеждност, която се увеличава с времето.
Когато MTTR (средното време за ремонт) намалее, екипите по поддръжката прекарват по-малко време в режим на реактивен ремонт. Това възстановено време може да бъде инвестирано в превантивна поддръжка - подобрение в съответствието с изискванията за превантивна поддръжка, което намалява честотата на повреди.
Когато честотата на повреди намалее, има по-малко аварийни повиквания, което намалява натиска, който причинява отложени превантивни ремонти. Когато отложените превантивни ремонти намалеят, съответствието с изискванията за превантивна поддръжка се подобрява допълнително. Когато съответствието с изискванията за превантивна поддръжка се подобри, MTBF (средното време за отказ) се увеличава.
Когато MTBF се увеличи, MTTR става по-малко критичен, защото има по-малко ремонти за извършване.
Това е маховикът на надеждността: намаляване на MTTR → повече време за профилактично обслужване → по-високо съответствие с изискванията за профилактично обслужване → по-малко повреди → по-ниско въздействие на MTTR върху общия OEE.
Fabrico е платформата, която стартира и поддържа този маховик. Намаляването на MTTR идва от по-бързото откриване, реакция и диагностика, които интегрираните OEE и CMMS на Fabrico позволяват. Допълнителното време, освободено от намаляването на MTTR, се връща директно в графика за профилактика на Fabrico CMMS, генерирайки по-добро съответствие с програмата за профилактика.
По-доброто съответствие с програмата за профилактика се вижда в данните за тенденцията на OEE на Fabrico като нарастваща MTBF. Подобрението на MTBF захранва оптимизацията на интервала за профилактика на AI Agent. Цикълът се усложнява.
Това означава „интегрирана OEE и CMMS“ от оперативна гледна точка. Не два инструмента, свързани чрез API, а платформа, където подобряването на една метрика създава условия, които подобряват следващата.