Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах ITSM 365 Пользователи Компании Лента заказов Курс по ITSM

10 причин, по которым проваливается внедрение CMDB

10 причин, по которым проваливается внедрение CMDB

CMDB — хранилище информации, о всех ИТ-объектах компании. Идея создания всеобъемлющего централизованного хранилища информации об ИТ (CMDB) — весьма популярна. Многие берутся за проект создания CMDB, но немногое достигают успеха. Tobin Isenberg на сайте BusinessServiceManagementHub анализирует причины провалов таких проектов.

Недостаточное внимание менеджмента

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

Владельцам КЕ сложно получить доступ

Владельцем CMDB обычно является группа Управления Изменениями. В то же время Конфигурационными Единицами управляют совершенно другие сотрудники. Это нормальная ситуация, однако не тогда, когда владельцы КЕ не могут получить доступ к CMDB.

Мусор на входе — мусор на выходе

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

Недостаточная интеграция с другими решениями

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

100%  или ничего

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

Сложности с поиском

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

Слишком большое внимание к разработке концепции

Когда компания разрабатывает CMDB самостоятельно, то часто много времени уделяется разработке дизайна базы данных и планированию. Не стоит застревать на этом этапе до 2020 года.

Все и сразу

Вы планируете CMDB, а заодно сразу же Управление Изменениями, Проблемами, HelpDesk и другие модули ITIL? Вы только что отложили внедрение на 18-24 месяца, увеличили стоимость решения и уменьшили вероятность успешного внедрения каждой из систем.

Снизу вверх — неправильный подход

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

10 причина в статье осталась открытой — добавьте свою по вкусу. Например, Роб Ингланд (ИТ-скептик),  популярный ITSM-блоггер, считает, что CMDB большинству компаний не нужна вообще.

Полный текст статьи на сайте Business Service Management Hub.com

Дополнительные материалы

Комментарии (11)

  • Аватар

    Чернин Роман [rchernin], 07 февраля 2011, 14:27

    2
    Прописная истина, но основная проблема внедрения CMDB - неочевидность пользы. Редко удается четко сформулировать потребности, которые будут удовлетворены, то есть иметь четкий "заказ", кроме абстрактного "хочу все под контролем".
    Так что я бы предложил поделиться реальными кейсами, ЗАЧЕМ в итоге внедряли CMDB и КАКУЮ ПОЛЬЗУ получили.

    Из конкретных проблем странно что не упомянута следующая: часто отсутствуют отстроенные процедуры поддержания CMDB в актуальном состояние и собственно "внедрение CMDB" подменяют "Инвентаризацией".
  • Аватар

    Котельников Илья [iluha], 07 февраля 2011, 14:31

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

    Моксин Александр Евгеньевич [StFoster], 07 февраля 2011, 17:23

    1
    Если продолжить мысль. Поставщик ИТ-Услуг, точнее его процессы и положение дел могут находиться всего в двух состояниях "бардак" и "порядок".
    В состоянии "бардак" удачное внедрение CMDB невозможно по понятным причинам - CMDB слишком чувствителен к остальным процессам, его невозможно будет поддерживать, а значит и пользоваться им в состояние "бардак".
    В состоянии "порядок" компания уже в принципе имеет CMDB просто в распределенном виде, а не централизованном - первая линия не страдает от безумной ротации персонала и накопила базу знаний, отдел учета владеет полной информацией по основным средствам, включая лицензии, менеджеры владеют информацией по договорам, отдел администрирования имеет всю информацию по ключевым объектам инфраструктуры, которые меняются не так часто. Процессы отстроены так, что все знают к кому обратиться за недостающей информацией, а если предоставление информации начинает отнимать слишком много времени, её владелец в том или ином виде налаживает доступ к ней для остальных. В итоге потери от нескольких ситуаций в год, которых централизованная CMDB помогла бы избежать, в принципе на порядки ниже, чем затраты на централизацию. Итог: "Мы внедрили CMDB, потратили некоторое количество времени и ресурсов. И что изменилось? В общем-то ничего. У нас по прежнему порядок."
    • Аватар

      Бычков Валерий [vbychkov], 07 февраля 2011, 20:02

      0
      Вообще ITIL выделяет 5 уровней зрелости для существующих процессов. Первые два можно охарактеризовать, как  "бардак". А вот дальше идут:
      3 уровень стандартизированные и документированные процессы
      4 уровень управляемые и измеряемые процессы
      Как раз на 1-2 уровне зрелости CMDB ничего не даст. А вот при переходе с 3 на 4 и тем более с 4 на 5 она будет работать так, как задумывалось - для этого в компании уже будут созданы все необходимые условия.
    • Аватар

      Рубинштейн Кирилл [krubinshteyn], 08 февраля 2011, 10:53

      0
      Действительно, ситуации "распределенной" CMDB могут быть. Но может быть и так, что получить инфорацию из какого-бы то ни было кусочка не так просто, т.е. тут все "внедрение" можно свести к интеграции.

      И как вы правильно сказали -- все нужно правильно посчитать, чтобы расходы на внедрение были ниже предполагаемого эффекта.
    • Аватар

      Котельников Илья [iluha], 08 февраля 2011, 16:37

      0
      Вы все верно сказали про "бардак" и "порядок", но вот с выводами, что CMDB не принесет пользы никогда я бы поспорил.

      Если использовать единственное субъективное измерение качество предоставляемого ИТ-сервиса (причем бинарное) - "бардак\порядок", то CMDB действительно не даст измеримого эффекта - "порядок" останется "порядком",  а "бардак" будет "бардаком".

      Чтобы получить понимание результативности внедрения CMDB в ИТ-службе мало сказать, что должно улучшиться - нужно придумать измеримые параметры качества. CMDB (как и большинство стандартизаций) дает эффект на масштабах. За счет его внедрения снижаются риски, малые или редкие издержки становятся меньше и случаются реже. Отследить эти изменения вы сможете только при помощи мониторинга метрик. Получается, что наибольший эффект от такого внедрения Вы увидите при 4-ом и 5-ом уровнях зрелости.
  • Аватар

    Рубин Дмитрий Юрьевич [drubin], 07 февраля 2011, 19:59

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

    Ну, и, конечно, надо верить и видеть выгоду от внедрения процессу управления конфигурациями и CMDB в частности. Т.е. описал КЕ, связал их, сделал процедуры актуализации и что дальше? А дальше все самое интересное - управление мощностью, непрерывностью, финансами, т.е. при внедрении CMDB необходимо для себя понимать, что это построение правильного, как модно говорить, ландшафта - инвестиции, на котором в будущем можно будет снимать хороший профит. 
    • Аватар

      Юсов Алексей [alexus], 09 февраля 2011, 21:48

      0
      Любые внедрения будут эффективными, если они дают конкретный экономический эффект. Нет кленового сиропа - нет блинчиков!
      • Аватар

        Рубин Дмитрий Юрьевич [drubin], 09 февраля 2011, 21:54

        0
        Внедрение CMDB само по себе к сожалению не даст прозрачного экономического эффекта. А вот управление мощностями, которое можно будет построить на созданной ранее CMDB, уже такой эффект даст может. Самый простой пример - аналитика загруженности различных участков инфраструктуры и соответственно более эффективное ее использование, т.е. отсутствие избыточности ,а это уже явная экономия.
        • Аватар

          Юсов Алексей [alexus], 09 февраля 2011, 22:08

          0
          Ну если эта "явная" (сколько конкретно в граммах/ваттах/у.е.?) экономия окупает затраты на внедрение CMDB+CapM, то это будет суперуспешный проект! И премию дадут!
  • Аватар

    Парфирьев Владислав [Vlad], 15 февраля 2011, 09:53

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

Также рекомендуем