Я активно участвовал в формировании процедур поддержки их ERP-системы (которая OeBS R12), когда они запускались лет пять назад. Корпоративного маразма было очень много, бороться за здравый смысл было тяжело. Например, помню сказанное при мен определение, в чём разница между вторым и третьим уровнями поддержки. Цитирую почти дословно: «Ну когда попроще, то второй, а если псложнее, то третий!..» Я в результате написал там базовый набор регламентных документов: Регламент поддержки, Релизную политику, Регламент управления изменениями и ряд более мелких. Процедуру эскалации сделал сразу и хорошую, так как я был исполнителем и мне самому это было нужно. До сих пор сносно работает.
В Вашем случае вижу много благообразно выглядещей мути. Намеренно запутанное понятие эскалации, невнятное разделение ответственности по уровням поддержки и т.п. Так поступают, когда ориентируются не на результат, а на процесс. Олимпийский подход.
Так что сочуствую. Как рядовому исполнителю у Вас нет шансов улучшить ситуацию.
Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.
Устраивает или не устраивает не запрос, а ход работ. То есть работы там ведутся, но меня это не устраивает. Если я могу сказать в терминах бизнеса, что меня не устраивает, то я эскалирую. Если не могу, то считаю это личными придирками и не эскалирую. Это с точки зрения инициатора.
А с точки зрения исполнителя, я по другому подхожу к организации работ. Если HelpDesk должен закрывать стандартные инциденты (например, сброс паролей), то с чего вдруг он эти запросы будет передавать на следующий уровень? Пусть выполняет свою работу. Если второй уровень должен решать все инциденты (кроме стандартных, которые решает HelpDesk), то пусть решает. И так далее.
В моём представлении инциденты до третьего уровня не доходят.
Не совсем понимаю, о какой проблеме с инцидентами идёт речь.
В моём понимании инцидент прилетает в HelpDesk и там его либо решают (если он стандартный, типа сброса пароля), либо отправляют на 2й уровень. HelpDesk отвечает за то, что правильно выберет группу поддержки 2го уровня. Либо инцидент сразу прилетает на 2й уровень, если его заводят сразу в трекере.
Дальше на входе всегда идёт какая-то фильтрация, чтобы сразу распознать ошибки назначения и переназначить инцидент. Когда инцидент берётся в работу, он уже не должен больше переназначаться. Я сторонник того, что на 3й уровень инцидент не отправляют, вместо этого заводят отдельный запрос. Так получается у всех участников свой чётко очерченый круг ответственности. И SLA легче писать, и следить за метриками.
Если неправильные назначения инцидентов являются проблемой, то их несложно посчитать и сделать метрикой в SLA.
Да, мне тоже. Но как тогда ещё можно понять устойчивое выражение «эскалировать на следующий уровень поддержки», кроме как передать запрос на решение куда-то-там? Они называют это функциональной эскалацией.
Да что тут вкладывать, скорее глаза открыть. Глядишь, после прочтения этой статьи кто-нибудь таки настроит у себя на проекте нормальный процесс эскалации. Плюшки-то за это очень даже вкусные. Не руководитель созреет, так рядовые сотрудники потребуют.
Пользователям лучше дать возможность указать критичность и масштаб влияния из которых получится приоритет в соответствии с матрицей приоритетов. Это не потому, что рядовым пользователям доверять нельзя, а потому что по своей сути для пользователя своя проблема всегда важнее, потому что не даёт выполнять собственные обязанности. Сотрудники поддержки пусть ставят приоритеты сами, правильная приоритезация является одной из их обязанностей.
Я активно участвовал в формировании процедур поддержки их ERP-системы (которая OeBS R12), когда они запускались лет пять назад. Корпоративного маразма было очень много, бороться за здравый смысл было тяжело. Например, помню сказанное при мен определение, в чём разница между вторым и третьим уровнями поддержки. Цитирую почти дословно: «Ну когда попроще, то второй, а если псложнее, то третий!..» Я в результате написал там базовый набор регламентных документов: Регламент поддержки, Релизную политику, Регламент управления изменениями и ряд более мелких. Процедуру эскалации сделал сразу и хорошую, так как я был исполнителем и мне самому это было нужно. До сих пор сносно работает.
В Вашем случае вижу много благообразно выглядещей мути. Намеренно запутанное понятие эскалации, невнятное разделение ответственности по уровням поддержки и т.п. Так поступают, когда ориентируются не на результат, а на процесс. Олимпийский подход.
Так что сочуствую. Как рядовому исполнителю у Вас нет шансов улучшить ситуацию.
Устраивает или не устраивает не запрос, а ход работ. То есть работы там ведутся, но меня это не устраивает. Если я могу сказать в терминах бизнеса, что меня не устраивает, то я эскалирую. Если не могу, то считаю это личными придирками и не эскалирую. Это с точки зрения инициатора.
А с точки зрения исполнителя, я по другому подхожу к организации работ. Если HelpDesk должен закрывать стандартные инциденты (например, сброс паролей), то с чего вдруг он эти запросы будет передавать на следующий уровень? Пусть выполняет свою работу. Если второй уровень должен решать все инциденты (кроме стандартных, которые решает HelpDesk), то пусть решает. И так далее.
В моём представлении инциденты до третьего уровня не доходят.
В моём понимании инцидент прилетает в HelpDesk и там его либо решают (если он стандартный, типа сброса пароля), либо отправляют на 2й уровень. HelpDesk отвечает за то, что правильно выберет группу поддержки 2го уровня. Либо инцидент сразу прилетает на 2й уровень, если его заводят сразу в трекере.
Дальше на входе всегда идёт какая-то фильтрация, чтобы сразу распознать ошибки назначения и переназначить инцидент. Когда инцидент берётся в работу, он уже не должен больше переназначаться. Я сторонник того, что на 3й уровень инцидент не отправляют, вместо этого заводят отдельный запрос. Так получается у всех участников свой чётко очерченый круг ответственности. И SLA легче писать, и следить за метриками.
Если неправильные назначения инцидентов являются проблемой, то их несложно посчитать и сделать метрикой в SLA.