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

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

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

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

ITIL- это технология-агностик. Вы можете делать 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.

The IT Skeptic , 16 ноября 2006. Перевод Виталия Фролова, Виктории Шаховой.
URL: http://www.itskeptic.org/

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

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