Развитие и трансформация ИТ-контура: опыт «РусГидро ОЦО»

В «РусГидро ОЦО» развитие ИТ-контура быстро вышло за рамки технических доработок. Центру нужно было управлять разными учетными системами, согласовывать доработки с несколькими участниками и постепенно переводить разрозненные решения в единый управляемый контур. Ярослав Никулин, начальник отдела по координации и внедрению проектов «РусГидро ОЦО», рассказал Клубу ОЦО, как центр прошел путь от разрозненных учетных систем к более управляемой модели автоматизации, пилотирования и работы с данными.

Быстрый старт ОЦО сформировал ИТ-наследие

РусГидро ОЦО создавался с практической задачей — централизовать и оптимизировать сервисные функции. Чтобы не тормозить запуск, компании подключали к ОЦО без глубокой перестройки: сохраняли исторических сотрудников, процессы и информационные системы.

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

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

Поэтому в ОЦО пришли к выводу: автоматизацию нельзя развивать только через отдельные инициативы подразделений. Нужен единый механизм принятия решений (см. рис. 1).

Дополнительным стимулом для пересмотра подхода стали изменения в ИТ-ландшафте. 1С прекратила поддержку УПП, с которой у ОЦО было связано много внутренних решений, включая интеграции с электронным документооборотом. Параллельно начался переход с SAP на «1С УХ», а импортозамещение усилило необходимость переносить значимые решения на отечественные платформы.

В этих условиях ОЦО начал выстраивать единый контур согласований между бизнес-методологами и ИТ-аналитиками. Его задача — оценивать новые доработки сквозным образом: действительно ли доработка нужна, насколько эффективна, можно ли ее тиражировать, какие риски она создает, какие системы затрагивает и какие компании должны быть охвачены.

Необходимость адаптации процессов в ходе импортозамещения

Один из самых показательных проектов «РусГидро ОЦО» — переход от SAP к 1С Управление Холдингом. Снаружи это выглядело как замена одной учетной системы другой. Однако на практике переход оказался сложнее: SAP и 1С .

ОЦО не мог просто перенести прежний процесс в новую систему. При переходе были выявлены около 300 функциональных разрывов между SAP и 1С, которые пришлось закрывать через новые функциональные требования, доработки и адаптацию процессов. Дополнительную сложность создает отраслевая специфика энергетики, включая процессы, связанные с оптовым рынком электроэнергии и мощности. 

Практический пример. Для материнской компании переход на «1С УХ» требовал не только замены системы, но и воссоздания привычной для пользователей логики работы. При этом даже успешно реализованное решение нельзя автоматически передать другим предприятиям группы. Для компаний со схожим профилем на Дальнем Востоке тиражирование может занимать 6–8 месяцев (на одну компанию). 

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

Отдельный урок — работа с подрядчиками. В проекте выяснилось, что учетную систему и электронный документооборот могут развивать разные команды. Из-за этого даже по отдельным операциям возникают споры, кто формирует акты сверки, кто передает данные, кто отвечает за результат.

Поэтому зоны ответственности лучше закреплять до старта проекта. Иначе команда тратит время не на развитие решения, а на согласование того, где заканчивается ответственность одного подрядчика и начинается ответственность другого.

ОЦО должен первым проверять новые ИТ-решения на практике 

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

При этом ИТ-оператор отвечал за стабильность сервисов и не всегда мог быстро поддерживать изменения. ОЦО же нужно было двигаться быстрее: централизованные процессы росли, усложнялись и требовали постоянной оптимизации (см. рис. 2).

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

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

Поэтому новые ИТ-решения сначала проверяют в ОЦО: кадровый электронный документооборот, внутренние системы, корпоративный портал. Для ИТ это возможность увидеть, как решение работает в сложном и массовом контуре. Для ОЦО — способ заранее повлиять на инструменты, с которыми затем будет работать вся группа.

Роботы помогают, но не заменяют учетную систему

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

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

Практический пример. В условиях инвентаризации за короткий срок нужно было подготовить тысячи документов, но изменение одного поля в ITSM/ESM могло привести к падению робота. В такой ситуации автоматизация, которая должна была ускорять процесс, сама становилась источником риска.

Поэтому ОЦО перенес самые важные автоматизации в учетные системы. При внедрении «1С УХ» центр сразу закладывает решения, которые частично заменяют прежних роботов и снижают зависимость от внешней автоматизации. 

Это не значит, что от роботов нужно отказаться. Они по-прежнему полезны для временных, точечных и вспомогательных задач. Но для критичных процессов надежнее встраивать автоматизацию в учетную систему — туда, где создаются и обрабатываются данные.

Разрозненные данные мешают управлять сервисом

Следующая проблема также возникла из-за ИТ-наследия. Разные учетные системы и процессы создавали множество источников данных, поэтому быстро получить общую картину по ОЦО было сложно.

Сотрудникам приходилось собирать информацию из SAP, 1С, Диадока и других систем, сопоставлять выгрузки в разных форматах и вручную переносить данные. Даже внутри 1С форматы могли отличаться. Из-за этого, например, отчет о качестве оказания услуг превращался в долгую сборку данных по каждой компании.

Практический пример. Чтобы подготовить аналитику по процессам ОЦО, сначала нужно было найти нужный источник, выгрузить данные, привести их к единому виду и перенести между системами. Прежде чем получить результат, нужно понять, откуда тянется нужная информационная нить.

Такая модель мешает управлять сервисом на основе оперативных данных. ОЦО может качественно выполнять процессы, но для анализа нагрузки, качества, SLA и динамики ему нужна единая база данных. 

Озеро, шина и хранилище данных как следующий уровень зрелости

Ответом стала единая архитектура данных. В РусГидро формируется озеро данных группы: туда в едином формате попадают данные ОЦО, включая проводки, которые проводят бухгалтеры и другие сотрудники центра. Так информацию можно быстрее получать в нужном виде и использовать для аналитики. (см. рис. 3)

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

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

Рисунок 3. Целевая архитектура данных ОЦО 

Практический пример. Когда ОЦО нужно сравнить результаты текущего и прошлого года, часто приходится обращаться к архивным источникам. Из-за большого количества проводок часть данных уходит в архив, и оперативная аналитика усложняется. Хранилище данных должно решить эту проблему: документ сохраняется один раз, а другие системы работают с единой версией через ссылку.

Что из опыта «РусГидро ОЦО» полезно другим центрам

Опыт «РусГидро ОЦО» показывает: быстрый запуск сервисной модели может в будущем привести к необходимости доработки ИТ-контура. Подключение компаний без глубокой перестройки помогает быстрее перевести их на обслуживание, но затем центру приходится проводить ИТ-трансформацию.

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

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

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

Четвертый подход — развитие архитектуры данных. Без озера, шины и хранилища данных крупный ОЦО неизбежно сталкивается с ручной аналитикой, разными версиями документов и сложностями в оценке качества сервиса.

Зрелость ИТ-контура ОЦО определяется не отсутствием сложностей, а способностью с ними работать: видеть ограничения, превращать локальные проблемы в понятные правила и постепенно собирать разрозненные автоматизации в устойчивую архитектуру.