"Монстр, пожирающий ресурсы". Такое шуточное определение надежностно-ориентированного технического обслуживания (RCM) приводит Erik Hupjé на своём сайте.
Но в каждой шутке, как известно, есть только доля шутки. А остальное - правда. Почему же есть организации, которые на каком-то этапе говорят: "Хватит этой ерунды с RCM, это слишком дорого"?
Причиной являются ошибки, которые они допускают при внедрении RCM. На пять самых распространенных из них указывает автор этой статьи.
1. Непонимание того, что вы начинаете.
Зачастую в программах RCM все инвестиции заказчик делает вначале, а все ощутимые выгоды он получает в конце. Неготовность к этому, когда потрачено много денег, а результатов относительно мало, приводит к прекращению поддержки проекта со стороны руководства заказчика.
Участникам проекта лучше настроить программу RCM так, чтобы внедрять улучшения на ранних этапах и быстро получить ощутимые выгоды.
2. Выполнение RCM на всем предприятии.
Лучше этого не делать, так как вы потеряете много времени и денег. Следует сначала сосредоточиться на самых сложных и проблемных системах, и лишь затем переходить к системам, которые менее сложны и доставляют меньше хлопот. По ходу проекта нужно четко документировать затраты и выгоды, и до тех пор, пока уровень рентабельности инвестиций высокий, следует продолжать дальнейший анализ RCM.
3. Не вовлечение нужных людей.
Обычно организации пытаются ограничить свои усилия и проводить RCM-анализ с меньшей командой, чем это действительно необходимо. И если вы попытаетесь выполнить RCM, не привлекая всех необходимых специалистов, у вас ничего не получится.
Это относится и к внутренним, и к внешним ресурсам. Чтобы добиться успеха, нужен опытный, компетентный координатор (фасилитатор) RCM, который будет руководить процессом. Немногие организации обладают такого рода внутренними возможностями, поэтому необходимо привлекать внешнего консультанта.
4. Слишком много времени тратится на блок-схемы и анализ критичности.
Очень легко потратить бесчисленное количество часов на красивые блок-схемы и подробный анализ критичности. Обычно это происходит, когда разрабатывается план проекта RCM, который в конечном итоге охватывает всё предприятие. К тому времени, когда это будет сделано, останется очень мало времени и бюджета для проведения фактического анализа RCM.
Поэтому не делайте все свои блок-схемы и весь анализ критичности заранее. Делайте это система за системой, насколько это возможно.
5. Проведение тщательного RCM-анализа без последующей реализации.
Автор приводит пример азиатской компании, которая провела один из лучших документированных анализов RCM, которые он когда-либо видел.
Обширный анализ критичности, отличные блок-схемы, хорошо описанный эксплуатационный контекст, четкие и точные функции, функциональные отказы, обширный анализ видов отказов (FMA) и хороший анализ задач. Каждый проведенный RCM-анализ для каждой системы был красиво переплетен в большие папки.
Все это было там. Это было идеально. Должно быть, это было довольно дорого. Была только одна маленькая проблема. Когда автор спросил про эти скоросшиватели… они просто лежали на полке в офисе много лет и просто пылились.
Этот дорогостоящий RCM-анализ никогда не шел дальше этих скоросшивателей. Ни одна часть этого великого труда не попала в CMMS и не была реализована. Это случается чаще, чем можно подумать.
Поэтому, когда вы создаете свой проект, убедитесь, что в нем участвуют нужные заинтересованные стороны. Особенно в крупных организациях. Вы должны убедиться, что люди, которые будут внедрять RCM в вашу CMMS, будут вовлечены с самого начала. Таким образом, они получают результаты анализа в удобном для понимания и реализации формате.
Затем разбейте свое исследование на этапы, применяя результаты первого этапа, прежде чем переходить к следующему этапу. Помните, реализация — это то, где создается ценность.
