Управление активами и конфигурациями — как избежать конфликта интересов

При внедрении комплексного процесса управления активами и конфигурациями приходится сталкиваться со следующей проблемой. Процессы управления активами и управления конфигурациями (именно так, посмотрим на них, как на два отдельных процесса) имеют несколько разные задачи, но частично пересекаются в части охвата. Да-да, именно частично. Дело тут в следующем: с точки зрения управления конфигурациями нам, в первую очередь, интересны технические и особые (характерные для конкретной категории) характеристики конфигурационных единиц, их местоположение и связи между ними. Плюс, поскольку наши любимые сервисно-ресурсные модели строятся с использованием только части категорий конфигурационных единиц (например, рабочие станции обычно не участвуют в моделях ИТ-услуг), часть категорий оказывается за рамками охвата управления конфигурациями. А управление активами интересует несколько другой набор категорий и другой состав атрибутов, обусловленных требованиями учёта. Группы атрибутов, интересующие управление аппаратными активами, примерно такие:

  • идентификация (категория, модель, SN, инвентарный №, и т.п.);
  • местоположение (площадка, помещение, адрес, стойка, и т.п.);
  • состояние (статус);
  • ответственность (владелец, МОЛ, рабочая/ответственная группа, пользователи и т.п.);
  • важные даты и сроки (закупки, ввода в экспл., гарантии, и т.п.);
  • финансовые (поставщик, цена, основание, и т.п.).

Опять же, управление активами интересует не весь спектр категорий конфигурационных единиц. Например, виртуальные машины, базы данных, кластеры, экземпляры приложений с точки зрения управления активами обычно исключаются из охвата, так как не имеют материального выражения. Таким образом, управление конфигурациями и управление активами "пересекаются" в части управления одними и теми же конфигурационными единицами. Преимущественно — в отношении разных групп атрибутов. Но есть и общие — например, местоположение, которое крайне важно и с точки зрения управления конфигурациями ИТ-услуг, и с точки зрения материального учёта оборудования.

И вот тут становится интересно, когда мы осознаём, что одни и те же люди никак не могут и строить сервисно-ресурсные модели и вести материальный учёт. Те, кто ближе к "железу", как правило, далеки от конфигураций ИТ-услуг. Те, кто ближе к уровню систем и приложений, далеки от вопросов материального учёта. На практике получается, что и менеджеры процессов управления конфигурациями и управления активами — разные. Что, в целом, соответствует COBIT5, и это хорошо.

Но при мысли, что разные люди с разной структурой подчинения будут решать, каждый в своей "песочнице", вопросы, касающиеся "общих" конфигурационных единиц, становится как-то не по себе. Что, например, помешает специалисту по учёту активов взять и, например, списать, а затем организовать утилизацию какого-нибудь устаревшего сервера, если система учёта активов выдала ему соответствующий алерт? Я, конечно, сейчас фантазирую, но вы, я думаю, понимаете все возможные последствия ситуации, когда несколько групп сотрудников независимо решают вопросы в отношении одних и тех же объектов управления!

Давайте разберёмся, какие тут возможны методы предотвращения проблем. Я бы перечислил следующие факторы успеха:

  • назначение менеджера всего процесса управления активами и конфигурациями; это позволит выстроить системную работу по совершенствованию процесса, в том числе в части взаимодействия между процессами;
  • формализация правил учёта конфигурационных единиц различных категорий; правила учёта для категорий, используемых в сервисно-ресурсных моделях, должны предусматривать специальные модели изменений и их согласования;
  • внедрение механизмов мониторинга изменений конфигурационных единиц;
  • разграничение доступа в системе учёта к отдельным категориям и отдельным атрибутам для категорий конфигурационных единиц;
  • постановка управления критичными конфигурационными единицами.

По поводу последнего пункта хотелось бы поговорить особо. В библиотеке COBIT5 в составе процесса управления активами описана процедура BAI09.02 Manage critical assets, из описания которой можно почерпнуть ряд полезных моментов. Для решения описанной выше задачи явно полезно сделать следующее:

  • закрепить перечень категорий и отдельных конфигурационных единиц, являющихся критичными; определить уровень критичности; в описанной задаче можно отнести к критичным все конфигурационные единицы, участвующие в сервисно-ресурсных моделях (с разным уровнем критичности);
  • закрепить ответственных и ограничить доступ к критичным компонентам;
  • обеспечить централизованное планирование прерывания работы критичных компонентов;
  • ограничить возможности удалённого доступа к критичным компонентам;
  • обеспечить информирование смежных подпроцессов (управления конфигурациями и управления активами) о проводимых изменениях.

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

А как вы решаете данную проблему, коллеги?

ITIL ITIL Intermediate: Release Control and Validation

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

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

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

  1. Альберт

    По-моему, в данном случаи конфликт интересов основная движущая сила. Если его убрать, то всё остановится. Поэтому лучше если каждый будет заниматься своими вопросами. Единственное что нужно проработать это процедуры взаимодействия.

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

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

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

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

ИЮЛ
3
Учебный курс:
Основы ITIL (очно)