Если ваш ИТ-департамент отправляет каждый запрос на изменение (RFC) в Совет по изменениям (CAB) для утверждения, то вы неправильно управляете изменениями.
По моему опыту, есть четыре причины того, что все или большинство RFC отправляются в CAB:
- Плохо построенный процесс управления изменениями.
- Не прозрачные бизнес-требования для внесения изменений («что мы должны получить в результате?»).
- Объем RFC не понятен.
- В ИТ есть те, кто больше озабочен выполнением предписанных действий, чем хорошей работой.
Хорошо продуманный процесс управления изменениями должен облегчить, но не перегружать контролем осуществление изменений. Эффективные процессы управления изменениями устраняют столько разногласий, сколько возможно, гарантируя ясность того, каким образом осуществляются изменения. В то же время хороший процесс управления изменениями обеспечивает правильный баланс между защитой управляемой среды от неправильных изменений и скоростью внесения изменений в эту среду.
Если управление изменениями четко определено и выполняется хорошо, то только некоторые избранные RFC (с акцентом на “некоторые”) должны быть представлены CAB.
Почему ваш CAB не работает
Почему многие организации недовольны своими процессами управления изменениями? Потому что, их позиционирование CAB, не работает. CAB представляет собой барьер или пропускной пункт, а не партнёра. Поэтому CAB во многих организациях обречён на провал.
Каковы признаки неудачного CAB?
- Не определены формальные критерии оценки RFC. Если они были определены, то недостаточно хорошо документированы или не опубликованы.
- RFC плохо написаны. Цель внесения изменений неясна, непонятно, какие ресурсы необходимы или какие зависимости существуют.
- Каждый RFC отправляется в CAB для утверждения реализации. Мало того, что это демонстрирует отсутствие понимания целей CAB, это еще и свидетельствует о плохо построенном процессе.
- RFC часто предоставляются в последнюю минуту и затем принудительно встраиваются в процесс. Это свидетельствует об отсутствии управленческой поддержки. Подобное поведение также влияет на процесс управления изменениями. Подобная практика и пренебрегает тем, как это может отразиться изменениях, которые уже запланированы и назначены для реализации.
- Слишком много “экстренных” изменений. Исключая ситуации наличия ошибок, влияющих на важные бизнес-функции, или угрозы ущерба бизнеса, если не будут приняты определенные меры, это просто вопиющее отсутствие планирования. Опять же, при отсутствии четко определенного процесса и сильной управленческой поддержки, это недопустимо.
- CAB состоит из незаинтересованных или неквалифицированных членов. Однажды я работал с организацией, которая проводит встречи CAB два раза в неделю в большом конференц-зале. В зале было несколько участников и несколько присоединились через конференц-связь. Менеджер изменений старательно читал вслух название каждого RFC в повестке дня, а затем спрашивал “есть ли возражения?” «Возражения» находились крайне редко, если вообще такое было, и запрос автоматически подтверждался. Еще большее беспокойство вызывало то, что практически все в конференц-зале занимались чем-то другим – проверяли электронную почту, переписывались, разговаривали с соседом. Можно только представить, что происходило на другом конце телеконференции. Какую ценность несёт такая встреча CAB? (Кстати, у этой организации был высокий коэффициент отказа от изменений. Поди разберись.)
Хотите знать причину, почему ваш CAB не работает? Плохое проектирование процессов и отсутствие управленческой поддержки.
Хотите это исправить?
Вот как это делается:
- Определение модели авторизации изменений
- Правильный размер ваших RFC
Введение в Модель авторизации изменений
Определяет ли ваш текущий процесс управления изменениями модели авторизации изменений? Модель авторизации определяет, кто авторизует или утверждает какой тип изменений. Уровень, на котором санкционируются изменения, «лежит там, где существует ответственность за принятие риска и восстановление.»[1]
Внесение изменений – бизнес-решение и важен поиск и включение необходимых для принятия правильных решений людей. Модель авторизации изменений – это способ гарантировать, что правильные люди примут правильные решения.
Определение полномочий на внесение изменений требует формального определения критериев оценки RFC. Такие критерии, как стоимость, потребность в ресурсах, риски, масштабы, стоимость задержки и другие факторы, должны быть идентифицированы и определены как часть критериев. Опять же, это решение не только для ИТ – это бизнес-решение, поэтому бизнес-коллеги должны быть вовлечены в определение критериев оценки.
Как только модель авторизации изменений определена, все в организации понимают не только, как будет оцениваться RFC, но и кто будет их авторизовывать. Когда RFC соответствует определенным критериям оценки указанного уровня, то определенные ответственные люди участвуют в заседании CAB и рассматривают эти RFC. Определение полномочий на авторизацию изменения в его модели также решает давний вопрос для многих менеджеров по изменению – «каких бизнес-коллег необходимо привлечь?» Правильный размер ваших RFC
Итак, как вы можете перестать посылать каждый RFC в CAB?
Легко. Прекратите посылать каждый RFC в CAB. Начните отправлять в CAB только правильные RFC, те для авторизации которых CAB действительно необходим.
Я давно считаю, что главные цели управления изменениями заключаются в том, чтобы максимально приблизить полномочия по осуществлению изменений к тем, кто выполняет эту работу, и в то же время поддерживать надлежащий уровень управления изменениями.
Ограничение объёма RFC минимально жизнеспособной единицей работы улучшает управляемость RFC – становится легче проектировать, создавать, тестировать и внедрять изменения – поскольку делать нужно меньше. Поскольку делать нужно меньше, ограничение объёма RFC также снижает риски, связанные с изменениями.
Если объём меньше и риск минимален (и вы определили модель авторизации изменений соответствующим образом), RFC будет соответствовать определенным критериям оценки для более низкого уровня полномочий на изменение – в идеале, тех, кто выполняет работу.
Остановить отправку всех RFC в CAB
Проектирование и внедрение двух улучшений, которые были сейчас предложены для вашего процесса управления изменениями, не только повышает скорость ответной реакции процесса, но и помогает позиционировать CAB .
Вот несколько других вещей, которые необходимо сделать, чтобы еще улучшить процесс управления изменениями и помочь правильно позиционировать CAB для достижения успеха:
- Определить модели изменений. Многие изменения носят рутинный характер и осуществляются часто. Определение и использование моделей изменений не только обеспечивает согласованность их выполнения, но и является первым шагом к автоматизации изменений.
- Использовать pair programming. Это фантастическая концепция DevOps, которая помогает создавать более качественный код, что приводит к успеху в реализации изменений, обеспечивая высокий уровень качества на самом базовом уровне инфраструктуры.
- Определить портфель услуг. Портфель услуг предоставляет информацию об услугах, текущих инвестициях и обязательствах в ИТ, которые могут быть использованы в качестве входных данных для изменения решений авторизации.
Упростите свой процесс управления изменениями, чтобы облегчить внедрение изменений, а не избегать их.
[1] ITIL Service Transition, p 78.
Автор Дуг Теддер (Doug Tedder), оригинал How to Stop Sending Every Flipping RFC to a CAB
