Качество услуги начинается с ясного определения требований заказчика. Как составить спецификацию услуги, чтобы она позволяла поставщику и потребителю услуги говорить на одном языке? Как выявить требования заказчика и как перейти от них к управлению качеством?
Качество — это не то, что вы вкладываете в продукт или услугу. Это то, что от них получает заказчик.
Питер Друкер
Понятие сервисной операции
Давайте задумаемся, как мы воспринимаем качество предоставляемых нам услуг? Мы узнаем, насколько качественны услуги такси, только после того, как закажем машину и совершим поездку. Мы составим своё представление о технической поддержке, когда обратимся с вопросом и получим помощь. Мы вынесем свою оценку службе доставки цветов, когда курьер привезёт нам букет.
Таким образом, восприятие качества услуги формируется у потребителя только в результате некоторого действия, которое непосредственно связано с получением потребителем значимого для него результата и представляет собой акт взаимодействия с поставщиком или самостоятельного использования предоставленных им ресурсов. Такие действия мы будем называть сервисными операциями.
Некоторые примеры сервисных операций приведены в таблице 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.
