Вопрос по организации ответственности агентов.

[Maxwal]

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

Допустим есть 2 очереди: "ошибки" и "закупки" за каждый элемент отвечает по несколько человек. Клиент создает заявку по ошибке и она падает в соответствующую очередь. С этого момента начинаются непонятки. Агенты видят эту заявку и соответственно кто-то из них должен бы ее взять. Так вот как сделать чтобы заявки сразу падали на определенных агентов а не на группу, чтобы обеспечить ее выполнение и исключить вопрос "Кто виноват в невыполнении?" Что будет если агент уберет у себя в интерфейсе все "Мои очереди"?, он получается снимает с себя ответственность, как это искоренить?

Заранее спасибо.

[ykolesnikov]

Здесь есть 2 нюанса
1. Назначить агенту непосредственно клиентом заявку можно настройкой формы ввода заявки клиентом Ticket-->CustomerViewNew, но
2. А если он на вызове, в отпуске - заявка повиснет.
Выход в организации работы - либо менеджер(старший в группе), который просматривает очереди и назначает их конкретному агенту, либо регламент разбора заявок и способы контроля к нему.
Про "Мои очереди" - посмотрите в настройках Preferences для агентов в АдминКонфиге, можно ли заблокировать изменение их агентом, но по-моему вряд ли. Тогда контроль и "пирожок с полочки" за нарушение правил

[Maxwal]

Первый вариант отпадает. Клиента это не должно касаться.

Тут же возникает другой момент. От нежелания брать ответственность агенты могут кидаться заявкой друг-другу что тоже не хорошо.

Брать человека чтобы тот распределял заявки пока нет возможности, нас пока двое но взглянув в будущее понимаю что среди агентов может всегда начаться беспредел. Думал что как раз за равномерное распределение, организацию работы и своевременное выполнение должна отвечать такая система.

[ykolesnikov]

Система не может отвечать за распределение заявок, она не знает сколько времени займет работа по заявке. А если вас двое и нет начальника, надо договариваться. Хоть на пальцах кидайте.Если у вас есть распределение обязанностей, скажем один отвечает за настройку программщины, другой за картриджи, то можно добавить очереди по специализации и объяснить клиентам что куда направлять. Чудес не бывает, по крайней мере я таких систем не знаю.

[alexus]

Это не вопрос для настройки OTRS!
Это вопрос внутренней организации работы. Я вас уверяю, что в компаниях, где стоят решения HP, BMC etc., "футбол" заявок - такое же распространенное явление. Вас спасут только регламенты, "волшебные пендали" и пряники. И, Эврика!, - эскалация! Это как и есть механизм своевременного уведомления (контроля) начальства о том, что в силу тех или иных обстоятельств заявка не выполняется вовремя, как обещали клиенту. И дает гандикап для принятия управленческих решений.
То, что Вы смотрите в будущее, это замечательно! И Вы правильно видите все потенциальные проблемы. OTRS дает вам инструменты для их решения. Но это только инструменты, а не само решение. Решать эти проблемы должен человек-менеджер-начальник-директор-владелец!
И пользуясь правами модератора я перемещаю ветку в раздел методических вопросов. Ибо там самое ей место!

[Maxwal]

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

Тогда наверно обозначу вопрос иначе. Как в ваших компаниях это организовано? Ведь есть же такие Титаны как маилру, который успешно применяет ОТРС или именно из-за этого возникает негатив к ТП, потому что заявка может неограниченно долго гулять, каждый будет снимать с себя ответственность передавая на более "компетентного" товарища, до тех пор пока начальство не посмотрит и выяснится что "Кто последний тот и папа".

P/s По поводу изменения владельца - перекидывания друг на друга тоже разобрался

[yuri0001]

Здесь нет противоречий! Перемещать можно, но в нужный момент может и должен вмешаться арбитр/цербер/продавец пряников. А у титанов есть менеджеры заявок и они занимаются анализом и арбитражем. Есть еще механизм владельцев и ответственных за заявку, ну и, ЭСКАЛАЦИЯ, о чем уже Алексей и говорил. Все решения зависят от объемов и даже, если агентов двое, руководитель, если не хочет сам заниматься распределением работы, должен из двух равных выбрать того равнее. На то он и chief

[alexus]

1. Менять владельца тикета внутри очереди - почему нет? Бывают разные ситуации, в т.ч. и жизненные.
2. Менять очереди агентам - конечно, нет. Но как вы настроите, куда дадите доступ, там и будет агент работать.

На Хабре есть отличный пример, где Mail написал, как успешно они используют OTRS в своей поддержке. Там, конечно, народ, особенно обозленный, проехался по всей их техподдержке весьма неслабо ! Но, что характерно, все проблемные ситуации были связаны, по моему мнению именно с неправильной постановкой работы.

У нас, например, очереди разделены на 1-ую и 2-ую линию. В каждой очереди все имеют право брать любые незаблокированные заявки. Для всех заявок указывается сервис. Для каждого сервиса прописан SLA. Контроль времени исполнения осуществляется руководством с помощью эскалаций

Вторая система у нас используется для управления проектами. Там другие критерии доступа. Там эскалация осуществляется на основе параметров очередей. Руководство контролирует процесс общения с клиентом, чтобы во время отправлялись ответы, чтобы отслеживать время молчания клиента. Сроки исполнения для проектов, в онсновном, не используются, если это не проекты, например, по модернизации ИТ-инфраструктуры. Там если сроки прописаны в договоре, за ними тоже следим.
Мы - не монстры типа мейл-ру. У нас разбрры полетов происходят быстро и эффективно.

[dragushin]

Здравствуйте,
Коллеги, подскажите, возможно в OTRS 4 Free реализовать возможность ответственному за заявку создавать задачи агентам?

[ykolesnikov]

Коллеги, подскажите, возможно в OTRS 4 Free реализовать возможность ответственному за заявку создавать задачи агентам?

Сразу пачка вопросов/пояснений:
1. Что есть задача?
2. Способность агента создавать заявки зависит от его прав в группах, т.е наличие, как минимум права "create" для группы связанной с очередью для которой создается заявка.
3. От чьего имени создается задача/заявка.
4. Есть возможность разделить заявку и порожденная заявка останется связанной с исходной.
Возможностей много, поясните подробней что и для чего хотите сделать.
Кстати, в OTRS/ITSM - задача, это термин из Управления Изменениями и это уже другая кухня, но Вы, похоже, имеете в виду что-то другое.

P.S. Этот вопрос не относится к методическим вопросам ITSM, это просто вопрос по функционалу системы и его следует задать в другом разделе.

[dragushin]

Огромное спасибо за оперативный ответ.
1. Задача есть и она следующая, в решении запроса от пользователя как правило принимают участие несколько инженеров. Выглядит это следующим образом, пользователь открывает запрос, далее назначается ответственный за решение этого запроса, а он по необходимости может привлекать к решению запроса других инженеров создавая им задачи. Инженера решают задачи, списывают трудозатраты, ответственный все проверяет, если ОК - запрос переходит в решенные, клиент подтверждает, запрос закрывается. Как то так...
пример:
http://gyazo.com/9f26e90c59d2ee89d4588eb877753b56

2. Права агенту дал, но кнопки "Добавить задачу" в заявке не увидел.

3. Заявку создает клиент, а задачу в рамках заявки должен создавать ответственный (владелец) за решение заявки.

4. Спасибо за совет, если не найдем решения так и будем делать.

PS: Прошу прощения, понимаю что вопрос не относится к методическим вопросам ITSM, но у меня еще нет прав создавать темы, а тут затрагивается вопрос с ответственными, вот и решил задать свой вопрос в этой ветке.
Спасибо!

[dragushin]

Вот о чем я
http://gyazo.com/a8241434d419acccde69e15add260dac

[ykolesnikov]

Кнопки "Добавить задачу" нет а природе. Но агент может либо разделить свою заявку - кнопка "Разделить" ниже перечня заметок и далее все идет как создание новой телефонной заявки, но порожденная заявка становится связанной с родительской и отображается в TicketZoom, внизу экрана. При этом агент, по выбору, может ее создать как от своего имени, как клиента или оставить в качестве клиента порожденной заявки первоначального клиента, инициатора запроса. Здесь есть оргвопросы, но они все решаемы.
Либо идти по ветке Управление изменениями, т.е. установить пакет ITSM и использовать его функционал, т.е., на основании заявки на изменение, создается Изменение (Change) (терминология OTRS::ITSM) и к нему создаются задачи/workorders, которые можно связать условиями и т.д. Это сложнее, но при хорошо продуманных процессах можно выстроить все правильно. Здесь можно выстроить все по ITIL, с согласованиями и т.п и т.д. Изучайте, возможностей много.

[ykolesnikov]

Вот о чем я
http://gyazo.com/a8241434d419acccde69e15add260dac

Такой кнопки в стандартном функционале нет. Есть дополнительные Add-on's поставляемые за деньги или по подписке на поддержку, там есть пакеты реализующие workflow. Смотрите на официальном сайте OTRS или обратитесь к Алексею Юсову/alexus ("Радиант" - российский партнер OTRS)

[dragushin]

Понял, значит пойдем по пути разделения, большой спасибо!

[ykolesnikov]

Это наиболее простой путь, но советую посмотреть и на Упраление Изменениями/ITSM ChangeManagement

[LizSamor]

Введите KPI - и ваши агенты будут круглосуточно охотиться за новыми заявками, перехватывая их друг у друга, только чтобы получить лишний плюсик к карме

[alexus]

Введите KPI - и ваши агенты будут круглосуточно охотиться за новыми заявками, перехватывая их друг у друга, только чтобы получить лишний плюсик к карме

Даже самые правильные KPI не решают проблемы эффективности. KPI - это даже меньше, чем полдела.

[ykolesnikov]

Согласен с Алексеем. Разработка KPI - задача нетривиальная и творческая, алгоритма для нее нет, а следовательно, это отдельный проект с непредсказуемым результатом. Лучшие рекомендации Гуру от KPI могут остаться лишь рекомендациями при столкновении с менталитетом и формальным подходом. Так что пробуйте всё, но не ради привлекательных терминов, а дела для! Тут, как говорится - "...все жанры хороши, кроме скучного...".