Главная » Блоги Экспертов И ИТ-Компаний » Игровая маршрутизация
Идёт сезон бесплатных вебинаров по управлению ИТ CleverTALK 3 месяца назад

Игровая маршрутизация

В деловой игре GRAB@PIZZA, как и в любой бизнес-симуляции, предусмотрены некоторые упрощения и допущения. Оно и понятно, мы же только моделируем реальную рабочую ситуацию, а не пытаемся её детально воссоздать и проанализировать. Попытка полностью воссоздать процесс может привести к существенному усложнению игры. Однако есть один важный нюанс, который, как мне кажется, хорошо было бы ввести в игру.

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

  • пользователь/бизнес-заказчик должен правильно выбрать нужный пункт в каталоге услуг;
  • должна произойти корректная маршрутизация заявки вне зависимости от корректности выбора нужного пункта заказчиком.

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

Как же добиться корректной маршрутизации? Давайте сначала разберёмся, какой она должна быть, если мы говорим о потенциальном (это важно) запросе на изменение.

Тезис 1. Запросы на изменение не должны сразу попадать к разработчикам.

Как мы знаем, даже хорошо «прокачанный» бизнес-заказчик не всегда может со стопроцентной уверенностью сказать, что ему нужно именно изменение. Он может предполагать, что задача решается в рамках типовых активностей (запросов на обслуживание). Здесь важно, чтобы сотрудники первой линии обладали достаточной компетенцией для выявления базовых признаков запроса на изменение. И если таковые присутствуют, направляли заявку в группу бизнес-анализа, а не разработчику.

Тезис 2. Запросы на изменение не должны сразу браться в работу.

Особенно актуально, если роль второй линии выполняют разработчики. В этом случае достаточно типовой становится следующая ситуация: первая линия перекидывает заявку, ориентируясь не на результат, скажем так, предметного анализа, а на более простые признаки. В первую очередь, на компонент ИТ-обеспечения. Если написано в заявке, например, «у меня отчёт в 1С не формируется», значит, и переправить надо группе второй линии, обеспечивающей поддержку и разработку для системы 1С. А то, что такого отчёта в природе не существует, первая линия, понятное дело, может и не знать. И если у разработчика нет понимания важности правильной обработки изменений, если процесс управления изменениями не пустил ещё глубоких корней в сознании, велика вероятность того, что часть изменений будет закрываться в рамках выполнения запросов на обслуживание. С этим достаточно эффективно получается бороться в случае, если разработка выполняется силами подрядчиков. Попросту говоря, если изменение не зарегистрировано в должном порядке и не прошло согласования — подрядчик денег не получает. А вот если разработка внутренняя, мотивировать разработчиков на более осознанный анализ и переадресацию изменений в группу бизнес-анализа становится сложнее.

Вот поэтому и напрашивается ввести в GRAB@PIZZA дополнительный источник изменений — некорректно сформулированные обращения. Чтобы и первую линию потренировать, и разработчиков подтолкнуть к более осознанному анализу того, следует ли поступившее обращение сразу выполнить, или решение о взятии в работу должен принять кто-то другой. Например, тот же BRM.

Мнение автора может не совпадать с мнением редакции.



Источник: https://realitsm.ru/?p=26557


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Москва
Информационные технологии

Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>