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

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

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

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

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

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

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

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

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

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

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