Управление изменениями несет ответственность за управление процессами, связанными с Изменениями:.

■ в аппаратном обеспечении;.

■ в коммуникационном оборудовании и ПО;.

■ в системном программном обеспечении;.

■ в прикладном ПО, находящемся в эксплуатации;.

■ во всей документации и процедурах, связанных с работой, сопровождением и поддержкой систем, находящихся в эксплуатации.

Это значит, что за изменения в любом компоненте, находящемся под контролем проекта разработки какого-либо приложения (например, прикладного программного обеспечения, документации или процедуры), Управление изменениями не отвечает Эти изменения будут предметом процедур проектного Управления изменениями. Тем не менее, ожидается, что группа Управления изменениями будет тесно сотрудничать с менеджерами проекта управления разработкой приложения, чтобы обеспечить плавное внедрение и связность в изменяющихся средах.

В рамках процесса Управления изменениями предоставляется подтверждение (или отклонение) любого предложенного Изменения. Несмотря на то, что на Управлении изменениями лежит ответственность за выполнение процесса, уполномоченный за принятие решения - Консультативный комитет по изменениям (САВ или Change Advisory Board), который состоит по большей части из представителей различных подразделений организации. Следует заметить, что Управление конфигурациями отвечает за обеспечение доступности информации о возможных последствиях предлагаемого Изменения, а также за обнаружение и соответствующее представление этих возможных воздействий.

Могут возникать случаи, когда предлагаемое Изменение в инфраструктуре будет потенциально оказывать более масштабное воздействие на другие части организации (например, на проекты разработки приложений или бизнесподразделения), и наоборот. В любом случае, для устранения возможного отрицательного воздействия обязательным условием является наличие подходящего интерфейса между инфраструктурой и другими системами Управления изменениями (см. Рисунок 8.1).

Входные данные для процесса Управления изменениями:.

■ RFC;.

■ CMDB;.

■ Согласованный график изменений (FSC, или Forward Schedule of Changes).

Действия процесса включают следующее:.

■ фильтрация Изменений;.

■ управление Изменениями и процессом проведения Изменений;.

■ руководство Комитетом САВ и САВ/Комитетом по срочным изменениям (см. параграф 8.3.2):.

■ анализ и закрытие RFC;.

■ управленческая отчетность.

Выходные данные для процесса:.

■ FSC;.

■ RFC;.

■ протоколы собраний САВ и его действия;.

■ отчеты Управления изменениями.

Управление изменениями не отвечает за идентификацию компонентов, затронутых Изменением, или за обновление записей об Изменениях (это зона ответственности Управления конфигурациями). Также этот процесс не несет ответственности за Релизы новых или измененных компонентов (это зона ответственности Управления релизами). Связи между процессами Управления мощностями, Управления изменениями, Управления конфигурациями и Управления релизами показаны на Рисунке 8.2.

Рисунок 8.2 - Связи между процессами Управления мощностями, Управления изменениями, Управления конфигурациями и Управления релизами.

Ниже приведен пример разграничения процессов, взятый из «Свода практических рекомендаций для организации управления ИТ-услугами» (Code of Practice for IT Service Management) PD0005 - Британского института стандартов:.

Управление изменениями состоит из:.

■ оформления и записи Изменений;.

■ оценки влияния, затрат, преимуществ и рисков Изменений;.

■ подготовки обоснования затрат с точки зрения бизнеса и их утверждения;.

■ управления и координации внедрения Изменения;.

■ мониторинга и отчетности по внедрению;.

■ закрытия и анализа запросов на Изменение.

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

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

8.2.1 Почему Изменения важны.

«Изменение» обладает множеством теоретических определений, но наиболее подходящее из них является также и самым простым:.

Изменение - это процесс перехода из одного определенного состояния в другое.

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

■ оценку влияния изменений в бизнесе на ИТ;.

■ анализ воздействия Изменения в ИТ на бизнес;.

■ идентификацию Проблем, которые возникают постоянно и которые требуют больших Изменений;.

■ представление новых идей и технических новинок, которые влекут за собой еще большие Изменения.

Управление Изменениями стало работой, обеспечивающей занятость на полный рабочий день.

Если Изменениями управлять, чтобы оптимизировать риски, степень воздействия и простои, а также сделать так, чтобы изменения проходили успешно с первой попытки, то конечный результат для бизнеса - быстрое получение преимуществ (или уменьшение рисков) при сохранении денег и времени.

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

В этой главе приводятся рекомендации по управлению Изменениями, которые масштабируемы для:.

■ больших и малых Изменений;.

■ Изменений с крупным или малым влиянием;.

■ Изменений в течение требуемого периода;.

■ затрат;.

■ различных типов и размеров организаций.

8.2.2 Границы между разрешением инцидентов и Управлением изменениями.

Глава 5 этой книги рассказывает о жизненном цикле Инцидента и, совместно с главой 6 («Управление проблемами»), определяет рамки включения Управления изменениями в эти процессы. Тем не менее, полезно рассмотреть границы между разрешением Инцидентов и Изменениями. Инцидент не является Изменением, и Проблема не всегда может привести к Изменению. Изменение в терминах управления инфраструктурой является результатом устранения Проблемы, когда существует «состояние, отличное от ранее определенного». Оно может указывать на свое существование различными путями: как видимыми, так и невидимыми невооруженному взгляду.

Пример: ломается ПК, в связи с чем он изъят и заменен на новый. Управление инфраструктурой требует, чтобы после обращения по поводу Инцидента, регистрации этого Инцидента, его разрешения и устранения учетные записи.

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

Важно знать разницу между запросом на Изменение (Change request) и запросом на обслуживание (service request). Многие организации ошибочно считают запросы на обслуживание запросами на Изменение, например, просьба изменить пароль или расширить часы обслуживания. Это приводит к захламлению процесса Управления изменениями. Приведенные примеры являются Изменениями, но такими, которые можно отфильтровать и управлять ими более продуктивно, чем использую все процессы, описанные в этой книге.

Одной областью, которой еще до недавнего времени пренебрегало даже управление инфраструктурой, был откат, или стратегия возврата в предыдущее состояние. В первоначальных рекомендациях обязательно упоминался вопрос отката после «проблемных» Изменений, но теперь это понятие становится все более и более важным. Необходимо не только помнить о плане отката, но и хорошо его продумать перед внедрением. Очень часто про откат думают в последнюю очередь. Можно оценивать риски, писать и утверждать планы уменьшения воздействия, но зачастую игнорировать порядок возврата в первоначальное состояние или же рассматривать его только тогда, когда он останется единственной оставшейся возможностью. Процесс Управления изменениями должен обеспечить, чтобы во всех планах по проведению Изменений содержались планы отката на случай возникновения серьезных непредвиденных проблем.

8.2.3 Разработка приложений и Управление изменениями.

Если вы просто сообщите разработчикам приложений и системным аналитикам, что теперь все Изменения находятся под контролем единого процесса Управления изменениями, вы вряд ли получите горячую поддержку. Существует много достаточных оснований для использования такого единого процесса Управления изменениями. Однако, существующая динамика Изменений в системном проектировании и в программах делает почти невозможным установление контроля над Изменениями в ПО до того момента, когда системно протестированные версии отдельных программ или групп программ находятся в стадии приемочного теста, проводимого Заказчиком.

С точки зрения разработки программ, Управление изменениями должно быть в курсе того, что происходит, но ежедневный контроль версий и подобные задачи лучше оставить группе разработчиков приложений, при этом сделав упор на хорошую и своевременную коммуникацию. Финансирование Управления изменениями и Управления конфигурациями в разработке прикладного ПО может идти из бюджетов программ/проектов (что действительно считается передовым опытом во многих организациях). Релизы продуктов в операционную среду лучше всего финансировать таким же образом, чтобы расширить рамки процессов, не раздувая бюджет, отведенный на Управление услугами. Более подробная информация об этом содержится в главе 9. «Управление релизами».

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

■ строчка программного кода, которая (регулярно) меняется;.

■ модуль программного обеспечения;.

■ общие модули;.

■ завершенные программы;.

■ связанные программы;.

■ группы программ.

Однозначные жесткие рекомендации в этом случае неуместны. Вы должны принять решение самостоятельно на основе знания движущих сил вашего бизнеса, систем и ресурсов. Организация нуждается в принятии разумных решений с учетом таких факторов, как движущие силы бизнеса, риски, рабочая сила, средства, способности, организационные навыки и баланс затрат и преимуществ на микроуровне Управления изменениями и Управления конфигурациями. Если принято решение о централизованном контроле всех Изменений, потребуются значительные инвестиции в соответствующие программные средства и обучение. Более подробная информация содержится в Разделе 8.8.

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

8.2.4 Изменения в бизнесе и Управление изменениями.

Процесс Управления изменениями управляет Изменениями, ежедневно происходящими в бизнесе. Он не является заменой методам, используемым для управления и контроля проектов в рамках всей организации, например, PRINCE2.

Из следующих разделов этой главы вы узнаете о Консультативном комитете по изменениям (САВ) и его периодической роли в оценке необходимости Изменений, а также о временных рамках и важности Изменений. При необходимости, САВ должен быть вовлечен в группы управления программами и проектами, чтобы убедиться в том, что вопросы, связанные с Изменениями, а также цели и влияние Изменений и их разработка последовательно проходят по всей организации. Одним из способов помощи, оказываемой Управлением Изменениями тем, кто планирует Изменения, является построение моделей Изменений и поддержание связи с планировщиками мощностей, для оценки воздействия этих моделей.