Добрый день, коллеги.
Можете ли поделиться Best practice реализации кейса в BPM из коробки?
В ServiceDesk требуется завести группы исполнителей.
Группа исполнителей != организационая группа. К примеру, в группе исполнителей - "системные администраторы" будут сотрудники двух организационных групп - "Сетевой инфраструктуры" и "Серверной инфраструктуры". Т.о. группа исполнителей может состоять из части организационной группы или из двух (частей) групп.
Изначально предполагалось использование функциональных ролей для этой цели, но в ходе (зачёркнуто)принятия неизбежного понимания принципов работы BPM из коробки, пришёл к выводу, что данной сущностью не решить задачу.
Нравится
В платном дополнении «Task Control for bpm’online» есть в том числе и постановка задачи на функциональную роль. Если и не покупать, то можно поставить тестовую версию и посмотреть, какой подход авторы программы реализовали.
Григорий Чех,
Получается какой-то костыльный способ - создать БПроц, с целью назначения тикета на группу, после чего его на себя забирает конкретный специалист.
Я в целом не могу понять, для чего, тогда нужны функциональные роли? В логику системы из коробки заложено, что назначать обращения я могу только на организационную роль - реально существующий отдел.
В моём понимании функциональная роль - подразделение или сотрудник состоящий в какой-то команде (возможно, созданной между отделами или внутри отдела), выполняющий узкоспециализированные действия. К примеру - инженер IT-подразделения, задействованный в проекте разработки сервиса.
Статью читал, спасибо, вопросы остались по прежнему.
Помогите, пожалуйста, понять логику.
Предположим, что у меня есть команда проекта, в которой состоят сотрудники различных подразделений, функциональная роль - "Группа сопровождения проекта X".
Поступает обращение от клиентов по "проекту Х", которое эскалируется до функционального подразделения.
Вот тут основная проблема - как эскалировать кейс до функционального подразделения?
Подразделение — это не функциональная роль, а организационная.
Зверев Александр,
Получается, в контексте моего примера команда проекта должна быть организационной ролью? И из этого вытекает второй вопрос - само название "организационная роль" отношения к организационной структуре моей организации не имеет, чуть более, чем полностью?
Что мешает включать в несколько организационных одновременно? Вы же сами говорите, что это подразделение.
И более того, функциональные роли используются для предоставления доступа к разделам системы, но организационные для назначения задач и обращений. Верно ли я понимаю?
Зверев Александр,
Смущает название + наличие синхронизации с LDAP, из которого вытягивается иерархия доменной структуры.
Автоматически предполагаешь, что организационная роль на то и есть, чтобы вытянуть структуру организации.
Доступ можно выставлять хоть функциональным, хоть организационным, хоть отдельным пользователям.
Зверев Александр,
Проблема в том, что тикет я могу назначить только на организационную роль, но "вытянуть" из LDAP и привязать к организационной роли подразделение могу, лишь, единожды.
В таком случае рассмотрите дополнение из второго комментария, позволяющее ставить задачи на функциональные роли.