Что следует знать о термине «Соответствие ITIL-у»

Компании OGC и itSMF разочаровали своих клиентов, проигнорировав задачу соответствия продуктов, пишет ИТ Скептик для ITSM Watch.

Как-то так получается, что у каждого вендора есть ITIL. И большинство рабочих инструментов провозглашаются поддерживающими или соответствующими ITIL. Совсем недавно один из вендоров заявил, что они вот-вот получат «Сертификат ITIL», никак не меньше.

Меня раздражают те, кто использует термины ITIL, чтобы выделить характеристики своего продукта; в разной степени согласовываясь с основным значением слова, они провозглашают: «Да! Да! Целостность ИТ! Конечно, мы соответствуем. Администратор делает архивирование».

ITIL is technology-agnostic. Вы можете делать ITIL с бумагой для записи, и пройдет совсем немного времени до того, как производитель 3M начнет рекламировать бумагу как продукцию, “ соответствующую ITIL.»

Дело в том, что вендоров начинает распирать, когда дело доходит до ITIL. Слишком легко прилепить слово «ITIL» на рабочий инструмент. Все это только обесценивает значение ITIL и вводит в заблуждение сообщество (об обесценивании терминологии см. больше на my blog).

Вы можете симпатизировать вендору (насколько можно вообще симпатизировать). Они вряд ли могут игнорировать ITIL, хотя как OGC, так и itSMF оба упустили шанс, когда игнорировали соответствие продукта. Нет сомнения, у них были причины остаться в стороне от грязного бизнеса, но они оставили нерегулируемым область, которая вопиет о каком-то контроле.

Сегодня нет формальной независимой сертификации продуктов на соответствие ITIL. Pink Elephant предоставляет коммерческую лицензионную сертификацию PinkVerify но, по моему опыту, это не является хорошим доказательством соответствия для критериев, которые последуют.

OGC уже давно осуществляет индивидуальную профессиональную сертификацию, и теперь в конце-концов ISO/IEC выпустила организационную сертификацию (стандарт 20000). У поставщиков нет иного выбора, кроме заявления своих прав, и им некуда идти за подтверждением этих прав, если они правы, кроме Pinka.

Но мне кажется, все же существуют некие очевидные критерии для обоснованного человеческого определения термина “соответствующий ITIL.» Поэтому, если вы внедряете ITIL, задайте своему потенциальному поставщику следующие вопросы об их предположительно соответствующему или поддерживающему ITIL инструменту (включая некоторые, подтвержденные Pinkом):

Кто сказал, что инструмент соответствует или поддерживает ITIL? До какого уровня зрелости и какими характеристиками? Просто потому, что они считают его соответствующим процессу «Управления сбоями» на уровне зрелости 2, мало поможет вам, если вам нужен инструмент управления сервисом, который поднял бы вас до 4-го уровня.

Сколько из их сотрудников имеют сертификаты ITIL? Может быть, главный руководитель проекта? А если нет таких, то кто из ITIL-профессионалов консультировал проект? Устройте видеоконференцию для обсуждения соответствия.

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

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

Поскольку ITIL – это все об управлении качеством, спросите своего поставщика, как их инструмент поддерживает эту практику (OOTB)? Например, как он поддерживает определение целей? Как он измеряет и формирует отчеты по улучшению? Насколько детально он внедряет цикл Деминга (Планирование, выполнение, Проверка, Ввод в эксплуатацию)?

Управление сервисом ничто без управления уровнями сервиса. Независимо от того, является ли инструмент для управления Доступностью, Мощностью, Технической поддержкой или Конфигурацией, неважно, спросите как у них обстоят дела с соглашением об уровнях сервиса и как их инструмент соответствует особенностям управления и отчетности, связанными с соглашением об уровнях сервиса.

Соглашения об уровнях сервиса – это договора, состоящие из многих пунктов. Каждый договор определяет, с кем он составлен, на какой период, кто основные контактные лица, каков вертикальный порядок эскалирования проблем. Каждый пункт может определять время отклика технической поддержки, время восстановления, процент доступности, использование ресурсов и т.п.

Проблема определения времени, в которое Инцидент должен быть определен и решен (закрыт), не является задачей Соглашения об уровнях сервиса. Это одна цель уровня сервиса, которая может быть частью Соглашения об уровнях сервиса, если ее можно определить на пользовательском уровне. Не позволяйте поставщикам переопределять условия SLA для своих собственных целей.

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

Поддерживает ли инструмент рабочий процесс? (Очень странно, если согласованный с процессом инструмент не поддерживает). Работает ли он со «стандартными» рабочими процессами ITIL workflows (детально описанными в красной и синей книгах)? Каким образом документация объясняет необходимость внедрения инструмента для поддержки процесса ITIL?

Чаще всего крупные поставщики поставляют сервисы для внедрения инструментов в окружающей среде ITIL, но проверьте заранее, что поставляется в виде программного обеспечения, а что в руководстве пользователя. Если там нет ни слова об ITIL, то имейте виду, что эти поставщики сервиса поставляют вам «кота в мешке».

Собирает ли инструмент информацию с точки зрения сервиса? Инструменты, которые не могут измерять и поставлять информацию о сервисе на языке сервиса не являются инструментами ITIL (хотя они могут обеспечивать сбор основных данных для инструментов, относящихся к ITIL).

Например, инструмент управления должен показывать текущее состояние сервиса; Сервис Деск должен показывать текущее состояние сервиса на основании инцидентов, проблем и изменений; Сервис Деск и/или инструмент SLA должен предоставлять исторический отчет о консолидированной информации о доступности и совокупную статистику по сервису.

Как много из их сотрудников или партнеров имеют сертификаты ITIL более серьезного уровня, нежели Основы ITIL? Тренинг по основам ITIL известен там, где я живу как «погружение». Это основной процесс, который должен быть пройден каждым сотрудником ИТ. It provides just enough knowledge to be dangerous (Я знаю это, будучи сам профессионалом в области Основ).

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

Крупные поставщики обычно имеют здесь преимущества. Более мелкие часто кривят душой. Or worse they have no field support at all beyond one product tech at the local distributor. ITIL – это наука о процессах, а не инструментах: вам нужны люди, искушенные в процессах, чтобы внедрить ITIL.

Специально для Сервис Десков

Are Incident and Problem and Change all separate entities? (i.e., An Incident does not morph into a Problem: it spawns a Problem.) The Incident must continue to exist (and be resolved) as a distinct entity from the Problem. Changing the type of a record from Incident to Problem is not ITIL.

Do they provide Incident Matching OOTB? Incident Matching does not mean simple keyword searching—it is a clearly-defined ITIL process. (See the Service Support manual, page 102.)

Do they support Known Error and Workarounds as entities with associated workflow OOTB? Many tools have never heard of these. Some have them as categories of Problem, which is probably okay though strictly they should be another entity spawned from the Problem. Service Desk Level 1 staff need to be able to look for Known Errors and find the Workaround.

Do they assess impact and report it meaningfully? Displaying the CMDB tree in a pretty GUI is not impact assessment.

Finally, ask around. Many ITIL professionals will have additional important criteria from their own experience. If you have one you would like to add to the list, let me know at www.itskeptic.org. I would also love to hear your stories of the responses you got to some of the questions.

The IT Skeptic is an ITIL professional and active itSMF member who, for obvious reasons, prefers to remain anonymous. More thoughts from the IT Skeptic can be found at IT Skeptic.

The IT Skeptic , 16 ноября 2006. Перевод Виталия Фролова.
URL: http://www.itsmwatch.com/itil/article.php/3644451

Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.