Что такое конфигурационная единица
конфигурационная единица
конфигурационная единица
КЕ
(ITIL Service Transition)
Любой компонент или другой сервисный актив, которым необходимо управлять для того, чтобы предоставлять ИТ-услугу. Информация о каждой конфигурационной единице регистрируется в форме конфигурационной записи в системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом управления сервисными активами и конфигурациями. Конфигурационные единицы находятся под контролем процесса управления изменениями. Обычно они включают в себя ИТ-услуги, оборудование, программное обеспечение, здания, людей и документы, такие как процессная документация и соглашения об уровне услуг.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
configuration item
CI
(ITIL Service Transition)
Any component or other service asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system and is maintained throughout its lifecycle by service asset and configuration management. Configuration items are under the control of change management. They typically include IT services, hardware, software, buildings, people and formal documentation such as process documentation and service level agreements.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
Тематики
Синонимы
Смотреть что такое «конфигурационная единица» в других словарях:
ИТ Сервис Менеджмент — ITSM (IT Service Management, управление IT услугами) подмножество библиотеки ITIL получила наибольшую известность в силу того, что предоставление и поддержка IT услуг является первичной задачей IT подразделений и специализированных IT компаний,… … Википедия
время плановой недоступности услуги — (ITIL Service Operation) Ожидаемое время, в течение которого конфигурационная единица будет недоступна в связи с плановым обслуживанием. [Словарь терминов ITIL версия 1.0, 29 июля 2011 г.] EN service maintenance objective SMO (ITIL Service… … Справочник технического переводчика
время простоя — Период времени, в течение которого объект не может выполнять требуемую функцию. В.п. складывается из времени технического обслуживания и задержки, вызванных отсутствием рабочей силы, запасных частей, топлива, комплектующих изделий и др. В.п.… … Справочник технического переводчика
единая точка отказа — SPOF (ITIL Service Design) Любая конфигурационная единица, отказ которой может вызвать инцидент, для которого не определена контрмера. Единой точкой отказа может быть как сотрудник или шаг в процессе или деятельности, так и компонент ИТ… … Справочник технического переводчика
компонент составной КЕ — (ITIL Service Transition) Конфигурационная единица, которая является частью составной КЕ. Например, КЕ «ЦПУ» или «Память» могут быть частью составной КЕ «Сервер». [Словарь терминов ITIL версия 1.0, 29 июля 2011 … Справочник технического переводчика
надёжность (в информационных технологиях) — надёжность (ITIL Continual Service Improvement) (ITIL Service Design) Мера того, как долго конфигурационная единица или ИТ услуга может выполнять согласованные функции без перерывов. Обычно измеряется как MTBF или MTBSI. Термин… … Справочник технического переводчика
основное средство — (ITIL Service Transition) Измеримый актив бинеса, который имеет длительный жизненный цикл (например, здание, земельный участок, сервер или лицензия на программное обеспечение). См. тж. сервисный актив; конфигурационная единица. [Словарь терминов… … Справочник технического переводчика
работать — Функционировать в соответствии с ожиданиями. Процесс или Конфигурационная единица работают, если выдаются Требуемые результаты. [Словарь терминов ITIL версия 1.0, 29 июля 2011 г.] EN operate To perform as expected. A process or configuration item … Справочник технического переводчика
Планирование Внедрения. Управление изменениями, активами и конфигурациями в рамках Внедрения
8.3. Управление активами и конфигурациями
Для того чтобы управлять конфигурационными единицами, их нужно определить и классифицировать. ITIL рекомендует следующие категории:
Для управления совокупностью активов Управление активами и конфигурациями ведет Систему управления конфигурациями.
Деятельности в рамках Управления активами и конфигурациями показаны на рис. 8.4.
Рассмотрим подробнее деятельности, представленные на рис. 8.4.
Управление и планирование
Не существует единого шаблона для осуществления SACM. Менеджеры каждой организации устанавливают уровень Управления конфигурациями, приемлемый для конкретного случая и то, как его можно достичь. Это отображается в Плане управления конфигурациями.
Пример содержания Плана управления активами и конфигурациями.
Применяемые политики и стандарты:
Организация Управлением конфигурациями:
Система и инструменты Управления активами и конфигурациями.
Процессы и процедуры в рамках Управления активами и конфигурациями, например:
Ссылка на План реализации
Управление и контроль необходимых связей и интерфейсов, в частности, с финансовым управлением активами и поставщиками[16].
Для идентификации конфигураций важно:
Деятельность в рамках идентификации конфигураций включает в себя:
Всем конфигурационным единицам необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать.
Атрибуты конфигурационных единиц описывают характеристики, значимые в рамках SACM. В базе данных должны содержаться атрибуты каждой конфигурационной единицы. ITIL выделяет следующие стандартные атрибуты:
Основные связи между CI:
CI может иметь множество связей. Например, быть частью другой CI и одновременно использоваться другими CI.
Контроль конфигураций предоставляет механизмы контроля для конфигураций. CI не может быть перемещена, изменена, удалена без соответствующего контроля. Процедуры и политики контроля включают в себя:
Механизмы контроля должны быть спроектированы и встроены в новую или измененную услугу на ранних этапах ее развертывания.
Выделяют следующие статусы:
Необходимо четко определить, как CI будет переходить из одного статуса в другой. Пример жизненного цикла приложения на рис. 8.5.
Учет статусов обеспечивает корректность и актуальность записей о конфигурационных единицах, активах и их состояниях. Стандартные деятельности в рамках Учета состояний:
Запись о конфигурации создается в процессе идентификации и контроля CI, рассмотренных нами выше. Она обеспечивает прозрачность и трассируемость CI для всех процессов. Стандартная запись содержит следующее:
Включает в себя набор следующих проверок:
Только авторизованные и корректные CI должны использоваться для поддержки услуг. Если в рамках проверок выявлены нарушения, они должны быть немедленно устранены, а результаты проверок отображены в соответствующих отчетах.
Как и любой другой процесс, SACM имеет свои ключевые показатели производительности. Применяются следующие метрики:
Информацию, формируемую в рамках SACM, используют все процессы в рамках жизненного цикла услуг.
Планирование Внедрения. Управление изменениями, активами и конфигурациями в рамках Внедрения
8.3. Управление активами и конфигурациями
Для того чтобы управлять конфигурационными единицами, их нужно определить и классифицировать. ITIL рекомендует следующие категории:
Для управления совокупностью активов Управление активами и конфигурациями ведет Систему управления конфигурациями.
Деятельности в рамках Управления активами и конфигурациями показаны на рис. 8.4.
Рассмотрим подробнее деятельности, представленные на рис. 8.4.
Управление и планирование
Не существует единого шаблона для осуществления SACM. Менеджеры каждой организации устанавливают уровень Управления конфигурациями, приемлемый для конкретного случая и то, как его можно достичь. Это отображается в Плане управления конфигурациями.
Пример содержания Плана управления активами и конфигурациями.
Применяемые политики и стандарты:
Организация Управлением конфигурациями:
Система и инструменты Управления активами и конфигурациями.
Процессы и процедуры в рамках Управления активами и конфигурациями, например:
Ссылка на План реализации
Управление и контроль необходимых связей и интерфейсов, в частности, с финансовым управлением активами и поставщиками[16].
Для идентификации конфигураций важно:
Деятельность в рамках идентификации конфигураций включает в себя:
Всем конфигурационным единицам необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать.
Атрибуты конфигурационных единиц описывают характеристики, значимые в рамках SACM. В базе данных должны содержаться атрибуты каждой конфигурационной единицы. ITIL выделяет следующие стандартные атрибуты:
Основные связи между CI:
CI может иметь множество связей. Например, быть частью другой CI и одновременно использоваться другими CI.
Контроль конфигураций предоставляет механизмы контроля для конфигураций. CI не может быть перемещена, изменена, удалена без соответствующего контроля. Процедуры и политики контроля включают в себя:
Механизмы контроля должны быть спроектированы и встроены в новую или измененную услугу на ранних этапах ее развертывания.
Выделяют следующие статусы:
Необходимо четко определить, как CI будет переходить из одного статуса в другой. Пример жизненного цикла приложения на рис. 8.5.
Учет статусов обеспечивает корректность и актуальность записей о конфигурационных единицах, активах и их состояниях. Стандартные деятельности в рамках Учета состояний:
Запись о конфигурации создается в процессе идентификации и контроля CI, рассмотренных нами выше. Она обеспечивает прозрачность и трассируемость CI для всех процессов. Стандартная запись содержит следующее:
Включает в себя набор следующих проверок:
Только авторизованные и корректные CI должны использоваться для поддержки услуг. Если в рамках проверок выявлены нарушения, они должны быть немедленно устранены, а результаты проверок отображены в соответствующих отчетах.
Как и любой другой процесс, SACM имеет свои ключевые показатели производительности. Применяются следующие метрики:
Информацию, формируемую в рамках SACM, используют все процессы в рамках жизненного цикла услуг.
Управление Сервисными Активами и Конфигурациями. CMDB и ITIL.
Управление Сервисными Активами и Конфигурациями (Service Asset and Configuration Management), как данный процесс правильно называется в ITIL® v3, – один из самых трудных для понимания и внедрения процессов ITIL®, во всяком случае, такая оценка следует из опросов наших слушателей.
Попробуем понять эти трудности, разобрав некоторые риски, которые сопутствуют практикам данного процесса.
Для начала (как всегда) разберемся с основными понятиями рассматриваемого процесса. В процессе Управления Сервисными Активами и Конфигурациями появились новые понятия, которых не было в ITIL® второй версии. Кратко углубимся в основные понятия, используя определения из Глоссария.
CMS также содержит информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. Может содержать данные о сотрудниках, поставщиках, местоположениях, бизнес-единицах, заказчиках и пользователях CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации о всех CI и их взаимоотношениях.
Проиллюстрируем данные положения небольшой схемой, взятой из книги Service Transition:
Из схемы и определений мы видим, что:
CMS – более широкое понятие, чем CMDB и может содержать в себе объекты, не являющиеся CI.
Речь уже идет не только о базе данных, но о целой системе взаимосвязанных между собой баз данных, инструментария, сайтов и интерфейсов, имеющих разные уровни хранения, представления и отображения.
Перечень того, что может быть CI, значительно расширен и в него могут входить как физические, так и логичекие CI, как IT, так и бизнес объекты.
Конечно же, далеко не все компании имеют такую грандиозную систему управления конфигурациями даже в мечтах, но видение ITIL® впечатляет. Итак, какие же трудности и риски ожидают людей, решивших воплотить в жизнь данный процесс, какие ошибки они чаще всего совершают? Разберем некоторые из них:
Неверно или нечетко определены цели и задачи процесса
С самого начала, еще на этапе планирования, нужно четко расставить акценты, поскольку сам процесс, структура CMS и организация взаимодействия с другими процессами или подразделениями драматически зависят от того, какие задачи должны быть решены. Возможные варианты:
Установление контроля над основными элементами ИТ инфраструктуры, определение связей как между частями ИТ инфраструктуры, так и между ними и основными бизнес сервисами для проведения критичных для бизнеса изменений
Учет ценных активов, контроль сохранности, поддержка требований по безопасности, интеграция с системами мониторинга
Оперативная и точная инвентаризация ИТ активов по запросам бухгалтерии
Лицензионный контроль ПО
Но представим себе, что мы разобрались с требуемыми задачами. Тогда нас ожидает первый подводный камень:
Подход: «собираем все данные, которые возможно», что ведет к перегрузке процесса, а также к невозможности его поддерживать
Типичная ошибка в начале строительства данного процесса: все зачарованы возможностью собрать в CMDB максимально возможное количество информации. Как следствие, ужасно напрягаются все силы, проводится тотальная инвентаризация, в базу забивается все вплоть до последней дохлой мыши и – вот оно, счастье! Но нет, счастья, как всегда, нет, потому что мало все собрать один раз, надо все это богатство поддерживать в актуальном состоянии, отображая в CMDB все изменения, реально происходящие с многочисленными CI. Поскольку об этом заранее никто не подумал и сил на поддержку не запасал, наступает быстрая деактуализация части (а если не повезет, то и большей части) данных в CMDB и как следствие – ужасное разочарование и неверие в могущество ITIL®. А вот и второй подводный камень, тесно связанный с первым:
Потеря актуальности конфигурационной информации со временем, что вызывает ошибки, а также трудности и избыточные затраты при исправлении
Управление конфигурациями – особенный процесс, метафорически напоминающий воспитание маленького ребенка: мало его родить, надо о нем постоянно заботиться и это уже навсегда. Мало не подавиться большим куском на старте, надо еще поддерживать все актуальным в ходе процесса. На практике встречаются ситуации, когда по тем или иным причинам происходит потеря актуальности данных в CMDB, поэтому важно определить факт наступления такого состояния и продумать рациональные меры по его исправлению. Самой действенной мерой выявления является аудит, то есть сверка данных CMDB и реальных CI. К сожалению, проведение аудита является дорогим удовольствием, требует привлечения дополнительных ресурсов и, как минимум, правильного определения охвата аудита. На практике чаще всего проводится выборочный аудит.
Поддержка данных в CMDB в актуальном состоянии столь же важна, как и информативность самой базы. Требования к данным в CMDB:
Они должны быть актуальными (четко отображать состояние дел в реальной инфраструктуре на текущий момент)
Они должны быть достоверными (отсутствие ошибок в самих данных)
Они должны быть востребованными (нужными потребителям CMDB)
И здесь уместно рассмотреть следующее положение, которое также требует аккуратного и продуманного подхода. Это:
Установление обоснованного уровня точности, т.е. корреляции между моделью и реальной конфигурацией
Решить данную задачу нелегко, потому что здесь нужно верно решить уравнение с несколькими неизвестными:
Определить охват CMDB – например, что будет CI, какие будут категории CI?
Поскольку с первого раза решить все правильно будет непросто, задача решается в несколько итераций. При последующих итерациях могут решаться следующие задачи:
Добавление в CMDB данных, которые были нужны потребителям, но которых не оказалось в CMDB
Удаление из CMDB данных, которые не были востребованы потребителями базы
Изменение (расширение) охвата категорий CI, например, в результате изменения политик процесса по охвату
При всех итерациях необходимо определять ресурсы, необходимые для поддержки данных CMDB в актуальном состоянии. Наличие (отсутствие) таких ресурсов является критически важным.
Выводы
Таким образом, мы видим, что рекомендации ITIL позволяют нам уберечься от типичных ошибок, и дают нам верные подходы для решения даже такой сложной задачи, как построение правильного процесса управления сервисными активами и конфигурациями.
Портал №1 по управлению цифровыми
и информационными технологиями
При проработке процесса управления конфигурациями заинтересованные лица ставят задачи, выходящие за рамки академического процесса управления конфигурациями, о котором говорится в ITIL.
Типичная задача, которую может решить процесс управления конфигурациями:
Типичная задача, которую может решить процесс управления ИТ-активами:
Получается, что понятия «конфигурационная единица» и «ИТ-актив» различны? Или всё же едины?
Комментариев: 22
Андрей Боганов
Поднят очень интересный и правильный вопрос. Постараюсь на него ответить исходя из своего проектного опыта, анализа различных мировых источников знаний и применения их на практике.
1. Понятия КЕ и ИТ-актив разные, это разные объекты упраления, иногда они могут быть между собой «синхронизированы», а иногда нет. Почему, давайте разберемся, что есть что, по сути:
КЕ — конфигурационная единица, это элемент ИТ инфраструктуры используемый для предоставления ИТ сервиса.
ИТ-актив — это конкретный ИТ ресурс (который может включать спосоности ИТ персонала), стоящий денежных средств, предназначенный для предоставления ценности основной деятельности организации (с учетом всех этапов своего жизненного цикла).
При этом, у каждого понятия свой «жизненный цикл», приведу примеры:
ЖЦ КЕ — Ввод в эксплуатацию, эксплуатация, вывод
ЖЦ ИТ-актива — Планирование создания, закупка/разработка, ввод в эксплуатацию, эксплуатация, вывод из эксплуатации, утилизация/перепродажа.
При этом, с каждым этапом ЖЦ могут быть связаны свои специфические финансовые расходы, а могут и не быть вообще.
Приведу примеры случаев, когда понятия ИТ-актив и КЕ «синхронизируются» на разных фазах ЖЦ, а когда плохо или совсем никак:
КЕ НЕ = ИТ-актива, например: «Виртуальная машина 1,2. N (КЕ)» и сам «Сервер виртуализации (актив)»
ИТ-актив НЕ = КЕ, например: «Лицензия на ПО (актив)» и «конкретная инсталляция ПО (КЕ)»
Или «Партия флэшек» стоит средств, а каждая как КЕ не нужна.
Да, иногда на фазе ЖЦ «Эксплуатация» эти объекты (КЕ и ИТ-актив) могут синхронизироваться, но важно понимать, что это разные объекты управления с разным ЖЦ, разными сопутствующими данными и акцентами. КЕ — акцент в функциональные возможности для предоставления ИТ-сервисов при экусплуатации, а ИТ-актив — акцент на затраты и финансовое влияние на всех фазах своего ЖЦ.
ITAM/ITSM процессный архитектор.
Дмитрий Исайченко
КЕ — конфигурационная единица, это элемент ИТ инфраструктуры используемый для предоставления ИТ сервиса.
На мой взгляд, это очень спорное определение. Например, услуги третьих сторон вряд ли корректно считать частью нашей ИТ-инфраструктуры. Однако же они часто весьма разумно учитываются как конфигурационные единицы, поскольку требуют управления и влияют на предоставляемые нами ИТ-услуги.
Андрей Боганов
хорошо, давайте возьмём определение их ITIL:
«Конфигурационная Единица (КЕ) — Любой компонент или другой сервисный актив, которым необходимо управлять для того, чтобы предоставлять ИТ- услугу.»
Дмитрий Исайченко
В своём ответе я выразил несогласие с логической связкой «CI — это элемент инфраструктры. «, представленной в Вашем определении. Внешний сервис — это просто наглядный пример, иллюстрирующий некорректность такого определения, не более того.
методологически и по сути «КЕ» и «Внешний сервис» — это понятия разного уровня
А вот это утверждение мне кажется или непоняным или не очень обоснованным. Например, канал передачи данных между двумя площадками довольно часто по сути есть услуга внешней стороны (интернет-провайдера). Поясните, пжл, почему канал передачи данных — это «понятие другого уровня» по отношению к CI.
Андрей Боганов
в своём комментарии я имел виду, что понятия «КЕ» и «сервис» — это понятия разного уровня. Конечно предоставление «сервиса» может базироваться на наборе «КЕ», но оно значительно шире перечня участвующих «КЕ» (+ время предоставления, условия предоставления и пр. ). Конечно, для упрощения автоматизации и учёта используемых объектов (в том числе и сторонних), участвующих в предоставлении нашего сервиса можно назвать простой внешний сервис типа «канала передачи», как «КЕ». Вопрос конкретной реализации. Спорить не буду.
Дмитрий Исайченко
Впрочем, прошу прощения: отождествлять канал с услугой в данном случае не очень корректно. Канал — есть ресурс, услуга — есть предоставление и обеспечение работоспособности ресурса.
ОК, заменим пример. Рассмотрим внутренний нормативный документ. Может такой документ быть логично представлен в виде CI? При наличии соответствующих задач учета — да. Корректно ли считать нормативный документ частью ИТ-инфраструктуры? Хм, все, конечно, зависит от определения ИТ-инфраструктуры, но по-моему это все же довольно странно. Не согласны?
Андрей Боганов
Согласен, то определение, которое я дал изначально Уже того, что можно рассматривать как КЕ. Я просто хотел акцентировать внимание на элементах инфраструктуры и показать разницу понятий КЕ и ИТ-актив на примерах. Замечание принимается. Скажем, с учётом обозначенной коррекции:
Владимир Максимов
Возвращаясь к нашему с тобой спору о том, являются ли способности персонала ИТ-активом.
«ЖЦ ИТ-актива — Планирование создания, закупка/разработка, ввод в эксплуатацию, эксплуатация, вывод из эксплуатации, утилизация/перепродажа. «
И совершенно неприменимо к «способностям» и т.п.
Андрей Боганов
если посмотреть внимательнее на мою запись, то перед этим идет фраза «у каждого понятия свой «жизненный цикл», приведу примеры: » — т е это примеры ЖЦ. ИТ-актив штука сложная. Если сказать по сути, по простому, это совокупность железа, ПО и человеческих способностей/возможностей для обеспечени работы элементов этого «ИТ-хозяйства». Поэтому, прошу рассматиривать это просто как пример ЖЦ «ИТ-железа». Способности — не трогать 🙂
Владимир Максимов
Но твое определение приводит к противоречию с IBPL, ибо те 12 процессных областей, описанных в IBPL не имеют никакого отношения к «способностям». ИТ активы — то, что было приобретено организацией и является одним из ресурсов организации, enabler-ом бизнес процессов, наряду с другими ресурсами — сотрудниками с их способностями, финансами, временем и т.п.
Андрей Боганов
Пример, сложного ИТ-актива — это «ИТ-аиатема», что это такое, по сути?
Совокуность АО (железа) + ПО + сопутствующих операционных сервисов, которые основани на профессионалных «способностях» ИТ персонала.
Жизнь и мой проектный опыт показывает, что в нашей российской действительности без «способностей» ИТ персонала, актив не живет 🙂
Андрей Боганов
Извиняюсь, в моем тексте конечно ресь идет об «ИТ-системе»
Владимир Максимов
> без «способностей» ИТ персонала, актив не живет.
то есть, не выполняет своих функций, не обеспечивает необходимый бизнес-процесс или сервис. Это так, ибо ИТ-актив — только один ИЗ ряда ресурсов, необходимых для работы определенного ИТ сервиса. Так же как и «способности» персонала, финансы, время. Но это не делает другие необходимые ресурсы активами.
Андрей Боганов
спасибо, так и есть, в тему.
Также еще хотел добавить о важности и учете аспекта «способностей». Одно из целевых назначений методологии ITAM — это обеспечение управления ИТ-финансами. И одним из важнейших факторов, влияющих на расчет «себестоимости» ИТ-активов и в конечном итоге ИТ-сервисов, является учет трудовых затрат ИТ-персонала, которые могут, в конечном итоге, определять существенно влиять на расчет стоимости ИТ-сервиса.
Дмитрий Исайченко
Вопрос «немолод», как загадка про курицу и яйцо. Приведу свой вариант ответа (внимание, ИМХО).
С точки зрения управленческого учёта в ИТ, ИТ-активы без проблем можно было бы рассматривать как подмножество конфигурационных единиц (CI). Обосную. Конфигурационая информация традиционно включает в себя пять блоков:
1. функциональный (какие функции поддерживает, что умеет);
2. эксплуатационный (кем и как используется, кем и как обслуживается);
3. материальный (где расположено, какие физические характеристики имеет);
4. контрактный (кем предоставляется и поддерживается, на каких условиях);
5. финансовый (закупочная цена и другие реквизиты закупки, балансовая стоимость, отнесение на ЦЗ, материальная ответственность, связанные затраты).
Каждый из перечисленных блоков может включать в себя как атрибуты, так и связи с другими объектами (как с другими CI, так и с объектами других типов). Сведения об ИТ-активе являются подмножеством конфигурационной информации в части пункта 5 и частично пунктов 3-4.
Но на практике ИТ-активы являются объектами не только ИТ-учета, но и общекорпоративного управленческого учета, и БНУ. И практическое удобство разделять в учетных ситемах объекты «CI» и «ИТ-актив» связанно именно с необходимостью увязывать между собой ИТ- и не-ИТ-учет ИТ-активов. Например, бухгалтерия учитывает приобретенный ПК в сборе, а ИТ-подразделение — отдельно системный блок и монитор. Или бухгалтерия ведет учёт eToken’ов партиями, а ИТ-подразделение — поштучно, поскольку поштучно отслеживает выдачу пользователям. И так далее.
Таким образом, если подняться на уровень повыше (не реализации, а методологии), то получается следующее: разделение CI и ИТ-активов является следствием того, что понятие «ИТ-актив» является пересечением двух разных множеств — CI и корпоративных активов, у каждого из которых свои правила учета.
Андрей Боганов
в своём первоначальном комментарии я хотел подчеркнуть, что не надо смешивать и путать понятия КЕ и ИТ-актив в одну «кучу», как иногда это делают некоторые сторонники ITIL. Т. к., по сути, это разные объекты/»множества». Которые между собой по многим параметрам могут совпадать, а могут и нет. У них разное целевое назначение, разный жизненный цикл и разный набор атрибутов. И суть в том, что управлять ими надо по разному. Искусство в том, чтобы процессы управления конфигурациями и ИТ-активами «бесшовно» дополняли друг друга для комплексного решения. При этом, могут применять различные методологии и различные средства автоматизации, которые должны быть грамотно синтерированы для построения целостного решения.
Дмитрий Исайченко
Андрей, я же и не спорил. Я лишь попытался более чётко ответить на вопрос «Почему».
Андрей Боганов
спасибо, Ваш комментарий очень хорошо иллюстрировал вопрос «почему» и был в тему, отлично дополнив аспектом уравленческого учета!
Олег Скрынник
Ну вы, граждане, развернули полемику. Догадываюсь, что это не самый сложный и не самый интересный вопрос.
Желающие обсудить практику приглашаются на учебный курс «Управление ИТ-активами» 2-3 июля.
Алексей Юсов
Действительно, полемика слишком далека от народа, хотя если напрячься, можно понять, что Дмитрий и Андрей говорят оба одно и тоже — «нет, КЕ не равно ИТ-актив».
А «ветка» от Владимира приводит к мысли, что главный ИТ-актив — это люди. А люди — тоже не КЕ ))).
Андрей
«Да не согласен я, с обоими. «©
КЕ и ИТ актив — это НЕ разные объекты. Это разные наборы атрибутов одного и того же объекта. В зависимости от процесса, вам может понадобится различный набор атрибутов. Поясню на аналогии — есть человек, и для его участия в научном процессе важны параметры, отражающие уровень его образования. А для пошива одежды для него, эти параметры не имеют значения, но важны физические параметры — размеры. И бывают ситуации, когда оба набора парметров важны — научная деятельность в космосе, на пример.
Вы можете работать с КЕ и ИТ активами отдельно, но по мере роста зрелости ваших процессов, вам придется в определенный момент эти разные наборы атрибутов одного и того же объекта свести вместе. Поизойдет это когда вы начнете рассматривать своё ИТ подразделение в качестве производственного, производящего продукцию — ИТ услуги. И как для любого произвожственного подразделения вопросы себестоимости продукции станут, в ряде случаев, определяющими.
Андрей Боганов
Благодарю за конструктивный комментарий!
По сути, речь идет об объектах ИТ-инфраструктуры, но мы смотрим на них «разными глазами», поэтому и видеть должны «разные атрибуты» и в разные этапы «жизненного цикла». В моем проектном опыте есть случаю как «отдельного» внедрения, так и случаи «комплексного» внедрения процесса «управления ИТ-активами и конфигурациями», где нужно было учитывать разные наборы атрибутов и разные этапы ЖЦ. При этом, была одна система автоматизации и в ней все учитывалось в едином объекте учета. Все зависит от постановки задачи, «чем нужно управлять и чем это будет обеспечено (организационно и технически)?»