Остерегайтесь предложений, содержащих слова «внедрение ITIL», или «запуск управления инцидентами», или «применение управления изменениями». Они могут указывать на некорректное, ограниченное понимание ITIL (впрочем, каждый хоть иногда, но использует подобные формулировки). Вы не внедряете процессы, а улучшаете

их (см. далее замечания о том, почему такие проекты лучше рассматривать как трансформацию, а не внедрение).

Все и так управляют инцидентами. Вопрос в том, насколько хорошо они это делают. Для ответа на этот вопрос обычно используется модель зрелости СММ, от первого до пятого уровня. Если кто-то говорит, что у него нет процесса, процесс есть - просто на первом уровне

Непросто найти хорошие метрики для измерения эффективности ITIL.

Распространенное решение - оценивать её на основе измерения зрелости. Как мы отмечали в главе «Культ ITIL», стр. 23, это может привести к формированию цикла: следование ITIL повышает уровень следования ITIL.

Успех определяется в терминах ITIL, так что внедрение ITIL наверняка приведет к повышению зрелости с точки зрения ITIL. Этот факт не означает, что деньги были потрачены не зря, и не помогает это оценить.

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

Возможно, одна из самых печальных картин в мире ITIL - организации, внедряющие процессы из книг в то время как их собственные процессы отлично работали.

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

Если я решаю тратить собственные деньги на изменение внешнего вида своего собственного дома, это моё право: деньги-то мои. Деньги, на которые внедряется ITIL, не мои. Можно сорвать отличный ковёр с целью тщательной полировки пола под ним. Очень занимательно, но вполне бесполезно. Таковы многие проекты по внедрению ITIL.

CMDB - это централизованное хранилище информации обо всех объектах, управляемых ITIL, и связях между ними. CMDB описывается ITIL, начиная с самой первой версии. Из ITIL2 было непонятно, является ли CMDB единым физическим хранилищем. В ITIL3 явно сказано, что не является, кроме тех мест в тексте, где это по-прежнему непонятно.

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

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

• Любовь. Метод требует совершенно неприемлемых ресурсов от вендора, и потому применяется лишь в отношении двух-трёх перекормленных заказчиков.

• Игра на честолюбии. Заказчика надо сделать героем. Напечатать его лицо в цветном журнале, лучше на обложке. Подарить этот номер журнала, вставленный в рамочку.

Если ваша организация уже использует RUP, SDLC, Agile, СММ, PMI, COBIT, 6Sigma, TQM или что-то в этом роде, убедитесь, что в ITIL-проекте запланировано привлечение экспертов из этих областей для того, чтобы обеспечить интеграцию 1TIL с ними. Учитывайте, что в ITIL не описаны интерфейсы к этим подходам, а кое-где между ними возникают противоречия.

Даже ITIL3 всё ещё не вполне обеспечивает интеграцию с ISO 20000, часто вульгарно именуемым «Стандарт ITIL», не говоря уж о прочих подходах и методологиях (см. «Стандарт», стр. 13).

Как мы выяснили (см. «Не ждите доказательств», стр. 26), не существует достоверных свидетельств преимуществ ITIL в деле улучшения процессов управления ИТ по сравнению с другими подходами.

Вы можете успешно оптимизировать свои процессы применяя вместо ITIL астрологию. Процессы всегда улучшаются, если уделять им достаточно внимания. Разница между ITIL и плацебо пока не исследована.

В большинстве случаев в пользу ITIL говорит статус стандарта де-факто. Но не делайте это единственным фактором, влияющим на ваш выбор.

Возможно, это для всех очевидно, но всё же: есть такой смешной способ обосновывать внедрение ITIL. Собственно, в нём нет специфики ITIL, он довольно универсален. Выглядит это примерно так:.

«Простой систем в прошлом году привел к потере компанией 185 миллионов долларов. Общее время простоя составило 83 часа, то есть каждая минута простоя обошлась компании в 37 тысяч долларов. Среднее время восстановления для инцидентов первого приоритета составляет около 150 минут. Согласно данным из презентации на конференции, где был кто-то из моих знакомых, внедрение ITIL обеспечивает сокращение времени восстановления на 10%. В прошлом году у нас было 22 инцидента первого приоритета, поэтому ожидаемое сокращение потерь для бизнеса в результате внедрения ITIL составит 22 х 150 х 0.1 х $37,000 = $12,000,000 в год при затратах на внедрение всего в $ 7,000,000, которые окупятся за 7 месяцев».

Тонкая грань между этими понятиями - в том, какие именно услуги предоставляются организации (или какие услуги она хочет, чтобы ей предоставлялись).

Помните ASP (Application Service Provider)? Сейчас их модно называть SaaS (Software as a Service). В конце девяностых они должны были полностью изменить современный бизнес. Не изменили, хотя некоторые интересные примеры успеха в этой области есть: SalesForce.com и ... э ... ну... SalesForce.com.

На самом деле, есть, конечно, ещё несколько примеров, в том числе - связанных с ITIL. Самый известный - service-now.com, онлайн Service Desk.

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

Основные продукты ITIL-проекта - это документы, средства автоматизации, коммуникации, мероприятия, а иногда - организационные структуры и роли.

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