Законы Мерфи в проектах цифровизации ТОиР

Почему «всякая работа требует больше времени, чем вы думаете»? Правда ли, что «предоставленные сами себе события имеют тенденцию развиваться от плохого к худшему», а «всякое решение плодит новые проблемы»? И как все эти наблюдения связаны с процессом техобслуживания и ремонтов материальных фондов предприятия? Сегодня мы поговорим о законах Мерфи и о том, какое место они занимают в ТОиР.

Вы можете прочитать статью внизу или просто посмотреть это видео:) Ну или и то, и другое — как пожелаете.

Почему мы говорим о ТОиР?

Наша компания «Деснол Софт» занимается разработкой и развитием линейки решений на платформе 1С, ориентированных на управление ремонтами и управление надежностью оборудования. Наши разработки — «1С: ТОИР Управление ремонтами и обслуживанием оборудования» и «1С:RCM Управление надежностью».

Что такое 1С: ТОИР? Это решение, которое обеспечивает всесторонний учет в рамках процесса управления ремонтами оборудования. Но основные возможности использования программы — гораздо глубже и шире. Вся соль — в нюансах организации бизнес-процессов. При осознанном и ответственном подходе к организации процессов ТОиР система автоматизации начинает показывать эффективность буквально на этапе опытно-промышленной эксплуатации, а в иных случаях — путь долог и труден. И наш рассказ — именно о тех подводных камнях, этих «иных случаях». Мы приведем примеры того, почему же «если что-то может пойти не так, оно пойдет не так».

Законы Мерфи

Как появились законы Мерфи и что это вообще такое?

Так называемый закон Мерфи был впервые сформулирован и использован на американской авиабазе в 1949 году капитаном Эдвардом Мерфи. в то время он был инженером на проекте ВВС США, целью проекта было определение максимальной перегрузки, которую способен выдержать человеческий организм. И вот в один прекрасный день капитан обнаружил критическую ошибку, допущенную одним из техников при монтаже экспериментального оборудования, и сказал в его адрес крылатую фразу: «Если что-то можно сделать неправильно, это будет сделано неправильно». Руководитель проекта, составлявший список различных правил и законов, добавил это высказывание в свой список и озаглавил его «Закон Мерфи». Постепенно этот список стал достоянием общественности и начал пополняться, по сути, наверное, став прообразом современных мемов.

При этом в законах Мерфи скрыт глубокий смысл. Ну, и немного черного юмора. И поэтому мы смотрим на них не с пессимизмом, а скорее с интересом, пытаясь каждый раз разобраться, с какого же момента «всё пошло не так».

Основных законов Мерфи всего семь. И сейчас мы рассмотрим каждый из них с точки зрения нашего любимого ТОиР, то есть процесса техобслуживания и ремонтов оборудования и прочих производственных и непроизводственных активов.

Закон № 1. Всё не так легко, как кажется

Нет запчастей — есть люди, нет людей — есть запчасти
Первый эпизод из этой серии — переход на график ППР (планово-предупредительных ремонтов).

Желание перейти на плановые ремонты — это классика жанра, как говорится, для 102 процентов предприятий. Нормативы есть. Техкарты есть. Люди есть. Можно строить график «по наработке», «по календарю» и вроде как проблем нет. Но… упираемся в МТО (материально-техническое обеспечение): не получается обеспечить поставки запчастей точно в срок. А когда (с запозданием) привозят запчасти, выясняется, что теперь уже людей не хватает, т. к. объем накопившихся за время ожидания работ превысил емкость по персоналу. Да еще к тому же пара ключевых механиков в это время по графику отпусков ушли на заслуженный отдых.

1С: ТОИР эту проблему решает: строит график МТО под план по ремонтам. И если ремонт «плывет», то и план по ресурсам можно легко скорректировать, и мы можем увидеть пики потребностей в персонале, принять решение об отпусках или более точно спланировать перенос ремонта, чтобы не создавать «узкое горлышко» или, наоборот, разобрать завал.

Окей. Даже если график ППР мы построили. А дальше…. Начинается реальная жизнь: внеплановые работы, аварии, пандемия, остановка производства. А дальше сталкиваемся с тем, что часть оборудование ремонтируется по наработке, а часть — по расписанию. И вот построенные графики поехали… вопрос — как их скорректировать и скорректированные вести, кроме как использовать автоматизированную системы?

Меньше знаешь — хуже управляешь!

Следующий эпизод. Наш клиент — сервисная компания, обслуживающая вахтовые поселки на условиях аутсорсинга. Заказчик — крупный золотодобытчик. Желание заказчика — видеть все заявки, работы, ремонты, дефекты как подтверждение объема работ и затрат подрядчика. Подрядчик, реализуя желание заказчика, внедряет 1С: ТОИР и начинает вести учет оборудования, заявок, ремонтов — в общем всего того, что ведется в 1С: ТОИР.

Чтобы было понятно, инфраструктура вахтового поселка — это 8 общежитий, 4 столовых, 3 магазина, спорткомплекс, несколько бань и т. п. В общем, можно сказать, инфраструктура небольшого микрорайона.

Ну и вот на защите результатов наш сотрудник-консультант совместно с представителями нашего клиента — сервисной компании выступают перед комиссией директоров генерального заказчика (т. е. заказчика услуг нашего клиента) и показывают аж 3328 дефектов оборудования, зарегистрированных всего за 3 месяца. И эта комиссия со стороны генерального заказчика тут же говорят: «Ничего себе! А что там такого могло случиться?». А ведь каждый из трех тысяч — реально устраненный дефект!

Какие выводы мы из этого случая можем сделать? Вывод один — «не всё так легко, как кажется». И пока мы не начинаем измерять — сколько ломается, что ломается, сколько времени, денег, людей идет на ремонты — мы объективно не знаем: «А что же там творится?». Необъективная оценка ситуации ведет к чему? К неправильным решениям. А отражаются они на чем? На качестве и на прибыли.

Ремонт без причины — признак… сами знаете кого

Тема следующего эпизода — регистрация дефектов и фиксация причин их возникновения. Суть эпизода: если мы толком не анализируем причины, часто и фиксировать их смысла нет. Например, зарегистрировали дефект, без анализа причин провели ремонт. Но истинная причина так и не была устранена. В конце концов оборудование вышло из строя, и ущерб от этого был гораздо больше, чем мог бы быть, если бы мы проанализировали причины изначально.

Вспомним несколько реальных случаев из нашей проектной практики. Розничная сеть. Кондиционер в магазине не справлялся с охлаждением. Мастера приехали, дозаправили фреоном и уехали. А по факту внешний блок забился пылью и песком, чуть позже вышел из строя, пришлось заменять кондиционер полностью.

Или другой пример — про газовые котлы. Сердобольный сотрудник держал их на минимальной мощности. Позже выяснилось, что при такой эксплуатации газовый котел выходит из строя быстрее, чем если бы он работал на номинальной мощности. То есть искреннее желание сотрудника продлить срок службы оборудования привело к скорейшей его поломке. К слову сказать, что и в график ППР котел тоже включен не был.

Вывод из этой ситуации таков. Фиксировать дефекты недостаточно, нужны процедуры анализа причин дефектов. И самая простая техника здесь — «5 почему» (также реализована в 1С: ТОИР).

Закон № 2. Всякая работа требует больше времени, чем вы думаете

Снова крупная розничная сеть. Слесаря-рабочего отправили выполнять ремонт по привычному маршруту сразу в три торговых точки. Но при этом характер дефекта не был проанализирован заранее, поэтому слесарь «завис» на первом объекте, а до двух других даже не добрался, т. е. два объекта остались просто необслуженными. Ситуация повторялась из раза в раз. В итоге — дополнительные простои, убыток от размороженной продукции, недовольство работой службы эксплуатации и т. д. Заявки при этом велись примитивно: фиксировались ФИО, адрес, телефон, краткое описание дефекта. Всё.

После автоматизации и внедрения 1С: ТОИР дефекты расследуются (для их более качественного устранения), внедрены нормативы обслуживания, к каждому объекту ремонта привязаны техкарты с продолжительностью работ. Плюс мы добавили дополнительную опцию — мобильное приложение. Вся информация доступна слесарю прямо на месте — из смартфона, а еще он может сообщить инженеру в офис, если что-то пошло не так, а инженер в офисе уже принимает оперативное решение-либо отправляет «на подмогу» другого сотрудника, либо делает что-то еще.

Закон № 3. Из всех возможных неприятностей произойдет именно та, ущерб от которой больше

А вот эпизод, который иллюстрирует, как говорится, «не слишком большой ум» и отвагу. На одном из предприятий руководство долго выбирало, какие именно мобильное устройства приобрести для работы механиков. В результате выбрали дорогие пылевлагозащищенные промышленные планшеты, которые можно ронять на пол, с которыми можно работать под дождем и так далее.

И что вы думаете? В течение первой недели работы один из этих планшетов «как бы случайно» был утоплен рабочими в кислоте, а другой «как бы случайно» забыт под прессом!

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

Суть посыла — гораздо глубже. Если не подготовиться к внедрению новых технологий заранее, можно столкнуться с саботажем и его малопредсказуемыми последствиями. А это ставит под угрозу весь проект, затраты на его реализацию и снижает шансы на получение положительных результатов, которых обычно достигают наши заказчики при внедрении системы автоматизации техобслуживания и ремонтов.

Закон № 4. Если четыре причины возможных неприятностей заранее устранены, всегда найдется пятая

Оранжевый — новый горячий
Представьте себе крупный агрохолдинг. Заступает ночная смена. Выходит новый дежурный (он же начальник смены). В журнале открытых дефектов — пусто. Он проводит осмотр… И видит, что подшипник на одном из вентиляторов (а диаметр самого подшипника более метра) — красный, то есть раскаленный! Естественно, тут же следует останов оборудования и — как следствие — простой производства. Когда вентилятор остановили и подошли, чтобы осмотреть, оказалось, что подшипник был накануне окрашен оранжево-красной краской. Он не был раскаленным, он просто был красным, но о факте его покраски (в нестандартный цвет) не было записи в журнале обслуживания, поэтому дежурный сразу подумал худшее. Т. е. потери из-за простоя — абсолютно бессмысленные.

К слову, в 1С: ТОИР можно прямо из карточки объекта ремонта посмотреть информацию обо всех работах и ремонтах, выполненных с данным объектом. И если бы у этого дежурного механика был под рукой (например, в мобильном телефоне) электронный журнал выполненных работ, он мог бы по нему «пробежаться» и посмотреть: что было сделано, какие мероприятия по обслуживанию проводились. Он наверняка увидел бы запись о том, что подшипник был окрашен, и такой ситуации можно было бы избежать.

«Потемкинские» ремонты

Еще один эпизод из этой серии. Нефтеперерабатывающее предприятие является заказчиком услуг по ТОиР, а ремонты и эксплуатационные мероприятия осуществляет внешний подрядчик. Внедрили ППР. Начали сравнивать с прошлогодними отчетами — и выяснили, что подрядчик проводил работы на несуществующем оборудовании, а на ряде оборудования в эксплуатации ППР вообще не проводился. Вот такие «потемкинские» ремонты.

Легенды нашего городка

Или другой пример. Крупное предприятие розничной торговли федерального масштаба. Ремонты выполняются в тысячах торговых точек. Рабочим объявили, что будет внедряться мобильное приложение. Сотрудники не знали, что при этом им будут выдаваться служебные мобильные телефоны, поэтому на следующий день большинство из механиков пришло на работу… с кнопочными! Чтобы мобильное приложение установить было нельзя.

Дальше — больше. Начали работать с приложением. И тут пошла легенда, что местоположение текущего пользователя будет отслеживаться по геокоординатам (на самом деле это правда, наше приложение это может, так делается для контроля присутствия сотрудников на объектах и повышения эффективности работы ремонтной службы). Начались приколы. Кто-то, когда выполнял работы, обматывал телефон в фольгу. А кто-то обматывал в фольгу и клал в кастрюлю, если задерживался с утра дома и опаздывал на работу.

Закон № 5. Предоставленные сами себе события имеют тенденцию развиваться от плохого к худшему

«Отжимание» и прочие неспортивные приемы
Опишем ситуацию, которая наблюдается у многих наших заказчиков. Разные подразделения делают заказы на запчасти. Но если при этом нет резервирования запчастей под конкретные работы, возникает ситуация «кто первым встал, того и тапки». Начинается скрытая игра между подразделениями — «отжимание» и прочие неспортивные приемы.

Что делать? Если есть 1С: ТОИР, резервирование гарантировано, и подобных проблем уже не будет: запчасть под ремонт зарезервирована и выдается только под конкретный заказ.

Самоделкиным посвящается

Еще один важный момент — учет гарантий. Как правило, если учета гарантий нет, то ремонтники смело разбирают, например, станок (гарантийный срок которого еще не истек), тем самым лишая свою компанию возможности ремонта этой единицы оборудования в рамках гарантийных обязательств поставщика. И получается: ремонт сделали за свой счет (хотя могли бы за счет поставщика оборудования) и, не исключена вероятность, что сделали плохо — гарантии при этом лишились в любом случае.

В 1С: ТОИР есть возможность запрещать выполнять работы хозспособом на оборудовании, которое находится на гарантии, тем самым избегая вот таких вот ненужных потерь.

Закон № 6. Как только вы примете решение делать какую-нибудь работу, находится другая, которую надо делать раньше

В качестве иллюстрации этого закона сразу же вспоминается ситуация до старта проекта у одного из наших из заказчиков. У клиента несколько ТЭЦ. Есть выделенное юрлицо, которое занимается ремонтами. Планирования нет, четких распоряжений нет. Зато есть много подразделений, которые нуждаются в ремонте. И что получается? Все звонят в ремонтную службу и тот, кто первым дозвонится, будет первым в очереди на ремонт. Тот начальник, кто громче наорет или чья должность выше, получит ремонтную бригаду. Рабочих вызывает большая шишка на ТЭЦ-1, они еду туда, там течет кран. А в это время на ТЭЦ-2 проблема с основным оборудованием — не происходит нагнетание пара. Простой, потери денег…

Или еще одна компания. Фирма осуществляет сервис медицинского оборудования в городских больницах и поликлиниках Москвы. Заявок много, инженеров мало. Приоритеты непонятны. Что-то сломалось, а что сломалось, как именно сломалось — информации нет. Что чинить в первю очередь, а что может подождать — неизвестно.

Аналогичные ситуации наблюдаются часто, и мы решаем их на наших проектах.

Закон № 7. Всякое решение плодит новые проблемы

Какие проблемы плодит, казалось бы, понятное решение — внедрить 1С: ТОИР?

Но «не всё так просто», как мы с вами уже знаем…

Есть гипотеза: «надо внедрить 1С: ТОИР, и все наши проблемы решатся». Мы часто слышим это от наших заказчиков. Однако те, кто так говорят, не оценивают последствия: ведь, когда внедрение подойдет к концу и система заработает в полную силу, нужно с ней работать, регулярно вводить данные. Причем делать это точно, оперативно, скрупулезно и детально. А на это часто нет времени… Или вводят все по-разному (кто как хочет). Или вводят неоперативно — в конце дня. Или вообще данные неоткуда взять…

Решение есть. Есть различные способы упростить и улучшить ситуацию: это и мобильные приложения, это и интеграция с АСУТП, это системы мониторинга. Сейчас мы умеем загружать данные в 1С: ТОИР с любого оборудования, практически из любых источников. А для персонала мы проводим обучение, адаптируем регламенты и составляем инструкции.

P. S.

Ну и на закуску — еще один курьезный случай. На промышленном предприятии пропала колесная пара. Ее так и не удалось обнаружить. И когда один из аксакалов производства уходил на пенсию, у него спросили: «Михалыч, а куда же в итоге делась та колесная пара? Ответ Михалыча удивил даже бывалых. Он ответил, что колесная пара получилась с дефектом, и, чтобы не лишиться премии, он согнал ее в стружку и просто стал делать новую.

Что здесь сказать? Если бы на этом предприятии был внедрен 1С: ТОИР, такую ситуацию можно было легко отследить, потому что система позволяет вести учет не только нагрузки, но и полезных отходов (в частности, стружки). И подобный факт было бы достаточно сложно утаить.

В общем, как мы с вами видим, любая даже самая непростая ситуация позволяет извлечь уроки. А риск можно расценивать и как угрозу, и как возможность.

Если процессы ТОиР у вас до сих пор не автоматизированы, значит, все перечисленные законы Мерфи у вас работают на полную катушку. Потому что «если что-то может пойти не так, оно пойдет не так». Автоматизируйте процессы управления техобслуживанием и ремонтами, и отрицательных проявлений законов Мерфи на ваших предприятиях будет значительно меньше!