Согласованные сроки разрешения инцидента в bpm'online service 7.x

Добрый день, коллеги!

Интересует ваш опыт и мнение.
Как в рамках bpm'online органичнее реализовать возможность изменения сроков решения инцидентов? Иногда бывает так, что клиент сам просит решить инцидент (запрос на изменение, например) не в оговоренный SLA срок, а в запланированное время (например, через 2 недели). Или запрашиваемый сервис нестандартный, или заранее не может быть высчитан и требует анализа в каждом из случаем.

Насколько я понимаю, сейчас bpm'online однозначно автоматически считает срок разрешения (даже если реклассифицировать). Но в этом случае такие обращения однозначно будут просроченными, что несправедливо портит показатели.

Как лучше решить данную ситуацию?
Спасибо!

Нравится

1 комментарий

Добрый день, Владимир!

Сам термин SLA(соглашение об уровне предоставления услуги) подразумевает, что в таком соглашении содержиться детальное описание предоставляемого сервиса, в том числе перечень параметров качества, методов и средств их контроля, времени отклика поставщика на запрос от потребителя.
По этому наш продукт работает именно так.

Если у Вас возникают ситуации, которые Вы описали ранее, то вариантов решения могу предложить несколько (все они требуют проработки):

1) Выполнять преостановление выполнения обращения базовыми средствами используя состояние паузы "Ожидает ответа", Вы его можете переименовать по необходимости.
В таком случае сроки будут преостановлены. (и ставить задачу на ответственного с отображением в расписании даты последуещего созвона\согласования\ решения)

2)Суть аналогична с первым пунктом, но реализация чуть другая.
Можно создать поле "Дата согласованного решения", в котором будет выбираться дата, которую Вы согласовали с клиентом и реализовать логику, которая будет к срокам решения\реакции добавлять разницу времени, между указанными сроками и указанной даты в колонке "Дата согласованного решения". (в таком случае, желательно раздать права к такой колонке только группе пользователей у которой будут эти полномочия).

3) Разблокировать поля планового решения\реакции на изменения и раздать права на изменение только определенной группе пользователей\или пользователю. (но этот кейс в нашем понимании портит логику системы.)

Показать все комментарии