Метод сервисных операций

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

Понятие сервисной операции

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

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

Некоторые примеры сервисных операций приведены в таблице 1.

Заметим, что в представленном определении сервисной операции нигде не содержится ИТ-специфики – оно подходит для самых разных услуг. Если же сфокусироваться на ИТ-услугах, то специфика, в основном, будет связана с тем, что потребляемые ресурсы будут представлять собой информацию или технологии, предназначенные для её сбора, обработки, хранения, передачи и отображения.

Еще раз подчеркнём, что сервисная операция неразрывно связана с получением потребителем значимого для него результата. Оценка потребителем этого результата и есть основа его восприятия качества услуги.

Применение сервисных операций

Понятие сервисной операции имеет несколько весьма полезных применений.

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

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

В-третьих, действия, выполняемые в интересах потребителя услуги, могут быть связаны и с его бизнес-планами, и с потребностью в ресурсах. Следовательно, список сервисных операций может стать основой и для определения ограничений по объему потребления услуги, и для планирования ресурсов поставщика, и для расчёта стоимости услуги.

Должен признаться, что на сегодняшний момент, не все представленные здесь применения полностью нашли подтверждение в нашей практике. Однако и те результаты, которых уже удалось достичь в рамках проектной деятельности (прежде всего, в части спецификации содержания услуг и измерения их качества), на наш взгляд, доказывают пользу идеи.

Но как на практике сформировать список сервисных операций для ИТ-услуги?

Формирование списка сервисных операций

Формирование списка сервисных операций, безусловно, требует усилий поставщика услуги. И усилия эти связаны не только с выполнением работы по анализу бизнес-процессов заказчика, но и с изменением восприятия ИТ-специалистами того, в чём заключается их работа и как оценить её результаты.

Принципиально составление списка сервисных операций выполняется относительно просто, особенно для услуг, формируемых на основании бизнес-процессов заказчика: мы берём схему бизнес-процесса, анализируем шаги процесса, в рамках которых используются информационные системы, и вносим эти шаги (возможно с небольшими уточнениями или изменениями формулировок) в таблицу сервисных операций услуги. Мы выполняли эту работу в банках, на производстве и для предприятий сферы услуг – логика и последовательность действий одинаковы.

Конечно, прочитав предыдущий абзац, многие читатели воскликнут: «Где же на практике взять актуальные описания бизнес-процессов?!» Но метод сервисных операций работает и без актуальных описаний процессов, хотя и с бóльшими трудозатратами.

Дело в том, что существует два принципиально разных и дополняющих друг друга способа описания бизнес-процессов – вертикальный и горизонтальный. Вертикальный определяет общую иерархическую классификацию работ, выполняемых на предприятии. Он отвечает на вопрос «Что надо делать?», но не «Как надо делать?». Горизонтальный способ описания, напротив, предполагает формирование workflow-диаграмм, отвечающих на вопрос «Как и в какой последовательности надо совершать действия в каждом конкретном случае?». Естественно, горизонтальные описания процессов уникальны для каждого конкретного предприятия. Но вертикальные описания являются более или менее типовыми для отрасли и поэтому могут использоваться для формирования списка сервисных операций и без локальной процессной документации.

Таким образом, последовательность действий при формировании каталога услуг и разработке списка сервисных операций по услугам может выглядеть следующим образом:

1. открываем организационную структуру предприятия, анализируем распределение функций, выявляем вертикальные процессы, формируем предложения по структуре каталога услуг;
2. сопоставляем выявленные процессы с распространёнными вертикальными отраслевыми моделями (eTOM, PCF, …) и собственными наработками, уточняем содержимое процессов;
3. накладываем процессы на ИТ-системы, выявляем кандидатов на сервисные операции (если есть регламенты горизонтальных процессов, на этом шаге они могут очень пригодиться);
4. обсуждаем результаты проделанной работы с представителями бизнес-подразделений для уточнения результатов (к этой работе также весьма полезно привлекать бизнес-аналитиков и системных архитекторов – они могут существенно дополнить и уточнить картину).

В итоге для крупных услуг получаем таблицу из 30-50 сервисных операций, для небольших – из 5-15 операций. Фрагмент списка сервисных операций по услуге «ИТ-обеспечение кредитования физических лиц» представлен в таблице 2. 

Любопытно, что, в общем, аналогичный подход применяется при формировании списка сервисных операций для ИТ-услуг, выделенных не по бизнес-процессам, а по базовым (неспециализированным) ИТ-системам. Пример списка сервисных операций по ИТ-услуге «Корпоративная электронная почта» представлен в таблице 3.

Получившаяся таблица сервисных операций чётко определяет содержимое услуги и является основой для измерения качества и объёма потребления услуг.

Измерение качества и объёма потребления услуг

В таблицах 2-3 есть колонка «Требования заказчика». В ней можно указать, какие требования заказчик предъявляет к выполнению одной или нескольких сервисных операций. Например, «Общее время автоматизированной предкредитной обработки кредитной заявки не должно превышать 15 минут», «Доставка почты внутреннему получателю должна выполняться в течение 1 минуты» или «Доступ к почте с персонального компьютера и через web-интерфейс должен быть обеспечен по рабочим дням в период с 09:00 до 21:00 МСК (5×12), а суммарные нарушения доступности за месяц не должны превышать 5 часов». Эти требования являются основой для измерения качества услуги[1].

Кроме того, если поставщик берёт на себя обязательства, связанные со скоростью обработки информации, неизбежно возникают ограничения на объем потребления услуги. А значит, появляется и задача его измерения.

Сервисные операции, сформулированные на понятном заказчику языке, помогают выявить требования заказчика. А таблица 4 – сформулировать требования в пригодном к измерению виде.

Следующий шаг – перейти от отдельных требований и соответствующих им метрик к интегральной оценке качества услуги. Это можно сделать с помощью сбалансированных карт показателей и SLAM-таблиц. Подробнее этот вопрос рассматривается в книге «ITSM. Руководство по измерению»[3].

Но для того чтобы обеспечить взятые на себя обязательства, мало научиться измерять сервисные операции и оценивать качество услуги. Надо суметь транслировать требования заказчиков к ИТ-услугам, ориентированным на бизнес, на операционную деятельность по управлению ИТ-системами и ресурсами.

Связь требований к услугам с требованиями к системам

Трансляция требований заказчиков к ИТ-услугам на ИТ-системы и связанную с ними деятельность выполняется в два этапа:

1. определяем ИТ-системы, используемые при выполнении сервисных операций, выявляем точки интеграции систем;
2. транслируем требования, связанные с сервисными операциями, на уровень поддерживающих их ИТ-систем.

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

Трансляция требований заказчиков на уровень ИТ-систем и ресурсов позволяет обоснованно определить точки нехватки возможностей поставщика для удовлетворения требований заказчика услуги. А значит, определить уровень услуги с учётом имеющихся ограничений.

Метод сервисных операций

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

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

[1] Строго говоря, помимо требований заказчиков, существуют так называемые «обычно предполагаемые» и «обязательные» требования. Обычно предполагаемые требования для ИТ-услуг соответствуют базовому уровню услуг. Например, если у заказчика нет по отношению к ИТ-услуге особых требований доступности, предполагается, что она должна быть доступна в режиме 09-19 МСК, по рабочим дням, с уровнем доступности 95%. Обязательные требования являются следствием законодательства или предъявляются регуляторами. Например, для услуги «Пассажирское такси с водителем» водитель должен быть трезв, автомобиль – исправен, а для перевозки детей младше 12 лет должны использоваться детские кресла.

[2] Иногда показатели объёма потребления могут также использоваться и для оценки качества.