О том, что деятельность является неотъемлемой частью описания услуги, вроде бы давно договорились.
Невозможно предметно говорить об услуге, не рассматривая то, как она потребляется. То есть то, из каких операций (деятельности) состоит потребление (и предоставление) услуги. Метод сервисных операций, разработанный компанией Cleverics несколько лет назад, как раз и используется для выявления требований к услуге, исходя из понимания этой природы – деятельность в рамках потребления/предоставления.

В этом вопросе сходятся, вроде бы, все. Ну, или почти все. Например, гражданский кодекс (статья 779 ГК РФ) описывает услугу как совершение определенных действий или осуществление определенной деятельности. Или налоговый кодекс (статья 5 НК РФ (часть первая) от 31.07.1998 N 146-ФЗ, ред. от 06.06.2019): «Услугой для целей налогообложения признается деятельность, результаты которой не имеют материального выражения, реализуются и потребляются в процессе осуществления этой деятельности».

В книге «Основы» новой ITIL 4 описывается три типа сущностей, которые могут использоваться при формировании сервисного предложения (service offering) – описания того, что поставщик услуги предлагает потребителю в качестве услуги:

1. Товары (goods) – то, что передаётся потребителю; и далее сам потребитель отвечает за использование товаров (например, wifi-маршрутизатор в подарок абоненту при подключении домашнего интернета).
2. Доступ к ресурсам (в нашем примере с домашним интернетом – сеть, к которой подключается абонент, или, например, почтовый/прокси/p2p сервер).
3. Сервисные операции (service actions) – деятельность, выполняемая представителями поставщика, потребителя или ими совместно (например, взаимодействие со службой поддержки). Это та самая неотъемлемая часть описания услуги, с которой я начал заметку.

Разобраться в этих понятиях получше может помочь статья «Компьютер как услуга».

Сейчас я хотел бы остановиться на «ресурсах» (п.2), поскольку за последнее время пару раз возникала дискуссия, вызванная следующей позицией.

Так как всё, что потребитель получает от услуги (или с помощью услуги), он(а) получает в результате деятельности, ничего кроме деятельности в описании услуги быть не может.

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

Зачем же тогда в структуре описания нужна сущность вида «доступ к ресурсам»?

Мне кажется самым простым объяснением следующее.

Описание услуги должно давать картину, которая одинаково понятна потребителю и поставщику и позволяет производить измерение и оценку предоставления услуги. Действительно, поставщик формирует описание услуги, чтобы договориться с потребителем. Эта договорённость и соответствующие сервисные отношения будут эффективными, если обеими сторонами будут одинаково пониматься критерии оценки.

Но поскольку поставщик не всегда владеет информацией о том, как устроена деятельность потребителя (по разным причинам: поставщик/ИТ не может, или потребитель/бизнес не хочет), или нет возможности объективного измерения этой деятельности (точнее, той её части, в которой услуги способствуют её выполнению), проще и корректнее договариваться об услуге, как ресурсе, к которому будет предоставляться доступ. Т.е. свести описание услуги к описанию правил предоставления доступа к ресурсам.

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

Разумеется, в приведённой заметке два подхода к описанию противопоставляются только для того, чтобы продемонстрировать разницу. Но на самом деле они могут использовать в комплексе. Именно поэтому в ITIL 4 описывает все три типа сущностей как то, что может быть использовано для формирования сервисных предложений.

Нужно ли сводить всё к описанию в сущностях одного типа? В идеальном пределе, наверное, всё будет привязано к деятельности потребителя и, соответственно, выражено в терминах сервисных операций. Но будет ли это рациональным выбором в каждых сервисных отношениях? Насколько нам (поставщику и потребителю это нужно; сможем ли мы обойтись без этого); и насколько для нас это трудозатратно (и вообще выполнимо)?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление уровнем услуг и каталогом услуг

Разработка каталога, SLA, метрик качества, расчёт доступности