Ян Ван Бон - ИТ Сервис-менеджмент. Введение
- Название:ИТ Сервис-менеджмент. Введение
- Автор:
- Жанр:
- Издательство: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).
ИТ Сервис-менеджмент. Введение - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
• Наивысшая степень воздействия– изменение, требующее значительных усилий. Руководителю Процесса необходимо предварительно получить авторизацию на выполнение изменения от руководства ИТ или Руководящего комитета ИТ, после чего изменение представляется на рассмотрение Консультативного комитета (CAB).
Эти коды могут быть представлены в цифрах, например: низкая степень = 1 / высшая степень = 3.
Большинство изменений относятся к двум первым категориям. В добавление к классификации должны быть также определены группы, участвующие в работе над техническим решением, и услуги, затрагиваемые изменением.
7.4.4. Планирование
В рамках процесса осуществляется планирование изменений на основе графика, называемого Согласованным планом изменений [113] Forward Schedule of Change – FSC.
(FSC). План FSC содержит подробную информацию обо всех утвержденных изменениях и их планировании. Члены Консультативного комитета (CAB) дают рекомендации по планированию изменений, так как необходимо учитывать наличие персонала, ресурсов, затраты, различные аспекты задействованных услуг, а также мнение заказчиков. Консультативный комитет (CAB) играет роль консультативного органа. В целом Управление Изменениями имеет делегированные полномочия, т. к. оно действует от лица руководства ИТ. Возможно, что изменения наивысшей категории необходимо утверждать руководством ИТ до их представления Консультативному комитету (CAB). Утверждение изменения имеет несколько аспектов:
• Финансовое одобрение– анализ затрат/выгод и выделение бюджета.
• Техническое одобрение– оценка необходимости, возможности проведения изменения и его степени воздействия.
• Бизнес-одобрение– одобрение пользователями требуемой функциональности приложения и степени воздействия изменения.
Для целей эффективного планирования Управление Изменениями должно взаимодействовать с проектным офисом и другими подразделениями компании, занимающимися разработкой и внедрением изменений. Кроме того, достаточное внимание должно уделяться своевременному осведомлению пользователей о планировании изменений, возможно, в виде рассылки Согласованного плана изменений (FSC).
Политика проведения изменений
Изменения по разным Запросам можно объединять в одном релизе. В этом случае при неудачной реализации будет достаточно одного возврата к исходному состоянию [114] Back-out.
. Такой групповой релиз должен рассматриваться как одно изменение, даже если он содержит в себе несколько изменений. Релизы могут планироваться с учетом функциональных задач, необходимых для бизнеса. Они могут охватывать аппаратные и программные средства, и их внедрение осуществляется Процессом Управления Релизами. Рекомендуется определить политику компании в этой области и информировать о ней ИТ-организацию и заказчиков (см. также «Управление Релизами»). Цель политики – оградить пользователя от ненужного беспокойства («перекапывание дороги каждую неделю»).
После консультаций с участвующими ИТ-подразделениями, Консультативный комитет (CAB) может определить регулярные периоды времени («окна») для проведения изменений, когда степень воздействия на ИТ-сервисы будет минимальной. Подходящими периодами могут быть выходные дни или нерабочее время. Таким же образом могут быть определены периоды, когда допускается минимум изменений или они вообще не допускаются, например, рабочее время или конец финансового года, когда все подразделения пользователей делают отчеты.
Совещания Консультативного комитета (CAB)
Информация о планировании изменений должна распространяться заранее до совещания CAB. Соответствующая документация и информация о пунктах повестки дня также должны рассылаться до совещания.
Повестка дня совещания CAB должна включать ряд постоянных пунктов, в том числе:
• неавторизованные изменения;
• Запросы на Изменения (RFC), которые должны быть оценены членами Консультативного комитета (CAB);
• авторизованные изменения, которые не были представлены на рассмотрение консультативного комитета (CAB);
• открытые и закрытые изменения;
• оценка произведенных изменений.
Оценка степени воздействия и ресурсов
При оценке необходимых ресурсов и степени воздействия изменения члены Консультативного комитета (CAB), Руководитель Процесса Управления Изменениями и другие участники (определенные Консультативным комитетом) должны учесть следующие аспекты:
• вопросы возможностей («мощности» или «емкости») подвергающихся воздействию услуг;
• надежность и возможность восстановления;
• планы по Управлению Непрерывностью ИТ-услуг;
• планы возврата к исходному состоянию;
• вопросы безопасности;
• степень воздействия изменения на другие ИТ-сервисы;
• регистрация изменения и его предварительное одобрение;
• необходимые ресурсы и затраты (поддержка и обслуживание);
• количество и наличие необходимых специалистов;
• необходимое время на весь цикл изменения;
• новые ресурсы, которые должны быть закуплены и пройти тестирование;
• степень воздействия на текущую операционную деятельность;
• какие-либо возможные конфликты с другими изменениями.
Члены Консультативного комитета (CAB) могут также дать рекомендации по определению приоритета изменения.
7.4.5. Координация
Об утвержденных изменениях сообщают соответствующим техническим специалистам, которые будут разрабатывать и внедрять эти изменения. Перед внедрением происходит этап тестирования. В разработке, испытании и внедрении утвержденных изменений важную роль может играть Процесс Управления Релизами. Большое внимание должно уделяться вопросам информирования персонала внутри компании для поддержки изменений.
Подготовка изменения [115] Building.
Не все изменения проходят отдельную фазу компоновки. Например, стандартные изменения, такие как перемещение персональных компьютеров, могут планироваться и осуществляться незамедлительно.
Компоновка может включать создание новой версии программы с новой документацией, руководствами, инсталляционными процедурами, планом возврата к исходному состоянию и аппаратными изменениями. Управление Изменениями осуществляет контроль и координацию, его поддерживают Процесс Управления Релизами и руководители линейных подразделений, которые обеспечивают предоставление необходимых ресурсов.
Процедура возврата к исходному состоянию должна разрабатываться как часть общей схемы проведения изменения на случай, если изменение не обеспечивает достижение необходимого результата. Управление Изменениями не должно одобрять проведение изменения при отсутствии процедуры возврата. Если изменение влияет на среду пользователя, должен быть составлен коммуникационный план. План внедрения изменения также составляется на стадии компоновки.
Читать дальшеИнтервал:
Закладка: