Критерии СООТВЕТСТВИЯ? ITIL верификации на соответствие ITIL от IT Skeptic перевод Е.Демьяновой
31.07.2009
OGC и itSMF обманули ожидания своей аудитории, отказавшись регламентировать область верификации продуктов на соответствие ITIL [Добавление: OGC, безусловно, уже пересмотрел свою позицию в отношении данного вопроса и выпустил стандарт по верификации программного обеспечения на соответствие ITIL]. Тем не менее, существуют четкие критерии, позволяющие однозначно определить, соответствует ли продукт ITIL. В статье я приведу несколько вопросов от IT Skeptic, которые следует задать потенциальному поставщику программного инструмента для того, чтобы самостоятельно это выяснить.
ITIL не зависит от технологии. Вы можете внедрить ITIL, пользуясь одними стикерами, и, судя по сегодняшней ситуации, в самом скором времени 3Mвполне может объявить стикеры, «соответствующими ITIL». В самом деле, как только речь заходит об ITIL, поставщики начинают бить себя кулаком в грудь. Самое простое – навесить ярлык «ITIL» на операционный инструмент. Результат у этого один: обесценивание значения ITIL и введение сообщества в заблуждение.
В этой ситуации можно только посочувствовать поставщикам, если только можно проявлять сочувствие к поставщикам программного обеспечения (когда-то я и сам работал на них). Несмотря на то, что и OGC, и itSMF оставили их один на один с проблемой верификации продуктов на соответствие ITIL, решать ее им надо. У OGC и itSMF, безусловно, были веские причины не связываться с этим бизнесом, но ведь, в итоге, мы получили отсутствие контроля там, где он необходим.
На текущий момент нет формальной независимой сертификации по определению соответствия программного инструмента ITIL. Pink Elephant проводит свою сертификацию PinkVerify на коммерческой основе. Что-то мне подсказывает, что такая сертификация не может являться надежным показателем соответствия продукта критериям, которые я приведу далее [Замечу, что Pink Elephant впоследствии протестовал против использования слова «соответствие» применительно к PinkVerify. По-моему, это обычная демагогия, как и вся эта канитель по поводу использования слов «соответствие» и «верификация на соответствие»].
Уже давно OGC проводит индивидуальную профессиональную сертификацию, наконец, и ISO/IEC выпустил сертификацию для организаций (стандарт 20000). Вот поставщикам программного обеспечения и не остается ничего более, как самим объявлять свои продукты, соответствующими ITIL, и идти в Pink Elephant за подтверждением.
На мой взгляд, существуют все же очевидные, интуитивно понятные критерии определения соответствия продукта ITIL. Поэтому, если вы внедряете ITIL, задайте потенциальному поставщику следующие вопросы, чтобы выяснить, насколько их предполагаемое соответствие ITIL или соответствие программного инструмента ITIL реально, даже если это соответствие был подтверждено Pink Elephant:
- Кто говорит о том, что продукт соответствует или поддерживает ITIL? Какому уровню зрелости он соответствует и в каком объеме? Если они говорят о поддержке управления инцидентами на уровне зрелости 2, для вас это будет неактуальным, если вы хотите получить инструмент по управлению уровнем услуг, для того чтобы достичь уровня зрелости 4.
- Какое количество разработчиков их продуктов являются сертифицированными специалистами ITIL Master/Manager? Это главный архитектор продукта? Если нет, тогда, кто из сертифицированных специалистов ITIL Master оказывает им консультации при проектировании? Требуйте телефонной конференции для того, чтобы обсудить соответствие.
- Использование терминологии ITIL. Одно из преимуществ любой стандартной платформы – это использование стандартных терминов, что позволяет новому персоналу, поставщикам услуг, аудиторам, преподавателям и подрядчикам быстро знакомиться с организацией и однозначно понимать друг друга. Это ненормально, если инцидент называют как-то по-другому, особенно если инцидент называют проблемой, а проблему — ошибкой. Путаница будет бесконечной.
- Использование терминологии ITIL. Только одно использование терминологии ITIL само по себе не может свидетельствовать о поддержке ITIL. Процессы ITIL четко определены в красной и синей книгах. Если инструмент не работает в соответствии с этими процессами и не позволяет видоизменять эти процессы при внедрении, он не поддерживает ITIL. Слишком просто изменить слова на нескольких экранных формах и объявить о соответствии.
- ITIL тесно связан с управлением качеством. Каким образом это решается в «коробочном» варианте продукта? Например, как реализована поддержка определения целевых показателей? Каким образом измеряется и фиксируется улучшение с течением времени? Включена ли явным образом поддержка цикла Деминга в продукт?
- Управление услугами – ничто без управления уровнем услуг. Независимо от того, предназначен ли инструмент для управления доступностью, мощностями, службой Service Desk, конфигурациями или чем-либо еще, спросите, откуда будут браться сведения о соглашениях об уровне услуг (SLA) и как данные будут передаваться в мониторинг и отчетность по SLA?
- SLA – это контракт, состоящий из множества пунктов. В таком контракте определяют, с кем он заключается, на какой период, ключевых сотрудников, порядок вертикальной эскалации. Каждый пункт может регламентировать время реакции, время на устранение, процент доступности, производительности, использования ресурсов и т. д. Установка пороговых значений для времени реакции или закрытия не является SLA. Это только одна из целей уровня услуги, составляющая SLA, если она может быть рассчитана для каждого пользователя. Не позволяйте поставщикам подменять сам термин SLA для того, чтобы «втиснуться» в рамки продукта.
- SLA относятся к услуге. Это может показаться очевидным, но SLA не относятся к активу или чему-либо еще. Отдельная цель SLA может определяться метрикой для актива; SLA – нет.Сверху вниз: если инцидент классифицирован по услуге, как по времени работы с инцидентом определить простой актив? Каким образом узнать, что соглашение об уровне сервиса может быть нарушено?
Снизу вверх: если сервер или сетевое устройство не работает, как определить услугу, на которую это окажет влияние? Как свести и объединить все простои в результирующее время простоя услуги?
- Поддерживает ли инструмент работу с процессами (workflow)? Довольно странно, если в процессно-ориентированном инструменте этого нет. Входят ли в «коробочный» вариант продукта стандартные процессы ITIL, описанные в красной и синей книгах? Например, поддерживает ли он ветвление процесса для важных и незначительных изменений? А для запросов и инцидентов? Каким образом обосновывается в документации внедрение продукта для поддержки процессов в соответствии с ITIL? Подавляющее большинство крупных поставщиков предлагают внедрять продукт, используя практики ITIL. Проверьте, есть ли расхождения между продуктом и документацией. Если в документации с трудом можно отыскать упоминание об ITIL, тогда надо понимать, что вам пытаются выдать желаемое за действительное.
- Предоставляет ли инструмент консолидированную информацию по услуге, причем здесь идет речь об услуге в терминах ITIL? Инструменты, которые не могут измерять или представлять информацию на языке услуги, не являются инструментами ITIL, хотя и могут быть основой для сбора данных, используемых инструментами ITIL. Например, мониторинг должен предоставлять текущее состояние услуги; Service Desk – текущее состояние услуги, основываясь на инцидентах, проблемах и изменениях; Service Desk и/или SLA – историческую отчетность по консолидированным данным о доступности и суммарную статистику по услуге.
- У какого количества специалистов по внедрению поставщика или партнеров поставщика есть сертификация выше, чем ITIL Foundation? Обучение по программе Foundation известна в моем кругу IT Skeptic-а как «краткосрочный интенсивный курс по натаскиванию». Это базовый курс, обязательный для каждого специалиста операционного управления ИТ, но явно недостаточный. При любом размере и сложности организации вам хотелось бы работать с самыми образованными специалистами, не говоря уже об их опыте и навыках: общий уровень подготовки команды – это хороший показатель истинной приверженности ITIL. Крупные поставщики на этом фоне, как правило, выгодно выделяются. Маленькие – часто пускают пыль в глаза: кроме одного специалиста по внедрению продукта у местного дистрибьютора, других специалистов может и не быть. В ITIL важны процессы, а не инструменты, поэтому, прежде всего, нужны специалисты, которые помогут внедрить процесс.
- Вопросы по службе Service Desk:
- Инциденты, проблемы и изменения – это разные сущности в продукте? Например, инцидент не трансформируется в проблему, он порождает проблему. Инцидент должен продолжать существовать как отдельная от проблемы сущность. Изменение типа записи с инцидента на проблему не относится к ITIL.
- Есть ли в «коробочном» варианте продукта функциональность сопоставления инцидентов? Сопоставление инцидентов – это не просто поиск по ключевым словам, это четко определенный процесс [Service Support, стр. 102].
- Поддерживаются ли известная ошибка и обходное решение как отдельные сущности в решении «из коробки»? Во многих инструментах нет даже упоминания о них. Некоторые – рассматривают их как категории проблемы. Такой вариант имеет право на существование, хотя, строго говоря, известная ошибка и обходное решение – отдельные сущности, порождаемые проблемой. У первой линии Service Desk должна быть возможность искать известные ошибки и обходные решения.
- Оценивают ли они влияние и могут ли они получать по нему содержательную отчетность? Отображение дерева CMDB в красивом интерфейсе — это не оценка влияния. Если какое-нибудь устройство удалить, будет ли услуга продолжать функционировать? Сколько серверов можно удалить с площадки без ущерба производительности, оставаясь в рамках соглашения об уровне услуг.
- Позволяет ли инструмент планировать изменение в решении «из коробки»?
- Как организуется работа комитета по изменениям? Например, какие данные брать за основу при подготовке документов и материалов перед проведением встречи? Как организовать работу комитета без необходимости проведения личных встреч для решения вопросов по незначительным изменениям?
Что вы думаете об этом? Вам есть, что добавить? Насколько версия 3 изменила этот список? Я думаю, что немного, но я еще не дочитал ее до конца.
Данная публикация является переводом на русский язык оригинальной статьи ИТ Скептика (IT Skeptic — "The IT Skeptic's ITIL Compliance Alignment Criteria").
Автор перевода — Елена Демьянова, компания "Инфосистемы Джет".
Оригинальная статья опубликована здесь >>>
This publication is the Russian translation of the original article IT Skeptic — "The IT Skeptic's ITIL Compliance Alignment Criteria".
The Author of this translation — Elena Demyanova, Jet Infosystems company.
The original text of the article can be found here >>>
Возврат к списку