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

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

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

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

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

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

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

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

    Для практика понятно, что достичь таких целей «сходу» не получится и требуется постепенное наращивание функциональности и слаженности всех веток управления.

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

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

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

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

    В качестве конечной цели указываем «вспомогательный механизм системы принятия решений путём управления конфигурациями и активами»

    • Подход «проектируем-запускаем-корректируем-запускаем- ...» в данном случае может привести к тому, что придется на каждом этапе «проектируем» сильно пересматривать, то что было сделано ранее.

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

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

      Мне кажется, что это тупиковый путь...

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

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

        Это медленно, да, но это не тупик 🙂

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

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

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

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

            «можем ориентироваться на существующие бизнес-процессы. Можем предъявлять к ним требования.» А теперь скажите это CFO «в глаза».

            Могу почти со 100%-ой уверенностью воспроизвести его ответ: «Да, вы много чего _можете_. Но делать будем так, как я скажу.»

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

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

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

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

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

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

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

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

  • ...что позволит нам в перспективе десяти-двенадцати лет реализовать описанную в ITIL Bottomless Knowledge Management System, а на ее основе — извечную мечту всех айтишников «вся информация — в одном месте».

    Мне кажется, очень мало шансов пройти этот путь до конца. С точки зрения принятия решений мне кажется более реалистичной крамольная идея Скептика об «управлении конфигурациями без CMDB». www.realitsm.ru/2010/10/u...eshh-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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT