Заметка об эскалации
О делегировании поговорили. Есть еще один не менее важный процесс - эскалация. Надо отметить, в отличие от делегирования он обделен вниманием коучей и редко упоминается в книгах.
С одной, стороны, в эскалации нет особых тайн и секретов: если проблема выходит за рамки полномочий или компетенций сотрудника - это поводникому не рассказывать до последнего эскалировать ее на уровень руководителя.
С другой стороны, желая выполнить очередную задачу, об это очень легко забыть. Однажды я попал в такую ситуацию: несколько заказчиков требовали реализовать их задачи с максимальным приоритетом. Я провел целый день, упражняясь в комбинатором планировании, переставляя задачи в MS Project и пробуя применить всякие ухищрения вроде овертаймов. Ни один из вариантов не мог удовлетворить всех заказчиков сразу. Тогда я позвонил своему руководителю, описал проблему, свои вычисления, и попросил определить приоритеты. Через полчаса он прислал упорядоченный список проектов, а еще через час план был составлен.
Конечно, тут есть очень тонкая грань. В какой-то организации было бы правильнее установить приоритеты самостоятельно. А в какой-то изначально не браться за планирование без приоритетов. Поэтому какие-то базовые правила эскалации не помешают.
Кроме правил "когда эскалировать", имеет смысл определить "как эскалировать". Когда-то один из моих руководителей дал мне следующий совет: "Если ты видишь какую-то проблему, недостаточно просто сказать о ней руководителю. Необходимо проработать варианты ее решения, оценить их плюсы и минусы, а уже потом идти к руководителю с этой информацией. В этом случае ему достаточно будет выбрать один из вариантов".
Если подытожить, то эскалация, пожалуй, не обладает тем множеством ньюансов и сложностей, как делегирование. Но с другой стороны имеет смысл определить 2 принципа:
С одной, стороны, в эскалации нет особых тайн и секретов: если проблема выходит за рамки полномочий или компетенций сотрудника - это повод
С другой стороны, желая выполнить очередную задачу, об это очень легко забыть. Однажды я попал в такую ситуацию: несколько заказчиков требовали реализовать их задачи с максимальным приоритетом. Я провел целый день, упражняясь в комбинатором планировании, переставляя задачи в MS Project и пробуя применить всякие ухищрения вроде овертаймов. Ни один из вариантов не мог удовлетворить всех заказчиков сразу. Тогда я позвонил своему руководителю, описал проблему, свои вычисления, и попросил определить приоритеты. Через полчаса он прислал упорядоченный список проектов, а еще через час план был составлен.
 |
| Изображение с сайта https://media.giphy.com/media/l2JdUD8QbC8gz55N6/giphy.gif |
Кроме правил "когда эскалировать", имеет смысл определить "как эскалировать". Когда-то один из моих руководителей дал мне следующий совет: "Если ты видишь какую-то проблему, недостаточно просто сказать о ней руководителю. Необходимо проработать варианты ее решения, оценить их плюсы и минусы, а уже потом идти к руководителю с этой информацией. В этом случае ему достаточно будет выбрать один из вариантов".
Если подытожить, то эскалация, пожалуй, не обладает тем множеством ньюансов и сложностей, как делегирование. Но с другой стороны имеет смысл определить 2 принципа:
- Когда? - В каких случае эскалировать проблему.
- Как? - В каком формате передавать информацию в случае проблем.
Комментарии
Отправить комментарий