Без чего невозможно описать услугу?

О том, что деятельность является неотъемлемой частью описания услуги, вроде бы давно договорились.
Невозможно предметно говорить об услуге, не рассматривая то, как она потребляется. То есть то, из каких операций (деятельности) состоит потребление (и предоставление) услуги. Метод сервисных операций, разработанный компанией 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 описывает все три типа сущностей как то, что может быть использовано для формирования сервисных предложений.

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

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Дмитрий Исайченко

    > В идеальном пределе, наверное, всё будет привязано к деятельности потребителя и, соответственно, выражено в терминах сервисных операций.

    1. Сервисные операции не обязательно связаны со специфичной бизнес-деятельностью потребителя. Например, для электронной почты — это операции использования почты, но как и зачем заказчик её использует — это его дело, т.е. вот прямо его бизнес. Поэтому для общетехнологических услуг формирование спецификации в терминах сервисных операций не обязательно означает понимание бизнес-процессов заказчика.

    2. У любого правила должна быть область применимости. В этом случае ответ на перечисленные вопросы, как мне кажется, лежит в плоскости классификации поставщика услуг (commodity supplier — strategic partner).

    1. Игорь Гутник Автор

      Дмитрий, спасибо за уточнения!

      1. Я специально сформулировал это как «деятельность потребителя», имея в виду ориентацию на деятельность и описание с точки зрения этой деятельности вне зависимости от того, структурирована эта деятельность в виде бизнес-процесса или нет (е-почта).

      Т.е. если я правильно понял п.1 комментария, мы вроде бы совпадаем. Нет?

      Мои вопросы в конце были про то, какова эта самая область применимости.

      Уровень отношений (п.2, commodity supplier — strategic partner), действительно влияет на то, насколько поставщик будет погружён в детали деятельности потребителя.

      А что по поводу тезиса о том, что в некоторых случаях уровень этой погружённости ограничен способностями поставщика? Например, поставщик хотел бы договариваться об услуге в терминах СО, но, не имея возможности измерения, вынужден описывать услугу в терминах доступа к ресурсам.

      1. Дмитрий Исайченко

        > ...поставщик хотел бы договариваться об услуге в терминах СО, но, не имея возможности измерения, вынужден...

        НЕжелание, НЕзнание и НЕумение – три главные пружины гомеостазиса. Нежелание шевелиться и думать, как следствие – незнание сути происходящего и возможностей, как следствие – неумение сделать шаг в направлении перемен. Это настолько общая история, о ней написаны очень достойные книги. Что уж говорить про SLM…

        > Мои вопросы в конце были про то, какова эта самая область применимости.

        Еще одну границу области применимости (плюс к позиционированию поставщика) я вижу в содержании услуги. Для очень «маленьких», атомарных услуг, суть которых, по сути, и есть одна сервисная операция — описание в виде списка СО просто не нужно. Например, услуга техподдержки. То есть мельчить можно до бесконечности, но это, чем дальше, тем дороже и потому менее полезно.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
26
Учебный курс:
Основы DevOps (Осталось 4 места)