Подскажите пути настройки системы для внутренней поддержки

[Boriso]

Здравствуйте!

Установил OTRS, настроил идентификацию агентов через AD и был ошеломлён отсутствием возможности отправки агентами сообщений в собственную поддержку. Нашёл тему https://otrsteam.ideascale.com/a/dtd/Ag ... 5266-10369 , где предлагается агентам ходить через customer.pl. В примерах интеграции заказчиков с AD не нашёл возможности синхронизации. Мне кажется, что задача довольно распространённая, поэтому должно быть простое решение.

Хочу реализовать следующую функциональность. Основная задача - обеспечить поддержку заказчиков по продуктам, а также избавиться от внутренней email переписки, когда может быть несколько ответственных.

А) Есть очереди:

• it, accounting, head - очереди внутренней поддержки сотрудников, куда они пишут свои вопросы сотрудникам технической поддержки, бухгалтерии, руководству
• soft1, soft2, soft3, ... - очереди по отдельным программным продуктам, где сотрудники соответствующих отделов взаимодействуют в ходе работы, решают возникающие вопросы
• customer1_soft1, customer1_soft2, ... - очереди поддержки отдельных программных продуктов, установленных у заказчика 1
  ...
• customerN_softX, customerN_softY, ... - очереди поддержки отдельных программных продуктов, установленных у заказчика N

Б) Есть роли:

• staff - все сотрудники компании, могут создавать запросы в очередях внутренней поддержки, но не видят списки существующих запросов в этих очередях; созданные ранее запросы видят и могут отвечать на них
• it_support, accounting_support, head_support - сотрудники внутренних служб поддержки, которые могут просматривать запросы в соответствующих очередях и отвечать на запросы сотрудников; любой из сотрудников поддержки может создать и запрос в соответствующей очереди и назначить исполнителем другого сотрудника
• soft1_support, soft2_support, ... - сотрудники отделов, отвечающих за соответствующие программные продукты; могут создавать запросы и отвечать на них в рамках очередей soft1, soft2, ...
• customer1_soft1_support, customer1_soft2_support, ... - сотрудники поддержки заказчика 1 по соответствующим программным продуктам; могут просматривать соответствующие очереди и отвечать заказчику;
• customer1_soft1_comment, customer1_soft2_comment, ... - сотрудники поддержки программных продуктов, которые могут комментировать запросы заказчика 1, но не могут отправлять ответы;
  ...

В) Полномочия на работу с запросом определяются по матрице просмотра и отправки сообщений. Пользователь системы может иметь возможность просмотра сообщений в запросе, а может иметь возможность на просмотр и комментариев. Одновременно у него могут быть права только на просмотр, на просмотр и отправку сообщений или на просмотр и отправку комментариев. В результате получаются следующие полномочия для отдельного запроса:

1. "Наблюдатель заказчика" - видит лишь сообщения в запросе, но добавлять собственные не может;
2. "Заказчик" - видит лишь сообщения в запросе, но может отправлять собственные запросы в ответ;
3. "Наблюдатель поддержки" - видит и сообщения, и комментарии в запросе; собственные сообщения или комментарии отправлять не может;
4. "Участник поддержки" - видит и сообщения, и комментарии в запросе, но в запрос может оставлять лишь комментарии;
5. "Сотрудник поддержки" - видит и сообщения, и комментарии в запросе, причём может в запросе оставлять как комментарии, так и отвечать заказчику сообщениями.

Г) Каждому пользователю (или роли) на уровне очереди определяется:

• Возможность создания новых запросов в очереди;
• Возможность просмотра списка запросов в очереди;
• Полномочия на отдельные запросы (см. п. В) по умолчанию; эти полномочия автоматически распространяются на запросы в данной очереди, если не определено иное (см. ниже)

[Boriso]

(продолжение первого сообщения)

Д) На уровне отдельных запросов могут быть изменены общие полномочия для конкретного пользователя (выбор из ограниченного полномочиями справочника пользователей системы):

1. Пользователя можно сделать владельцем запроса (даже если у него нет прав на очередь и т.п.), в этом случае он получает права на данный запрос ("Участник поддержки" или "Сотрудник поддержки"); после того владельцем запроса становится кто-то другой, то пользователь опять получает базовые права на данный запрос;
2. Пользователю можно явно назначить любую из ролей ("Наблюдатель заказчика", "Заказчик", "Наблюдатель поддержки", "Участник поддержки", "Сотрудник поддержки"); если у пользователя есть одна из подобных ролей, то он видит запрос в списке запросов очереди; при необходимости роль можно у пользователя отнять.
3. Когда пользователь создаёт запрос (является его автором), то он автоматически получает роль "Заказчик" и возможность просмотра данного запроса в очереди.

Е) Дополнительно должны определяться ещё полномочия на присвоение ролей пользователям и т.п. Требуется настройка уведомлений по email, смена статусов запроса и т.д.


Подскажите, пожалуйста, есть ли возможность настроить подобное на OTRS и в какую сторону копать. Какие есть варианты?

В первую очередь сейчас интересует вопрос реализации агентов как авторов запросов, чтобы они могли из одного интерфейса как отвечать в одних очередях, так и создавать новые запросы в тех же очередях и других.


P.S. Мне совсем не ясна идея жёсткого разделения пользователей системы на агентов и заказчиков, поскольку это всё можно было бы сделать лишь полномочиями и согласно им настраивать отображение элементов интерфейса.

[merkushov]

По моему, почти всё что вы описали реализуемо. Единственное, не понял про "Полномочия на работу с запросом определяются по матрице просмотра и отправки сообщений".

Вопрос создания заявок Агентом меня тоже очень сильно интересует. Стандартное решение это создавать через "телефонную заявку", других приемлемых вариантов я не нашёл. Пытаюсь проанализировать возможность доработки OTRS под это дело. Если есть кто-то кто понимает внутреннее устройство системы и заинтересован в доработке, можем устроить мозговой штурм.

[ykolesnikov]

P.S. Мне совсем не ясна идея жёсткого разделения пользователей системы на агентов и заказчиков, поскольку это всё можно было бы сделать лишь полномочиями и согласно им настраивать отображение элементов интерфейса.

Коллеги, красиво излагаете, но!
Что такое внутренняя техподдержка? Почему агент, если ему нужна поддержка не может создать заявку как клиент? Это что - мания величия?
Большей частью агенты специализированы по функционалу - поддержка сетей, поддержка приложений, техобслуживание.... В нормальной компании каждый занимается своим делом. И что такого сложного и криминального, если агент по обслуживанию принтеров создает как клиент завку на установку приложения? Он в этом случае настоящий клиент и мало чем отличается от внешнего клиента, только компания у него своя, местная. И в отчетах по заявкам будет все нормально.
Ход с телефонной заявкой также в данном случае нормален, т.к. создавать заявку он будет от имени себя как клиента
Я вас не отговариваю - хозяин-барин, но видит бог здесь есть много над чем поработать в более принципиальных вещах.
Автору темы могу посоветовать только тщательно изучить мануал админа и основные понятия системы.
Как Вам ответил коллега, практически все реализуемо. Совмещайте свою терминологию с терминологией системы и пробуйте. Практически, функционал OTRS+ITSM покрывает многое из Управления Инцидентами, Проблемами, Изменениями и Конфигурациями по ITIL
Никого не хотел обидеть, если в чем-то задел, прошу извинить.