Портал №1 по управлению цифровыми
и информационными технологиями

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

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

Казалось бы, всё просто – в 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, атрибутов, требований к аудиту и так далее логично вынести в приложение к основному документу. В качестве же названия для самого документа лично мне больше всего нравится, как раз, “План управления сервисными активами и конфигурациями”. И документ, на мой взгляд, должен быть один. Конечно, в силу специфики конкретной организации такое название может не подойти. Может требоваться что-то вроде “Положения” или “Регламента”. Но с учётом выноса дополнительной информации в приложения такое переименование не представляет проблем. Так или иначе, мы получаем единое описание комплекса процессов управления сервисными активами и конфигурациями.

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

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 2

  • Роман

    Добрый день!
    А есть ли примеры / шаблоны для дальнейшей доработки по месту?

    • Артем Мукосеев

      Роман, добрый день!

      К сожалению, в открытом доступе таких шаблонов у нас нет.
      Есть некоторые примеры на сайте, например, здесь.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;