Тома Библиотеки: о чем они?

В Библиотеке рассматривается много разнообразных управленческих

процессов, правила их построения, организация их

функционирования и взаимодействия. Для иллюстрации реальной

ситуации рассмотрим жизненный цикл инцидента -

последовательность действий клиента и службы поддержки при

возникновении какой-нибудь нестандартной ситуации в ходе

пользования сервисом:

l клиент связывается с Service Desk - диспетчерской службой,

ответственной за общение с клиентами по всем возникающим

у них вопросам и проблемам и сообщает о проблеме;

l устанавливается связь инцидента с процессом "Управления

инцидентами";

l инцидент учитывается в процессе "Управления проблемами";

при дальнейшем анализе возможны обращения к процессам

"Управления возможностями" и "Управления уровнями

сервиса";

l инициируется процесс "Управления изменениями" для

координации внесения изменений;

l процесс "Управления ИТ-финансами" производит оценку

стоимостей с точки зрения бизнеса;

l процесс "Управление непрерывностью сервисов" участвует в

формировании требуемых изменений для учета возможностей

возврата к предыдущему состоянию при неудачном изменении

и для обеспечения непрерывности предоставления услуг;

l внесение изменений контролируется процессом "Управления

внедрением", несущим ответственность в том числе и за учет

всех произведенных изменений "Управлением

конфигурациями" (предоставляя всю необходимую для этого

информацию);

l процесс "Управление доступностью" обязательно должен

произвести со своей стороны оценку изменений в

оборудовании и программном обеспечении;

l процесс "Управление конфигурациями" должен зафиксировать

действующее состояние (для возможности возврата) и новую

конфигурацию в Базе данных конфигурационных единиц

(CMDB);

l процесс "Управления взаимоотношением с клиентами" должен

поддерживать связь с клиентом для его полного и

своевременного информирования о прогрессе в разрешении

его проблемы.

Как видно, все процессы находятся в тесном, порой нелинейном

взаимодействии и если попытаться реализовать какой-нибудь один

(или несколько), эффект может не оправдать надежд и скорее

послужит основанием для отрицания идеи в целом. Для исключения

этого предлагается одновременно внедрять все процессы, но не с максимальной полнотой, а на достижимом в реальной ситуации

уровне. В любом случае, даже если нет возможности реализовать

процесс, его необходимо обязательно обозначить (и тем самым

отнести его реализацию на будущие этапы внедрения системы).

Например, можно отметить необходимость организации процессов

"Управление непрерывностью предоставления сервисов" и

"Управления ИТ-финансами" как отдельных, но на какое то время

поручить их реализацию соответственно руководителю всего бизнеса

(управление непрерывностью) и финансовому директору (управление

ИТ-финансами). Понятно, что эти менеджеры в большей степени

ориентированы на несколько иные проблемы, но при определенных

условиях их деятельности может быть вполне достаточно и для

управления ИТ-сервисами.

Нельзя не отметить еще один важный принцип ITIL - отношение к

тем, кто использует в своих целях услуги ИТ. Кто они: пользователи

или потребители? Разница между в следующем: пользователь как

правило использует то, что ему дают и не имеет возможности

попросить то, что ему реально необходимо. Потребитель сам вправе

выбирать и формулировать свои потребности, заключать соглашение

о необходимых уровнях сервисов и требовать их соблюдения. При

рассмотрении всех (и внутренних, и если есть-внешних) клиентов ИТ-

подразделения как потребителей достигается дополнительные

полезные результаты - возможность полного учета реальных

стоимостей услуг и построение универсальной, прозрачной для

контроля, системы управления (не зависящей от конкретного

клиента).

Тем не менее, в томах Библиотеки используется понятие "User" для

выделения в отдельную группу всех, кто использует услуги, и в

другую группу (Customer) - тех, кто фактически заказывает услуги и

платит за них (как правило, высшее руководство соответствующих

подразделений и организаций - клиентов). Отношение к таким

"пользователям" должно быть именно как к "потребителям".

CMDB

CMDB - это централизованное хранилище информации обо всех объектах, управляемых ITIL, и связях между ними. CMDB описывается ITIL, начиная с самой первой версии. Из ITIL 2 было непонятно, является ли CMDB единым физическим хранилищем. В ITIL 3 явно сказано, что не является, кроме тех мест в тексте, где это по-прежнему непонятно. Оценивая любые предложения по внедрению ITIL тщательно изучите планы по развитию CMDB. Скептик настаивает на том, что создать на практике CMDB, описанную в ITIL, за разумные деньги невозможно. Такая работа потребует огромных ресурсов и как следствие - огромных и неоправданных затрат. Те организации, которые стремятся поднять зрелость управления конфигурациями до четвёртого или пятого уровня, вероятно, попытаются проделать эту работу. Остальные остановятся на этапе обоснования затрат. Вот ещё пример: корпоративный самолёт при правильном подходе может, наверное, оправдать связанные с ним инвестиции. Будет ли это оптимальным способом потратить деньги с учётом других вариантов - отдельный вопрос. Надо сказать, что так рассуждает меньшинство. С CMDB связано много споров.

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. И будьте готовы к тому, что попытки дорого вам обойдутся.