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

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

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