Jan van Bon (стр. 24 из 60)
- Руководителя по Управлению Изменениями (председатель);
- Руководитель по Управлению (Уровнями) Услуг;
- Представителей Службы Service Desk и Процесса Управления Проблемами;
- Руководителей линейных подразделений компании;
- Бизнес-руководителей (или их представители) со стороны заказчика;
- Представителей пользователей;
- Представителей разработчиков приложений;
- Администраторов программного обеспечения и системных администраторов;
- Представителей поставщиков.
Охват (сфера действия или границы) [104]процесса
Сфера действия Процесса Управления Изменениями определяется вместе со сферой действия Процесса Управления Конфигурациями, так как Управление Конфигурациями предоставляет информацию для оценки воздействия изменения на инфраструктуру. После проведения изменения Управление Конфигурациями обновляет Конфигурационную Базу Данных (CMDB). Если в базе данных CMDB ведется учет компьютерных мышей и клавиатур, то замена клавиатуры рассматривается как изменение. Определение сферы действия процесса является динамической деятельностью, так как сфера действия может меняться, и потребность в информации из базы данных CMDB также меняется. Следовательно, сфера действия должна регулярно пересматриваться, и модель данных CMDB должна обновляться соответственно.
Для того, чтобы обеспечить эффективное взаимодействие Процессов Управления Изменениями и Управления Конфигурациями, необходимо регистрировать изменения и обновлять соответствующие записи в CMDB. Можно допустить, что ряд повседневных заданий, точно определенных и подчиняющихся установленным процедурам (т. е. стандартных заданий), не требуют контроля со стороны Процесса Управления Изменениями. Примерами таких заданий могут быть установка кассет для резервного копирования, создание идентификаторов (ID) пользователей и т. д. Эти действия не обрабатываются как изменения, а самое большее классифицируются как Запросы на Обслуживание в рамках Процесса Управления Инцидентами. Внимательное изучение стандартных действий может быть полезно для предотвращения излишней бюрократизации Процесса Управления Изменениями.
Одним из способов выполнения таких действий является определение так называемых "предварительно авторизованных"[105]изменений (или "категории 0"), которые записываются в базу данных изменений (предпочтительно самими запрашивающими), но не требуют использования процедур по Управлению Изменениями. Например, если при приеме на работу нового сотрудника обычно выполняются четырнадцать действий (создание новой учетной записи[106], настройка рабочей станции, электронной почты и т. д.), то эти действия не требуют столь внимательного изучения, как значительные изменения инфраструктуры. Такой вид стандартных изменений обрабатывается по типовому шаблону как предварительно авторизованный "Запрос на Обслуживание".
Целью Процесса Управления Изменениями является гарантия использования стандартных методов и процедур для быстрой обработки изменений с минимальным возможным отрицательным воздействием изменения на качество услуг. Все изменения должны быть отслеживаемыми, чтобы можно было ответить на вопрос: "Что изменилось-"
7.2.1. Преимущества использования процесса
Для эффективного предоставления ИТ-услуг организация должна уметь обрабатывать большое количество изменений с надлежащим Уровнем Ответственности при принятии решений.
Преимуществами Процесса Управления Изменениями являются:
- уменьшение отрицательного воздействия изменений на качество ИТ-услуг;
- более точные оценки затрат для предлагаемых изменений;
- уменьшение количества изменений, потребовавших возврата к исходному состоянию, и каждый такой возврат происходит более гладко;
- предоставление руководству более полной информации об изменениях, что позволяет выявлять проблемные области;
- повышение производительности работы пользователей за счет более высокой стабильности и качества ИТ-услуг;
- повышение производительности работы ИТ-персонала, не отрывающегося от плановой работы для проведения срочных изменений и процедур возврата;
- рост способности компании проводить частые изменения без нарушения стабильности ИТ-среды.
Процесс Управления Изменениями принимает или отклоняет каждый Запрос на Изменение (RFC). Руководитель Процесса Управления Изменениями содействует работе процесса, но реальные решения о наиболее значительных изменениях принимаются консультативным комитетом по изменениям (CAB). Членами комитета CAB являются представители разных отделов компании, а также заказчиков и поставщиков. Ответственность за предоставление информации о потенциальном воздействии предлагаемых изменений несет Процесс Управления Конфигурациями.
Рис. 7.2. Позиционирование Процесса Управления Изменениями
Входы Процесса Управления Изменениями включают в себя:
- Запросы на Изменения (RFC);
- информация из базы данных CMDB (в частности, анализ степени воздействия изменений);
- информация из других процессов (из Базы данных мощностей CDB, информация о бюджете и т. д.);
- планирование изменений (Согласованный план изменений[107]FSC).
Выходы процесса включают:
- обновленный план изменений (Согласованный план изменений FSC);
- моменты инициирования действий (триггеры) в рамках Процессов Управления Конфигурациями и Управления Релизами;
- повестка дня Консультативного комитета CAB, протоколы и принятые решения;
- отчеты по Процессу Управления Изменениями.
Управление Изменениями имеет описанную ниже взаимосвязь с другими процессами.
7.3.1. Управление Инцидентами
Процесс Управления Инцидентами имеет двухстороннюю связь с Процессом Управления Изменениями. С одной стороны, Управление Изменениями обрабатывает направляемые Управлением Инцидентами Запросы на Изменения для разрешения инцидента или запрашиваемые Управлением Проблемами изменения, устраняющие причину инцидента. С другой стороны, несмотря на многочисленные предосторожности, внедрение изменений все же может привести к возникновению инцидентов. Это может быть связано с ошибками проведения изменения или с недостаточной подготовкой пользователей к изменениям. Соответствующий персонал Управления Инцидентами должен быть информирован о проведении изменений, чтобы иметь возможность быстро определить и устранить возникающие инциденты.
7.3.2. Управление Конфигурациями
Управление Изменениями и Управление Конфигурациями являются настолько тесно связанными процессами, что они могут быть эффективно интегрированы между собой – шаг, рекомендованный в библиотеке ITIL.
Изменения регистрируются под контролем Процесса Управления Конфигурациями, анализ воздействия изменений также проводится с участием Процесса Управления Конфигурациями. Управление Конфигурациями определяет зависимость между Конфигурационной Единицей CI (вовлеченной в проводимое изменение) и другими CI, чтобы определить, на какие другие элементы будет воздействовать это изменение.
7.3.3. Управление Проблемами
Взаимосвязь между Процессами Управления Изменениями и Управления Проблемами во многом похожа на такую же связь между Процессами Управления Изменениями и Управления Инцидентами. С одной стороны, изменения часто бывают необходимы для разрешения проблем. С другой стороны, если проведение изменений недостаточно контролируются, они могут привести к новым проблемам.
7.3.4. Управление Релизами
Изменения часто приводят к необходимости разработки и распространения новых приложений или установке технической инфраструктуры. Это осуществляется с помощью Процесса Управления Релизами. Контроль над распространением новых версий осуществляется Процессом Управления Изменениями.
7.3.5. Управление Уровнем Сервиса
Процесс Управления Уровнем Сервиса вовлечен в определение степени воздействия изменений на предоставление услуг и бизнес-процессы. В зависимости от ситуации в Консультативном комитете (CAB) могут участвовать представители Процесса Управления Уровнем Сервиса. Если изменение оказывает значительное воздействие или связано с высоким риском, его внедрение и сроки должны всегда обсуждаться с заказчиком. Управление Изменениями направляет в Управление Уровнем Услуг отчет "Проектируемая доступность услуг"[108](PSA). В этом отчете Управление Изменениями излагает изменения в имеющихся Соглашениях об Уровне Услуг (SLA) и воздействие Согласованного плана изменений (FSC) на доступность услуг.
7.3.6. Управление Доступностью
Процесс Управления Доступностью инициирует изменения, направленные на повышение доступности услуг и проверяет, привели ли предпринимаемые меры к ожидаемому результату. Управление Доступностью часто привлекается при оценке потенциального воздействия изменений, так как это воздействие может повлиять на доступность услуги.
7.3.7. Управление Мощностями
Руководитель Процесса Управления Мощностями в первую очередь занимается вопросом анализа совокупного эффекта по результатам изменений в течение продолжительного периода времени, например, увеличением времени реакции приложений или потребностью в большей емкости для хранения информации. На основе составленного Плана мощностей Управление Мощностями регулярно предлагает усовершенствования и инициирует изменения в форме Запросов на Изменения (RFC).