На семинаре itSMF 19.01.2011 обсуждали тему координаторов изменений. Идея заключается в том, чтобы отделить функцию общего контроля исполнения и организации работ по проведению изменений от функции организации обработки отдельных запросов на изменения. Первое – ответственность менеджера изменений (менеджера процесса управления изменениями), второе – небольшого количества людей, обычно называемых координаторами изменений. "Обычно" потому, что роль координатора изменений, не будучи упомянутой в ITIL, используется в большинстве распространенных вендорских процессных моделей, в частности в модели BMC, HP и IBM (только в IBM Tivoli Unified Process эта роль называется "Владелец изменений", это не очень здорово очередным неоднозначным использованием слова "Owner", но в данном случае это к делу не относится). В реальности пожалуй ни одно внедрение управления изменениями в крупной компании не обходится без координаторов изменений, которые назначаются, как правило, по функциональному или географическому признакам (или по обоим сразу).

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

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

Но "полноценное" управление изменениями требует от менеджера определенных усилий – так или иначе, он участвует в реализации каждого изменения, не являющегося стандартным (в согласовании, в контроле сроков, в PIR'е, в решении спорных вопросов, связанных с переносом сроков, с изменением приоритетов, с форсированием ускоренного развертывания в обход политики релизов и так далее). И поэтому есть второй вариант:

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации