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

Нужен ли процесс “Управление запросами на обслуживание” процессу “Управление инцидентами”?

O+F-TipsFulfillment-CallCenterЗа последнее время несколько раз на курсах по ITIL(с) обсуждался вопрос использования процесса управления запросами на обслуживание (Request Fulfillment Management [RFF]) для решения задач, лежащих в области интересов других процессов из процессной модели ITIL. Последнее обсуждение было вчера (Да. В корпоративном формате мы проводим тренинги и в выходные).
В качестве примера подобного обсуждения вопрос: «В каком процессе должен отрабатывать запрос на получение информации об инциденте, находящемся в работе (например, о текущем статусе инцидента)? В процессе «Управление инцидентами» [Incident Management , INC] или в RFF?»

Сначала зафиксируем очевидное.
Во-первых, источником информации (в т.ч. о текущем статусе) является, конечно же INC, поскольку именно в этом процессе происходи работа с инцидентом и в т.ч изменение статуса инцидента.
Во-вторых, ответственность за обеспечение прозрачности работы процесса лежит на INC, на что в ITIL  явно указано – обеспечение прозрачности процесса включено в список задач (objectives) процесса [ITIL Service Operation (SO) 4.2.1.2]. Кроме того, в примерах критических факторов успеха (CSF) есть такой: «Улучшать прозрачность и коммуникации в работе процесса», по которому даже сформулирован соответствующий KPI из списка примеров: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов [SO 4.2.8].
Также в списке примеров политик процесса INC сказано [SO 4.2.4.1): «Информация об инцидентах и их статусах должна своевременно и эффективно передаваться. Это предполагает наличие хорошего service desk для координации коммуникации информации об инцидентах тем, кто работает над инцидентами».

Видятся возможными следующие два варианта.
Мы можем дополнить INC процедурой, согласно которой будем отвечать на запросы информации пользователей о том, что сейчас происходит с зарегистрированным ранее инцидентами.
А можем отрабатывать такие запросы в рамках процесса RFF, который и так занимается консультированием и предоставлением пользователям информации.
Во втором случае RFF используются как транспорт, как канал коммуникаций, обеспечивающий передачу информации пользователям (по запросу, т.е. помимо автоматического оповещения со стороны INC).
При этом ответственность за эффективное использование данного канала для обеспечения должного уровня прозрачности процесса лежит на INC.

Можно посмотреть на это под другим углом.
При построении процесса INC мы должны обеспечить не только решение инцидентов (быстро, качественно, рационально и т.п.) но и работать на удовлетворённость, которая обеспечивается в т.ч. согласованным уровнем прозрачности. Т.е. мы должны построить процесс так, чтобы пользователь получал нужную информацию в согласованные с заказчиком моменты времени и в согласованном формате (по согласованным каналам). Это м.б. e-mail, СМС, информация на портале самообслуживания (в личном кабинете) или телефонный звонок (а в случае обработки инцидентов от VIP-пользователей, возможно, и личный визит). То, насколько качественно мы выполним эту работу (по построению процесса INC), можно в т.ч. оценивать через снижение расходов на реализацию процесса. В т.ч. расходов на информирование пользователей. И для достижения целей в этом направлении мы должны продумать и выбрать оптимальную комбинацию каналов коммуникаций (проактивные – автоматическое оповещение, реактивные –выдача информации по запросу). Т.е. качество коммуникаций с пользователем в рамках работы над инцидентом – это ответственность процесса INC. При этом RFF может использоваться как один из механизмов информирования.

Коллеги, а как у вас построена данная работа? В рамках какого процесса и почему?

 

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Альберт

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

     

    • Альберт, всё верно, в последний раз вопрос возник именно в контексте обсуждения взаимодествия с внешнего сервис-провадйреа с заказчиком.

      Хотя некоторые идеи, которые сформулировал Сергей ниже, применимы и для внутреннего сервис-провайдера.

  • Сергей Терехин

    Считаю, что такая бюррократизация не имеет смысла (создавать RFF для того чтобы сообщить инфу по инциденту). Если всё же хотим учитывать обращения пользователей за информацией по инциденту – то тут необходима только автоматизация  – чтобы по звонку пользователя данная информация была в автоматическом режиме добавлена к его инциденту (если конечно диспетчер нажал кнопочку добавить). Если автоматизации нет – то тут 2 случая:

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

    2. Пользователь просто спросил – то вот на это зачем тратить время диспетчера? Ведь если создавать RFF – то надо нажать создать, найти и добавить пользователя, классифицировать, внести инфу, сменить статус и чего-нить еще. В общем это выльется в несколько минут. Да диспетчер потратил 30 секунд на информирование пользователя – зато несколько минут надо это оформлять.

    3. Вот оформить RFF имеет смысл, если, например, была произведена консультация пользователя – как самому получить информацию – например, как работает рассылка от Service Desk, как воспользоваться порталом самообслуживания. Короче, запрос на обслуживание типа консультация/информирование пользователя.

    • 1. Согласен. П.1 – это действительно работа внутри INC без сомнений.

      2. Если я правильно понял, получается, что единственная причина, почему мы не регистрируем service request (SR), т.е. не запускаем работу в процессе RFF, – это не адекватные результату накладные расходы. Означает ли это, что в случае снижения накладны расходов (например, мощнаый функционал средств автоматизации ITSM + интеграция с телефонией, позволяющая автоматически идентифицровать щвонящего пользователя) и/или повышение по какой-либо причине важности информации о том, кто сколько рази в течение какого временип получал от нас информауию, вы готовы пойти на организацию такой свзки INC + RFF?

      3. Тут, как и в п.1 полность согласен.

      • Сергей

        2. Нет. Вообще не вижу смысла просто по звонку за информацией по инциденту создавать дополнительные запросы на обслуживание. Хоть и автоматизированно. Да и вообще, при возможности всё отавтоматизировать, уж лучше сделать хорошую систему оповещения и портал самообслуживания, нежели собирать ненужные данные. Вот какая ценность этих данных? Ну мы можем проанализировать сколько было доп звонков пользователя по инциденту – но что это даст? То что необходимо или/и лучше информировать пользователя, или/и предоставить ему доступ к порталу самообслуживания (в т.ч. наличие самого портала), или/и то что необходимо пользователя обучить вышеобозначенному (а вот обучение и будет RFF). Т.е. одно ведёт к другому – так зачем этот лишний шаг?

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

        • Второй абзац, вроде как, перечеркивает то, что написано в первом. Нет?

          Мне кажется, что то, что я пытался выразить, как раз совпадает с мыслью из последнего абазаца: "При опредеёных условиях [соотношении затрат на орагнизацию всей этойбюрократии с полезнустью собираемых данных] мы можем пойти/идём на организацию такой процедуры". И при этом, возможно, задействуем процесс RFF.

  • ДМБ

    У меня вот проблема – ссылки из письма дайджеста не открываются, куда регистрировать?

    • А если ссылку скопировать и вставить в адресную строку браузера, ссылка открывается?

      Если да, то, возможно, настройки безопасности почтового клиента/браузера (а м.б. дополнительных средств безопасности [например, антивируса], не позволяют исползовать ссылки внутри письма).

      Если нет, то, видимо, средства безопасности не блокируют, а "вычищают" ссылки из тела письма.

  • Александр

    Мы в обращении завели дополнительный вид работ, и когда заявитель интересуется статусом своей заявки, сотрудник serveice desk регистрирует эту работу под данным видом работ. Для просмотра таких работ создан отдельный отчет.

    • Александр, спасибо!

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

  • Rafkhat Osmonov

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

    • Всё правильно, в посте так и сказано (точнее процитирован ITIL) – информирование о статусе – это задача INC. Но вопрос-то был в том, как мы будем осуществлять передачу информации, если нас о ней попросят. В рамках INC, или RFF?

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

      Вопрос же про ситуацию, когда на спрашивают. Или Вы имели в виду, что оповещаем автоматически, а на зпросы не отвечаем?

      • Rafkhat Osmonov

        Вопрос понятен. Если нас спрашивают о статусе инцидента, то задача сводится к предоставлению доступа к инциденту в системе автоматизации. Это можно сделать в рамках RFF, т.к. запрос достаточно стандартный. Тем самым мы проактивно закроем вопросы, которые могут поступить от этого пользователя.

        • Не совсем.

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

          То, что описано в вашем сценарии, фактически означет, что сервис-провадер не предоставляет такой информации по запросу, ограничившись:

          1. предоставлением инструментария для самостоятельного получения информации и

          2. автоматическими уведомлениями.

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

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

          • Rafkhat Osmonov

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


Добавить комментарий для СергейОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM