Преимущества сервисного подхода

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

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

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

Кто наш клиент?

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

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

Важность бизнес-процессов и операций

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

В чем заключается сервисный подход?

Сервисный подход заключается в том, чтобы дать сотрудникам компании ИТ-инструменты, научить с ними работать и обеспечить согласованный уровень доступности этих инструментов. При этом уровень доступности определяется как компромисс между стоимостью ИТ-инструментов (включая стоимость их поддержки) и недополученной прибылью при их неработоспособности. Центральное понятие сервисного подхода — это услуга, название/описание которой понятно пользователю, для которой определены измеряемые параметры качества/продуктивности, а также стоимость. При этом между поставщиком и потребителем услуг не обязательно должны существовать «товарно-денежные» отношения. Стоимость должна быть зафиксирована и для того, чтобы сдерживать спрос и, таким образом, гарантировать достаточное качество. Исходя из требований прозрачности услуги для пользователя, логично было бы в качестве названий услуг выбирать названия операций, которые пользователь выполняет при помощи этой самой услуги.

Итак, главное:

• ИТ-услуга понятна пользователю.
• Определены ее параметры качества и продуктивности.
• Определена стоимость ИТ-услуги.
• Определена точка контакта (и менеджер услуги / сервис-менеджер) — куда обращаться в случае проблем.

Пример ИТ-услуги:

Начисление заработной платы: доступность 99% рабочего времени каждые 12 и 27 число месяца для каждого специалиста отдела персонала. Длительность операции: 5000 сотрудников в час, стоимость подключения: 300 рублей за рабочее место, стоимость поддержки: 100 рублей за рабочее место в месяц. Время устранения инцидента: 4 часа. Время выполнения запроса на подключение: 4 рабочих дня.

Каталог услуг

Хороший каталог услуг — это структурированный перечень услуг со ссылками на их спецификации. Каждая услуга должна быть снабжена кратким описанием. В спецификациях должны быть перечислены все вышеупомянутые характеристики вместе с их целевыми значениями, а также должно быть указано что делать в нестандартных ситуациях. Т.е., например, куда и как обращаться, если что-то сломалось, или возникла необходимость изменить функциональность услуги. Также в спецификации услуги должны быть указаны ответственные лица (кто отвечает за ее предоставление и кто за нее платит/на кого возложена ответственность за формирование требований к услуге). Структура каталога должна опираться на бизнес-процессы и может быть, например, такой:

• 1-й уровень: бизнес-направление.
• 2-й уровень: бизнес-процесс.
• 3-й уровень: бизнес-операция.

Таким структурированием каталога мы добиваемся следующих преимуществ:

1. ИТ-услуги являются составной (часто неотъемлемой) частью бизнес-процессов.
2. Метрики ИТ-услуг связаны с метриками бизнеса, применим учет объемов потребления.
3. Структура каталога поддерживает процесс бюджетирования.

Очевидно, что в крупной компании десятки-сотни бизнес-процессов и сотни-тысячи видов операций, поэтому сотрудникам-конечным пользователям необходимо показывать только те пункты (от 20 до 30) из каталога услуг, с которыми он имеет дело. Инструмент, который позволяет этого добиться в системе автоматизации — соглашение обуровне услуг (SLA).

Соглашение об уровне услуг, SLA в системе автоматизации

Соглашение об уровне услуг SLA — это соглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон — поставщика ИТ-услуг и заказчика. Подробнее об этом можно прочитать в одной из предыдущих заметок.

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

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

От теории к практике — обращение в SD

Перейдем к рассмотрению практических примеров.

Пользователь, сотрудник клиентского офиса кредитной организации звонит в службу поддержки и сообщает: «Я пытаюсь выполнить операцию Оформление кредитной заявки. Создаю новую заявку, вношу необходимую информацию, клиент подписывает документ, я нажимаю кнопку „Приложить“ и вставляю документ в авто-податчик сканера, после чего сканер затягивает документ и дальше ничего не происходит».

Оператор оформляет обращение, заполняя поля. Услуга: Оформление кредитной заявки. Описание: «Я пытаюсь выполнить операцию Оформление кредитной заявки. Создаю новую заявку, вношу необходимую информацию, клиент подписывает документ, я нажимаю кнопку „Приложить“ и вставляю документ в авто-податчик сканера, после чего сканер затягивает документ и дальше ничего не происходит». Категория обращения: «не работает» (инцидент). Симптом: система зависает после отправки документа в авто-податчик сканера. А также другие поля, на которых стоит остановиться чуть подробнее.

Ответственность за обращение (инцидент, запрос и т.д.)

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

Приоритет обращения

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

Крайний срок

Крайний срок обработки обращения зафиксирован в SLA и должен определяться требованиями бизнеса к времени подключения услуги/восстановления услуги и т.д. (самое распространенное решение). А еще правильнее в случаях с инцидентами — требованиями бизнеса к доступности ИТ-услуги и знаниями о частоте сбоев в данной услуге. Крайний срок обработки обращения должен обеспечиваться ресурсами ответственной за обращение группы (а также ресурсами других групп, которые оказывают данной группе поддерживающие услуги). Крайний срок обработки обращения не должен зависеть от приоритета, т.к. приоритет является лишь инструментом обеспечения крайнего срока. Например, обращение при регистрации получило приоритет 3 и долго «висело» в очереди. Но по мере приближения крайнего срока руководитель группы, ответственной за данное обращение, поднял его приоритет до 1, поставив в начало очереди и, таким образом, гарантировал соблюдение крайнего срока.

Как устроена ИТ-услуга?

Чтобы предоставлять ИТ-услугу необходимы активы и другие услуги. Например, для того, чтобы организация могла предоставлять услуги широкополосного доступа в Интернет (ШПД) ей, как минимум, необходимо сетевое оборудование и кабельная система (к ним будут подключать абонентов — клиентов организации), а также специалисты, которые будут все это поддерживать по определенным процессам. Кроме того, организации понадобится услуга «Доступ к магистральному каналу Интернет», которую будет оказывать провайдер. А этому провайдеру, в свою очередь понадобится все тоже самое + аналогичная услуга вышестоящего провайдера. При этом большинству клиентов организации не очень интересно что делают сотрудники этой самой организации, чтобы предоставить услугу ШПД. Но все клиенты требуют, чтобы у них был стабильный и быстрый интернет — тот, за который они заплатили. Также организация, которая предоставляет услуги ШПД своим клиентам, не вмешивается в дела своего провайдера, а лишь контролирует по отчетам, что конечный результат вышестоящего провайдера (скорость и доступность) соответствуют контракту (UC). Т.о., сервисный подход инкапсулирует внутренние процессы сервисной организации, оставляя клиенту лишь интерфейс в клиентскую службу организации.

Модель ИТ-услуги

Моделью ИТ-услуги будем называть иерархическую структуру, отражающую взаимосвязи между ИТ-услугой (назовем ее главной для удобства изложения), обеспечивающими ее активами (за работоспособность которых отвечает выделенная группа сотрудников) и поддерживающими услугами. Каждая поддерживающая услуга, в свою очередь, также имеет свою модель. Но данная модель уже выходит за рамки ответственности группы сотрудников, которая поддерживает главную ИТ-услугу. Для сотрудников данной группы важно лишь знать перечень поддерживающих услуг. Модель услуги разрабатывается, как стандарт услуги при ее проектировании и поддерживается в актуальном состоянии на протяжении всего жизненного цикла. Модель услуги является одним из важнейших инструментов сервисного подхода и используется для следующих целей:

1. Совместно со знаниями о трудозатратах на разработку/производство обеспечивающих активов (или затратах на приобретение) позволяет вычислить стоимость услуги (капитальные затраты).
2. Разграничивает ответственность. Позволяет упорядочить работу по заключению OLA.
3. Дает информацию для основательного/качественного планирования изменений и релизов.
4. Основа для настройки систем мониторинга и оценки влияния инцидентов (регистрируемых системами мониторинга).
5. Задает правила информирования и эскалации при возникновении инцидентов.
6. Карта для анализа ИТ-проблем.
7. Совместно со знаниями о трудозатратах на поддержку (затратах на аутсорсинг) позволяет точно вычислить стоимость услуги (операционные затраты)

Операционные соглашения об уровне услуг

Модель услуги позволяет разграничить зоны ответственности подразделений, участвующих в предоставлении этой услуги. Для регламентирования взаимодействия между этими зонами ответственности используются соглашения операционного уровня. OLA — по смыслу то же самое, что и SLA, или UC (поддерживающие/внешние контракты). Соответственно важно, чтобы OLA содержало всю ту же информацию, что и SLA. Особое внимание необходимо обратить на то, что OLA заключается между менеджерами услуг. С одной стороны — это менеджер группы, которая обеспечивает предоставление ИТ-услуги, а с другой — менеджер поддерживающей ИТ-услуги (возможно менеджер группы, которая обеспечивает предоставление данной услуги). Также OLA должно заключаться между менеджером ИТ-услуги (той, которая непосредственно предоставляется бизнесу) и менеджером группы, которая отвечает за ее предоставление. Также стоит обратить внимание на то, что одна и та же услуга может быть как ИТ-услугой, так и поддерживающей ИТ-услугой в зависимости от того, с какой точки зрения ее рассматривать.

От теории к практике — обработка обращений

В разделе «От теории к практике — обращение в SD» мы рассматривали пример регистрации в системе SD сбоя в работе услуги «Оформление кредитной заявки». Вернемся к этому примеру и рассмотрим теперь процесс обработки информации о данном сбое в системе SD. Как мы договорились выше, обращение о сбое (инцидент), зарегистрированное в системе SD автоматически (исходя из затронутой ИТ-услуги) попадает в очередь обработки группы поддержки, которая отвечает за нормальное функционирование данной услуги. Место в очереди определяется приоритетом. Руководитель группы поддержки отвечает за своевременное распределение работ по обращениям из очереди между сотрудниками группы. В разделе «Модель ИТ-услуги» мы поставили перед собой цель уметь определять стоимость ИТ-услуг. А одно из требований, которое позволит нам достичь этой цели — это учет трудозатрат. Таким образом на будущее договоримся, что все операции, которые выполняют сотрудники, должны фиксироваться в системе автоматизации. Объект, который будем использовать для этого, назовем «Наряд на работу», или просто «Наряд». На правилах обработки нарядов остановимся чуть позже, а пока вернемся к примеру обработки сбоя.

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

• Итак, руководитель группы назначил инцидент (точнее наряд на диагностику этого инцидента) одному из своих подчиненных. У наряда, также как и у инцидента, есть приоритет, унаследованный от инцидента. Работа по данному наряду начнется только в тот момент, когда он займет первое место в очереди. Предположим, что данный момент наступил. Мы помним, что у инцидента есть симптом, который, по сути, является признаком классификации текстового описания инцидента. Симптомы всегда связаны с конкретной ИТ-услугой и являются признаками проявления ИТ-проблем, существующих в данной конкретной ИТ-услуге. К проявлению одного и того же симптома могут вести различные причины. Поэтому для того, чтобы точно определить какая причина вызвала проявление симптома необходимо провести диагностику. В ходе диагностики используется диагностическая карта (см. раздел «Диагностическая карта и обходное решение»). С момента, когда причина установлена, проблема становится известной ошибкой. А для большинства известных ошибок мы знаем способы их устранения (способ устранения инцидента).

Сотрудник группы поддержки услуги работает по наряду на диагностику и устанавливает причину возникновения симптома. Работа, которую выполняет сотрудник подробно описана и нормирована по времени. Таким образом, симптомы инцидентов, причины инцидентов (а также работы по устранению причин) — это формализованные знания, которые поступают в процесс обработки инцидентов из процесса управления проблемами. После того, как причина установлена, ответственный сотрудник выполняет работы по устранению причины. Причем, если для устранения причины необходимо привлечение группы поддержки другой услуги, то регистрируется обращение по этой услуге (в данном случае она является поддерживающей). Работы же, которые выполняются внутри группы поддержки услуги регистрируются в виде нарядов. Обращение по поддерживающей услуге обрабатывается также, как и главное, только уже другой ответственной группой сотрудников. При этом главное обращение не закрывается и находится на контроле у ответственного сотрудника.

От теории к практике — решение проблем

Проблема — это корневая причина одного, или нескольких инцидентов. На вход процесса решения проблем подается ранее неизвестный симптом инцидента, который проявился в ходе эксплуатации услуги. Курирует решение проблемы руководитель группы поддержки, ответственной за услугу. Он назначает аналитика проблемы (как правило, одного из наиболее опытных сотрудников группы). Аналитик проблемы, используя модель услуги, выполняет следующие шаги:

1. Проверяет работоспособность всех активов, обеспечивающих предоставление услуги, которые находятся в зоне компетенции и ответственности его группы. Если актив найден, то разрабатывается, проверяется и применяется обходное решение. Если все активы функционируют в нормальном режиме, то переходим к следующему уровню проверки.
2. Находит поддерживающую услугу, предоставление которой нарушено и регистрирует обращение-инцидент. Группа поддержки данной поддерживающей услуги обрабатывает обращение алгоритму обработки инцидента, описанному выше. Если симптом известен, то выполняется обработка инцидента. Если же симптом ранее не встречался, то регистрируется и обрабатывается проблема. В любом случае, результатов работ является известная ошибка, для которой известно обходное решение. Данное решение встраивается в диагностическую карту и доводится до сведения специалистов группы, поддерживающих ИТ-услугу.

Диагностическая карта и обходное решение

Что представляет из себя диагностическая карта и обходное решение? Диагностическая карта — это ориентированный граф. У данного графа существует несколько «входных вершин» (полустепень захода которых равна нулю) — симптомов и несколько «выходных вершин» (полустепень исхода которых равна нулю) — причин. В вершинах графа находятся работы и результаты работ таким образом, что вершины типа «работа» всегда соединены с вершинами типа «результат» либо с вершиной типа «симптом». А вершина типа «результат» всегда соединена либо с вершиной типа «работа», либо с вершиной типа «причина». Обходное решение представляет из себя последовательность работ и/или обращений по устранению установленной при помощи диагностической карты причины.

Сервис-ориентированные изменения и релизы

Запрос на изменение — это, подобно инциденту или запросу на обслуживание, отдельная категория обращения. Как и все категории обращений, запрос на изменение также ссылается на услугу, имеет приоритет и другие атрибуты. Чаще всего соглашение об уровне услуг заключают таким образом, что данная категория обращений доступна для подачи только владельцу услуг. Иначе есть риск получить поток несогласованных требований к функционалу услуги. Ответственным за запрос на изменение целесообразно назначать сервис-менеджера, который уточняет у владельца услуги требования, анализирует и оценивает их, а также выполняет оценку риска. После чего, используя в том числе модель услуги для определения состава участников, сервис-менеджер собирает комитет по изменениям. Необходимо учитывать связи изменений с другими объектами, а именно: изменение может быть направлено на устранение проблемы, а также может само породить проблему. Для реализации изменения в услуге может потребоваться выполнение изменений в поддерживающих услугах. Таким образом, один запрос может порождает несколько изменений. Пакет изменений, которые целесообразно внедрять одновременно образуют релиз.

Для управления релизами важно определить политику. Политика релиза определяется для каждой ИТ-услуги / группы ИТ-услуг и объема (срочные, значительные, малые). Gолитика релиза должна описывать:

• Правила именования/нумерации.
• Распределение ролей.
• Допустимая частота выпуска.
• Средства автоматизации сборки и распространения.
• Правила распространения (полномасштабный запуск / поэтапный запуск).
• Правила проверки достижения целевого состояния компонентов релиза (ИТ-активов и КЕ).
• Шаблоны календарей развертывания.
• Правила тестирования для всех уровней, а именно: тестирование сборок и компонентов, тестирование интеграции, готовность служб эксплуатации, проверка SLA, проверка соответствия бизнес-целям.
• Критерии применения и процедуры аварийного возврата к предыдущему состоянию.

От теории к практике — роли

В вышеописанных процессах принимают участие следующие важные роли, неформальное описание функционала которых выглядит так:

• Владелец услуги — платит, диктует требования, взаимодействует с Сервис-менеджером.
• Сервис-менеджер — контролирует предоставление ИТ-услуги на согласованном уровне, отчитывается перед Владельцем услуги.
• Менеджер проблем — организует решение проблем при предоставлении ИТ-услуг.
• Менеджер изменений — организует проведение изменений в ИТ-услуге.
• Менеджер релизов — организует подготовку, тестирование и развертывание релиза новой версии ИТ-услуги.
• Менеджер процесса — следит за достижением целевых показателей процесса, предлагают корректирующие меры, устраняют конфликты.

При этом в большинстве ситуаций (безусловно, принимая во внимание масштабы) видится разумным объединение ряда ролей (сервис-менеджер, менеджер проблем, менеджер изменений, менеджер активов) в одном сотруднике.

По-настоящему универсальные правила!

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

Обращение — факт обращения потребителя услуги в точку контакта (Service Desk, или группу поддержки услуги).

Наряд на работу — требование на выполнение специалистом группы конкретной, описанной, нормированной работы.

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

Релиз — одно, или несколько изменений, развертывание которых выполняется одновременно.

SLA/OLA/UC — соглашения между:

• Владельцем услуги и Сервис-менеджером (SLA).
• Менеджерами групп поддержки (OLA).
• Сервис-менеджером и менеджером группы (OLA).
• Менеджером группы поддержки и Внешним поставщиком услуг (UC).
• Сервис-менеджером и Внешним поставщиком услуг (UC).

Нет коментариев