CMMS софтуер за инженери по надеждност: проследяване на проблемни активи и интеграция с RCM

Инженерите по надеждност използват CMMS по различен начин от ръководителите на поддръжката или операторите на завода. Тяхната основна нужда е история на отказите — детайлна, структурирана и търсима — която позволява анализ на коренните причини, валидиране на FMEA и идентифициране на най-проблемните елементи. Повечето CMMS системи събират работни наряди, но не и данни за отказите във форма, която може да се използва за надеждностни анализи. Разликата е в структурата на данните: работен наряд, който казва „подменен лагер на компресор, линия 3“, е история на поддръжката. Работен наряд, който записва режим на отказ (отлющване вследствие на умора), компонент (вътрешен пръстен), вероятна причина (недостатъчно смазване), коригиращо действие (смяна с подобрен лагер, увеличаване на честотата на превантивната поддръжка) и време до отказ от последната подмяна, е данни за надеждността. CMMS системи, които изискват от инженерите по надеждност да изграждат тази структура чрез персонализирани полета и извличане на данни, вместо чрез вградена таксономия на режимите на отказ, създават значително аналитично натоварване. Най-добрите CMMS за инженерите по надеждност са тези, които улавят данните за отказите в момента на приключване на работния наряд от техниците — чрез структурирани падащи менюта за режим на отказ, причина и коригиращо действие — а не тези, които разчитат на бележки в свободен текст, които след това трябва да бъдат анализирани.

Средно време между неизправности (MTBF) и средно време за ремонт (MTTR) изчисленията изискват качество на данните в CMMS, което повечето организации подценяват. MTBF се нуждае от точни времеви марки на събитията на повреда — момента, в който активът е спрял да функционира, а не кога е създадена работната поръчка. MTTR се нуждае от начални и крайни времеви марки на работната поръчка, които отразяват действителното време за ремонт, а не времето за административна обработка. В повечето внедрявания на CMMS техниците завършват работните поръчки часове или дни след действителната работа, което влошава и двете изчисления. Инженерите по надеждност трябва да изискват при оценката на CMMS: автоматизирано засичане на повреди, задействано от данни за престой от OEE или SCADA (премахващо ръчното регистриране на събитията на повреда), мобилно завършване на работни поръчки на мястото на актива (осигуряващо записване на времеви марки в реално време) и вградено табло за MTBF/MTTR с визуализация на трендовете — а не стъпка за износ в Excel и изчисление там. Идентификацията на „лошите играчи“ — 20% от активите, причиняващи 80% от непланираните престои — изисква CMMS, което може да класира активите по честота на повредите, общ принос към престоя и разходи за поддръжка в единен изглед. Това е стандартна функция в качествените CMMS платформи, но изисква чисти, структурирани исторически данни, за да даде значими резултати.

Поддръжката, ориентирана към надеждността (Reliability-Centered Maintenance, RCM), генерира стратегия за поддръжка за всяко средство въз основа на анализ на режими на повреда — резултатът е набор от задачи за планова поддръжка (PM) с посочени честоти и критерии за инспекция. CMMS е механизъмът за изпълнение на RCM: той превръща изхода от RCM в графици за PM, следи за спазването и улавя данните за повреди и състояние, които валидират или актуализират RCM анализа. Предизвикателството при интеграцията е, че анализът на RCM обикновено се извършва в отделен инструмент (Reliability Workbench, Isograph или XFMEA) и трябва да бъде импортиран в CMMS по структуриран начин. Платформи CMMS с отворени API и възможност за структурирано импортиране на PM намаляват това затруднение при интеграцията. За програми за прогнозна поддръжка (PdM) CMMS трябва да получава сигнали за мониторинг на състоянието от системи за анализ на вибрации, термография или анализ на масло и автоматично да генерира или приоритизира работни поръчки въз основа на праговете на състоянието — а не да чака инженер по надеждността да създаде ръчно работна поръчка след преглед на данните от сензорите. Интегрираната архитектура на Fabrico за OEE и CMMS свързва автоматично влошаването на производителността с задействания за поддръжка, създавайки цикъл от данни, който подпомага поддръжката, базирана на състоянието, без да изисква отделен софтуерен слой за прогнозна поддръжка (PdM).