Меню

Otrs настройка шаблона заявки

Otrs настройка шаблона заявки

OTRS позволяет изменять предопределенные состояния заявок и их типы, а также добавлять новые. Для состояния важны два атрибута: имя (state-name) и тип (state-type).

Предустановленные состояния в OTRS: «закрыто успешно», «закрыто неудачно», «обьеденено», «новая», «открытая», «в ожидании с автозакрытием+», «в ожидании с автозакрытием-«, «в ожидании с напоминанием», «удаленная».

Новая

Заявки находятся в этом состоянии, когда они создаются на основе входящих сообщений электронной почты.

Открытая

Это состояние по умолчанию для заявок, которые присвоены очередям или агентам.

Ожидание с напоминанием

После того как время ожидания истекло, владелец заявки будет получать напоминание на электронную почту. Если заявка не закрыта, то напоминание о заявке будет отправлено всем агентам в очереди. Напоминание о заявках будет отправлено только в рабочее время и будет повторятся каждые 24-часа, пока агент не изменит состояние заявки. Время, которое заявка проведет с таким статусом будет добавлено к времени эскалации.

Если время ожидания вышло, заявки с этим статусом будут установлены в «Закрытые неуспешно». Время, проведенное заявкой в этом статусе будет добавлено к времени эскалации.

Ожидание авто-закрытие+

Если вышло время ожидания, заявки с этим статусом будут установлены в «Закрыто Успешно». Время, проведенное заявкой в этом статусе будет добавлено к времени эскалации.

Обьедененные

Это состояние для заявок, которые были объеденены с другими заявками.

Removed

This is the state for tickets that have been removed by the customer. Tickets will not really be deleted, they are just no longer shown as open. In order to enable this state in the customer interface you need to add the state type «removed» to the sysconfig setting «Ticket::Frontend::CustomerTicketZoom###StateType».

Закрыта Успешно

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

Закрыта Неудачно

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

Настраиваемы состояния

Every state has a name (state-name) and a type (state-type). Click on the States link on the Admin page and press the button «Add state» to create a new state. You can freely choose the name of a new state. The state types can not be changed via the web interface. The database has to be directly modified if you want to add new types or change existing names. The default state types should typically not be modified as this can yield unpredictable results. For instance, escalation calculations and the unlock feature are based on specific state types.

Имя/название уже существующего состояния может быть изменено или новые состояния добавлены на этом экране. Если состояние «new» было изменено в веб-интерфейсе, это состояние также должно быть настроено в Kernel/Config.pm или через SysConfig. Параметры заданные в сценарии приведенном ниже должны быть изменены, чтобы убедиться в том, что OTRS работает с измененным состоянием для бывшего «new».

Сценарий: Изменение параметров настройки в Kernel/Config.pm.

Если нужно добавить новый тип состояния, то это можно сделать с помощью клиентской программы управления базами данных, изменив таблицу ticket_state_type базы данных OTRS, как это показано в нижеприведенном сценарии

Script: Изменение базы данных OTRS.

На данный момент можно использовать новый тип состояния, который вы только что создали. Как только состояние будет связано с этим новым типом состояния, то чтобы убедится что новое состояние используется и работает коректно нужно также изменить настройки OTRS. Используя SysConfig внесите изменения в следующие опции:

Ticket Priorities

OTRS поставляется с пятью предустановлеными уровнями приоритетов, которые можно изменить перейдя по ссылке «Приоритеты» на Панели Администрирования. При создании настраиваемого списка приоритетов, пожалуйста помните, что они сортируются в алфавитном порядке. Также OTRS сортирует заявки в QueueView по их внутреннему номеру (ID).

Читайте также:  Настройка cisco air sap

Important

Если был создан новый приоритет, или был изменен уже существующий, то можно также произвести изменения некоторых параметров в SysConfig:

Ответственность за Заявку & Наблюдение за Заявкой

Начиная с OTRS 2.1 и выше, в дополнение к владельцу заявки можно определить ответственного за нее агента. Кроме того, все мероприятия, связанные с заявкой могут просматриваться не только владельцем но другими людьми. Эти две возможности системы реализованы с помощью функций TicketResponsible и TicketWatcher и также позволяют работать в рамках иерархической структуры команды.

Ответственность за Заявку

The ticket responsibility feature facilitates the complete processing of a ticket by an agent other than the ticket owner. Thus an agent who has locked a ticket can pass it on to another agent, who is not the ticket owner, in order for the second to respond to a customer request. After the request has been dealt with, the first agent can withdraw the ticket responsibility from the second agent.

With the configuration parameter Ticket::Responsible, the ticket responsibility feature can be activated. This will cause 3 new links to appear in the ticket activities menu of a zoomed ticket in the agent interface.

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

Figure 4.82. Changing the Responsibility of a ticket in its zoomed view

After clicking on «Responsible», a pop-up dialog to change the responsibility of that ticket will open (see figure below). This dialog can also be used to send a message to the new responsible agent.

Figure 4.83. Pop-up dialog to change a ticket’s responsibility

Если активирована функция ответственности за заявку, то в шаблоне Ответственность, агентского веб-интерфейса OTRS можно просмотреть список всех заявок, за которые агент несет ответственность.

Просмотр Заявок

Начиная с OTRS 2.1 и выше с помощью функции TicketWatcher, выбранные агенты, такие как, например, руководители могут просматривать определенные заявки без их обработки.

The TicketWatcher feature can be activated with the configuration parameter Ticket::Watcher which adds new links to your actions toolbar. Using Ticket::WatcherGroup, one or more user groups with permission to watch tickets can also be defined.

In order to watch a ticket, go to its zoomed view and click on the «Subscribe» link in the ticket activities menu (see figure below).

Figure 4.84. Subscribing to watching a ticket in its zoomed view

If you no longer want to watch a specific ticket, go to its zoomed view and click on the «Unsubscribe» link in the ticket activities menu (see figure below).

Figure 4.85. Unsubscribing from watching a ticket in its zoomed view

The list of all watched tickets can be accessed through the Watched view of the OTRS agent interface (see figure below), as soon as the ticket watcher feature gets activated.

Источник

OTRS.ru

Русскоязычное сообщество OTRS Helpdesk и OTRS ITSM

Как добавить поле в форму (или шаблон) заявки клиента?

Модератор: ykolesnikov

Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение Лебедев Игорь » 05 окт 2010, 21:21

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение alexus » 05 окт 2010, 23:06

А для чего вам нужно отдельное поле? Клиент может вполне написать в теле письма дату и время и дополнительно указать приоритет. А при установленном ITSM агент может ставить отметки о времени начала и завершения работ.
Тут, как мне кажется, Вам следует методологически определиться. С точки зрения ITSM, запрос срока исполнения должен соответствовать SLA с данным клиентом, а не выставляться самим клиентом как обязательный параметр тикета.

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

С уважением,
OTRS.ru

С уважением,
Алексей Юсов

Prod: OTRS ITSM 5.0.14 on CentOS 7 x64 Linux with MySQL 5.7

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение alexus » 06 окт 2010, 00:45

С уважением,
OTRS.ru

С уважением,
Алексей Юсов

Prod: OTRS ITSM 5.0.14 on CentOS 7 x64 Linux with MySQL 5.7

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение Лебедев Игорь » 12 окт 2010, 08:26

С уважением,
OTRS.ru

Подвопрос

Сообщение Лебедев Игорь » 12 окт 2010, 08:44

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение alexus » 12 окт 2010, 10:09

С уважением,
Алексей Юсов

Prod: OTRS ITSM 5.0.14 on CentOS 7 x64 Linux with MySQL 5.7

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение Лебедев Игорь » 12 окт 2010, 22:02

alexus писал(а): А для чего вам нужно отдельное поле? Клиент может вполне написать в теле письма дату и время и дополнительно указать приоритет. А при установленном ITSM агент может ставить отметки о времени начала и завершения работ.
Тут, как мне кажется, Вам следует методологически определиться. С точки зрения ITSM, запрос срока исполнения должен соответствовать SLA с данным клиентом, а не выставляться самим клиентом как обязательный параметр тикета.

С уважением,
OTRS.ru

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение alexus » 12 окт 2010, 22:55

С уважением,
Алексей Юсов

Prod: OTRS ITSM 5.0.14 on CentOS 7 x64 Linux with MySQL 5.7

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение Лебедев Игорь » 14 окт 2010, 14:34

Re: Как добавить поле в форму (или шаблон) заявки клиента?

Сообщение ULiX » 15 окт 2010, 05:42

В интерфейсе клиентов:
http://. /otrs/customer.pl
на панели есть пункт «Заявки компании».
Если пользователи в одной компании, то их заявки будут отображены при выборе данного пункта.

А теперь важный момент.
В конфигах есть параметр:
[ ‘UserCustomerIDs’, ‘CustomerIDs’, ‘customer_ids’, 1, 0, ‘var’, », 0 ],

Вот эта запись задает поле в AD или в базе где хранятся ID всех кустомеров одной компании. Через точку с запятой или запятую, или ‘|’, именно в таком порядке приоритета.
Хм. как-то неудобно.
Если это LDAP то у каждого пользователя должно быть поле со списком всех остальных пользователей его компании.
Изучу ещё немного этот вопрос, может чего ещё найду.

Вот часть кода, которая возвращает заявки при выборе «Заявки компании»

Тут ключевой параметр CustomerID с массивом CustomerIDs. Нужно перечислить ID всех пользователей в компании.
В данный момент для определения спсика IDs делается один запрос чтения поля из базы, и парсится строка этого самого списка.

С LDAP такие преобразования сделать будет просто. Тем более что у пользователя в AD уже есть готовый под это дело атрибут company.
Потребуется пропатчить файлик
\otrs\Kernel\System\CustomerUser\LDAP.pm
в частности функцию: CustomerIDs.

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

Раздел мануала
11.2.1.1. Customer with multiple IDs (Company tickets)
подтверждает мои выводы по поводу компаний.

Источник

Создание тикет-системы на базе OTRS

В данный момент у компании EFSOL для поддержки клиентов, а также внутренних сервисов используется платная тикет-система, которую мы получаем по модели SaaS. Со стороны функционала претензий к системе нет. Однако, мы задумались о другом решении для организации тикет-системы из-за экономических факторов:

Читайте также:  Контекстное меню windows 10 настройка

Выбор решения для тикет-системы

Поиск тикет-системы производился, используя следующие требования:

Были обозначены цели, которые планируем достичь с использованием новой тикет-системы:

Из всех решений, которые были рассмотрены, наиболее подходящим показался OTRS.

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

Термин Обозначение
1 Заявка (Тикет) Любое обращение в службу технической поддержки.
2 Инцидент Незапланированное прерывание сервиса или снижение качества его работы. Например выход из строя оборудования, медленная работа сервисов.
3 Запрос на обслуживание Запрос от пользователя для предоставления консультации или выполнения плановых действий, например, установка нового ПО или оборудования.
4 Клиент Внешний пользователь системы. Тот, кто формирует заявку.
5 Агент Внутренний пользователь системы. Тот, кто заявку обрабатывает
6 Очередь Место расположения заявки, сущность, которая позволяет разделить общий массив заявок.
7 Каталог услуг База данных или документ, который содержит перечень услуг, предоставляемых клиенту.
8 SLA Соглашение об уровне услуг. Соглашение, в котором регламентированы сроки решения заявок в зависимости от услуги, типа заявки и ее приоритета.
9 Блокировка заявки Агент, когда принимает заявку к выполнению, становится ее владельцем и, таким образом, блокирует заявку. Заблокированная заявка не видна другим агентам очереди и они не могут ее закрыть.

Обзор OTRS

Рассмотрим функционал системы, который можно получить сразу после установки и базовой настройки:

Далее необходимо сопоставить приоритет заявки с ее типом и SLA. В таблице ниже настраивается матрица какой ID SLA будет выбран при определенном ID типа заявки и приоритете.

Оператор проводит классификацию заявки указывая приоритет и сервис. Далее может закрыть ее сам или же передать другому оператору или в другую очередь.

Настройка системы OTRS

Для реализации первого этапа установили систему и начали ее настройку.

Базовая настройка

После того как система была установлена, ее нужно было настроить.

В результате получился инструмент, позволяющий использовать такой функционал:

Базовая кастомизация

Для соответствия системы потребностям компании выполнили небольшую кастомизацию:

Настроен SLA. Регламентное время решения заявки вычисляется в зависимости от типа заявки (запрос на обслуживание или инцидент), приоритета и сервиса. Настроено рабочее время. Также выполнен расчет приоритета в зависимости от срочности и критичности заявки. Изначально в заявках есть только параметр приоритета.

Настроено ограничение на прием заявок. Настроили прием заявок только с почты клиентов или агентов. С адресов, не зарегистрированных в системе, заявки не принимаются, в ответ отправляется уведомление о незарегистрированном адресе.

Реализован механизм оценки заявок. При закрытии заявки исполнителем, автор получает уведомление с просьбой принять выполнение заявки и поставить оценку. Если у автора есть замечания, он отвечает на данное письмо и заявка возобновляется в работу, а его ответ крепиться комментарием к заявке.

Реализован механизм подсчета возвращенных заявок. Количество возвращенных заявок и количество раз, которое они были возвращены является очень важным показателем качества работы ИТ-службы, поэтому в форму заявки был добавлен счетчик возобновления заявок.

Отчеты

Для оценки качества работы ИТ-подразделения пока решили использовать 3 отчета:

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

Отчет «Возвращенные заявки». Показывает количество возвращенных заявок в абсолютном и процентном соотношении и показывает сколько раз была возвращена конкретно каждая заявка.

Планы по дальнейшему развитию

В будущем планируется реализовать следующий функционал:

Вывод

Мы запустили готовую тикет-систему в облаке и предлагаем её в аренду.

EFSOL Системная интеграция. Консалтинг

Источник

Adblock
detector