Портал №1 по управлению цифровыми
и информационными технологиями

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

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

Комментариев: 5

  • Леонид

    …используется для выявления требований к услугЕ

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT