Звоните: +7 (495) 517-57-25

Третья версия библиотеки ITIL® привнесла несколько новых концепций. Среди прочих, одна выделяется авторами довольно явно — это понятия полезности (utility) и гарантии (warranty). Насколько применимы в жизни эти понятия? Есть ли в них ценность, или же это очередная спорная идея?

Следует сразу отметить, что данные понятия встречаются только в новом ITIL. Другие уважаемые источники знаний и передового опыта, такие как COBIT или MOF, прямых аналогий не содержат, хотя тот же COBIT был обновлён до версии 4.1 совсем недавно. При этом в ITIL понятия полезности и гарантии обсуждаются довольно подробно и регулярно встречаются в тексте всех основных книг. Что же представляют из себя полезность и гарантия?

Обращение к глоссарию (словарю) ITIL v3 вносит не очень много ясности в данный вопрос. Действительно, все описания концепции ITSM настойчиво рекомендуют ИТ-подразделению чётко оговаривать с заказчиком конечный результат работы ИТ — ИТ-сервис. Оговаривая тот самый ИТ-сервис, ИТ-отдел непременно вспомнит о его (сервиса) функциональности. В то же время заказчик сервиса, конечно же, не забудет про важные для него параметры сервиса, такие как доступность, безопасность, или требования к непрерывности.

Похоже, именно это и имели ввиду авторы третьего ITIL, назвав старое и уже известное по-новому? Оказывается, не совсем. Посмотрим подробнее.

Из глоссария ITIL v3:

Полезность (Utility) — Функциональность, предлагаемая продуктом или сервисом для обеспечения определённых потребностей. Зачастую определяется как «что делает продукт/сервис».

Полезность сервиса (Service Utility) — Функциональность ИТ-сервиса с точки зрения заказчика. Бизнес-ценность ИТ-сервиса создаётся комбинацией полезности («что сделает сервис») и гарантии («насколько хорошо он это делает»).

Гарантия (Warranty) — Обещание или гарантия того, что продукт или сервис будет соответствовать согласованным требованиям.

Гарантия сервиса (Service Warranty) — Уверенность в том, что ИТ-сервис будет соответствовать согласованным требованиям. Может быть в виде формального соглашения, такого как SLA или договор, либо как маркетинговое сообщение или представление торговой марки. Бизнес-ценность ИТ-сервиса создаётся комбинацией полезности («что сделает сервис») и гарантии («насколько хорошо он это делает»).

Любопытно, почему в глоссарии разведены понятия «полезность» и «полезность сервиса», «гарантия» и «гарантия сервиса»? Оказывается, эти понятия являются новыми только по отношению к библиотеке ITIL — для управления сервисами вообще они чем-то новым не являются.

Задумаемся над тем, как конечные потребители оценивают сервис. Любой сервис, не обязательно в области информационных технологий.

Потребители будут считать сервис приносящим пользу (ценность) только в том случае, если он соответствует назначению (для чего это сервис приобретает потребитель?) и соответствует условиям использования (каким должен быть сервис, чтобы быть пригодным?). Именно эти два аспекта — соответствие назначению (fit for purpose) и соответствие условиям использования (fit for use) называют полезностью и гарантией, соответственно.

Из чего складывается полезность?

Полезность, в свою очередь, достигается одним из следующих способов:

  1. обеспечивая требуемую для потребителя производительность;
  2. устраняя или снижая имеющиеся у потребителя ограничения.

Забавно, что иногда есть возможность увеличения производительности за счёт устранения ограничений. И конечно же, есть масса случаев, когда совершенно не требуется достигать безумной производительности, но так глубоко мы задумываться не будем.

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

Ограничение — это запрет, невозможность выполнения какой-либо работы или задачи. Снижение ограничений можно представить себе на примере туристического агентства: предоставление клиенту большого выбора вариантов отдыха может быть только в том случае, если агентство имеет доступ к системам бронирования нескольких туроператоров. Эти системы могут быть совершенно разными, использовать различные каналы передачи данных и интерфейсы. Объединяя доступ к этим системам в единый ИТ-сервис, поставщик может снять ограничения по количеству туроператоров и, таким образом, дать больше возможностей для потребителя.

Что входит в гарантию?

В рамках третьей версии ITIL гарантия складывается из ответов на четыре чётких вопроса:

  1. Обладает ли сервис требуемой доступностью?
  2. Обладает ли сервис достаточным запасом по мощности?
  3. Соответствует ли сервис требованиям по безопасности?
  4. Соответствует ли сервис требованиям по непрерывности?

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

Связи перечисленных понятий могут быть довольно просто изображены на схеме:

ITIL v3 Utility and Warranty

Как видно из схемы, полезность без гарантии (и наоборот) создаёт мало ценности для заказчика. Представим себе ИТ-сервис, предоставляемый с помощью мощной ERP-системы с очень широкой функциональностью. В случае, если доступность этой ERP-системы оставляет желать лучшего, заказчик вряд ли сможет использовать её для решения своих бизнес-задач. Аналогично, если ИТ-департамент внедрил прекрасное решение, использующее многократное резервирование и соответствующее самым жёстким требованиям по безопасности, но не обладающее требуемой для заказчика функциональностью, ценность такого решения крайне мала.

Итак, суммируем. Как и многое в ITIL, понятия полезности и гарантии на поверку оказываются довольно простыми и логичными — это, к счастью, не ядерная физика. Назвать их гениальной идеей довольно сложно. Однако их понимание и внимание к этим аспектам сервиса могут сильно помочь в диалоге с заказчиком, при составлении соглашения об уровне сервиса (SLA), при разъяснении сотрудникам ИТ сложного вопроса: «В чём же, наконец, состоит ценность ИТ для основного бизнеса?».

Олег Скрынник