Портал №1 по управлению цифровыми
и информационными технологиями

Конфигурационная единица или ИТ-актив

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

Сначала про «конкретику с цитатами». В практическом руководстве по управлению ИТ-активами последней, четвёртой версии библиотеки ITIL определение актива выглядит так:

IT asset Any financially valuable component, resource, or capability that could contribute to the delivery of an IT product or service.
The types of IT assets have grown in recent years to include physical assets like servers, desktops, laptops, and network hardware, as well as less tangible assets such as virtual servers, cloud resources, software and software licenses, developed code, databases, information, and knowledge.

Отметив то, что в тексте-пояснении, который дополняет определение, явно сказано, что виртуальный сервер является примером ИТ-актива, сфокусируемся на самом определении. 1) «компонент, ресурс или способностью, который даёт вклад в предоставление услуги/продукта» и при этом 2) «имеет ценность/стоимость с финансовой точки зрения». С первой частью обычно более-менее всё понятно. Спор чаще возникает по поводу второй части. Некоторые считают, что раз мы можем определить некоторую себестоимость того или иного элемента, то это и есть та самая «стоимость с финансовой точки зрения». А это не так. Например, в сервисно-ресурсной модели [СРМ] услуги, которую мы используемся для построения экономической модели услуги, позволяющей определить потребность в ресурсах и экономически обоснованным образом определить затраты на предоставление услуги, виртуальный сервер имеет свой «ценник». Пример модели, построенной для демонстрационного примера, разбираемого на курсе, на скриншоте.

Аналогичная иллюстрация – скриншот визуализатора затрат из нашей системы автоматизации по реальной услуге.

То есть, в приведённых примерах виртуальная машина является точкой, относительно которой мы принимаем решения не только с точки зрения управления конфигурациями, но и можем (должны) определить затраты, которые возникают на нашей стороне для того, чтобы обеспечить функционирование этого элемента СРМ.

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

Разумеется, мы можем трактовать понятие «ИТ-актив» более широко, к чему нас вроде и подталкивает процитированная формулировка определения. Но будем ли делать с точки зрения управления всё то же самое по отношению к виртуальной машине, что мы будем делать по отношению к лицензиям, аппаратному обеспечению? Скорее всего нет.

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

Мы строим систему управления, элементами которой являются затрагиваемые в текущем разговоре «управление конфигурациями» и «управление ИТ-активами». И то, что попадает в область ответственности/интересов соответствующего элемента системы управления, определяется задачами, которые мы ставим перед этим элементом и тем, как он будет устроен. По-моему, только принимая во внимание этот момент, можно пускаться в рассуждения о разнице между конфигурационной единицей и активом. Иначе, оставаясь лишь с формальными определениями этих понятий, лишь жонглируя цитатами из ITIL и других умных книг, рискуем уподобиться тем, кто тратил интеллектуальные усилия на споры по поводу того, сколько ангелов могут уместиться на кончике иглы.

Ведь на практике отнесение той или иной сущности к одной из групп («активы», «конфигурационные единицы») означает, что

  1. Эта сущность будет описываться разными (пересекающимися, но не совпадающими) наборами атрибутов
  2. Жизненный цикл этой сущности будет описываться разными фазами. Что в реальной жизни означает, разные процедуры работы с этой сущностью.

Поэтому, да, возможно, что виртуальный сервер вы отнесёте к ИТ-активам. Но задайте себе вопрос: «Что в этой связи мы будем делать «ИТ-активного»?» Если такие отличительные признаки присутствуют, то мы имеем дело с активом. Но если, как это чаще всего бывает, ответ на этот вопрос «ничего», то зачем вы отнесли виртуальный сервер к активам? Что вы от этого получаете?

«Управление ИТ-активами (ITAM)»
Трёхдневный практический курс на основе IBPL, ITIL, COBIT, ISO 20000 и ISO 19770

Комментариев: 16

  • Михаил Буталин

    ITIL в России не работает. Статья из серии “когда коту делать нечего”. Все успешные “кейсы” – это отработка KPI

    • Роман

      ITIL в России работает. Всё счастливые или более счастливые пользователи и клиенты это подтвердят

    • Михаил, всё зависит от того, что именно вы подразумеваете под «ITIL работает» и «успехом». Наверняка, при определённом понимании этих фраз ваше утверждение верно. Но, думаю, не при всех.

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

      Ведь те самые KPI, отработка которых, как Вы пишете, и есть успех, кто-то разрабатывает. Как, почему, зачем? В организациях, где KPI действительно являются управленческим инструментом, необходимо, чтобы кто-то умел формировать адекватную систему KPI. Условный ITIL здесь может помочь. Для решения подобной задачи потребует думать, рассуждать. Возможно, спорить, убеждать, доказывать. Жаль, если работа организована так, что заниматься всем этим можно только тогда, «когда коту делать нечего». Так бывает. Но тогда трудно придумать, что может помочь, и, вероятно, это вопрос не к ITIL.

  • Андрей

    Мне кажется неправильной сама постановка вопроса- “Вопрос проведения границы между множествами «конфигурационные единицы» и «ИТ-активы» ”
    Речь идет об одно и том же объекте. Для описания объекта используются разные наборы атрибутов – финансовые и технологические. Но это один и тот же объект и странно проводить по нему границы. Тот же виртуальный сервер. Для финансовой оценки, например расчета себестоимости услуги, вам важен набор атрибутов, свойственный для актива(Asset). Для операционной деятельности вам важен набор атрибутов, свойственный для конфигурационной единицы (CI). Но в обоих случаях речь идет об одном и том же объекте.

    • Андрей, спасибо за детальное, понятное описание сценария!
      Ровно об этом я и говорил в одном из последних абзацев («Мы строим систему управления…»).

      Если я правильно понял, Вы предлагаете один организационный механизм (процесс, практику), в рамках которого будет осуществляться учёт всего. Всех объектов, о которых нам нужно что-то знать в рамках управления услугами. При этом понятно, что нам не нужно два названия для одной и той же сущности. Есть сущность, объект, как Вы написали, у которого есть разные атрибуты. Какие-то атрибуты важны с точки зрения управления конфигурациями, а какие-то с точки зрения управления активами. Но поскольку в предложенной картине это один механизм, то и разделять нет смысла. Сами термины «конфигурационная единица» и «ИТ-актив» теряют смыл. Можно обойтись одним. Например, в предыдущей, третьей версии ITIL был описан один процесс «Управление сервисными активами и конфигурациями» («Service assets and configuration management»). Правда, там авторы всё-таки пытались развести понятия «конфигурационная единица» (configuration item) и «сервисный актив» (service asset). Но, это не всегда удавалось. Да, и это не так критично, поскольку процесс-то один. То есть, как раз картинка, похожая на предлагаемую Вами.

      На мой взгляд, описанный вариант возможен и является частным случаем. Частным потому, что, мы, работая с использованием такой механики, столкнёмся с тем, что выполняем разные наборы работ по отношению к объектам в зависимости от того, о какой стороне данного объекта (о каком наборе атрибутов) идёт речь. И требования к интерфейсам с прочими практиками (например, управление финансами), в том числе общекорпоративными (например, закупочные процедуры) будут различаться. И в какой-то момент с точки зрения управления окажется более эффективным разделить эти области деятельности (управление активами и управление конфигурациями). Как предлагается, например, в COBIT 2019, ГОСТ Р ИСО-МЭК 20000-1—2021 (который перевод ISO 20000), ITIL 4.

      В каждой из этих областей свои объекты управления. То есть объекты, которыми мы управляем в рамках данной области. В управлении активами таким объектом является актив. В управлении конфигурациями – конфигурационная единица (КЕ). Являются ли данные объекты управления (ИТ-актив и КЕ) просто проявлением, разными сторонами одного и того же объекта реального мира? Может быть да, может быть нет. В какой-то момент вам придётся напрягаться, чтобы описывать некоторые сущности в качестве одного объекта (кстати, что именно?). Например, лицензия на средства виртуализации (гипервизор, управление и т.п.) и виртуальные машины. Кстати, в каждой виртуальной машине установленная операционная система, которая, в случае с одной до сих пор довольно широко используемой импортной системой может лицензироваться ооочень по-разному. Вот поэтому обычно и описывают эту часть вот такой картинкой (есть такая и в практическом руководстве «Управление конфигурациями» в ITIL 4).
      Конфигурационные единицы и ИТ-активы

      Но самое главное, разумеется, не то, что написано в той или иной книге, а то, что стоит за написанным. Идеи, факторы, которые влияют на то, как мы будем строить систему управления. И задача, соответственно, состоит не в том, чтобы поделить (или не поделить) все сущности, которые мы можем идентифицировать на две кучки. А в том, чтобы определить охват процессов/практик. То есть, это не просто теоретическая задачка, а управленческое решение относительно того, как будет организована работа ИТ в данной области. Вопрос не новый, обсуждался неоднократно. В частности, рекомендую ознакомиться с коротким комментарием от бесспорного ITSM-эксперта.

      • Андрей

        Маленькое уточнение. Я не предлагаю единый процесс на все на свете:)). Я о том, что один и тот же объект используется в разных процессах, но это один и тот же объект. В разных процессах используются разные атрибуты. Но в едином, корпоративном управлении все процессы должны быть связаны между собой. ( это как в ER моделировании – если некая таблица в вашей модели не связана ни какой либо еще, то она в вашей модели лишняя). И понимание того, что речь идет об одном и том же объекте , как раз и служит для связи некоторых процессов. К сожалению ITIL так и не разродилось общей моделью процессов(бизнес процессов), да и то что есть с трудом можно назвать полноценной моделью.

        • Понял. Спасибо за уточнение!
          Тогда остаётся вопрос: “Удастся ли для найти такой набор объектов, чтобы он был универсальным, и менялся лишь набор атрибутов. которыми мы эти универсальные объекты описываем?” По-моему, это трудно.
          Например, какой набор объектов выбрать и как описать между ними взаимосвязи в примере: набор виртуальных машин, перемещаемых между различными аппаратными серверами, на которых развёрнут кластер виртуализации с необходимыми инструментами управления (где для простоты всё покрыто разными (core, vm) лицензиями в составе enterprise agreement (subscription))? Или всё перечисленное считать КЕ? Каждую отдельную лицензию? А если это другая форма лицензирования, и разные вендоры?
          Мне кажется, что и так можно прорисовать все сущности и все связи. Но как-то это… Притянуто, что ли. Ведь, например, по отношению к некоторым сущностям (ВМ) у вас не будет закупок. А если вы удалили ВМ? Что происходит с КЕ? А с активом? Как меняется набор объектов и их взаимосвязи?

  • Сергей Л. Знаменский

    В полемике является ли виртуальный сервер ИТ-активом я бы поддержал точку зрения автора статьи – Игоря Гутника. Виртуальные серверы имеют “короткий” жизненный цикл, совпадающий с ЖЦ любого КЕ и не совпадающий с ЖЦ ИТ-активов. Поэтому вряд ли стоит относить виртуальный сервер к ИТ-активам, если для этого нет веских причин.
    Стоит отметить, что не все объекты учета используемые в ИТ могут проявлять одновременно свойства КЕ и свойства ИТ-актива: есть КЕ, не являющиеся ИТ-активами (виртуальный сервер например), есть и ИТ-активы, не являющиеся КЕ (лицензия на использование ПО например).

    • Сергей, спасибо за примеры!
      Они как раз хорошо ложатся в картинку, прикреплённую к комментарию выше.

  • Андрей

    Решил добавить свои 5 копеек про виртуальный сервер. С одной стороны, если мы говорим о его реализации на внутренней инфраструктуре, то получается что он действительно не есть самостоятельный актив, а лишь используется в операциях с активами(распределение лицензий и т.д.). Но как только мы меняем подход и принимаем решение арендовать его в каком либо ЦОДе, то опаньки – вот он уже и полноценный актив, оставаясь при этом еще и конфигурационной единицей.

    • Похоже на то 😉
      Или, например, канал связи, арендуемый у телеком-оператора. Или любые другие важные с точки зрения управления конфигурациями объекты (есть КЕ), которыми мы управляем через контракты (за которые платим). Точнее, которые приобретаем. Потому что под описание в предыдущей фразе подходит и работы, оплачиваемые по контракту, и направленные на поддержку работоспособности КЕ (CI). Как написал в заметке, на мой взгляд, возникновение «ценника» (затрат, связанных с этим объектом) необязательно делает его активом (в практическом смысле этого слова, а не с точки зрения широкой трактовки «актив – всё, что для нас ценно»).

  • Павел

    А если задать вопрос по другому: “если ИТ-актив разделить на части, будут ли его части являться ИТ-активами?”
    Ведь на виртуальный сервер можно посмотреть как на часть физического, мощности которого выделяются на его функционирование.
    А вот на КЕ можно (или дпже нужно) смотреть, как на некую абстрактную сущность: для функционирования ИТ-сервиса нужен сервер, не конкретный сервер, а абстрактный, главное, чтобы он удовлетворял определённым требования RAM, CPU, HDD, ОС и т.п. А вот его реализация это уже другой вопрос: физический, виртуальный, арендованный.
    Можно сказать, что КЕ описывает, какие элементы нужны, а активы – как они реализованы.
    Кстати лицензия тоже может быть рассмотрена в таких же проекциях: лицензия, как необходимый компонент, она нужна, чтобы что-то работало, а “реализована” она может быть по разному: стандалон, подписка, часть бандла или купленная отдельно, OEM и т.п.

    • Можно сказать, что КЕ описывает, какие элементы нужны, а активы – как они реализованы.

      Павел, тогда, если я правильно понял, Вы находитесь в той же картине, которую описывает Андрей: “КЕ и Активы – разные стороны (наборы атрибутов) одного итого же набора объектов”. Если строить систему управления так, то области на картинке будут совпадать. Это один из возможных вариантов.

      А если задать вопрос по другому: “если ИТ-актив разделить на части, будут ли его части являться ИТ-активами?”

      Задаться вопросом, чтобы что? В каком контексте (решая какую задачу)?
      В общем виде мой ответ на вопрос следующий. Если в результате декомпозиции/агрегации получается то, что нам нужно учитывать в рамках управления конфигурациями, то это КЕ, если в рамках управления активами – Актив. Если и там, и там, то…

  • Андрей

    “Остапа несло” :)))
    Вся эта суета по поводу КЕ/Актив на мой взгляд связана с тем, что КЕ и Активы ведут в разных системах. Это вполне обосновано(ведение в разных системах), поскольку процессы работы с ними сильно разные. Но, как я уже говорил ранее, эти процессы связаны между собой и сама постановка между “умной и красивой” не совсем правильная. Повторюсь, речь идет про одни и те же объекты и разные системы должны содержать механизмы связи между КЕ и Активом. А ведь есть еще и IDM (системы управления доступом), которые оперируют еще одним понятием – ресурс, и он тоже неразрывно связан и с КЕ (доступ к конкретным КЕ) и с активами (на пример объем свободных подключений в рамках закупленной лицензии(актив)). Кто о чем, а я опять о том, что ITIL все никак не удосужится создать единую модель бизнес процессов, что сняло бы кучу вопросов(как пример – serviceDesk , это процесс или инструмент?) И ведь у них есть понимание необходимости в общей модели(по крайне мере у части соучастников :)) Но так до сих пор и не разродились, хотя задел есть и достаточно внушительный.

    • “Остапа несло” :)))

      👍

      Вся эта суета по поводу КЕ/Актив на мой взгляд связана с тем, что КЕ и Активы ведут в разных системах. Это вполне обосновано(ведение в разных системах), поскольку процессы работы с ними сильно разные.

      Да, это может быть организовано, как разные области/потоки работ (в ITIL4 – практики). Вне зависимости от того, одна информационная система или разные. Но, вы правы, если системы разные, это дополнительный фактор, влияющий на выбор «делить/не делить».

      Но, как я уже говорил ранее, эти процессы связаны между собой и сама постановка между “умной и красивой” не совсем правильная. Повторюсь, речь идет про одни и те же объекты и разные системы должны содержать механизмы связи между КЕ и Активом.

      Про “умные и красивые” не понял.

      Совпадаем в том, что между объектами типа КЕ и Актив (то есть объектами управления в этих двух практиках) должны быть связи.

      По-прежнему не совпадаем в том, что это один и тот же набор объектов. Такая картина возможна, если мы воспринимает КЕ и Актив как разные стороны (наборы атрибутов) одних и тех же сущностей. На мой взгляд это частный случай. Этот сценарий описывает только пересечение двух областей на картинке, игнорируя остальные части. Так можно рассуждать. Принимаем решение, исходя из решаемых задач и соображений оптимальности.

      …что сняло бы кучу вопросов(как пример – serviceDesk , это процесс или инструмент?

      Лично я вообще не об ITIL 😉 Поэтому не хочу сейчас выступать адвокатом (сильно оффтоп уже). Коротко – у библиотеки другая задача.
      Но забавно, что, опираясь, например, на информацию из двух последних версий библиотеки, Ваш вопрос стоило бы сформулировать так: “Service Desk – это функция или практика способность (capability)?” Ибо сервис деск как процесс авторы ITIL, насколько я помню, не предлагали определять. Да, и как инструмент.

  • Сергей Л. Знаменский

    У меня есть несколько неожиданное предложение.
    Я осознаю, что КЕ – исторически устоявшаяся аббревиатура, пришедшая из устаревших версий ITIL – к ней просто привыкли.
    При этом нужно осознавать, что КЕ – это неудачный перевод английского термина “configuration item”. Почему неудачный? Потому что требует пояснения – иначе он непонятен.
    Однако в ITIL 4 мы видим иной термин: “компонент услуги” – лично мне он нравится больше – он интуитивно понятен.
    Может пришла пора отказаться отказаться от термина КЕ в пользу “компонента услуги” ?
    Может тогда и полемика с противопоставлением КЕ и ИТ-актива утихнет сама собой, потому что все встанет на свои места?


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;