Главная Обратная связь

Дисциплины:






CMDB как ERP для IТ



Есть мнение, что CMDB объединяет всю-всю информацию об ИТ так же, как ERP объединяют всю-всю информацию о предприятии в целом. Вопрос о полезности ERP - отдельная интересная тема. Есть множество примеров, когда ERP привели компании на грань краха или перевели через эту грань.

Хотя, конечно, есть организации, которые достаточно велики, широко распределены и безумны для того, чтобы инвестиции в ERP себя оправдали.

Но утверждать на этом основании, что инвестиции в CMDB тоже себя оправдают, - это всё равно что утверждать, будто бы использование тяжелой транспортной авиации компанией DHL для доставки грузов автоматически оправдывает использование тех же самолетов для доставки молока в столовую компании DHL. То, что организация управляется при помощи супердорогого чуда техники, ещё не значит, что такое же чудо должно управлять объектами ИТ инфраструктуры.

ITIL убеждает нас, что нам нужен А380, в то время как денег у нас как раз достаточно для покупки ручной тачки. С ней мы идём на крышу и пытемсяя полететь. Результат нетрудно предвидеть. Многочисленные ERP, базы данных, словари данных, хранилища, каталоги не преуспели в деле

унификации среды, в которой мы существуем. CMDB тоже не справится (а равно Web Services, SOA, .NET .. ). Очнитесь и прекратите изобретать магическую систему для управления всем на свете. Давайте позволим нашим данным пребывать в неполном порядке. Давайте отойдем от принципа «всё должно быть полным и корректным». Можно жить и без CMDB ...... и отлично себя чувствовать. Статистически управление конфигурациями - один из самых редко внедряемых процессов. Одно исследование, проведенное в 2008 году!, по казало, что 30% крупных организаций (то есть тех, что могут позволить себе CMDB) утверждают, что у них есть что- то, что они так называют. Скептик оценивает долю организаций, использующих СМОВ-как это-понимает-ITIL как 2%-5%. Возникает вопрос: а как остальные справляются? Управление инцидентами / проблемами / изменениями чудно довольствуется базой активов. И не так уж важно, что управление релизами, доступностью или непрерывностью использует другие источники информации. Перфекционисты считают, что источник информации должен быть общий, но если это правило нарушается, ничего особенно страшного не происходит. Здорово, если удается хранить базовую информацию о зависимостях между ключевыми КЕ2 и услугами. опыт показывает, что большинству организаций неплохо удается вручную поддерживать эти связи в порядке для пары- тройки десятков услуг. Всего услуг немного больше

- обычно в несколько раз. И люди просто выбирают наиболее важные для того, чтобы вести учёт связей. Что происходит с остальными? Они просто работают. Как всегда это делали. И если надо, анализируются «на лету». И это помогает. Пока вам не нужно управлять конфигурациями на уровне зрелости выше третьего, вы можете делать это без CMDB. Многие так поступают. У вас может быть реестр активов, средства удаленной диагностики и управления, система управления закупками и даже каталог услуг. И не быть CMDB в понимании ITIL. С другой стороны, если вы NASA, или Boeing, или Tata, или EDS, не обращайте на меня внимания. Вы ищете пятого уровня зрелости, и для большинства процессов это потребует

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





sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...