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

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

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

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

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

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

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

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

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

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

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

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

  • Рубрики

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

    • Книга Cleverics про метрики и KPI рекомендована слушателям MBA по направлению ИТ
      Вышедшая в начале года книга Дмитрия Исайченко и Павла Демина «Управление услугами на основе измерений» получила рекомендацию от Высшей школы бизнес-информатики НИУ ВШЭ в качестве …
    • Определяем полюс потребителя
      При анализе и построении «путешествия заказчика» (customer journey) одной из важнейших задач является получение ответов на ряд вопросов, а именно: кто конкретно …
    • Семь распространённых мифов о DevOps
      В сообществе разработчиков бытует множество мифов о DevOps. И это и неудивительно, учитывая, сколько новшеств привнесла эта концепция за последние годы. DevOps — это …
    • Разрешение конфликтов в Agile-командах
      Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при …
    • Очередность прохождения курсов ITIL 4
      Имеет ли значение, в каком порядке проходить курсы по ITIL? Рассказывает аккредитованный тренер по ITIL 4 Игорь Фадеев. Cleverics — первая в России и одна из первых в …
    • 1 октября конференция «Роботизация бизнес-процессов 2020»
      1 октября 2020 издательство «Открытые системы» проведет ежегодную конференцию «Роботизация бизнес-процессов 2020» https://www.osp.ru/iz/rpa2020, где на одной площадке будут …
    • ITIL® 4 DITS — огонь, вода и медные трубы
      Мы уже писали о скором релизе последнего экзамена в сертификационной линейке ITIL 4 Digital and IT Strategy (DITS). Сейчас стоит добавить следующее (из информации, которую можно …
    • Как бизнес-аналитику встроиться в гибкую среду?
      Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики  зачастую считают, что они должны …
    • Деловая игра Grab@Pizza: вкусный кейс
      Деловые игры – один из наиболее эффективных видов тренинга, позволяющий на основе близкого к реальному кейса попрактиковаться в выстраивании любой работы. Участники деловой игры …
    • ITAM & SAMday пройдёт в Москве 2 октября
      ITAM & SAMday  – всероссийская независимая конференция, посвященная вопросам управления ИТ-активами и программными активами — пройдёт в Москве 2 октября в режиме …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT