В деловой игре GRAB@PIZZA, как и в любой бизнес-симуляции, предусмотрены некоторые упрощения и допущения. Оно и понятно, мы же только моделируем реальную рабочую ситуацию, а не пытаемся её детально воссоздать и проанализировать. Попытка полностью воссоздать процесс может привести к существенному усложнению игры. Однако есть один важный нюанс, который, как мне кажется, хорошо было бы ввести в игру.
В игре чётко разграничены точки входа “заявок” (назовём их так в целях обобщения) – через процесс управления инцидентами и через процесс управления взаимоотношениями с бизнесом. Всё красиво, каждый должен заниматься своим делом. Первая линия – маршрутизировать или решать/выполнять инциденты и запросы на обслуживание. BRM – разбираться в бизнес-задачах и пытаться сбалансировать ожидания с возможностями по внедрению изменений. На практике же, чисто технически, вход всё равно один – через ITSM-систему. В том смысле, что все “заявки”, так или иначе, регистрируются и обрабатываются в едином инструменте автоматизации. И здесь мы сталкиваемся с традиционной проблемой “человеческого фактора”, выражающейся в двух сложностях:
- пользователь/бизнес-заказчик должен правильно выбрать нужный пункт в каталоге услуг;
- должна произойти корректная маршрутизация заявки вне зависимости от корректности выбора нужного пункта заказчиком.
Пункт первый, как мы знаем, довольно трудно достижим. Всё очень зависит от конкретных персоналий – ключевых бизнес-заказчиков. Поэтому важность второго пункта, как правило, существенно выше.
Как же добиться корректной маршрутизации? Давайте сначала разберёмся, какой она должна быть, если мы говорим о потенциальном (это важно) запросе на изменение.
Тезис 1. Запросы на изменение не должны сразу попадать к разработчикам.
Как мы знаем, даже хорошо “прокачанный” бизнес-заказчик не всегда может со стопроцентной уверенностью сказать, что ему нужно именно изменение. Он может предполагать, что задача решается в рамках типовых активностей (запросов на обслуживание). Здесь важно, чтобы сотрудники первой линии обладали достаточной компетенцией для выявления базовых признаков запроса на изменение. И если таковые присутствуют, направляли заявку в группу бизнес-анализа, а не разработчику.
Тезис 2. Запросы на изменение не должны сразу браться в работу.
Особенно актуально, если роль второй линии выполняют разработчики. В этом случае достаточно типовой становится следующая ситуация: первая линия перекидывает заявку, ориентируясь не на результат, скажем так, предметного анализа, а на более простые признаки. В первую очередь, на компонент ИТ-обеспечения. Если написано в заявке, например, “у меня отчёт в 1С не формируется”, значит, и переправить надо группе второй линии, обеспечивающей поддержку и разработку для системы 1С. А то, что такого отчёта в природе не существует, первая линия, понятное дело, может и не знать. И если у разработчика нет понимания важности правильной обработки изменений, если процесс управления изменениями не пустил ещё глубоких корней в сознании, велика вероятность того, что часть изменений будет закрываться в рамках выполнения запросов на обслуживание. С этим достаточно эффективно получается бороться в случае, если разработка выполняется силами подрядчиков. Попросту говоря, если изменение не зарегистрировано в должном порядке и не прошло согласования – подрядчик денег не получает. А вот если разработка внутренняя, мотивировать разработчиков на более осознанный анализ и переадресацию изменений в группу бизнес-анализа становится сложнее.
Вот поэтому и напрашивается ввести в GRAB@PIZZA дополнительный источник изменений – некорректно сформулированные обращения. Чтобы и первую линию потренировать, и разработчиков подтолкнуть к более осознанному анализу того, следует ли поступившее обращение сразу выполнить, или решение о взятии в работу должен принять кто-то другой. Например, тот же BRM.
Мнение автора может не совпадать с мнением редакции.