Согласованные сроки разрешения инцидента в bpm'online service 7.x
Добрый день, коллеги!
Интересует ваш опыт и мнение.
Как в рамках bpm'online органичнее реализовать возможность изменения сроков решения инцидентов? Иногда бывает так, что клиент сам просит решить инцидент (запрос на изменение, например) не в оговоренный SLA срок, а в запланированное время (например, через 2 недели). Или запрашиваемый сервис нестандартный, или заранее не может быть высчитан и требует анализа в каждом из случаем.
Насколько я понимаю, сейчас bpm'online однозначно автоматически считает срок разрешения (даже если реклассифицировать). Но в этом случае такие обращения однозначно будут просроченными, что несправедливо портит показатели.
Как лучше решить данную ситуацию?
Спасибо!
Нравится
Добрый день, Владимир!
Сам термин SLA(соглашение об уровне предоставления услуги) подразумевает, что в таком соглашении содержиться детальное описание предоставляемого сервиса, в том числе перечень параметров качества, методов и средств их контроля, времени отклика поставщика на запрос от потребителя.
По этому наш продукт работает именно так.
Если у Вас возникают ситуации, которые Вы описали ранее, то вариантов решения могу предложить несколько (все они требуют проработки):
1) Выполнять преостановление выполнения обращения базовыми средствами используя состояние паузы "Ожидает ответа", Вы его можете переименовать по необходимости.
В таком случае сроки будут преостановлены. (и ставить задачу на ответственного с отображением в расписании даты последуещего созвона\согласования\ решения)
2)Суть аналогична с первым пунктом, но реализация чуть другая.
Можно создать поле "Дата согласованного решения", в котором будет выбираться дата, которую Вы согласовали с клиентом и реализовать логику, которая будет к срокам решения\реакции добавлять разницу времени, между указанными сроками и указанной даты в колонке "Дата согласованного решения". (в таком случае, желательно раздать права к такой колонке только группе пользователей у которой будут эти полномочия).
3) Разблокировать поля планового решения\реакции на изменения и раздать права на изменение только определенной группе пользователей\или пользователю. (но этот кейс в нашем понимании портит логику системы.)