2014 год, 9-я конференция
Рассмотрен опыт работ по внедрению и тиражированию на все станции федеральной гидрогенерирующей компании системы Maximo.
У нас в компании внедрена система Maximo, это продукт компании IBM. Хочу сразу сказать, мы к Maximo относимся просто как к одному из элементов системы УФАП — это система управления фондами и активами. УФАП — это больше, чем просто Maximo, и сегодня я расскажу только непосредственно про Maximo, она у нас в общей системе комплексных информационных систем «РусГидро».
В каких-то направлениях деятельности компании что-то автоматизировано, что-то нет. Это параметры проекта Maximo, этапы, на которые мы условно разделяем весь проект. Первый этап был в 2004—2007 годах, когда Maximo внедрялась на станции Волжско-Камского каскада (тогда еще КВГЭК) Начиная с 2007 года пошел второй этап — тиражирование на все остальные станции федеральной гидрогенерирующей компании. Третий этап внедрения УФАП, вернее, непосредственно Maximo — это мы переходили со старой версии Maximo 5.2 на версию 7. Сразу скажу, изменения были: в целом по процессу, наверное, нет, но филиалы ощутили этот переход. Не скажу, что он был болезненным, он был менее болезненным, чем внедрение самой системы, потому что станциям некоторым по 70 лет, а система новая, и привыкать к чему-то новому очень сложно. Но за два года мы управились.
Любая система базируется на каких-то справочниках. В частности, в данном случае справочник выглядит как модуль оборудования, то есть где у нас расписано всё. Во-первых, заложен классификатор. Расписаны активы. Расписаны местоположения, где они расположены. И здесь справа в колонке я представил процент использования данного функционала (рис. 3).
Сразу скажу, что это моя экспертная оценка. В данном случае мы используем эти модули на 70%, потому что так получается, мы особое внимание уделяем основному оборудованию, вокруг которого, условно говоря, крутится наш бизнес. Мы очень много лет занимаемся оценкой состояния именно основного оборудования, вот поэтому я написал 70%, потому что у нас в системе, конечно, заведено вспомогательное оборудование, но оно просто не паспортизировано. Я всегда это открыто говорю. Основное оборудование мы знаем, всю его историю, вплоть до паспортов. По вспомогательному оборудованию паспорта, конечно же, есть, но системно эта работа не проводилась. Так получилось, в первую очередь, потому что станций много, станции разные, соответственно, не дошли еще руки до того, чтобы «причесать», так сказать, привести к единому виду паспорта вспомогательного оборудования.
Следующий модуль, который у нас используется, — это модуль «Планы», посредством его мы планируем производственные программы ремонтов и технического обслуживания в Maximo, именно в Maximo у нас ведутся программы ремонта и технического обслуживания. Функционал в части ремонтов в Maximo задействован на 100%. В Maximo возможно спланировать программу ремонтов по услугам, материалам. Сразу скажу, у нас ресурсы не планируются, т.к. у нас 95% ремонтной программы — это подрядный способ, то есть мы людьми не управляем.
При этом в системе у нас формируется рабочее задание, в системе мы можем посредством интеграции с «ГрандСметой» получить стоимость ремонтных работ и на основании загруженных смет, как по плану, так и по сметам подрядчиков, формировать акт выполненных работ, причем утвержденный по форме КС-2. Этот функционал у нас полностью готов, и мы им пользуемся.
Однако не все филиалы этим функционалом пользуются. Здесь больше организационный момент, когда все зависит от главного инженера конкретного филиала. Когда ему это нужно, как на Саяно-Шушенской ГЭС, Новосибирской ГЭС, то главный инженер ставит подрядчику условие: «Я не подписываю акты, выгруженные не из Maximo!» Ему подрядчик другие акты и не приносит. На других филиалах главный инженер таких условий не ставит, ему приносят акт выполненных работ, сформированный в той же «ГрандСмете», он его подписал — и дело с концом, сдали в бухгалтерию.
В планировании производственных программ у нас есть модуль «ТО и Ремонт», это, по сути, так называемый модуль ППР. Модуль «Рабочие задания» влияет, соответственно, на функционал исполнения. Есть электронный журнал дефектов, четкое планирование, интеграция с «ГрандСметой». Что касается журнала дефектов, тут мы были, не побоюсь этого слова, первыми: мы первая энергокомпания в России, которая перешла на электронный журнал дефектов, причем перешла официально. В 2011 году мы подписали соответствующий протокол с Ростехнадзором. У нас в компании нет бумажного журнала дефектов. Если вы услышите, что на какой-то станции «РусГидро» (именно «РусГидро», не холдинга) ведется журнал дефектов, это значит, что на этой станции занимаются саботажем. То есть у нас официально отменен бумажный журнал дефектов, и Ростехнадзор, приезжая на станцию, требует выгрузку из системы. В части «ГрандСметы» налажена интеграция уже лет шесть: планы по услугам и материалам, которые мы планируем, рабочие задания мы выгружаем в «ГрандСмету», там все осмечено, загружаем обратно, и у нас получается работа с ее ценами.
Вернусь к электронному журналу дефектов. Мы понимаем, что нам необходимо перерабатывать классификатор дефектов. Электронный журнал дефектов выполняет тупую функцию — это фиксировать дефект и его устранение. Какую-то аналитику очень сложно построить по существующему классификатору дефектов. Поэтому мы сейчас ресурсами нашего аналитического центра, который создан в компании, пытаемся немножко переструктурировать, создать даже заново классификатор дефектов, чтобы можно было проводить аналитику по дефектам, которые возникают на оборудовании.
Последние два модуля — «Система оповещения» и Модуль сводного планирования.
Система оповещения используется:
Оперативники фиксируют возникающие на станции чрезвычайные ситуации, все классифицируется персоналом, и делается рассылка на электронную почту руководству компании. Все оповещения привязываются конкретно к единице оборудования, то есть в истории по каждой единице оборудования мы видим в том числе и оповещения.
Модуль сводного планирования.
Разработка существующего Модуля сводного планирования была произведена по заказу компании в 2009 году. Это было обусловлено отсутствием на рынке промышленных систем, позволяющих решить поставленные задачи, в частности, обеспечить версионирование данных. В настоящее время на рынке представлены промышленные решения, на базе которых возможно реализовать функционал Модуля сводного планирования.
Дело в том, что в IBM Maximo хранится самая последняя версия, а модуль сводного планирования нам позволяет делать версии различные (т.е. была такая, стала такая, потом изменилась, а потом проводить аналитику между версиями). К сожалению, в Maximo версионность не поддерживается.
Появляется все больше и больше требований к данному модулю, и его платформа большего не позволяет, мы хотим перейти на промышленную платформу и там и закрыть все наши потребности.
И теперь непосредственно по самой системе. Подобным образом у нас расписаны все справочники, начиная с филиала (у нас есть филиалы как дистанционные, так и не дистанционные). В подобном графике мы расписали структуру активов, структуру местоположений, что-то определили в комплексах. Например, систему пожаротушения, она может быть разбросана, оборудования может быть много. В процессе планирования и исполнения производственной программы ремонтов Maximo на первом этапе специалисты формируют объем работ, проставляют сроки. В Maximo 7 появился модуль Scheduler, имеющий много преимуществ. В чем его удобство: не нужно ничего никуда перегружать. Подтягивается вся программа, все рабочие задания, открывается диаграмма Ганта, и можно подвигать вправо-влево соответствующие рабочие задания, выставить нужные сроки, сохранить все, сроки автоматом меняются в рабочем задании. Т.е. нет необходимости в рабочие задания заходить и менять там сроки, они меняются автоматом.
В этом модуле можно строить различные сценарии программы. Т.е. можно не применять данные графиков ремонта, которые получаются, а можно его сохранить в виде сценария. Создать другой, посмотреть, какой больше нравится, и в нужный момент применить тот, на котором остановился. И все сроки на рабочем задании поменяются в соответствии с этим сценарием.
Специалисты наши технические планируют, формируют объем и график работ. Дальше специалисты-сметчики у нас эти работы при помощи «ГрандСметы» осмечивают. Все это уходит в виде программ уже в блок, которые занимается бюджетированием. Все это запланировали в финансовоэкономическом плане. Дальше заключается договор. И на этапе исполнения программы в Maximo загружаются сметы по договору, т.е. сметы подрядчика. На основании смет подрядчика у нас происходит формирование и закрытие актов выполненных работ.
Также на этапе исполнения идет интеграция с «ГрандСметой»: просто механически идет пересохранение актов выполненных работ из Maximo и обратно, т.е. там никакие расчеты не производятся, это делается для того, чтобы все эти коэффициенты как надо подвязались. Вот такой процесс.
Наше ближайшее развитие, то, что я вижу в виде обозримого будущего.
Управления МТР в части аварийного запаса. У нас есть стандарты. В соответствии с этими стандартами мы и ведём всю свою деятельность. Аварийный запас рассчитывается в разработанных расчетных модулях, в зависимости от состояния оборудования у
нас планируется необходимое количество аварийных запасов, которые должны быть на складе. И в системе мы реализовали механизм загрузки потребностей, сравнение с тем, что есть на складе, получение актуального перечня потребностей.
Управление МТР в части аварийного запаса:
• методология закреплена корпоративным стандартом;
Следующим этапом будет механизм обслуживания аварийного запаса: есть запчасти, которые лежат на складе, их нужно обслуживать. Этот запас всё время должен меняться, потому что он не должен пролежать всю жизнь на складе.
Модуль мониторинга. Его задачи — упростить работу с данными, снизить риски, связанные с несвоевременным или некорректным потоком данных. Как уже говорилось, в компании создан аналитический центр, который занимается оценкой состояния основного оборудования. И для оценки состояния основного оборудования аналитическому центру всегда требуется информация об активах.
Информацию об активах можно получить тремя способами: 1) АСУ ТП, 2) во время капитальных ремонтов проводить какие-то испытания и замеры, 3) проводить ежедневные, периодические обходы, осмотры.
Модуль мониторинга мы готовы были запустить в эксплуатацию, но решили посмотреть, как изменится жизнь наших работников. Получилось следующее: оперативник берет журнал или бумажку и пошел по маршруту. Прошел, записал, сел и начинает заносить всё это в систему. То есть, по сути, делает двойную работу: сначала бумажка, потом система. Поэтому мы решили, что запустим модуль мониторинга одновременно с внедрением мобильного решения. Тогда у нас оперативный персонал будет ходить в обходы не с бумажкой, а с планшетом, и будет на месте регистрировать те значения параметров, которые необходимо снять.
Данное мобильное решение будет использоваться службой мониторинга, которая будет проводить испытания при капитальных ремонтах. Они прямо в систему будут заносить соответствующие результаты измерений. Логика расчетов достаточно простая и закладывается в систему, чтобы, придя на свое рабочее место, сотрудник распечатал соответствующие протоколы, соответствующие акты, подписал и положил в соответствующую документацию. Таким образом мы исключаем ошибки при переносе данных и двойной ввод.
В результате внедрения мы повысили качество планирования программ ремонта на будущий период за счет использования типовых ведомостей, что позволяет прогнозировать бюджет.
У нас единый справочник услуг, материалов и запасных частей. Каждый может видеть, что лежит на соседнем складе, в соседнем филиале. По большому счету здесь речь идет о создании аварийных запасов. Возможность формирования тренда затрат по каждой единице оборудования в принципе делается, когда оборудование станций более-менее соответствует друг другу, как на Волжской и Жигулевской ГЭС. К примеру, был выявлен перекос в части ремонтного бюджета между Жигулевской и Волжской ГЭС, то есть там приблизительно одинаковый возраст станций, станции работают одинаково, однако затраты на ремонт одного агрегата у них отличались в два раза. Когда стали выяснять, оказалось, одни делали слишком много работ, другие слишком мало. В итоге сбалансировали, и сейчас стоимость ремонта за один агрегат на Волжской и Жигулевской ГЭС приблизительно одинакова. По остальным станциям такое сравнение можно сделать в рамках одной станции, а между двумя станциями нельзя. Единые требования к организации сбора данных о состоянии производственных активов. Это то, что сейчас предлагается в модуле мониторинга. Для того чтобы, условно говоря, провести оценку состояния различных генераторов на различных станциях, нужно предъявить единые требования филиалам, чтобы они эту информацию дали. Наша компания старается унифицировать все подходы для того, чтобы можно было в рамках унифицированной линии принимать экономические решения.
Журнал Prostoev.NET № 3(12) 2017
Автор: Рамазан Абакаров, департамент планирования и ремонтов технических сооружений и реконструкций ОАО «РусГидро»
This website uses cookies.