Ян Ван Бон - ИТ Сервис-менеджмент. Введение
- Название:ИТ Сервис-менеджмент. Введение
- Автор:
- Жанр:
- Издательство:Van Haren Publishing, по заказу ITSMF Netherlands
- Год:неизвестен
- ISBN:90-77212-15-9
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Ян Ван Бон - ИТ Сервис-менеджмент. Введение краткое содержание
Управление сервисами ИТ (IT Service Management, ITSM) развивается в России на протяжении последних пяти-шести лет, однако этот рынок еще недостаточно велик. Работающие в данной области компании не спешат объединить усилия и создать отечественные , хотя уже обладают квалификацией в сфере организации эффективной работы департаментов информационных технологий в различных отраслях. Между тем за рубежом накоплен солидный опыт в организации ИТ. В 80-х гг. британское Центральное агентство по вычислительной технике и телекоммуникациям (ныне OGC) разработало принципы эффективного использования ресурсов ИТ в государственных учреждениях страны. В результате была создана (IT Infrastructure Library, ITIL), где собраны лучшие методы в сфере услуг ИТ. В настоящее время библиотека представляет собой подробное описание наиболее важных видов деятельности в работе ИТ, перечень сфер ответственности, задач и процедур, которые, как утверждается, можно адаптировать для любого предприятия, большого или малого, использующего услуги аутсорсинга ИТ или реализующего собственные службы. На базе библиотеки ITIL свои структурированные подходы к управлению услугами ИТ разработали такие компании, как HP, IBM и Microsoft.
Книга представляет введение в ИТ Сервис-менеджмент - передовой подход по управлению информационными технологиями (ИТ). Он основан на материалах лучшего мирового опыта, собранного и систематизированного в Библиотеке ITIL (IT Infrastructure Library).
ИТ Сервис-менеджмент. Введение - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
• Неадекватная система ручной обработки– некоторые организации стараются как можно дольше хранить данные на бумажных носителях и покупают автоматизированные средства только тогда, когда работать становится невозможно. Это может приводить к задержкам в работе, путанице, потере персонала и ресурсов и т. д. Рекомендуется закупать автоматизированные средства обработки как можно раньше, ориентируясь на функциональные требования процесса.
• Влияние срочных изменений– всегда будут возникать ситуации, когда нужно срочно произвести изменение. Часто это происходит во внерабочее время. Если изменяемые Конфигурационные Единицы находятся под контролем Конфигурационной Базы Данных, то рекомендуется немедленно произвести запись результатов изменения в CMDB, но может возникнуть ситуация, когда отсутствует сотрудник, ответственный за эту задачу. В этом случае регистрацию изменений и обновление CMDB необходимо будет сделать при первой возможности.
• Чрезмерно плотный график работы– если график изменений (Запросов на Изменения) не оставляет времени на выполнение действий в рамках процесса Управления Конфигурациями, то в работе могут появляться задержки и данный процесс будет восприниматься как препятствие. Следует составлять реалистичные графики, основываясь на прошлом опыте.
• Понимание руководством важности процесса– поскольку Управление Конфигурациями является относительно новым процессом, не всегда достаточно видимым для сотрудников, персонал может сопротивляться его принятию. Должна быть достаточная приверженность к необходимости процесса со стороны руководства. Поэтому руководитель процесса должен информировать об Управлении Конфигурациями сотрудников компании и пропагандировать этот процесс в компании. Опыт показывает, что затраты на реализацию процесса будут значительно ниже, если процесс Управления Конфигурациями представлен в компании как отдельная дисциплина с закрепленным за ней персоналом и руководителем, отвечающим за процесс.
• Попытки обхода процесса– в состоянии спешки персонал может пытаться обойти правила работы процесса Управления Конфигурациями. Если такая ситуация возникает регулярно, то после разъяснения негативных последствий таких действий возможно применение дисциплинарных мер.
Глава 7. Управление Изменениями
7.1. Введение
Быстрое развитие ИТ-технологий и рынка привели к тому, что сейчас изменения стали обычным делом. Однако опыт показывает, что инциденты, влияющие на бизнес-приложения, часто бывают вызваны изменениями. Причины таких инцидентов могут быть различными: халатность сотрудников, недостаток ресурсов, недостаточная подготовка, слабый анализ воздействия изменения, несовершенство испытаний или «болезни роста». Если инциденты, связанные с изменениями, не будут контролироваться, из-под контроля может выйти все предоставление ИТ-услуг и сам бизнес. Число инцидентов может увеличиваться, каждый из них будет требовать принятия срочных мер, что в свою очередь может привести к возникновению новых инцидентов. Ежедневное планирование часто не в состоянии учитывать увеличивающуюся рабочую нагрузку. Это может повлиять на повседневную работу и на сопровождение ИТ-услуг.
Целью Процесса Управления Изменениями является руководство проведением изменений и ограничение числа инцидентов, вызванных изменениями. Девиз Процесса Управления Изменениями:
Не всякое изменение является улучшением, но всякое улучшение является изменением.
На рис. 7.1 показан цикл изменений, вызванный предложениями на новые разработки и улучшения (Процессы Предоставления услуг и Управления Проблемами), Запросами (адресованные в Процесс Управления Изменениями) и требуемыми решениями (Процесс Управление Проблемами):
• Инновации и усовершенствования– внедрение новых услуг и новых технических средств в ИТ-инфраструктуру становится причиной появления новых регулярно возникающих ошибок [98] Long-term errors.
в ИТ-инфраструктуре.
• Изменения– все, от небольших инсталляций до перестановки метафреймов, при неаккуратном проведении изменений могут стать причиной появления новых регулярно возникающих ошибок в ИТ-инфраструктуре.
• Корректирующие меры— нацелены на исправление недавно появившихся регулярно возникающих ошибок.
Рис. 7.1. Входы Процесса Управления Изменениями
Управление Изменениями действует как терморегулятор между гибкостью (одобрение изменений, которые могут привести к долгосрочным ошибкам) и стабильностью (одобрение изменений для исправления долгосрочных ошибок). Корректирующие меры уменьшают число инцидентов, за счет чего снижается рабочая нагрузка. Возвращаясь к аналогии с терморегулятором, можно сказать, что температура воды соответствует Уровню Изменений и Инноваций, с которой организация может справиться. Новые дома оборудуются душами с терморегуляторами, автоматически компенсирующими любые изменения давления воды. Если кто-либо и откроет кран холодной воды где-нибудь в доме, принимающий душ не ошпарится.
7.1.1. Основные термины
Две точки принятия решения об изменениях
Существуют две точки принятия решения о проведении изменений:
• Руководитель Процесса Управления Изменениями – лицо, ответственное за предварительный просмотр (фильтрацию) и классификацию Запросов на Изменения [99] Request for Change – RFC.
(RFC). В больших организациях в помощь Руководителю Процесса могут существовать Координаторы изменений, осуществляющие взаимодействие между ним и различными подразделениями организации. Одной из задач Процесса Управления Изменениями является получение требуемой авторизации изменения. В определенной степени сам процесс уже имеет полномочия, но для проведения некоторых изменений может потребоваться согласование с руководством ИТ (например, с Руководящим комитетом [100] Steering Committee.
или Исполнительным комитетом [101] Executive Committee.
). Руководитель Процесса Управления Изменениями также несет ответственность за планирование и координацию проведения изменений.
• Консультативный комитет по изменениям [102] Change Advisory Board – CAB.
(CAB) – консультативный орган, регулярно собирающийся для оценки и планирования изменений. Чаще всего одно или несколько значительных изменений выносятся на обсуждение Комитета. Отдельно создается комитет по срочным изменениям [103] Emergency Committee – EC.
(ЕС), который назначается руководством для принятия чрезвычайных решений. Состав Консультативного комитета является гибким и включает представителей всех основных ИТ-подразделений:
Интервал:
Закладка: