Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT