Статья посвящена методу сервисных операций как инструменту формирования спецификаций ИТ-услуг и выявления требований заказчиков. Автор предлагает использовать перечень конкретных действий (сервисных операций), через которые потребители получают значимые для них результаты, чтобы создать общий язык общения между поставщиками и потребителями услуг. Метод позволяет четко описать содержание услуги, сформулировать измеримые требования к качеству и объему потребления, а также транслировать эти требования на уровень ИТ-систем и ресурсов. Подход применим как для бизнес-ориентированных ИТ-услуг, так и для услуг, связанных с базовыми ИТ-системами, и помогает установить взаимосвязь между бизнес-процессами заказчика и возможностями ИТ-инфраструктуры.
Качество услуги начинается с ясного определения требований заказчика. Как составить спецификацию услуги, чтобы она позволяла поставщику и потребителю услуги говорить на одном языке? Как выявить требования заказчика и как перейти от них к управлению качеством?
Давайте задумаемся, как мы воспринимаем качество предоставляемых нам услуг? Мы узнаем, насколько качественны услуги такси, только после того, как закажем машину и совершим поездку. Мы составим своё представление о технической поддержке, когда обратимся с вопросом и получим помощь. Мы вынесем свою оценку службе доставки цветов, когда курьер привезёт нам букет.
Таким образом, восприятие качества услуги формируется у потребителя только в результате некоторого действия, которое непосредственно связано с получением потребителем значимого для него результата и представляет собой акт взаимодействия с поставщиком или самостоятельного использования предоставленных им ресурсов. Такие действия мы будем называть сервисными операциями.
Некоторые примеры сервисных операций приведены в таблице 1.
| Действующие лица | Примеры сервисных операций |
| Действия совершаются потребителем услуги с помощью предоставленных ему в рамках данной услуги ресурсов |
|
| Действия совершаются поставщиком услуги, но их результаты предоставляются потребителю и имеют для него самостоятельную ценность |
|
| Действия совершаются потребителем и поставщиком совместно |
|
Заметим, что в представленном определении сервисной операции нигде не содержится ИТ-специфики – оно подходит для самых разных услуг. Если же сфокусироваться на ИТ-услугах, то специфика, в основном, будет связана с тем, что потребляемые ресурсы будут представлять собой информацию или технологии, предназначенные для её сбора, обработки, хранения, передачи и отображения.
Еще раз подчеркнём, что сервисная операция неразрывно связана с получением потребителем значимого для него результата. Оценка потребителем этого результата и есть основа его восприятия качества услуги.
Применение сервисных операций
Понятие сервисной операции имеет несколько весьма полезных применений.
Во-первых, составив для некоторой услуги полный список поддерживаемых ею сервисных операций, можно описать содержание услуги на некотором промежуточном, понятном и поставщику и потребителю языке (особенно в корпоративном сценарии, когда поставщик и потребитель услуги являются структурными подразделениями одной компании или группы компаний). В самом деле, если мы говорим об ИТ-услугах, то для потребителя сервисные операции – это действия, направленные на предоставление ему результатов, а для поставщика – функции, выполняемые информационными системами и ИТ-персоналом. Таким образом, обсуждая содержание услуги, стороны начинают говорить на общем языке, что крайне важно и является одной из стержневых идей сервисного подхода.
Во-вторых, список сервисных операций помогает выявить требования потребителя к услуге. Причём эти требования оказываются сформулированными в неразрывной связи с действиями, через которые у потребителя формируется восприятие качества. А значит, оценка качества будет ближе к потребностям пользователей, имеет больше шансов стать основой для совместной работы над повышением качества услуги, а не просто формальным действием, выполняемым поставщиком «для галочки».
В-третьих, действия, выполняемые в интересах потребителя услуги, могут быть связаны и с его бизнес-планами, и с потребностью в ресурсах. Следовательно, список сервисных операций может стать основой и для определения ограничений по объему потребления услуги, и для планирования ресурсов поставщика, и для расчёта стоимости услуги.
Должен признаться, что на сегодняшний момент, не все представленные здесь применения полностью нашли подтверждение в нашей практике. Однако и те результаты, которых уже удалось достичь в рамках проектной деятельности (прежде всего, в части спецификации содержания услуг и измерения их качества), на наш взгляд, доказывают пользу идеи.
Но как на практике сформировать список сервисных операций для ИТ-услуги?
Формирование списка сервисных операций
Формирование списка сервисных операций, безусловно, требует усилий поставщика услуги. И усилия эти связаны не только с выполнением работы по анализу бизнес-процессов заказчика, но и с изменением восприятия ИТ-специалистами того, в чём заключается их работа и как оценить её результаты.
Принципиально составление списка сервисных операций выполняется относительно просто, особенно для услуг, формируемых на основании бизнес-процессов заказчика: мы берём схему бизнес-процесса, анализируем шаги процесса, в рамках которых используются информационные системы, и вносим эти шаги (возможно с небольшими уточнениями или изменениями формулировок) в таблицу сервисных операций услуги. Мы выполняли эту работу в банках, на производстве и для предприятий сферы услуг – логика и последовательность действий одинаковы.
Конечно, прочитав предыдущий абзац, многие читатели воскликнут: «Где же на практике взять актуальные описания бизнес-процессов?!» Но метод сервисных операций работает и без актуальных описаний процессов, хотя и с бОльшими трудозатратами.
Дело в том, что существует два принципиально разных и дополняющих друг друга способа описания бизнес-процессов – вертикальный и горизонтальный. Вертикальный определяет общую иерархическую классификацию работ, выполняемых на предприятии. Он отвечает на вопрос «Что надо делать?», но не «Как надо делать?». Горизонтальный способ описания, напротив, предполагает формирование workflow-диаграмм, отвечающих на вопрос «Как и в какой последовательности надо совершать действия в каждом конкретном случае?». Естественно, горизонтальные описания процессов уникальны для каждого конкретного предприятия. Но вертикальные описания являются более или менее типовыми для отрасли и поэтому могут использоваться для формирования списка сервисных операций и без локальной процессной документации.
Таким образом, последовательность действий при формировании каталога услуг и разработке списка сервисных операций по услугам может выглядеть следующим образом:
- открываем организационную структуру предприятия, анализируем распределение функций, выявляем вертикальные процессы, формируем предложения по структуре каталога услуг;
- сопоставляем выявленные процессы с распространёнными вертикальными отраслевыми моделями (eTOM, PCF, …) и собственными наработками, уточняем содержимое процессов;
- накладываем процессы на ИТ-системы, выявляем кандидатов на сервисные операции (если есть регламенты горизонтальных процессов, на этом шаге они могут очень пригодиться);
- обсуждаем результаты проделанной работы с представителями бизнес-подразделений для уточнения результатов (к этой работе также весьма полезно привлекать бизнес-аналитиков и системных архитекторов – они могут существенно дополнить и уточнить картину).
В итоге, выбрав нужный уровень детализации, для крупных услуг получаем таблицу из 30-50 сервисных операций, для небольших – из 5-15 операций. Фрагмент списка сервисных операций по услуге «ИТ-обеспечение кредитования физических лиц» представлен в таблице 2.
Любопытно, что, в общем, аналогичный подход применяется при формировании списка сервисных операций для ИТ-услуг, выделенных не по бизнес-процессам, а по базовым (неспециализированным) ИТ-системам. Пример списка сервисных операций по ИТ-услуге «Корпоративная электронная почта» представлен в таблице 3.
Получившаяся таблица сервисных операций чётко определяет содержимое услуги и является основой для измерения качества и объёма потребления услуг.
Измерение качества и объёма потребления услуг
В таблицах 2-3 есть колонка «Требования заказчика». В ней можно указать, какие требования заказчик предъявляет к выполнению одной или нескольких сервисных операций. Например, «Общее время автоматизированной предкредитной обработки кредитной заявки не должно превышать 15 минут», «Доставка почты внутреннему получателю должна выполняться в течение 1 минуты» или «Доступ к почте с персонального компьютера и через web-интерфейс должен быть обеспечен по рабочим дням в период с 09:00 до 21:00 МСК (5 x 12), а суммарные нарушения доступности за месяц не должны превышать 5 часов». Эти требования являются основой для измерения качества услуги1.
Кроме того, если поставщик берёт на себя обязательства, связанные со скоростью обработки информации, неизбежно возникают ограничения на объем потребления услуги. А значит, появляется и задача его измерения.
Сервисные операции, сформулированные на понятном заказчику языке, помогают выявить требования заказчика. А таблица 4 – сформулировать требования в пригодном к измерению виде.
| Группа показателей | Примеры формулировок требований |
| Показатели качества |
|
| Показатели объёма потребления2 |
|
Следующий шаг – перейти от отдельных требований и соответствующих им метрик к интегральной оценке качества услуги. Это можно сделать с помощью сбалансированных карт показателей и SLAM-таблиц. Подробнее этот вопрос рассматривается в книге «ITSM. Руководство по измерению»3
Но для того чтобы обеспечить взятые на себя обязательства, мало научиться измерять сервисные операции и оценивать качество услуги. Надо суметь транслировать требования заказчиков к ИТ-услугам, ориентированным на бизнес, на операционную деятельность по управлению ИТ-системами и ресурсами.
Связь требований к услугам с требованиями к системам
Трансляция требований заказчиков к ИТ-услугам на ИТ-системы и связанную с ними деятельность также опирается на список сервисных операций и выполняется в два этапа:
- определяем ИТ-системы, используемые при выполнении сервисных операций, выявляем точки интеграции систем;
- транслируем требования, связанные с сервисными операциями, на уровень поддерживающих их ИТ-систем.
При наличии нескольких слоёв в ИТ-архитектуре (системы, базы данных и вычислительные мощности, сети хранения и передачи данных) соответствующий анализ для каждого слоя производится отдельно – сначала трансляция требований от ИТ-услуг к ИТ-системам, затем от ИТ-систем к ресурсам нижних уровней.
Трансляция требований заказчиков на уровень ИТ-систем и ресурсов позволяет обоснованно определить точки нехватки возможностей поставщика для удовлетворения требований заказчика услуги. А значит, определить уровень услуги с учётом имеющихся ограничений.
Метод сервисных операций
Таким образом, рассмотренный в данной статье метод сервисных операций заключается в формировании спецификаций ИТ-услуг на основе перечня действий, непосредственно связанных с получением потребителями значимых для них результатов. Данный метод позволяет вести сервисный диалог на понятном обеим сторонам языке, лучше выявлять требования заказчиков услуг и придавать им измеримый вид, чётче транслировать требования к ИТ-услугам на уровень ИТ-систем и ресурсов.
Общая последовательность действий по применению метода сервисных операций к формированию спецификации услуги и заключению SLA представлена на следующем рисунке.
Сноски
- Строго говоря, помимо требований заказчиков, существуют так называемые «обычно предполагаемые» и «обязательные» требования. Обычно предполагаемые требования для ИТ-услуг соответствуют базовому уровню услуг. Например, если у заказчика нет по отношению к ИТ-услуге особых требований доступности, предполагается, что она должна быть доступна в режиме 09-19 МСК, по рабочим дням, с уровнем доступности 95%. Обязательные требования являются следствием законодательства или предъявляются регуляторами. Например, для услуги «Пассажирское такси с водителем» водитель должен быть трезв, автомобиль – исправен, а для перевозки детей младше 12 лет должны использоваться детские кресла.
- Иногда показатели объёма потребления могут также использоваться и для оценки качества.
- Исайченко Д., Журавлёв Р. ITSM. Руководство по измерению — LiveBook, 2015. — стр. 96-100.
