Для фондоемких предприятий очень важно добиться управляемости процессов эксплуатации, технического обслуживания и ремонта (ТОиР) производственной базы. Тем более что кризис заставляет компании работать на пределе эффективности.
Среди первоочередных мер: оптимизация затрат на ТОиР, повышение коэффициента использования оборудования и его надежности, полная загрузка персонала. Решение всех этих задач заключается в создании единой информационной системы управления ТОиР в масштабе предприятия (ИСУ ТОиР).
Кто принимает решение о покупке?
Необходимость информатизации ТОиР, то есть потребность в информационном обеспечении управления и операций в сфере ТОиР, становится очевидной в силу проблем, с которыми на определенном этапе сталкивается предприятие. Например, в течение ряда лет накапливаются неликвиды запчастей, которые в свое время были куплены, но почему-то не востребованы. Или в компании нет человека, отвечающего за необоснованную закупку той или иной товарно-материальной ценности (ТМЦ), а план закупок формируется приблизительно – от показателей прошлого года плюс некоторый запас.
Также довольно распространенная проблема – отсутствие точной информации, каким оборудованием владеет компания (количество, номенклатура, текущая конфигурация, где установлено), но при этом владелец (да и просто логика рыночных отношений) требует наладить учет. Это может иметь место, к примеру, на предприятии электрических сетей, где подразделения удалены от офиса на сотни километров. В процессе ремонтов меняются схемы сетей и состав установленного оборудования, но все изменения остаются на бумажных носителях, а их количество постоянно растет и найти некоторые документы бывает весьма непросто.
Еще один отрицательный пример – когда на предприятии отсутствует оперативная информация о дефектах. В этом случае реакция на возникшие дефекты запаздывает, и в итоге возникают отказы с соответствующими последствиями в виде внеплановых простоев и повышенных затрат на ремонты, проводимые по факту отказа.
Если эти и подобные им проблемы, которых может быть не один десяток, актуализированы и осознаны руководством предприятия, то можно считать, что оно находится в начале пути по внедрению ИСУ ТОиР. Пора проводить анализ имеющихся на рынке программных продуктов, искать подрядчиков работ, собирать информацию об опыте реализации таких проектов.
Есть ряд критериев, на которые нужно ориентироваться при выборе программного обеспечения (ПО) и поставщика услуг по внедрению ИСУ ТОиР. Предложение должно быть:
а) приемлемым по цене,
б) охватывать текущие задачи в сфере ТОиР, в том числе специфические отраслевые,
в) иметь перспективу развития (новые задачи обязательно возникнут),
г) иметь позитивную ретроспективу в виде реализованных проектов.
При этом в процессе оценки потребительских свойств ПО решающее слово должно быть за потребителем, то есть за теми службами, которые в итоге будут пользоваться системой – структурами, подчиненными главному инженеру, главному механику, главному энергетику. Отстранение или вытеснение этих специалистов на периферию губит идею автоматизации ТОиР в корне. Другая крайность, когда к выбору привлекают главного инженера, а он собирает «низы» и задает им такой вопрос: «Ну что, нужна вам такая система?». Естественно, рядовые сотрудники ответят ему отрицательно. Им ведь придется приложить усилия для ее изучения и использования. Главный инженер или главный механик должны понимать, что система нужна лично ЕМУ и еще ряду руководителей для решения задач управления. Поэтому он должен не спрашивать, а принимать решение: система нужна, и она будет внедряться. Точка.
Грамотный руководитель понимает, что возможен определенный саботаж и сопротивление такому решению со стороны подчиненных. Для его преодоления необходимо терпеливо и настойчиво разъяснять исполнителям позитивные следствия внедрения:
1) автоматизация предприятия, как это ни странно на первый взгляд, ведется не для того, чтобы работать МЕНЬШЕ, а для того, чтобы работать ЭФФЕКТИВНЕЕ,
2) сотрудник, который станет работать эффективнее, почувствует соответствующую оценку своего труда,
3) сотруднику придется в определенные моменты тратить свое время на работу с системой, но зато в другие моменты он сэкономит время за счет автоматического формирования документов и отчетов, оперативного поиска информации и т. д.
На большинстве предприятий, конечно же, есть дирекция по информационным технологиям или отдел АСУП. Работники этих подразделений как никто другой на предприятии разбираются в технологических тонкостях ПО и информационных систем. Но кто лучше главного механика сможет оценить возможности ПО в таких специфических и важных моментах, как, например, классификация отказов и дефектов, их регистрация и обработка или удобство работы с электронным планом-графиком ремонтных работ? Кроме того, технические службы успешно могут курировать работу нарядно-допускной системы, вести учет данных по условиям безопасного выполнения работ, выписывать распоряжения на ремонты, когда это действительно необходимо.
Два подхода к внедрению ИСУ ТОиР
Конечно, чтобы руководить процессом выбора ПО и услуг по внедрению ИСУ ТОиР, необходимо владеть соответствующей терминологией, иметь представление о тенденциях, основных технологических направлениях в этой области. Далее представлены некоторые ключевые позиции, которые помогут руководителю ориентироваться в этой проблематике.
Тенденции автоматизации
Можно выделить два подхода к внедрению информационной системы.
Первый подход: используется один программный продукт, который позволяет автоматизировать все службы: бухгалтерию и финансы, закупки, отдел продаж, склад, отдел кадров, отдел главного механика, производственно-технологический отдел, цеха и т. д.; при этом за ту или иную службу отвечает соответствующий модуль программного продукта.
Универсальный и всеобъемлющий продукт не может одинаково хорошо поддерживать все перечисленное, но это с лихвой компенсируется следующими выгодами:
* продукт – от одного разработчика, в его основе лежат единые стандарты организации данных, поэтому для информационных связей между модулями нет необходимости в специальных программах-конвертерах. Потенциально проблемные «стыки» в ПО отсутствуют;
* при работе в системе снижаются трудозатраты отдела АСУП по поддержке сотрудников предприятия, так как все они пользуются одним и тем же программным продуктом;
* систему проще развивать, потому что компания взаимодействует с одним разработчиком, обновление версий происходит в едином технологическом процессе.
Второй подход: используется несколько программных продуктов, лучших в своем классе (возможно, от разных разработчиков). Каждый продукт автоматизирует свою сферу деятельности, а вместе они объединяются информационными связями в единую систему.
Например, один продукт может использоваться для управления персоналом, другой – для управления складом, третий – для управления сбытом, четвертый – для управления ТОиР и т. д. При объединении этих продуктов в единую систему организуются взаимные информационные потоки. Например, из системы управления персоналом в систему управления ТОиР передается штатное расписание, из системы управления складом в систему ТОиР – наименования (номенклатура) товаров (запчастей), а в обратном направлении – заявки на запчасти, информация о списании ТМЦ на выполненные работы и т. д.
Аналитики и практики признают, что реализация первого подхода далеко не всегда возможна. Опыт показывает, что на крупном промышленном предприятии даже самый мощный программный продукт охватывает не более 70% потребностей. Словом, от интеграции нескольких ПП не уйти, придется сочетать системы и программы, а не пытаться вписаться в монолитный программный продукт. Эту тенденцию подтверждают некоторые поставщики ПО и руководители ИТ-служб промышленных предприятий. Так, директор департамента информационных технологий ОАО «СИБУР – Русские шины» Марина Аншина считает, что «невозможно представить более-менее развитую компанию, которая удовлетворялась бы одним программным продуктом, пусть это даже самая современная ERP‑система. Она не решит всех задач, хотя бы уровня автоматизации технологических процессов. Приходится «сшивать» лоскутки систем интеграционными «нитками». Только в таком случае компания сможет получить существенную выгоду от автоматизации».
Тем не менее оба подхода продолжают существовать. По-видимому, речь идет о применимости того или иного подхода к конкретному предприятию, к определенной отрасли. Сфера ТОиР весьма значима и в то же время очень сложна на фондоемких предприятиях. Речь идет о металлургии, энергетике, химии, транспорте, добывающей отрасли. Здесь нельзя автоматизировать ремонтную деятельность «по остаточному принципу» и пожертвовать ею ради указанных выше выгод. По нашему мнению, в этих отраслях первый поход будет контрпродуктивен, по крайней мере в отношении поддержки и автоматизации ТОиР. Попытаемся пояснить это с общих позиций.
Программные продукты и поставщики
Указанным двум подходам соответствует предложение следующих программных продуктов, автоматизирующих управление ТОиР:
1) ERP – Enterprise Resource Planning, планирование ресурсов предприятия,
2) EAM – Enterprise Asset Management, управление основными фондами предприятия.
Многие системы класса ERP имеют в своем составе модуль ТОиР, однако, как правило, эти модули появились у них относительно недавно. Можно ли с помощью этих модулей управлять процессами ТОиР? Необходимо иметь в виду, что когда ERP-система используется для управления ТОиР, она используется не по своему назначению. Концептуально данные системы разрабатывались для автоматизации стандартных повторяющихся процессов производства типа «продажи-закупки-склад» с задачей улучшить выполнение каких-то работ, и с этими задачами они справляются весьма успешно. Для ТОиР же характерно не только стремление «улучшить», но и в не меньшей степени «исключить», «изменить» или «добавить» выполнение тех или иных работ. Само содержание деятельности в сфере ТОиР изменяется из месяца в месяц, из квартала в квартал, из года в год, как изменяются параметры и состав оборудования, его возраст и наработка, характер и параметры отказов и дефектов. На предприятии возникают нестандартные проблемы выбора стратегии ТОиР и метода планирования работ для различных групп оборудования, комплексирования и увязывания в одном плане-графике нескольких таких методов.
ERP-системы «выросли» из программных продуктов финансового учета. Соответственно модуль ТОиР также несет на себе отпечаток продукта для «белых воротничков», его возможности отличаются от видения потребностей, которого придерживается ремонтно-эксплуатационная служба. Естественно, что в разных системах недостатки выражены в большей или меньшей степени. Например, анализ стоимостных показателей эксплуатации в модуле ТОиР может быть ограничен только разрезом счетов Главной книги и невозможен в разрезе единиц оборудования или их местоположений. В то время как ремонтной службе необходимо иметь определенную степень свободы для учета по факту, модуль ТОиР может не обладать достаточной гибкостью. Модуль ТОиР, как правило, подчинен потребностям бухгалтерского учета, осуществляет непрерывные транзакции данных в бухгалтерию, что создает значительные трудности в случае, если понадобится «откатить» назад. Возможности ERP-системы по созданию справочников и каталогов оборудования могут устраивать бухгалтера, но могут совершенно не устраивать механика, которому требуется иное представление и иная детализация. В модулях ТОиР некоторых ERP-систем отсутствуют такие необходимые функции, как обработка дефектов, учет и классификация отказов, мониторинг технического состояния оборудования, автоматический учет наработки. В целом для модулей ТОиР в ERP-системах характерен доминирующий акцент на финансы, сбор стоимостных данных об оборудовании и ТОиР для их консолидации в управленческой отчетности.
Необходимо оценивать и наличие соответствующего опыта у поставщиков ERP-систем. При внедрении ИСУ ТОиР важна способность работать с контингентом ремонтных служб предприятий, обучать его, разрабатывать для него документацию. Как подчеркивает Александр Васильев, первый заместитель главного инженера Смоленской АЭС, «в системе ТОиР должны работать сотни сотрудников, которые больше привыкли «кувалдами забивать гвозди», чем стучать по клавишам ПК. Многие сотрудники, которые должны работать в системе, никогда не работали за компьютером. Поэтому при автоматизации ТОиР вопросы полноценного обучения персонала приоритетны. То же самое касается и инструкций для всех категорий пользователей: они должны быть достаточно подробны и наглядны. При автоматизации бухгалтерии таких проблем не может быть в принципе. Для автоматизации ТОиР требуется создание протяженной сети и оснащение рабочих мест, расположенных в производственных зонах. Это иногда трудно реализуемо технически из-за недостатков существующих сетей электропитания и связи. Особенно это касается удаленных объектов. При автоматизации «кабинетных» бизнес-процессов таких проблем, как правило, не возникает».
В связи с последней проблемой отметим, что, в частности, в EAM-системе TRIM, разрабатываемой, например нашей компанией, она решена за счет возможности работы с распределенной базой данных, когда пользователи удаленных объектов работают со своими локальными базами, а те, в свою очередь, синхронизируются с центральной базой данных в офисе. При этом пакеты синхронизации передают только ту информацию, которая изменилась, и даже телефонных каналов связи для таких пакетов оказывается достаточно.
Системы ЕАМ и CMMS: базовые отличия и применение
Развитие ПО класса EAM берет начало из так называемых систем CMMS (Computerized Maintenance Management System), ориентированных на поддержание технической готовности оборудования посредством планово-предупредительных ремонтов. Потребности в повышении эффективности производственных фондов и персонала, оптимизации затрат на ТОиР, оптимизации длительности жизненного цикла оборудования по критериям рентабельности и прибыльности привели к совершенствованию CMMS-систем и разработке продуктов класса EAM.
Как некоторое подмножество EAM-систем выделяют так называемые системы класса MRO (Maintenance, Repair and Overhaul) – в том случае, если в качестве объектов ТОиР выступают транспортные средства и другая сложная техника (например, военная).
Таким образом, CMMS- и EAM-системы имеют базовое отличие, заключающееся в направленности на решение задач различного уровня. Это отличие не означает, что CMMS-системы во всех случаях хуже. В каких-то случаях их возможностей будет достаточно на все времена, а в каких-то они могут использоваться как временные решения. Например, временное использование простого CMMS-продукта позволит предприятию «пощупать» технологию управления ТОиР, подобраться к ней как бы издалека, получить представление, о чем идет речь, и на этой основе понять свои потребности в сфере автоматизации ТОиР, подойти к полномасштабному проекту с продуманными требованиями к системе и с подготовленной группой специалистов. Александр Васильев, осуществляющий руководство проектом внедрения TRIM на Смоленской АЭС, отмечает, что, действительно, в начале проекта на предприятии «как правило, нет полной ясности, какие процессы ТОиР действительно надо автоматизировать, какова их логика. Например, сейчас очевидно, что при принятии решения об автоматизации ТОиР на нашем предприятии мы совершили ошибку, исключив автоматизацию процессов МТС на 1-м этапе. А может, и наоборот, если бы замахнулись сразу на все, то могло ничего не получиться. Но АСУ МТС, как составную часть системы ТОиР, мы обязательно запустим в этом году».
Экономический кризис также актуализирует потребности в простых и временных CMMS-решениях, которые в будущем могут быть заменены на EAM-системы. Это позволит заняться самыми насущными проблемами уже сегодня, не откладывая их на окончание проекта внедрения EAM-системы. Длительность же «временного» использования системы зависит от того, когда система выполнит ту задачу, для которой она приобреталась. Формально длительность жизненного цикла может быть определена через амортизацию, когда затраты на систему полностью перейдут в себестоимость продукции.
Другие основания сделать выбор в пользу CMMS (по крайней мере, временно):
* перед предприятием стоят тактические задачи – наладить учет оборудования, автоматизировать рутинные операции по планированию работ, формированию заявок на запчасти и т. д., навести порядок в отчетности и учете затрат;
* предприятие организационно не готово к внедрению EAM-системы – происходит реорганизация, кадровые изменения в руководстве, выделение ремонтных подразделений. В таком случае внедрение CMMS-системы будет готовить хороший задел для будущего EAM-проекта в части сбора и систематизации данных. Например, можно провести паспортизацию оборудования, собирать статистику отказов и дефектов;
* решается задача автоматизации не всего предприятия, а отдельного подразделения, цеха. Здесь возможностей CMMS-системы, как правило, достаточно. Она может использоваться для учета эксплуатационных состояний оборудования в цеху (отказ, резерв, работа), автоматического подсчета наработки, итоговой оценки за период длительности работоспособного состояния оборудования и определения на этой основе качества и стоимости услуг сервисной организации и т. д.
Итак, на наш взгляд, при использовании модуля ТОиР для создания ИСУ ТОиР имеется риск получить систему, которой будут довольны все сотрудники, кроме тех, кто занят в ремонтах. Пользователи из ремонтной службы будут избегать работы с модулем ТОиР, данные будут вводиться в него эпизодически, что в итоге сделает такую систему бесполезной. Андрей Исаев, директор производственного филиала ООО «Окуловская бумажная фабрика», отмечает: «Мы изначально выбрали вариант двух отдельных программных систем – бухгалтерской и управления ТОиР. В настоящее время база системы ТОиР постоянно наращивается в соответствии с меняющимся составом оборудования и работает параллельно с системой бухучета, при этом необходимыми данными системы обмениваются посредством конвертера». Добавим, что речь идет соответственно о CMMS-системе TRIM-PMS и программном продукте 1С. Отметим также, что недавно в составе 1С: УПП появился модуль (конфигурация) 1С: ТОиР.
По словам Александра Васильева, «какую систему внедрять, зависит от того функционала, который может предоставить система по требованию предприятия. Если модуль ТОиР в ERP-системе полностью удовлетворяет требованиям предприятия, то почему бы не использовать его, если речь идет об автоматизации предприятия в целом? Хотя мне не известны такие ERP-системы, которые имеют ТОиР-функционал, сравнимый с ЕАМ-системами, и которые могли бы быть использованы для автоматизации ТОиР на предприятии, подобном нашему. При выборе системы для автоматизации ТОиР мы руководствовались следующими основными критериями: функциональность, стоимость, российский разработчик (имеем негативный опыт внедрения зарубежной системы)».
При решении вопроса об использовании модуля ERP-системы для автоматизации управления ТОиР руководителю необходимо учитывать следующее.
1) Это целесообразно, если требуется автоматизировать только базовые операции: учет основных средств, учет финансовых показателей ТОиР, получение основных отчетных форм по затратам и планам затрат на ТОиР, планирование планово-предупредительных ремонтов по календарю и учет выполнения работ.
2) Модули ТОиР в ERP-системах медленно развиваются, их новые версии выходят редко, раз в несколько лет. Поэтому внедрение модуля ТОиР, как правило, означает, что он будет поставляться на условиях «как есть», удовлетворяя часть текущих потребностей. Будущие потребности предприятия в сфере управления ТОиР также могут остаться не охваченными.
3) Модуль ТОиР в ERP-системе является вспомогательным, зависимым. Поэтому внедрение ERP-системы начинается, как правило, не с него, а с ключевых модулей, необходимых для его работы. Например, в таком порядке: главная книга, дебиторы, кредиторы, денежные средства, управление закупками, управление складами, управление основными средствами, управление ТОиР. Подождать очереди модуля ТОиР можно, если процессы ТОиР на предприятии не являются основными.
Участники процесса разработки и внедрения информационной системы ТОиР как внутри предприятия, так и вне его, имеют собственные представления о том, какой должна быть эта система. Также они имеют собственные приоритеты в этом вопросе, подчас противоречивые. Решение коллизий, на наш взгляд, должно основываться на положениях ГОСТа Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем», в частности приложения D. Цитируем: «Системы, рассматриваемые в настоящем стандарте, … созданы и используются с целью предоставления функциональных возможностей в заданных условиях для удовлетворения ПОТРЕБНОСТЕЙ пользователей и иных ЗАИНТЕРЕСОВАННЫХ лиц». Это возможно только путем интеграции программных продуктов и информационных систем, обеспечивающих соответствующие потребности компании.
Автор: Владимир Иорш, Игорь Антоненко
