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

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

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

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

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

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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

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

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

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

  1. Альберт

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

    0
    0

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

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

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

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

НОЯ
27
Учебный курс:
Основы ITIL (очно)