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

Маршрутизация обращений пользователей

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

Давайте попробуем понять, в каких случаях можно отказаться от маршрутизации по классификации и чем это чревато.

Первым в голову приходит простой вариант: "компания маленькая и все друг друга знают". Давайте его не будем рассматривать, с ним все понятно.

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

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

Однако, с появлением классификации возникает задача обеспечения правильности ее выполнения, а это очередные знания, которыми надо делиться, обновлять и т.д.

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

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

  • Юрий Ерин

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

    • Юра, расписал подробнее. 

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

  • Алексей Кадеев

    Здравствуйте, коллеги!

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

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

    • Алексей, добрый день!

      Описание впечатляет, но есть ряд вопросов: как добиваетесь правильности выбора ИТ-услуги и причины? Можете привести примеры ваших ИТ-услуг, они ближе к ИТ-системам или бизнес-процессам?

      Как вы совершенно справедливо заметили "без поддержания таблицы маршрутов … механизм работать не будет". Много ресуров уходит на поддержание? 

  • Алексей Кадеев

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

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

    В идеальном мире ресурсов тратится не много. Актуализация таблицы выполняется только по факту нахождения обходного решения проблемы, или при внедрении новой ИТ-услуги. Кроме того, эта активность распределена между различными ролями. В неидеальном – чуть больше :), но за счет стремления к идеальному состоянию.

  • Armen

    Коллеги, 

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

    Если интересует, я могу предоставить пример чек листа.


Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM