Спросил свою 3070ti «Как думаешь, что важнее – процесс или результат?», а он мне отвечает, чтобы я сам выбирал. И зачем эти нейросети, если они даже не могут выбрать, что для меня важнее и лучше…

Даже при отсутствии в демке контекста – всячески рекомендую попробовать, установка в один клик, подложить свои данные в один клик и три минуты на обновление модели, указать в резюме, что я теперь разработчик генеративных нейросетей – тоже много времени не заняло (¬‿¬)

Конечно, в Группе MOEX они – разработчики – занимают крайне важное место. Без их экспертизы было бы невозможно построить ландшафт, который позволяет нам оказывать полный цикл торговых и пост-трейдинговых услуг. При этом производственный процесс входящих в Группу компаний сильно отличается друг от друга и с завидной регулярностью выдает новые средства автоматизации, модифицирует и выводит из эксплуатации уже используемые. Это вызвано ростом потребностей бизнес- и поддерживающих подразделений, появлением регуляторных требований, повышением требований к импортозамещению и защите ЗОКИИ вслед за изменениями геополитики.

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

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

• Исторически ввиду разных требований на разных средствах автоматизации сложилось 3 разных реализации процесса – на Бирже, в Центральном депозитарии, в Клиринговом центре. Все они юридически представляют собой отдельные организации в составе Группы MOEX и для них актуальна унификация процесса.

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

• Были отдельные примеры, когда двигались проектные сроки и задерживалось внедрение новых решений, из-за непрозрачности отдельных процедур и недостаточной поддержки участников процесса.

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

• Требования к системам, составу документации и согласований, которые должны быть предоставлены для успешного ввода в эксплуатацию, нередко не выполнялись.

• ИТ-функции в отдельных случаях узнавали о внедрении и передаче на поддержку новых систем в момент передачи\развертывания промышленной инфраструктуры.

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

• новые ИТ‑системы корректно учтены в реестрах учета CMDB и EAM, включая все необходимые для эксплуатации параметры;    

• документация по ИТ-системам, необходимая для эксплуатации, предоставлена и согласована самостоятельными структурными ИТ- и ИБ-подразделениями компании;

• внедрены и реализуются контрольные процедуры, направленные на предотвращение эксплуатации новых ИТ-систем без выполнения процессных требований.

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

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

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

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

  Для этого: настроим интеграцию перечня систем между системами EAM и CMDB

• Нужен автоматизированный запрет в ITSM на выдачу новых мощностей и изменение существующих мощностей для случаев, когда в соответствующем запросе не указана система, выбранная из CMDB ITSM.

  Для этого: настроим ограничения на формах регистрации соответствующих запросов на портале ITSM

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

  Для этого: настроим сверки между платформами виртуализации и данными по серверам и СХД в CMDB, подсветим расхождения в BI

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

  Для этого: настроим ограничения на формах регистрации соответствующих запросов в таск-трекере

• Нужен автоматизированный контроль над появлением новых НМА по собственным разработкам и лицензиям в бухгалтерском учете для случаев, когда новые НМА не относятся к ИТ-системам, зарегистрированным ранее в EAM и CMDB.

  Для этого: доработаем интеграцию между системами бухгалтерского учета и ITSM, чтобы появилась возможность сверки реестров и работы над отклонениями

• Нужен автоматизированный запрет в ITSM на регистрацию запросов на изменения в случаях, когда статус ИТ-системы в CMDB отличается от статуса «В разработке», «В опытно-промышленной эксплуатации», «В промышленной эксплуатации». Для этого: настроим ограничения на формах регистрации соответствующих запросов на портале ITSM, ограничения в таск-трекере для отдельных видов ЗНИ, которые создаются по интеграции

• Нужен автоматизированный запрет в ITSM на регистрацию обращений в случаях, когда статус ИТ-системы в CMDB отличается от статуса «В разработке» (в нем разрешаем регистрировать ЗНО), «В опытно-промышленной эксплуатации» (в нем разрешаем регистрировать ЗНО и инциденты), «В промышленной эксплуатации» (в нем разрешаем регистрировать ЗНО и инциденты).

  Для этого: настроим ограничения на формах регистрации обращений в ITSM, ограничения в таск-трекере для обращений, которые создаются по интеграции

• Нужен запрет на регистрацию новых ролей\привилегий для любой ИТ-системы в случаях, когда статус ИТ-системы в CMDB отличается от статуса «В опытно-промышленной эксплуатации», «В промышленной эксплуатации».

  Для этого: вырабатываем с ИБ-подразделениями соответствующие автоматизированные и организационные ограничения.

Помимо этого, по процессу в целом есть большие планы по развитию – он все еще недостаточно автоматизированный, недостаточно оцифрованный, недостаточно понятный:

1. Распространим процесс управления вводом систем в эксплуатацию на все этапы ЖЦ систем и технологий совместно с функциями Архитектуры и Инноваций, чтобы развивать не только на ввод в пром и вывод из прома, но и объединить разрозненные требования к системам на всех этапах.

2. Создадим автоматизированный сквозной процесс ввода систем в эксплуатацию и вывода из нее на базе BPMS + ITSM + EAM.

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

4. Внедрим автоматизированные контрольные процедуры и инструменты дашбординга для ИТ-руководителей, направленные на предотвращение обхода процесса на всех этапах ЖЦ систем и технологий

И начнем с разработки дорожной карты на двухлетнюю перспективу. С таким горизонтом планирования понятно, что самое главное – сохранить свою способность обеспечивать перемены. Она, в свою очередь, обусловлена:

• Навыками решения проблем взаимодействия

• Ориентацией на бизнес-результат

• Готовностью брать ответственность за решения

• Высокой внутренней мотивацией

• Ну и немного импровизацией :)

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

Станислав Дружинин,

Департамент сопровождения торговых и вспомогательных систем

Хакимзянов Тимур,

Управление развития ИТ-процессов Центра компетенций ITG