ITIL не зависит от технологий. Вы можете следовать рекомендациям ITIL, используя липкие бумажные листочки Post-it™, и если дела и дальше пойдут так, как они идут сейчас, зМ скоро будет рекламировать эти листочки как «совместимые с ITIL».
Привычка вендоров лепить слово «ITIL» на каждый продукт, хоть как-то связанный с эксплуатацией ИТ, размывает и обесценивает смысл слова «ITIL» и вводит в заблуждение потребителей.
Их (вендоров) можно понять (ну... до некоторой степени). Несмотря на бездействие OGC и itSMF, они не могут оставить ITIL без внимания.
Независимой сертификации программных продуктов на соответствие ITIL тоже не существует. Pink Elephant предлагает сертификацию PinkVerify™, но, по опыту Скептика, она не учитывает некоторых важных критериев (из числа приведённых ниже) при оценке соответствия.
OGC уже давно проводит сертификацию специалистов, а стандарт ISO 20000 дал нам и сертификационную схему для организаций. Ходят слухи о появлении в будущем и сертификации ПО на основе ISO20000. Вендорам ничего не остаётся, кроме как изобретать собственные свидетельства «соответствия» и некуда идти за подтверждением этого соответствия, кроме как в Pink Elephant.
Однако существует несколько очевидных признаков, по которым можно довольно уверенно судить о «соответствии ПО ITIL». Задайте приведённые ниже вопросы кандидатам на роль вашего поставщика ПО для ITIL, не исключая тех, что уже прошли сертификацию PinkVerify
Кто утверждает, что этот продукт соответствует ITIL? На каком основании? Какой уровень зрелости процессов он поддерживает?.
То, что кто-то считает, что система обеспечивает адекватную автоматизацию управления инцидентами на уровне зрелости «2», не очень ценно для вас, если вам нужно автоматизировать управление уровнем услуг на уровне «4».
Есть ли среди проектировщиков продукта сертифицированные сервис-менеджеры или эксперты?.
Главный архитектор сертифицирован по ITIL? Нет? Вообще никто? Тогда кто тот гуру, что их консультировал? Потребуйте возможности пообщаться с этими людьми.
Используется ли терминология ITIL (корректно!)?.
Важный плюс от следования любому общепринятому подходу или стандарту - это стандартные термины. Благодаря им поставщики, аудиторы, тренеры и временные сотрудники быстро находят общий язык. Поэтому нет ничего хорошего в том, что инциденты называются в системе как- то иначе (особенно - в том, что они называются там «проблемами», а проблемы - «сбоями»). Путаница может зайти очень далеко.
Поддерживаются ли системой процессы ITIL?.
Использовать правильные слова недостаточно. В книгах ITIL довольно внятно описаны процессы. Если система не поддерживает эти процессы (и их бесчисленные вариации, возникающие при внедрении в жизнь), то система не поддерживает ITIL. Поменять пару слов на экранных формах и сказать, что теперь мы соответствуем ITIL - это слишком просто.
Большинство серьёзных производителей ПО предлагают своим покупателям консалтинг. В этом случае посмотрите внимательно на состав предлагаемых работ. Внедрение продукта и внедрение ITIL - очень разные вещи. Иногда консультанты даже не упоминают ITIL.
Посмотрите на сайт вендора: какие там есть руководства и другие поддерживающие документы? Если ITIL в них не упоминается, вы можете быть уверены: вас пытаются провести.
Поддерживает ли система потоки работ (workflow)?.
Довольно странно, если система автоматизации процессов этого не делает. Есть ли в системе шаблоны потоков работ для процессов ITIL? Описывает ли документация к системе внедрение этих потоков?.
ITIL - про управление качеством. Как решается эта задача в системе?.
Например, как реализовано определение целей и порогов? Как формируется соответствующая отчётность? Как реализован цикл Деминга? (Примечание: практически все продукты на рынке проваливают эту часть теста.).
Позволяет ли система управлять услугами?.
Системы, которые не транслируют измерения на уровень услуг - не ITIL-системы. Что не мешает им предоставлять последним полезные данные об инфраструктуре.
Например, средства мониторинга должны показывать текущий статус услуг; система Service Desk должна показывать состояние услуг с учетом случившихся инцидентов, проблем и изменений; должна быть доступна историческая информация по услугам и параметрам их качества.
Как поддерживаются SLA?.
Управление услугами невозможно без управления уровнем услуг (SLM). Независимо от того, чем управляет предлагаемая система - доступностью, производительностью, безопасностью... узнайте как она получает информацию о содержании SLA и как участвует в мониторинге выполнения SLA.
SLA - это контракты с довольно сложной структурой. Они определяют условия предоставления услуг, ответственность сторон и параметры качества услуг. Каждому параметру соответствует целевое значение, или SLT (Service Level Target).
Договоренность о времени обработки инцидентов - это ещё не SLA. Это лишь одна из множества целей. Не позволяйте производителям ПО переопределять понятие SLA, подгоняя его под возможности своих систем
SLA - это про услуги. Это может казаться очевидным, но SLA - не про активы, и вообще ни про что другое; они - про услуги, они определяют уровни услуг. Отдельные цели в SLA могут относиться к отдельным активам; SLA- не могут.
Есть ли в команде вендора, работающей на внедрениях, специалисты с сертификацией ITIL выше уровня Foundation?.
«Основы» - это только основы. Если ваша организация достаточно велика и сложно устроена, вам, скорее всего, понадобится кто-то более сведущий, причём одной сертификации здесь мало, пригодятся ещё знания и опыт. Тем не менее, уровень их формальной подготовки как минимум говорит о серьёзности их отношения к ITIL.
Крупные вендоры обычно выигрывают по этому критерию (тем не менее, см. следующую главу, «Услуги к вашим продуктам»). Небольшие - часто хороши только на словах. Или, того хуже, у них вообще нет специалистов по внедрению, одни продавцы.
Рекомендации.
93. Ищите поставщиков, которые разбираются в ITIL, системы, которые были созданы для ITIL, и доступные ресурсы, которые помогут вам во внедрении.