Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

На успешную реализацию процесса могут повлиять следующие проблемы:

? Неправильно определен охват (границы) Конфигурационной Базы Данных или Уровень Дета­лизации Конфигурационных Единиц – если сфера действия Конфигурационной Базы Данных слишком мала, то важные части инфраструктуры будет невозможно проверить, исправить, защи­тить или восстановить. Если же наоборот охват слишком большой, то громоздкость базы данных будет препятствием, замедляющим все процессы Сервис-менеджмента. При большом количестве уровней, атрибутов и взаимоотношений будет трудно поддерживать базу данных в актуальном со­стоянии. Слишком низкий Уровень Детализации приведет к регистрации неполной информации о Конфигурационных Единицах и связанных с ними инцидентах, проблемах, известных ошибках и Запросах на Изменение.

? Неадекватная система ручной обработки – некоторые организации стараются как можно доль­ше хранить данные на бумажных носителях и покупают автоматизированные средства только тог­да, когда работать становится невозможно. Это может приводить к задержкам в работе, путанице, потере персонала и ресурсов и т. д. Рекомендуется закупать автоматизированные средства обра­ботки как можно раньше, ориентируясь на функциональные требования процесса.

? Влияние срочных изменений – всегда будут возникать ситуации, когда нужно срочно произве­сти изменение. Часто это происходит во внерабочее время. Если изменяемые Конфигурационные Единицы находятся под контролем Конфигурационной Базы Данных, то рекомендуется немед­ленно произвести запись результатов изменения в CMDB, но может возникнуть ситуация, когда отсутствует сотрудник, ответственный за эту задачу. В этом случае регистрацию изменений и об­новление CMDB необходимо будет сделать при первой возможности.

? Чрезмерно плотный график работы – если график изменений (Запросов на Изменения) не оста­вляет времени на выполнение действий в рамках процесса Управления Конфигурациями, то в ра­боте могут появляться задержки и данный процесс будет восприниматься как препятствие. Следует составлять реалистичные графики, основываясь на прошлом опыте.

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

? Попытки обхода процесса – в состоянии спешки персонал может пытаться обойти правила работы процесса Управления Конфигурациями. Если такая ситуация возникает регулярно, то после разъяс­нения негативных последствий таких действий возможно применение дисциплинарных мер.

Глава 7 Управление Изменениями

7.1. Введение

Быстрое развитие ИТ-технологий и рынка привели к тому, что сейчас изменения стали обычным де­лом. Однако опыт показывает, что инциденты, влияющие на бизнес-приложения, часто бывают вы­званы изменениями. Причины таких инцидентов могут быть различными: халатность сотрудников, недостаток ресурсов, недостаточная подготовка, слабый анализ воздействия изменения, несовер­шенство испытаний или "болезни роста". Если инциденты, связанные с изменениями, не будут кон­тролироваться, из-под контроля может выйти все предоставление ИТ-услуг и сам бизнес. Число ин­цидентов может увеличиваться, каждый из них будет требовать принятия срочных мер, что в свою очередь может привести к возникновению новых инцидентов. Ежедневное планирование часто не в состоянии учитывать увеличивающуюся рабочую нагрузку. Это может повлиять на повседневную работу и на сопровождение ИТ-услуг.

Целью Процесса Управления Изменениями является руководство проведением изменений и ограничение числа инцидентов, вызванных изменениями. Девиз Процесса Управления Изме­нениями:

Не всякое изменение является улучшением, но всякое улучшение является изменением.

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