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

Второе дыхание управления конфигурациями

Идеи и подходы к построению управления конфигурациями, описанные в ITIL (Service Transition), понятны и симпатичны… Но почему в этой области так много проектов, реализация которых так и не привела к ожидаемому эффекту? Давайте это разберем.

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

А много ли людей, использующих информацию о конфигурациях? Разговаривая с коллегами в ИТ-организациях, я спрашивал их, какую конфигурационную информацию они использовали и когда обращались к ней в последний раз? Зачастую звучал ответ, что не использовали никакой официальной информации о конфигурациях, потому что не доверяли точности и актуальности собранных данных. Люди не пользуются этим инструментом, и называют его «базой только для записи».
Было инвестировано время, деньги в сбор и обработку информации о конфигурациях, но так и не получено абсолютно никакой практической пользы от этих инвестиций.

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

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

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

План улучшения, который я предлагаю, заключается в следующем:

  • Определите заинтересованных лиц, которые могут получать ценность от информации о конфигурациях
    Поговорите с заинтересованными лицами о том, в чем особенность их работы, и какая информация о конфигурациях поможет им работать эффективней
  • Наглядно продемонстрируйте, как информация о конфигурациях может использоваться в создании ценности для ИТ-организации и клиентов
  • Используйте эти предложения в качестве основы для пересмотра политик управления конфигурациями, чтобы управление конфигурациями фокусировалось на том, как оно будет создавать ценность
  • Перепроектируйте процесс
  • Убедитесь, что CMDB, как инструмент, обеспечивает свое предназначение
  • Разработайте коммуникационную и обучающую программу, описывающую варианты использования CMDB, чтобы помочь понять людям, как они могут использовать управление конфигурациями и в чем практическая польза от этого использования
  • Внедрите мониторинг и отчетность, опять же на основе задокументированных вариантов использования CMDB, чтобы знать, какова же ценность, обеспечиваемая процессом на самом деле

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

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

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

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

  • Павел

    Эх, вот бы кейс практический, да в деталях рассмотреть бы как кто-то реализовывал план улучшений такой.

    В булитах то всё красиво.

  • Павел

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

    И вот заинтересовать «поставщиков» не просто, то что им нужно, как правило они могут получить из своих «тулзов».


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

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

  • Рубрики

  •  
  • Авторы

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

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • 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. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT