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

Учет активов и управление конфигурациями

Опубликовано 1 февраля 2011
Рубрики: CMDB, конфигурации и активы, ITSM, Обо всём на свете
Комментарии

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

На курсе, как всегда, была дискуссия о том, можно ли совместить управление конфигурациями и управление активами в едином процессе и получить пользу сразу в двух направлениях:

1. Получить информацию полезную для оценки влияния элементов инфраструктуры друг на друга (для оценки влияния инцидентов, изменений и т.д.)

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

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

Единственное, что мне кажется допустимым, это единая система хранения информации.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление изменениями и конфигурациями в ИТ
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Также по теме:

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

  • Анатолий Павлюченко

    Для тех, кто начинал с ITIL V2, логичнее выглядит разделение управления конфигурациями и управления активами. Третья версия формулирует цели для этого процесса таким образом, что получение указанной пользы отходит на второй план. На первый план выходит ускорение принятия решений.
    Для практика понятно, что достичь таких целей “сходу” не получится и требуется постепенное наращивание функциональности и слаженности всех веток управления.
    Так что, на мой взгляд, 1) нужно разделять на этапе внедрения и 2) в результате (сложно сказать когда) должен получиться единый процесс.

    • Евгений Шилов

      Т.е. Вы предлагаете менять сам процесс с течением времени? Изначально проектируем как управление конфигурациями, потом плавно размываем до управления конфигурациями и активами?

  • Анатолий Павлюченко

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

    • Евгений Шилов

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

      • Анатолий Павлюченко

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

        Вариант, при котором сразу вовлекается не ИТ люди, подразумевает изначальную ответственность “вне ИТ”, т.е. и управлять проектом будет не ИТ.

        • Евгений Шилов

          “Вариант, при котором сразу вовлекается не ИТ люди, подразумевает изначальную ответственность «вне ИТ», т.е. и управлять проектом будет не ИТ.”

          Не обязательно, мы можем ориентироваться на существующие бизнес-процессы. Можем предъявлять к ним требования. При этом проект останется “ИТшным”.

          • Анатолий Павлюченко

            “можем ориентироваться на существующие бизнес-процессы. Можем предъявлять к ним требования.” А теперь скажите это CFO “в глаза”.
            Могу почти со 100%-ой уверенностью воспроизвести его ответ: “Да, вы много чего _можете_. Но делать будем так, как я скажу.”
            Конечно, необходимость работы с процессом управления конфигурациями и активами подразумевает достаточно высокую зрелость организации. Но, с другой стороны, это также подразумевает и высокую ответственность за принятия решений. _Нормальный_ финансовый директор никогда не делегирует “свою” ответственность за пределы своего отдела даже в рамках проекта.

            Можно ещё пообсуждать межфункциональные проекты, но аксиома такова CFO>CIO

            • Евгений Шилов

              “_Нормальный_ финансовый директор никогда не делегирует «свою» ответственность за пределы своего отдела даже в рамках проекта.”

              Прекрасно, пусть отвечает. Внедрение процесса управления активами, отчасти может быть вызвано как раз его требованиями. Поэтому отвечая на запрос CFO, мы готовы заниматься активами, однако для этого нам от вас надо: 1.,2.,3…., будьте добры обеспечить.
              Если деятельность связанная, например, с закупками, вне ИТ, то иначе как запросить данные у бизнеса мы не сможем. Если бизнес не готов на взаимодействие, то чудес не бывает, обращаться к нам с вопросами, опирающимися на информацию, которой у нас нет, бесполезно.

              • Анатолий Павлюченко

                “отвечая на запрос CFO” – это и есть “Вариант, при котором сразу вовлекается не ИТ люди”.

                А так, да, эту часть мы можем называть “ИТшным” проектом.

  • Роман Журавлёв

    …что позволит нам в перспективе десяти-двенадцати лет реализовать описанную в ITIL Bottomless Knowledge Management System, а на ее основе – извечную мечту всех айтишников “вся информация – в одном месте”.
    Мне кажется, очень мало шансов пройти этот путь до конца. С точки зрения принятия решений мне кажется более реалистичной крамольная идея Скептика об “управлении конфигурациями без CMDB”. http://www.realitsm.ru/2010/10/upravlenie-konfiguraciyami-ne-veshh-a-praktika/

    • Анатолий Павлюченко

      … кстати, “вся информация – в одном месте” – это не только айтишников мечта.

      Вот когда Скетик освободит ITIL и сделает свою V4, тогда и посмотрим, какую “вещь” он предложит в качестве замены CMDB 😉

      • Евгений Шилов

        На самом деле, мечта звучит так: “Хочу чтобы вся информация была под рукой”. А одно это будет место или два, между которыми настроена интеграция, позволяющая легко получить доступ ко второй части, это может быть уже неважно.

  • Олег Скрынник

    Третий ITIL в этом вопросе, как и во многих других, весьма забавен. У читателя главы “Service Asset and Configuration Management” из книжки “Service Transition”, знакомого с текстом ITIL v2, может сложиться ощущение, что авторы ITIL v3 сильно не заморачивались и просто везде, где встречается слово configuration или словосочетание configuration item, добавили рядышком слово asset.

    В частности, если в начале главы делается попытка расширить цели этого обновлённого процесса так, чтобы что-то сказать про активы, то по мере продвижения к концу главы упоминания активов становятся всё более редки… А раздел “4.3.5.1. SACM Activities” содержит блок-схему видов деятельности, знакомых нам по ITIL v2, без всяких там активов. И хоть раздел называется “ASSET and configuration activities”, подпись под означенной схемой гласит “Typical CONFIGURATION management activity model”.

    Получается, что ITIL v3 в части учёта активов говорит мало полезного. Разве что декларации о необходимости эти сервисные активы всячески оптимизировать.

  • Роман Журавлёв

    ну так оно много где… “старые” процессы SD (Service Design – ex-Delivery) практически скопированы из v2 и от этого мало связаны с первыми главами книги (SD Principles и т.п.) и вообще с “проектированием”. Они исключительно про “предоставление”.

    Впрочем, это, наверное, тема для отдельной дискуссии.

  • Павел Солопов

    “Слишком уж разные источники информации, триггеры обновления информации.”

    Сначала стоит определиться с понятиями Актив и КЕ, точнее даже со свойсвами, которыми мы их наделяем.
    Если Актив, это исключительно финансовая информация, то Вы абсолютно правы. если же под активом мы понимаем и некоторые другие свойсва физического объекта, такие как его местоположение, состояние, функциональность, то получается, что и для управления активами нам необходима информация из управления изменениями. Попробую пояснить на примере некоего сервера:
    О его приобретении (стоимость, срок службы, возможно что-то ещё) мы узнаём от бухгалтерии.
    Затем мы его внедряем в инфраструктуры для выполнения какой-то роли, т.е. у него появляется местоположение, он в соответствии со своей ролью прикрепряется к какому-то подразделению и т.д. Эту информацию нам даст управление изменениями (может дать).
    Затем мы проводим его модернизацию, добавляем, например, память. Соответсвенно его стоимость должна увеличиться, изменится его функциональность. Информация о том, что добавлена память мы опять узнаём из изменений.
    Затем мы меняем ПО установленное на нём (например на менее важное, в виду морального износа) и сервер перерпрекрепляется к другому подразделению (которое использует новое ПО), соответственно эта информация также будет получена из управления изменениями.
    И т.д.

  • Андрей Волков

    С одной стороны идея убрать дублирование информации, с другой то, что в CMDB без особого разрешения ничего невозможно изменить. Мне кажется, что вот из-за этого дисбаланса мнения расходятся. ITIL не даёт конкретных рекомендаций “длина пароля 8 символов, менять раз в 45 дней”, поэтому мне кажется, что оба варианта верны.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.