Как разработать программу управления изменениями в ИТ

"Нужно учитывать, что нет более трудной для исполнения, сомнительной для успеха и наиболее близкой к провалу задачи, нежели установление нового порядка вещей."
Макиавелли (1446-1507)
 

Программа управления изменениями (ПУИ) более известна как процесс управления изменениями или же контроль над процессом по управлению изменениями – это формальный процесс, который используется для того, чтобы все изменения в работе над изделием или в системе велись скоординировано и подконтрольно (описание этому есть в стандарте ISO-20000). ПУИ – это не управление организационными изменениями, не стоит их путать. УОИ управляет результатами бизнес-процессов, включая и создаваемые благодаря ИТ-инициативам, изменениями в организационной структуре, а также в корпоративной культуре предприятия. По сути, ОУИ управляет изменениями в части персонала.

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

Никогда не стоит делать соответствующие изменения без какого либо надзора в системе. Любые идеи по изменению работы должны не только согласовываться с высшим руководством, но и оглашаться всему коллективу компании. Без обсуждения действий на высшем уровне ПУИ – это просто потеря времени и средств, но, если правильно совместить все средства, то данная программа убережет вас от многих серьезных ошибок.

Шаги

1. 1 Разработайте запрос на изменения (ЗИ). Это значит, что необходимо создать специальную форму, которая будет заполняться и предоставляться при наличии вопроса, серии вопросов и идей по данному поводу для предотвращения будущих негативных последствий. ЗИ будет полезен и в том случае, когда будут появляться новые бизнес-решения, способные влиять на основной курс компании. Также ЗИ необходим при условии внешних влияний (постановление властей, изменения ведения дел партнерами и т.д.).
2. 2 Создайте условия для изменения бизнеса. Внесение изменений в ведение дел – это бизнес-решение, для принятия которого необходимо сопоставить прибыль с затратами. Даже в ситуации изменений исключительно инфраструктуры (в силу выхода из строя ИТ-системы или ее компонентов), расходы понесет бизнес, а не ИТ-отдел. Были случаи, когда разрабатывались специальные процедуры по резерву средств на аварийное обслуживание системы – но основное решение все равно лежит на руководстве компании.
3. 3 Создайте проект поддержки изменений. Развитие изменений (и их тестирование) входит в функционал ИТ-отдела. Если случается аварийная ситуация, вроде поломки сервера, функции ИТ, как правило, прописаны, в то время как при разработке новой системы требуется совместная работа ИТ-команды и бизнес-пользователей. Систему разрабатывает ИТ, она утверждается руководством бизнеса, внедряется ИТ, тестируется представителями ИТ и пользователями и окончательный продукт утверждается и теми, и другими.Особое внимание нужно уделять влиянию нововведений на существующие системы.
4. 4 Проверяйте управление изменения специальным отделом – для этого нужно создать комитет по изменениям (КПИ). КПИ анализирует все изменения перед их внедрением в систему, в этот комитет должны входить люди с разными точками зрения и обширными знаниями. Функция такого отдела проста – проверить, что изменения в процессе работы пройдут максимально безболезненно, а на случай каких либо эксцессов проверить наличие технологий, позволяющих компенсировать недостатки новой системы. Перед тем, как ввести какие либо изменения, команда разработчиков передает свой проект в КПИ, где его тщательно проверят на возможные риски. Стратегия внедрения в систему, коммуникации с заинтересованными лицами, контроль результатов и условия восстановления возможных ошибок – все это те факторы, над которыми должен работать КПИ. К слову, комитет по изменениям не отвечает за определение уместности изменений – это решают за него. Также КПИ не должен отвечать за экономическую эффективность нововведения – это решение исключительно за руководством бизнеса.
5. 5 Внедрите изменения. Если КПИ выразил несогласие по поводу изменений и выдал ряд причин, по которым нововведение будет рискованным (это бывает довольно часто, так как не все риски можно просчитать заранее либо не все коммуникации были заранее спланированы), команде разработчиков изменений дается время на перепланирование действий и предоставление нового плана КПИ. Если комитет одобрит, то можно реализовывать проект. Конечно, не всегда нужно, чтобы КПИ следило за реализацией нововведений, но зачастую у консультантов комитета есть обширный опыт, который пригодится в процессе внедрения изменений – хотя опять же, эти люди будут скорее экспертами по конкретным вопросам (ЭКВ), а не представителями КПИ. Когда происходит изменение, то все шаги по его реализации должны быть задокументированы и подтверждены КПИ. Весь процесс должен быть тщательно задокументирован, а утвержденный процесс должен неукоснительно соблюдаться.
6. 6 Оповестите о результатах. Независимо от того, успешно ли было введено изменение, были ли некоторые проблемы по ходу реализации проекта или, хуже всего, изменения спровоцировали сбой в работе и не могут быть быстро исправлены – все должно быть передано в КПИ и документально оформлено. КПИ, в свою очередь, отвечает за передачу информации заинтересованным сторонам и сохранение документов вкупе с поддержкой результатов в системе управления изменениями (и неважно, автоматизированная ли это база данных, или же все имеется только на бумаге, так или иначе, все данные должны быть доступны для аудита).
7. 7 Контролируйте возникновение проблем вследствие изменений. Любые возникающие вопросы следует сопоставлять с документацией КПИ во избежание непредвиденных проблем и побочных эффектов. Зачастую нежелательные последствия не видны сразу и проявляются лишь в процессе пользования системой при регистрации проблемы в соответствующих системах. Так, например, добавление новых полей к базе данных может не иметь прямого негативного воздействия на систему, но могут очевидным образом повлиять на работу в сети других пользователей, не имеющих доступа к работе с модификацией системы.
8. 8 Необходимо периодически производить аудит ПУИ. По крайней мере, необходимо хотя бы раз в год проводить аудит ПУИ, чтобы гарантировать доступность и заполнение документации. Все документы должны быть предварительно рассмотрены и иметь соответствующие подписи и печати. Результаты изменений также должны быть задокументированы и оформлены.

Советы

• Специальное оборудование должно соответствовать регламенту ПУИ. Так, в помещении с оборудованием должны быть проверены системы пожаротушения, очищен черновой пол в дата-центре, должна проводится постоянная вентиляция и даже проводиться борьба с вредителями. Известны случаи, когда ЗИ поступал даже по поводу поломки лампочки в центре обработки данных (к примеру, лестница упала и повредила сеть).
• Стандартные профилактические работы должны утверждаться предварительно. Так, если время перезагрузки сервера – 2 часа ночи в воскресенье, то не стоит подавать ЗИ каждый раз, а просто утвердить регулярность этих работ.
• Все процедуры должны рассматриваться ПУИ. Если даже в резервной системе планирования есть изменения, они должны пройти через управление изменениями. Анализируйте любые изменения (в системе или процессах), чтобы определить наличие связанных с ними рисков.

Предупреждения

• Любые решения должны передаваться в КПИ. Конечно, запрос «это изменение нужно» может быть и обоснованным, но также он может быть и личной амбицией одного из руководителей. КПИ должны проверять все решения и анализировать риски внедрения того или иного изменения.
• Периодически меняйте состав КПИ. Одни и те же члены комитета могут, в конце концов, начать принимать одни и те же решения, что вызовет застой развития компании. Поэтому грамотной политикой будет периодическая ротация КПИ, что позволит вам иметь под рукой надежный аналитический инструмент.

Citations

International Standards Organization
COBIT
ITIL
Wikipedia Reference