ПРОЕКТЫ
Техническое обслуживание и ремонт основных фондов (ТОРО) начинается с их учета. На электрогенерирующем предприятии задача эта сама по себе несложная - сложен процесс внедрения ее автоматизированного решения. Наибольшая трудность заключается в том, что самые известные системы автоматизированного учета основных фондов (IBM Maxima, SAP PM, Oracle EAM и др.) строятся на паспортном описании единиц оборудования и объектов, подлежащих учету при планировании потребления ресурсов. Паспорт представляет собой иерархический список деталей и узлов объектов. Но в российском электроэнергетическом сегменте, как утверждает Сергей Дятлов, директор по ИТ "Пятой генерирующей компании оптового рынка электроэнергии" (ОГК-5, www.ogk-5.com), каждое сложное изделие - уникально. К таковым относятся, например, блоки тепловых генерирующих станций (ГРЭС).
Сергей Дятлов:
"Управление техническими
рисками сегодня стало
приоритетным"
С позиций ТОРО такой объект, как ГРЭС, представляет собой некоторое количество, как правило, однотипных по функциям (именно по функциям) групп блоков. Так, на Конаковской ГРЭС, где начинался описываемый ниже проект разработки и внедрения системы автоматизации ТОРО (далее система "ТОиР"), таких блоков восемь. Каждый из них уникален по спецификации конструкции, и единым паспортом их никак не описать - у каждого свои набор и типы оборудования, иногда и своя технологическая схема.
Когда начиналось создание ТОиР, составлением технических паспортов оборудования на электростанции могли заниматься максимум пять технологов, которым по уровню квалификации и загруженности другой работой можно было поручить выполнение такого задания. Как показывали внутренние расчеты, для описания восьми блоков им понадобилось бы примерно 8,5 лет.
Главный риск проекта автоматизации ТОРО, по мнению Сергея Дятлова, заключается в возможности ошибиться на этапе первичной классификации информации, описания объектов и ввода справочников в систему. Это трудоемкая работа с малой возможностью тиражирования ввиду уникальности описываемых объектов, которую должны выполнять совместно технолог и аналитик.
В будущей автоматизированной системе ТОРО нужно было учитывать разные категории ремонтов - текущие, средние и капитальные. Ремонты каждой категории производятся с различными интервалами, а капитальные ремонты иногда приводят к изменению функциональной схемы устройств: в процессе ремонта в блоках могут произойти такие изменения, которые потребуют существенной коррекции паспорта блоков и устройств. Описание состава оборудования энергообъекта (электростанции в целом) обязательно должно укладываться в межремонтный интервал, равный одному году. Поскольку срок актуальности описания объектов планирования (в нашем случае тепловых электростанций) имеет четкие границы, то для своевременного изменения паспорта оборудования нужен соответствующий по численности и квалификации штат технологов.
Энергетика имеет явно выраженную сезонную цикличность работы, а потому внедрение любой ИС, включая ТОиР, возможно только с учетом данной особенности. По этой причине ремонтные работы привязывают к летнему периоду, когда нагрузка на объекты минимальна.
В течение I квартала текущего года выполняется централизованное календарное планирование ремонтной кампании единой энергосистемы страны на следующий год. Нужно составить общий сбалансированный по генерируемой мощности график для всей энергосистемы, учитывающий выведенные в ремонт и остающиеся в работе блоки. Нельзя, например, в одном регионе одновременно перевести в ремонт столько мощностей электростанций, что генерируемая ими электроэнергия окажется меньше потребляемой.
С января по июнь технологи энергопредприятий заняты планированием ремонтных работ, и реально привлечь их к созданию системы можно только с середины лета до января. Именно в этот период сотрудники энергопредприятия имеют возможность заняться внедрением автоматизированных систем.
Портрет заказчика и потребность автоматизации ТОРО
Осенью 2004 г. Конаковская ГРЭС была введена в состав ОГК-5, образованной решением совета директоров РАО "ЕЭС России". ОГК-5 объединила четыре тепловые электростанции федерального уровня: Конаковскую, Невинномысскую, Рефтинскую и Среднеуральскую.
Проблема автоматизации ТОРО остро обозначилась еще до образования ОГК-5 - в 2000 г., после того как РАО ЕЭС ввело отраслевые стандарты на нормативы планирования ремонтов, так называемый "Справочник структурных показателей для формирования свободных цен на энергоремонт в условиях перехода к рыночной экономике".
Задача энергопредприятия - обосновать свои ремонтные издержки, а Федеральная служба по тарифам РФ (ФСТ) должна проверить и утвердить их обоснованность. Для того чтобы обе стороны - предприятия и их контролер - говорили на одном языке, и был введен упомянутый справочник, представляющий собой стандарт на предоставление информации, на формы документации, на бизнес-процесс тарификации. Разработан документ ЦКБ "Энергоремонт", получившим разрешение от государства на проведение экспертизы предоставляемой станциями документации.
Никакой готовой информационной системы для поддержки введенного стандарта на Конаковской ГРЭС не было. По оценкам ИТ-специалистов теплостанции, в 2000 г. выбор решений в области автоматизации ТОРО, доступных в Москве и имеющих организационную поддержку пользователей, был сильно ограничен, даже с учетом российских разработок, к тому же отечественные программы решали задачи ведения оперативного учета состояния оборудования, но модуль планирования ремонтных работ в них отсутствовал. Поэтому решено было попробовать справиться с задачей автоматизации ТОРО своими силами.
То, как начиналась разработка и внедрение ТОиР, можно приводить в качестве примера "как не должно быть". Прежде всего, это была инициатива снизу, а не сверху, как рекомендовано в анналах внедрения ИС. Позднее из-за этого возникли серьезные проблемы.
Сергей Дятлов как раз незадолго до этого, в конце 1999 г., пришел на Конаковскую ГРЭС на должность инженера АСУ с новосибирского завода "Электросигнал", где он работал начальником ИТ-отдела. Состояние ИТ-ресурсов на станции соответствовало, по его оценкам, уровню 10-15-летней давности по сравнению с ситуацией на знакомых ему предприятиях приборостроения (например, только лет пять назад удалось наладить электронную почту). Морально тоже было непросто. Руководство не видело потребности в развитии автоматизации, отношение к АСУ было "по остаточному принципу". Занять руки и голову было особо нечем.
В такой обстановке стихийно сформировалась неформальная команда молодых, энергичных, с опытом работы специалистов, среди них оказались и технологи, которых жизнь различными путями привела в энергетику. Начали обсуждать концепцию будущей системы, подходы, алгоритмы. Сергей Дятлов написал первые варианты программы. Самым доступным для разработки в тех условиях оказался инструмент "1С:Предприятие" "(версия 7.7 которого была приобретена на Митинском рынке на личные деньги - о финансировании работ предприятием речь не велась: на службе у инженера Дятлова в ту пору не было даже компьютера).
Вскоре появилась написанная Дятловым за несколько дней программа автоматизированного планирования работ конструкторов с возможностью подготовки отчетов. Она понравилась начальнику конструкторского отдела: месячный план с ее помощью готовился с невиданной доселе скоростью. Программу показали главному инженеру станции. После этого к группе стали присматриваться, а начальник отдела подготовки ремонтов поделился с ИТ-специалистами спущенной сверху проблемой тарификации и планирования ремонтов, с которой технологам становилось все труднее справляться из-за напряженных информационных потоков и сжатых сроков. Автоматизация этих операций была включена в план работ, правда, при этом не было объявлено никакого проекта и проектной команды как таковой тоже не было сформировано. Сергей Дятлов стал выполнять функции бизнес-аналитика, проектировал информационную модель, стараясь построить "матрицу решения". Ее первый вариант был собран примерно через год, в 2001-м. И тут технологи, для которых в первую очередь и создавалась программа, выдали отрицательное заключение.
Новая информационная модель ТОРО
Начались циклы конструктивного обсуждения и доработок, каждый из которых занимал один-два месяца. Сначала просто пытались создать общую для айтишников и энергетиков терминологию. Именно на этом этапе была проанализирована и отвергнута паспортная основа системы и родилась идея многомерности с использованием функциональной схемы в качестве стержня.
"В построении своей модели, - рассказал Сергей Дятлов, - мы исходили из того, что функциональная схема реализуемого в электрических машинах физического процесса одинакова, в отличие от перечней задействованного в них оборудования. Мы описали функциональную схему объекта, получили совокупность функциональных измерений (в частности, объект ремонта и объект работ) и надфункциональных (например, номер блока). Теперь описать такой объект, как "поверхность нагрева корпуса котла", можно, задав пересечение измерений: энергоблок - котел - корпус А - поверхность нагрева, номер блока 3. Причем этого количества значений измерений будет достаточно для описания любой поверхности нагрева, любого котла, любого блока. При классическом же способе описания потребуется создать столько "деревьев" в паспорте, сколько существует реальных поверхностей нагрева во всех корпусах всех котлов всех блоков. На примере видно, что всего три "измерения" с небольшим списком значений в каждом точно описывают и идентифицируют объект, хотя и без инвентарного номера. Реально мы ввели и дополнительные измерения, такие как вид ремонта, подрядчик и др., чтобы получить полную аналитическую картину затрат. В итоге внедренная версия модели имела 13 измерений. Самым длинным (до 300 элементов) получился список объектов проведения работ для схем тепловых блоков: функциональная схема состоит из элементов - "объектов проведения работ", мы ввели такой термин, являющийся одним из измерений в нашей многомерной модели".
Ротор среднего давления турбины К-300-240
Авторы называют свой подход "многомерной моделью". С его помощью им удалось в несколько раз сократить "линейные списки" каждого "измерения" объекта: вместо 65 тыс. элементов в традиционном паспорте в списке каждого "измерения" трехмерной модели объекта не более 300 элементов. "Мы не утверждаем, - отметил Сергей Дятлов, - что паспорт не нужен. Для решения определенных задач он необходим и эффективен. ТОРО подразумевает выполнение трех блоков задач: планирование ремонтов, их исполнение и оперативное управление (оперативный учет состояния объектов). При оперативном управлении без паспорта не обойтись, поскольку работы производятся с технологической моделью объекта (коей и является паспорт), в то время как первые две задачи могут решаться с использованием функциональной модели объекта".
Благодаря новому подходу три специалиста Конаковской ГРЭС затратили на описание всей станции менее двух месяцев. Собранная программа, в которой использовался новый подход построения справочников, тестирование у технологов прошла удачно. Случилось это в самом конце 2002 г.
Хронология разработки и внедрения
Классификаторы по новой модели были составлены примерно за месяц. Программу уже с возможностью подготовки документации показали руководству технологов. Не вникая в детали, руководитель отдела ремонтов доложил о системе главному инженеру... В результате был издан приказ об обязательном использовании программы, собранной как макет, в производственных цехах.
Программу установили в девяти цехах примерно на 15 рабочих местах и начали эксплуатировать. В семи цехах из девяти новинку встретили "на ура", а в двух заняли позицию глухого неприятия, мотивируя это тем, что вариант обслуживания ремонтов с использованием программы более сложен и быстрее все сделать вручную в таблицах Excel, как уже привыкли.
Работая по старинке, технологи просто вбивали данные в электронные таблицы, а новая программа заставляла их замыкать логические связи между фрагментами вводимой информации. В тех двух цехах, где не было порядка в планировании и отсутствовала четкая организация рабочего процесса, поняли, что программа обнажает этот беспорядок. Оппозиционерам даже удалось на некоторое время запретить использование системы. Однако твердая и активная позиция большей части цехового персонала, занятого в планировании ремонтных работ, вынудила руководство отменить чисто политическое решение, продиктованное сиюминутной личной выгодой отдельных руководителей и наиболее консервативных исполнителей. Программу отстояли, и отстояли снизу: продукт оказался настолько ожидаем, что при его внедрении удалось добиться положительного результата без следования верному уже классическому постулату: возглавлять подобные проекты должно руководство предприятия уровня не ниже заместителя директора.
В феврале 2003 г. вышел приказ о вводе системы в промышленную эксплуатацию. И в этот раз руководство опять не советовалось с ИТ-службой. А готовности у ИТ-отдела к этому этапу не было. Пришлось на ходу дорабатывать функционал, писать документацию...
Несмотря на сложнейший режим работы "с колес", когда создаваемый продукт находится в эксплуатации, в августе 2003-го проектной группе удалось завершить функционал первой версии, включающий автоматизацию всех основных процессов планирования ремонтной кампании. С помощью системы стало возможным получать полноценные сводные данные о потребностях в материалах и запасных частях с графиками поставки, о затратах во всех необходимых разрезах аналитики.
Первая оценка работоспособности системы в условиях промышленной эксплуатации была дана в ЦКБ "Энергоремонт" на этапе проверки подготовленной с ее помощью документации для ремонтных тарифов. По мнению сотрудников ЦКБ, впервые за много лет они увидели документацию, в которой данные стыкуются между собою, в то время как до этой поры для них были привычны расхождения одних и тех же показателей, взятых из разных документов.
В 2004-м на предприятие пришла команда молодых управленцев, радикально изменивших положение дел в лучшую сторону, в том числе и в автоматизации электростанции. Была сформирована ИТ-служба, которую возглавил Сергей Дятлов. До этого ИТ-специалисты были приписаны к разным отделам: в бухгалтерии трудилась своя команда, в отделе кадров - своя и т. д., всего насчитывалось пять групп ИТ-инженеров. Уровень подготовки у них был самый разный - они использовали как Фортран, так и объектное программирование. Поэтому для начала провели обучение работе с продуктами "1С", сформировав в итоге структуру, способную сопровождать предложенную систему и развивать ее.
Проекту по разработке и развертыванию системы автоматизации ТОРО был придан необходимый формальный статус.
Создание первого промышленного варианта системы завершилось после внесения некоторых исправлений и включения в систему финансового модуля для формирования ремонтных смет. Если ранее составление одной сметы занимало две-три недели, то система позволяла сделать это практически мгновенно, поскольку все необходимые для этого данные готовились на предыдущих этапах ее эксплуатации и оставались доступны всем заинтересованным участникам ТОРО. Через два месяца после внедрения финансового модуля была существенно изменена структура сметного отдела - пример проактивного влияния ИТ на бизнес.
Систему ТОиР подключили к обслуживанию критически важных для предприятия бизнес-процессов. Это резко повысило статус и ответственность ИТ-персонала, у ИТ-подразделения появился свой бюджет, стала закупаться современная техника.
Сначала с помощью ТОиР можно было проводить только планирование ремонтных ресурсов, потом в ней появились модули фактического учета проведения ремонтов, следом была разработана поддержка план-фактного анализа, затем система научилась выгружать результаты в OLAP-средства.
Очистка бойлера турбины от солевых отложений
За счет деловой обратной связи с персоналом среднего уровня (начальники цехов, мастера, технологи) в систему оперативно вносились изменения в соответствии с происходящими переменами в структуре предприятия и бизнес-процессах, которые вводились новой командой менеджеров. Люди, эксплуатирующие систему, усвоили логику ее работы, стали задавать конкретные вопросы, предлагать варианты развития. Появились даже такие способы использования системы, которые не предполагались разработчиками изначально.
После образования ОГК-5 Сергею Дятлову была предложена в ней должность ИТ-директора. Первый год на новом посту был для него очень напряженным, и заниматься в этот период проектом ТОиР вплотную времени не было.
В начале 2005-го система обзавелась блоком логистики. В ТОиР наработана интересная методика, решающая задачу перехода на единый номенклатор предприятия. Раньше в бухгалтерии, в отделе снабжения и в системе ТОиР использовались разные номенклаторы (справочник номенклатуры, перечень всех объектов учета, реестр) объектов учета, что разрывало управленческий и бухгалтерский учет. Единый номенклатор вводился при ревизии складов, что потребовало серьезного пересмотра бухгалтерских и складских остатков и в итоге дало возможность осуществить привязку этих данных к технологическому номенклатору.
Сейчас по заказу финансовой дирекции к системе ТОиР пристраивается функциональный блок для стоимостного анализа ремонтных затрат. Это глубокий план-фактный анализ на основе управленческой аналитики. До этого использовалась только бухгалтерская аналитика, но она плоская, а хочется развернуть полную модель, заложенную в корне системы. Проблема здесь в том, что в отечественной энергетике планирование ведется не по трудозатратам, не по человеко-часам (как в других странах), а по тарифам: исходить приходится из нормативов стоимости работ, а не из реально потраченных ресурсов в человеко-часах. Наложить тот план, который составляется в нормативах отрасли, на реальный календарь работ трудно. Первое решение на бумаге есть. "С переводом предприятия на функционирование в рыночных условиях все "темные места" в планировании нужно прояснять, все приближения оптимизировать, - прокомментировал это направление развития ТОиР Сергей Дятлов. - Раньше главбух и главный экономист договаривались, куда отнести те или иные затраты, сейчас нужна формальная точность".
Одним из результатов внедрения новой системы ТОиР стало уменьшение времени цикла планирования ремонтов. Это позволяет просчитать большее, чем прежде, количество вариантов планов (несколько десятков), что резко поднимает качество планирования в части оптимизации затрат. "Ремонтный бюджет, - считает Сергей Дятлов, - устанавливается для нас государством, а не рынком. Предприятие должно доказывать государству обоснованность своих ремонтных издержек, составляющих весомую долю в себестоимости продукции, подготовив стандартизованный пакет документов. Таков первый цикл планирования ремонтов".
Тарифы на электро- и теплоэнергию пересматриваются ФСТ каждый год. Ответственность за принятие правильного плана ложится на конкретных экспертов-технологов, которые до внедрения ТОиР успевали в отведенное время составить всего один план. Нерыночный вариант провоцирует предприятия отрасли добиваться максимума допустимых по тарифам затрат. Поэтому в составлении плана велика роль экономистов, хорошо разбирающихся в том, как составить план, который, с одной стороны, не вызовет подозрения у ФСТ (контролирующей обоснованность работ), а с другой - обеспечит предприятию максимальный ремонтный бюджет. Утвердив этот бюджет, контролирующий госорган берет ответственность на себя, фактически заявляя, что если какие-то из запланированных работ не будут выполнены, то возможный ущерб государства превысит отпущенные средства.
В рамках подготовки утверждаемого государством бюджета система ТОиР сегодня позволяет просчитывать несколько вариантов ремонтных работ, и приоритет здесь у технологов, а финансисты только подтверждают их решение. Цель ремонта - обеспечить бесперебойную работу в межремонтный период. Поэтому в первую очередь ремонтируются те узлы, которые могут вызвать прерывание выработки электроэнергии.
После трех лет промышленной эксплуатации системы на Конаковской ГРЭС пришло понимание того, что можно составить небольшую программу, способную собрать все многомерные справочники в классический одномерный, а это на выходе даст тот самый автоматически сгенерированный паспорт. Многомерность позволяет описать все функциональные компоненты блоков. Поэтому заложенные в такую программу правила формирования компонентов должны помочь развернуть весь перечень объектов, но только без привязанной к конкретным физическим объектам информации (где располагается объект, какой инвентарный номер ему присвоен и т. д.). Практически получается паспортное описание объекта без малой части информации, привязанной к конкретному объекту, дополнить которую вручную большого труда не составляет даже для неквалифицированного специалиста.
Турбинный цех Конаковской ГРЭС
От ТОРО к управлению рисками
Традиционные паспорта понадобились только летом 2006-го, т. е. через три года после ввода в эксплуатацию системы ТОиР, и понадобились они не для нужд ТОРО, а для выполнения технического аудита - задачи, направленной на развитие внедренной системы. Для составления паспортов ТОиР позволила привлечь специалистов-технологов без ущерба основному планированию. После генерации шаблона менее чем за три летних месяца весь паспорт Конаковской ГРЭС был подготовлен.
Суть технического аудита заключается в фиксации событий, происходящих с конкретными физическими объектами: когда объект вышел из строя, по какой причине и т. д. Накапливание такой информации должно стать основой для нового этапа совершенствования ТОРО - внедрения системы управления техническими рисками. Чтобы ее реализовать, нужен массив данных за несколько лет. За три года такой массив накоплен.
Задача создания системы технического аудита и управления техническим рисками была поставлена перед ИТ после образования ОГК-5. В условиях рынка потребность в ней обозначилась особенно остро, поскольку отвечать за "ненесение нагрузки" придется жестче, чем при административном регулировании, - стоимость рисков, как считают в ОГК-5, вырастет на порядок. Поэтому бизнес-процесс технического аудита (как и его автоматизация) сегодня стал приоритетным. Что касается управления рисками (в первую очередь связанными с надежностью оборудования, оптимизацией расходов времени и денег), то сейчас руководство пытается осмыслить, какими из них и как нужно управлять и по каким критериям.
Управлением техническими рисками будет заниматься служба эксплуатации, а не ремонтники. Пока ее работники недостаточно подготовлены для эксплуатации ИТ-систем. При возникновении какого-либо события с оборудованием им придется запускать программу технического аудита, отыскивать в паспорте нужный объект, определять узел, в котором событие случилось, заносить причины события, выяснять, что в узле заменялось в процессе ТОРО, вводить в систему чертежи (если таковые использовались), т. е. вносить всю информацию, относящуюся к выполненной на объекте работе. Это рутина, но она позволит продолжить сбор данных для аудита, который очень нужен для повышения надежности эксплуатации.
Постскриптум
Весной 2006 г. генеральный директор ОГК-5 получил по почте рекламный проспект с презентацией нескольких систем, в том числе системы планирования ремонтов. Каково же было его удивление, когда в ней он узнал разработку своих специалистов. "Если программу начали воровать, - сказал он, - значит, настала пора ее продавать".
Предложение вынесли на правление, подготовили документы в патентное бюро, разработали бизнес-план продажи ТОиР, озвучили его на 4-й "Конференции ИТ-специалистов ДЗО РАО "ЕЭС России"".
Была пора, когда руководство, рассматривая обладание системой ТОиР как конкурентное преимущество, категорически не соглашалось на ее продажу. Но рынок продиктовал иную тактику.
По внутренним оценкам, ОГК-5 способна обеспечить внедрение трех-четырех инсталляций в год в трехлетней перспективе - это возможности ОГК-5, а не емкость рынка. Если оценивать потребность рынка, то как потенциальных покупателей можно рассматривать предприятия уровня генерирующих станций, а можно и вновь образованные энергетические компании в целом.
