Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Руководство 18 страница




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

Констатация возникших проблем и продолжение дальнейшей работы

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

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

Резюме

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

· Контроль и оценка продуктивности изменения после его внедрения на производстве, в соответствии с целями первоначального RFC и целями групп ролей модели коллективной работы MOF.

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

· Принятие решений по поводу реализации с неудачных изменений, касающихся их отмены, принятия дополнительных изменений, позволяющих исправить ситуацию, или осуществления подхода с “констатацией проблем и продолжением дальнейшей работы”.

· Закрытие успешно реализованных RFC и информирование инициатора.


Роли и обязанности

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

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

В процессе управления изменениями определены следующие три важные роли.

· Инициатор изменения.

· Менеджер изменений.

· Владелец изменения.

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

· Консультативный совет по изменениям (Change Advisory Board — CAB).

· Кризисный комитет CAB (CAB Emergency Committee — CAB/EC).

· Исполнительный комитет по информационным технологиям (IT Executive Committee — ITEC).

Инициатор изменения

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




Поделиться с друзьями:


Дата добавления: 2015-01-03; Просмотров: 236; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.015 сек.