Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT