Отношения процесса управления Изменениями с другими процессами

a. Управление Конфигурациями

Управление Конфигурациями отвечает за регистрацию доступных версий программного и аппаратного обеспечения в базе данных CMDB в качестве Базисных Конфигураций (от которых осуществляется развитие и к которым осуществляется откат).

b. Управление Изменениями

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

c. Управление Уровнем Услуг

.Управление Релизами отвечает за ввод в работу программных и аппаратных средств и отслеживает соглашения о доступности программных средств, заключенные в рамках Процесса Управления Уровнем Услуг.

3.3. Виды деятельности в рамках Процесса Управления Процесс Релизами

Управления Релизами состоит из следующих видов деятельности:

■ разработка политики в отношении релизов и их планирование;

■ компоновка и конфигурирование релизов;

■ тестирование и приемка релизов;

■ планирование развертывания релизов;

■ оповещение, подготовка и обучение;

■ распространение и инсталляция релизов.

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

 

 

На рис. показаны виды деятельности в рамках Процесса Управления Релизами и их связи с жизненным циклом изменения.

a. Выработка политики в отношении релизов и планирование

 

При планировании релиза рассматриваются следующие вопросы:

■ координация содержания релиза;

■ разработка графика ввода релиза;

■ согласование графика, территориальных объектов, на которых произойдет распространение релиза, и организационных единиц;

■ посещение объектов для определения реально используемых аппаратных и программных средств;

■ разработка плана оповещения (коммуникаций);

■ согласование ролей и ответственностей;

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

■ разработка планов на случай возврата к исходному состоянию;

■ разработка плана обеспечения качества релиза;

■ планирование приемки релиза руководством и пользователями.

Результаты этой деятельности представляют собой часть плана проведения изменения и включают планы релиза, планы тестирования и критерии приемки.

b. Проектирование, компоновка и конфигурирование

Рекомендуется выработать стандартные процедуры проектирования, компоновки и конфигурирования релизов. Основой релизов могут быть наборы компонентов (Конфигурационных Единиц — CI), разработанные внутри организации или закупленные у третьей стороны и прошедшие этап конфигурирования. Руководства по инсталляции и конфигурированию релизов должны рассматриваться как часть релиза и в качестве Конфигурационных Единиц должны включаться в число объектов, находящихся под контролем Процессов Управления Изменениями и Управления Конфигурациями.

План возврата к исходному состоянию

В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза.

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

Реальная компоновка релиза может включать:

Ø компилирование и связывание программных модулей, или

Ø наполнение баз данных тестовыми данными, или

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

■ Часто это выполняется автоматизированными инсталляционными скриптами, хранящимися в Библиотеке DSL вместе с планами возврата..

c. Тестирование и приемка релиза

 

Часто тестирование разделяют на:

 

= технические испытания разработчиками,

= функциональные испытания пользователями,

=испытания внедрения компоновщиками релизов и, возможно,

=окончательные приемочные испытания пользователями и руководством

 

Наиболее частой причиной неудовлетворительного внедрения изменений и релизов является неадекватность тестирования.

Результатами деятельности по тестированию и приемке релиза являются:

■ протестированные процедуры инсталляции;

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

■ известные ошибки и недостатки релиза;

■ результаты тестирования;

■ документация для управления и поддержки;

■ перечень систем, подвергающихся воздействию;

■ операционные (эксплуатационные) инструкции и средства диагностики;

■ планы на случай непредвиденных ситуаций и протестированные планы возврата;

■ программы обучения персонала, руководителей и пользователей;

■ подписанные приемо-сдаточные документы.

d. Планирование внедрения

Составленный на предыдущих этапах план теперь дополняется информацией о действиях по внедрению.

Планирование развертывания релиза включает:

■ составление графика, а также перечня задач и требуемых людских ресурсов;

■ составление перечня инсталлируемых и снимаемых с использования Конфигурационных Единиц, с указанием способа вывода из операционной среды;

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

■ рассылку уведомлений о релизе и другие контакты с вовлеченными сторонами;

■ составление планов закупки аппаратного и программного обеспечения;

■ закупку, размещение на хранение, определение и регистрацию всех новых CI для данного релиза в бае CMDB;

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

Существует несколько способов осуществления развертывания:

■ полное равертывание релиза - подход «большого скачка»;

■ поэтапное равертывание релиза, включающее несколько разновидностей:

- функциональное наращивание, когда все пользователи получают одновременно новые элементы функциональности;

- наращивание по объектам, когда развертывание ведется от одной группы пользователей к другой

- эволюционное развертывание с поэтапным расширением функциональности.

e. Оповещение, подготовка и обучение

Персонал, находящийся в контакте с заказчиками (Служба Service Desk и Управление Взаимоотношениями с Закачиками — CRM), операционный (обслуживающий) персонал и представители пользователей должны быть в курсе планов внедрения и его возможных последствий для повседневной деятельности. Для этого можно организовать совместное обучение, сотрудничество и совместное участие в приемке релиза. Необходимо согласовать распределение ответственностей, с соответствующим уведомлением каждого.

f. Распространение релизов и инсталляция

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

После инсталляции необходимо обновить информацию в базе данных CMDB для облегчения про верки лицензионных соглашений

4. 4. Показатели эффективности и проблемы процесса управления изменениями

 

Возможно возникновение следующих проблем:

■ Сопротивление изменениям - вначале возможно сопротивление персонала, привыкшего к старым привычным методам работы. Например, некоторым сотрудникам бывает трудно принять тот факт, что для проведения определенной деятельности они будут получать инструкции из другого подразделения. Для устранения таких ситуаций необходимо информировать этих сотрудников о преимуществах подхода ITIL.

■ Обход Процесса Управления Релизами - использование неавторизованных программ может привести к распространению вирусов, отрицательно повлиять на услуги и затруднить поддержку. Поэтому в отношении персонала и пользователей, пытающихся использовать неавторизованные программы, особенно в среде PC, должны быть предприняты решительные действия.

■ Срочные исправления - не следует действовать в обход Процесса Управления Релизами даже при необходимости срочных изменений.