Портал №1 по управлению цифровыми
и информационными технологиями

Граница между изменением и проектом

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

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

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

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

Давайте посмотрим теперь на процедуры проведения изменений, которыми пользуются с другой стороны стены. Зачем они нужны? Но ведь они нужны ровно за тем же самым. Мы, при проведении изменений в ИТ-инфраструктуре, так управляем риском, используя формализованные процедуры регистрации, авторизации и оценки. 

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

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

Таким образом, нам удается и разрушить стену между "Это наш проект и мы будем выполнять его так как считаем правильным!" и "Это наше оборудование, где согласованное RFC?", и обеспечить, то что в ходе изменений любого масштаба услуги остаются под контролем.

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM