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

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

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

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

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

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

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

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

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

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

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

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

GamingWorks Деловые игры на серьёзные темы:

  • Apollo-13 — ITSM на практике
  • Grab@Pizza — ИТ и основной бизнес
  • The Challenge of Egypt — управление проектами
  • 2020 — организационные изменения
  • Проект Феникс — DevOps на практике

 
Узнайте больше!

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

СЕН
27