Вот ещё пример: корпоративный самолёт при правильном подходе может, наверное, оправдать связанные с ним инвестиции. Будет ли это оптимальным способом потратить деньги с учётом других вариантов - отдельный вопрос.
Надо сказать, что так рассуждает меньшинство, но всё же не только автор этой книги. С CMDB связано много споров . Дополнительную информацию по теме можно найти на сайте Owning ITIL.
CMDB как ERP для IT.
Есть мнение, что CMDB объединяет всю-всю информацию об ИТ так же, как ERP объединяют всю-всю информацию о предприятии в целом.
Вопрос о полезности ERP - отдельная интересная тема. Есть множество примеров, когда ERP привели компании на грань краха или перевели через эту грань. Автор не знает ни одного проекта, в котором ERP оправдали бы сделанное бизнес-обоснование.
Хотя, конечно, есть организации, которые достаточно велики, широко распределены и безумны для того, чтобы инвестиции в ERP себя оправдали.
Но утверждать на этом основании, что инвестиции в CMDB тоже себя оправдают, - это всё равно что утверждать, будто бы использование тяжелой транспортной авиации компанией DHL для доставки грузов автоматически оправдывает использование тех же самолетов для доставки молока в столовую компании DHL. То, что организация управляется при помощи супердорогого чуда техники, ещё не значит, что такое же чудо должно управлять объектами ИТинфраструктуры.
ITIL убеждает нас, что нам нужен А380, в то время как денег у нас как раз достаточно для покупки ручной тачки. С ней мы идём на крышу и пытаемся полететь. Результат нетрудно предвидеть.
Жизнь без CMDB.
Многочисленные ERP, базы данных, словари данных, хранилища, каталоги не преуспели в деле унификации среды, в которой мы существуем. CMDB тоже не справится (а равно Web Services, SOA, .NET...). Очнитесь и прекратите изобретать магическую систему для управления всем на свете. Давайте позволим нашим данным пребывать в неполном порядке. Давайте отойдем от принципа «всё должно быть полным и корректным». Можно жить и без CMDB...
...и отлично себя чувствовать. Статистически управление конфигурациями - один из самых редко внедряемых процессов. Одно исследование, проведенное в 2008 году
, показало, что 30% крупных организаций (то есть тех, что могут позволить себе CMDB) утверждают, что у них есть что- то, что они так называют. Скептик оценивает долю организаций, использующих СМОВ-какэто-понимает-ITIL как 2%-5%. Возникает вопрос: а как остальные справляются?.
Управление инцидентами / проблемами / изменениями чудно довольствуется базой активов. И не так уж важно, что управление релизами, доступностью или непрерывностью использует другие источники информации. Перфекционисты считают, что источник информации должен быть общий, но если это правило нарушается, ничего особенно страшного не происходит.
Здорово, если удается хранить базовую информацию о зависимостях между ключевыми КЕ
и услугами. Опыт показывает, что большинству организаций неплохо удается вручную поддерживать эти связи в порядке для пары- тройки десятков услуг. Всего услуг немного больше.
- обычно в несколько раз. И люди просто выбирают наиболее важные для того, чтобы вести учёт связей. Что происходит с остальными? Они просто работают. Как всегда это делали. И если надо, анализируются «на лету». И это помогает.
Пока вам не нужно управлять конфигурациями на уровне зрелости выше третьего, вы можете делать это без CMDB. Многие так поступают. У вас может быть реестр активов, средства удаленной диагностики и управления, система управления закупками и даже каталог услуг. И не быть CMDB в понимании ITIL.
С другой стороны, если вы NASA, или Boeing, или Tata, или EDS, не обращайте на меня внимания. Вы ищете пятого уровня зрелости, и для большинства процессов это потребует CMDB... ну или работ по её созданию. Скептик по-прежнему сомневается, что эти работы закончатся построением идеальной CMDB. И будьте готовы к тому, что попытки дорого вам обойдутся.
О том, что делать со своей CMDB, читайте в главе «Ограничьте управление конфигурациями», стр. 53.
Рекомендации.
29.
Убедитесь, что управление конфигурациями использует прагматический подход, собирая необходимый минимум данных.
30.
Маловероятно, что начинать использование ITIL стоит с построения CMDB. Убедитесь, что начали с более важных вещей.
31.
Начните с каталога услуг (см. стр. 52): сформируйте его техническую версию для персонала ИТ. В этом техническом каталоге укажите ключевые КЕ, поддерживающие каждую услугу. Если персонал ИТ заслужил новую игрушку, внесите услуги в систему Service Desk и свяжите их с ключевыми КЕ. Но держите эту игрушку под строгим родительским контролем: она должна сохранять управляемость за разумные деньги. Возможно, в этот момент вы подойдёте к CMDB на максимально возможное расстояние.
На одной ITIL конференции представитель государственной структуры рассказывал мне о том, какая у них будет замечательная CMDB благодаря мудрому решению включать в неё только важное, оставляя за бортом все лишнее.
- Что лишнее, например? - спросил я.
- Например, персональные компьютеры.
- А на них нет важных приложений? - уточнил я.
Тут же выяснилось, что ключевые системы имеют архитектуру «клиент-сервер», так что компьютеры придется включить в CMDB.
- Но там не будет периферии, всяких там принтеров...
- Вот как? А какова доля обращений пользователей, связанных именно с принтерами?.
- ОК, пусть принтеры будут. Но не мышки же с клавиатурами!.
- Мммм... Вы ведь госслужба? Вам приходится прислушиваться к требованиям охраны труда и быть политкорректными? Среди ваших сотрудников есть инвалиды, которым нужны специальные устройства ввода?.
К этому времени он был бледен, потен и неприветлив.