План управления конфигурациями

При подготовке процессной (регламентной) документации по управлению активами и конфигурациями, если раньше никакой документации на эту тему в организации не было, может возникнуть вопрос — как правильнее назвать итоговый документ или документы? И сколько их должно быть?

Казалось бы, всё просто — в ITIL прямо сказано, что «целевой уровень управления сервисными активами и конфигурациями», который каждая компания должна определить для себя сама, документируется в Плане управления сервисными активами и конфигурациями (SACM plan, см.ITIL v3 2011 Service Transition, 4.3.5.2). Давайте чуть внимательнее посмотрим на его рекомендуемую структуру.

Пример структуры плана управления сервисными активами и конфигурациями.

  1. Общие сведения (назначение документа и контекст)
  2. Охват:
    • Сервисы
    • Среды и инфраструктура
    • География
  3. Требования:
    • Ссылка на политики и стратегию
    • Ссылка на требования со стороны бизнеса, сервис-менеджмента и внешние (контрактные)
    • Сводные требования к структуре ответственности, возможностям отслеживания изменений, формированию аудиторского следа
    • Ссылка на требования к системе управления конфигурациями (Configuration management system, CMS)
  4. Применимые политики и стандарты:
    • Политики
    • Индустриальные стандарты, например, ISO/IEC 20000, ISO/IEC
      19770-1
    • Внутренние стандарты, затрагивающие SACM (например, стандарты в части аппаратного обеспечения)
  5. Организационная структура SACM:
    • Роли и ответственность
    • Функции Совета по изменениям (Change advisory board, CAB)
    • Порядок авторизации базовых состояний, изменений и релизов
  6. Описание процедур и смежных процессов, в рамках которых реализуются активности процесса, например:
    • Идентификация конфигураций
    • Управление версиями
    • Управление интерфейсами
    • Управление поставщиками
    • Управление изменениями
    • Управление релизами и развёртыванием
    • Управление сборками ПО
    • Создание и поддержка базовых состояний
    • Сопровождение CMS
    • Закупка и списание конфигурационных единиц
    • Верификация и аудит CMS
  7. Связи и структура взаимодействия с другими процессами и функциями, например:
    • Управление основными средствами
    • Управление проектами
    • Управление разработкой и тестированием
    • Заказчики
    • Внешние каналы взаимодействия (Service provider interfaces, SPI)
    • Операционные функции, включая службу Сервис-деск
    • Управление взаимоотношениями и контроль поставщиков и подрядчиков

Как мы видим, структура Плана управления конфигурациями более всего походит на структуру документа, который мы понимаем, как описание процесса. Есть описание ключевых принципов (политик, стандартов и так далее), описание ролевой структуры, а также порядка выполнения отдельных процедур.

На практике доводилось встречать подход, при котором по процессу формируются два документа — Описание (регламент) процесса и План управления конфигурациями. При этом в План выносится информация о структуре CMDB, правилах именования и маркировки, требованиях к аудиту и так далее, и всё это — в разрезе отдельных категорий конфигурационных единиц. Как мне кажется, название «План» несколько не соответствует содержанию такого документа. Ведь в описанном случае этот документ содержит информацию об охвате учёта, выраженном через структуру категорий и требования к составу учитываемых данных, а также некоторые параметры выполнения процедур процесса. При этом описание самих процедур содержится в описании процесса, который, в таком случае, является единым для всех категорий и типов конфигурационных единиц. В частности, такой процесс, как правило, содержит процедуру «Обновление CMDB», которая обычно описывается довольно скудно с целью унификации. По факту же состав видов деятельности различается, как правило, не по конкретным категориям конфигурационных единиц, а по их группам. Например, состав процедур, а не только структура обновляемых данных, при управлении аппаратным и программным обеспечением заметно отличаются. В результате становится непонятно, как же организовать документы, чтобы, с одной стороны, охватить существенные для организации аспекты SACM, а с другой — сгруппировать информацию наиболее логично.

Мне видится рациональным разделять описание видов деятельности в рамках SACM на следующие блоки:

  • Управление ИТ-активами
    • аппаратными (физическим оборудованием)
    • программными продуктами и лицензиями на ПО
  • Управление расходными материалами и комплектующими
  • Управление конфигурациями (учёт логических КЕ, построение и поддержание конфигурационных моделей).

Такая группировка основана на различиях в жизненных циклах и правилах учёта. При этом описание структуры CMDB, атрибутов, требований к аудиту и так далее логично вынести в приложение к основному документу. В качестве же названия для самого документа лично мне больше всего нравится, как раз, «План управления сервисными активами и конфигурациями». И документ, на мой взгляд, должен быть один. Конечно, в силу специфики конкретной организации такое название может не подойти. Может требоваться что-то вроде «Положения» или «Регламента». Но с учётом выноса дополнительной информации в приложения такое переименование не представляет проблем. Так или иначе, мы получаем единое описание комплекса процессов управления сервисными активами и конфигурациями.

Мнение автора может не совпадать с мнением редакции.

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
20
АВГ
23