Поделиться
ТОиР: берем инциденты под контроль
Многие компании, задумывающиеся над внедрением системы технического обслуживания и ремонта оборудования, задавали один и тот же вопрос: "Как быстро и недорого построить эффективную систему ТОиР, которая бы окупилась за короткое время?" Ответ на этот вопрос найти нелегко, однако попытаться стоит.История отечественного рынка ИТ и консалтинговых услуг знает немало примеров, когда эффективность ТОиР пытались увеличить за 9 месяцев путем внедрения ЕАМ/CMMS-системы, планируя сокращение простоев и аварий в 2 раза уже через год. Как правило, такие проекты выполнялись с привлечением небольших сил со стороны подрядчика, практически не затрагивали ресурсы со стороны заказчика, практически не меняли организацию работы служб предприятия, и в итоге – приводили к более чем скромному результату. После чего руководство предприятия-заказчика приходило к выводу о полной бесполезности внедряемой системы и о зря потраченном бюджете и силах. А в чем причина?
Где кроется ошибка?
Можно сказать, что причина подобной слабой эффективности проектов внедрения систем класса EAM/CMMS в качестве основных средств общего повышения эффективности процессов ТОиР – нежелание обеих сторон, и заказчика, и подрядчика, тратить ресурсы на методологическую проработку внутренних процессов ТОиР, на правильное планирование действий "step-by-step", а также нежелание менять внутренние схемы работы.
Причем, как правило, основной целью 90% проектов является внедрение "готовой" ИТ–системы, содержащей в себе шаблоны правильно организованных процессов, выработанных на основе опыта внедрений в лидирующих мировых корпорациях.
Информация об авторе
Андрей Викулин, руководитель отдела EAM-систем компании "АНД Проджект".
Правда, в ходе внедрения "готовой системы в сжатые сроки", как правило, выясняется, что некоторые шаблоны требуют сильного изменения со стороны предприятия, другие нуждаются в выделении служб, которых нет в организационной структуре, третьи – просто отвергаются, так как требуют от персонала выполнения дополнительных операций, связанных, как правило, с документированием и учетом выполненных задач.
Далее делается выбор: изменить внутреннюю схему работы под шаблоны мировых практик, следуя за сильными мира сего, либо попытаться выработать свою версию, если можно так выразиться – "локализацию" - заграничного know-how на свой лад, руководствуясь в первую очередь минимумом изменений в устоявшихся схемах работы.
В подавляющем большинстве случаев выбирается второй вариант. Причем все дебаты о результатах внедрения и повышении эффективности не имеют смысла: организация работы не изменилась, добавились лишь учетные операции.
Поэтому в данной статье хотелось бы рассмотреть ту часть внедрения EAM/CMMS, которая нацелена на методическую проработку работы персонала по новым правилам, которые в свою очередь поддерживаются системой; а именно, осветить оборотную сторону внедрения ЕАМ, которая редко поднимается в большинстве проектов. Стоит отметить, что речь идет не о конкретной системе, а в целом об инструментах управления техническим обслуживанием и ремонтами оборудования на базе различных информационных продуктов таких, как Imaint, Microsoft Dynamics AX (модуль ТОиР, разработанный компанией "АНД Проджект"), SAP ТОРО и других.
С чего надо было начинать
А как же обстоит дело с эффективностью ремонтов, которыми как раз и должна управлять внедряемая ЕАМ-система? Если быть более точным, то боремся мы все не за эффективность ремонтов, а за выдерживание планового режима работы оборудования – говоря проще, за его надежность. Ведущие международные эксперты по этому поводу советуют придерживаться принципа "It is more important to do the RIGHT THINGS than to do THINGS RIGHT" (Более важно выполнять правильные действия, нежели чем выполнять действия правильно).
В нашем случае, "правильные действия" - это понимание того, что мешает нормальной работе оборудования, и только потом разработка перечня действий по устранению данных факторов – то есть операций по ТОиР. Внедрение ЕАМ-системы в данном случае выступает как создание инструмента поддержки процессов, а не как основная цель.
Если обратиться к практике, то типовые факторы, снижающие надежность работы оборудования, сводятся к вполне простым и понятным вещам. Во-первых, это ненормативный характер эксплуатации (в том числе из-за несоответствующих условий окружающей среды и неквалифицированного персонала). Затем следует отметить факт незнания технологии обслуживания (например, по причине низкой квалификации кадров или отсутствия необходимой оснастки). В-третьих, это некачественные запасные части и материалы, а также наличие заводских дефектов оборудования.
Факторов может быть множество, но подавляющее их большинство как раз будет принадлежать этим трем группам. После детального анализа факторов и ранжирования их с точки зрения значимости в условиях конкретного предприятия можно переходить к планированию процедур по их устранению.
Как сделать инциденты контролируемыми?
Если предприятие не принадлежит к 5% тех, кто имеет полную техническую документацию по оборудованию и штат сертифицированных за границей ремонтников, то в большинстве случаев вариантов действий по устранению (или хотя бы нормализации) данных факторов не очень много. Сначала надо организовать учет наработки оборудования. Там, где есть счетчики мотто-часов, необходимо организовать фиксирование информации. Там где нет – фиксировать дату и время пуска/останова линий и агрегатов. Не понимая характера нормальной работы оборудования, невозможно понять, что этому мешает.
ТОиР от "АНД Проджект":
- 7 лет опыт внедрения EAM-систем
- Решения на базе Microsoft Dynamics AX и iMaint
- Мощная методологическая поддержка внедрения EAM-систем
- Отраслевые решения и экспертиза - энергетика, добыча полезных ископаемых, телеком, пищевая промышленность, предприятия ТЭК, химическая промышленность и другие
Затем следует создать классификатор типов инцидентов. Каждый тип инцидента связан к каким-либо фактором снижения надежности. Минимальный вариант классификатора: механический дефект, дефект электрической части, дефект КИПиА (контрольно-измерительных приборов и автоматики), неисправность автоматики и систем управления, прочие виды неисправностей. Для начала можно и так, а впоследствии необходимо расширить классификатор (в идеале – сделать его иерархическим), чтобы в процессе анализа инцидента можно было детализировать его в учете как "дефекты механической части/дефекты движущихся поверхностей/дефекты подшипниковых узлов/расцентровка подшипника". Кроме того, надо создать классификатор тяжести инцидента, то есть, насколько быстро надо среагировать, чтобы не усугубить последствия. Ведь одно дело – течь воды из трещины водопровода, другое – течь масла и гидроцилиндра под давлением 600 атмосфер. В зависимости от тяжести инцидента устанавливается нормативный срок реакции: к течи холодной воды можно послать мастера в течение дня, а к фонтану масла из гидроцилиндра надо бежать со всех ног, пока диспетчер регистрирует инцидент в системе. Также необходимо создать классификатор объектов ремонта, в котором сгруппировать оборудование, здания и сооружения таким образом, чтобы можно было сравнивать статистику однотипных аварий и простоев на однотипном оборудовании. Причем группировка должна быть тоже иерархической – от класса (механика, электрика, здания и т.п.) к конкретной модели или маркировке – КcВ90-220 (вертикальный двухкорпусной конденсатный насос). Группировка позволит ценить частоту и характер проявления основных видов дефектов на схожем оборудовании, что укажет на огрехи эксплуатации либо на заводские дефекты.
Очень важен и такой шаг, как установление понятного классификатора приоритетов оборудования. Он необходим для оценки срочности ремонта как с точки зрения тяжести последствий аварии, так и с точки зрения приоритетности конкретной единицы оборудования. Этот уровень градации жестко связан с ролью данной аппаратуры в обеспечении непрерывности производственного процесса и наличия дублирующих мощностей. Это позволит при диспетчеризации дефектов направлять силы на самые важные работы, а не туда, откуда громче всего кричат.
Короткая ссылка
