Есть такая практика – включать в число статусов обрабатываемых объектов (инциденты, обращения, задания/наряды на работы и т.д.) статус "Ожидание". Задача, которую решает этот статус, простая: обеспечить участникам процессов возможность отложить в сторону обрабатываемый объект в ситуации, когда по каким-то причинам его обработка пока невозможна. Например, ждем, пока пользователь вернется из отпуска или ждем, пока будет поставлена техника и т.д. В общем, найти разумное объяснение существованию этого статуса можно. Однако понятна и обратная сторона такой возможности: появляется способ отлынивать от работы. Традиционный способ сокращения халтуры – обязать переводящего в статус "Ожидание" указывать причину перевода. Однако при наличии богатой фантазии отдельные личности наверняка придумают миллион способов обойти это ограничение. К тому же проверка причин перевода в ожидание потребует от проверяющего (например, менеджера) определенных трудозатрат, зависящих от количества проверяемых объектов. .jpg)
В итоге разумным решением кажется следующее:
- переводить в статус "Ожидание" может только ограниченный круг лиц, например, руководители функциональных групп после получения объяснения от своих сотрудников;
- должен выполняться регулярный контроль наличия объектов, которые переводились в подобный статус с последующей (возможно выборочной) проверкой обоснованности применения данного статуса.
Отдельный вопрос – что делать со сроком (срок решения инцидента, выполнения задания и т.д.)?
Есть два варианта: останавливать время, сдвигая срок дальше на продолжительность времени ожидания, либо не останавливать. Если время останавливать, то "как смотреть потом в глаза Заказчикам"? Ведь обещали решить за 6 часов, а в ожидании инцидент пробыл два дня пока ждали. Если не останавливать, то что дает этот статус?
Что касается способов контроля и минимизации “халявы”: на мой взгляд, хорошая практика – при переводе в статус “Ожидание” указывать планируемую длительность ожидания, чтобы система по истечении этого срока выталкивала задание обратно в статус “Направлен в группу” или “В работе” (в какой именно – можно обсуждать, есть варианты).
А по длительности – в каких-то используемых у нас суппортных системах я встречал два статуса: “Pending customer” и “Pending provider”. Т.е., ждём заказчика и ждём по каким-то внутренним причинам (например, создали запрос внешнему поставщику и ждём, пока он там починит у себя что-то). Срок по SLA в первом случае можно честно продлять, а причину показывать заказчику. Во втором случае – срок по SLA, разумеется, не изменяем.
По-моему, более или менее логично.