За последнее время несколько раз на курсах по 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 может использоваться как один из механизмов информирования.
Коллеги, а как у вас построена данная работа? В рамках какого процесса и почему?
В целом если пользователь называет уже зарегистрированный инцидент, то вся коммуникация идет в рамках этого инцидента. По крайней мере для внутренних клиентов это работает нормально. В случаи внешних клиентов возможно RFF и будет иметь какой-то смысл.