Документ взят из кэша поисковой машины. Адрес оригинального документа :
http://wiki.cs.msu.ru/Main/StartOTRS?cover=print;raw=on
Дата изменения: Unknown
Дата индексирования: Sun Apr 10 14:44:18 2016
Кодировка: koi8-r
---+!! Использование OTRS %TOC% ---++ Введение или что это такое * *OTRS* — это система обработки инцидентов/заявок от участников/пользователей/заявителей, т.е. от людей с ролью: * *Клиент(Customer)* — человек, у которого *Проблема* (иначе зачем ему писать письмо, звонить, …). * *Проблема* — что-то, что хочет *Клиент* (зарегистрироваться, чтобы мы что-то сделали, чтобы мы чего-то не делали — не важно). * *Заявка(Ticket)* — трек, описывающий ход решения проблемы. Порождается действием *Клиента* (письмом, звонком, …). * *Агент(Agent)* — менеджер, который участвует в решении проблемы. Агентов может быть несколько, они могут делиться по уровню ответственности, направлению решаемых задач и т. д. * *Владелец(Owner)* заявки — агент, который взялся решать данную проблему. * *Ответственный (Responsible)* за тикет — агент, который решает данную проблему. Разница с владельцем в том, что владелец может делегировать решение другому агенту (сделать его текущим ответственным), но в целом именно владелец отвечает за заявку. * Агенты могут оставлять *Заметки(Note)* к заявке. Технически с заявкой также связаны понятия: * <b>Очередь (Queue)</b>— в которой лежит заявка. * Очередь может быть внутри другой очереди (т.е. быть её подочередью), права никак не зависят. * *Группа (Group)* — определяет права на очередь. Рассматривается версия OTRS 3.3, [[http://doc.otrs.org/3.3/ru/html/][официальную документацию можно посмотреть здесь]] При использовании OTRS следует помнить, что разрабатывалась она для скорейшего решения проблемы, поэтому, например: * оповещения о новых заявках поступают только заинтересованным именно в этих заявках * изначально (можно поменять) оповещения о своих действиях не приходят (что исключает возможность перепутать с другими оповещениями) * многие действия по заявке могут быть совмещены, например: * можно оставить внутренний комментарий и закрыть * или ответить и закрыть/изменить статус * можно при смене очереди сразу сменить и владельца ---++ Почему нельзя обойтись просто почтой Почта — это отличный инструмент, более того, OTRS использует почту как механизм общения между Заявителем и Агентом. Чтобы организовать совместную работу через почту существует два способа: * все письма на адрес support@ приходят всем агентам, которые ответственны за входящую почту, но этот случай мы далее рассматривать не будем, т.к. имеются следующие недостатки: * ответы агента видит только агент * непонятно, кто на какие письма должен отвечать (как поделить письма: по алфавиту (и должен ли агент обрабатывать заявку и от Андрея Яшина и Яшина Андрея?) * агенты вынуждены читать письма (заголовки писем), которые к ним не имеют отношения. * либо все агенты имеют доступ к одному ящику через IMAP-протокол: * прочитанное письмо отличается от непрочитанного (т.е. можно делить так: берем непрочитанное и обрабатываем) * проблема: как отличить нами прочитанное от другим человеком прочитанное? * А если письмо открыли, но прочитать не успели? Вспомнит ли агент про него? * ответы на письма лежат в одном месте (теоретически к переписке можно подключить другого агента) Ниже мы рассмотрим разные примеры, чтобы ответить на вопрос, чем OTRS лучше, чем просто почта, а пока можно отметить следующие особенности: * Заявка не может быть удалена (в то время как письмо удалить легко и менеджер искренне будет доказывать, что письма не было вообще). * при этом запись/удаление должны работать, т.к. у письма есть статус прочитано/не прочитано, а, скажем, для Maildir-хранения это — перекладывание из директории new в директорию cur * Вся переписка в Заявке хранится в одном месте * письма почтовые клиенты тоже научились группировать/показывать списком (письмо-ответ-ответ на ответ-...) * но делают они это по теме письма, поэтому в группу может попасть и просто похожее письмо. * Всегда видно, на какие заявки дан ответ, а на какие — нет. Письмо можно пометить, как прочитанное, но найти все письма, на которые не был дан ответ — задача не тривиальная. * тем более, что на ответное письмо вида "да, теперь всё хорошо" отвечать и не требуется. ---++ Аналогия Рассмотрим пример: * Заявка: это папка с документами по данной проблеме (будем называть ее дальше делом). Создается секретарем: * либо по письму, принесенному почтальоном * либо по звонку по телефону, * либо еще как. * Секретарь (который выполняет работу OTRS) присваивает делу номер и относит его в кабинет (это аналогия очереди) * в какой кабинет — определяет инструкция * также оповещает агентов, что поступило новое дело. Список оповещения формируют сами агенты. * Агент может придти в кабинет: * узнав о новом деле от секретаря * просто просматривая интересующие его кабинеты (в OTRS &mdash мои очереди) * узнав, что ему передали какое-то дело (о чем его тоже оповестит секретарь) * и т.д. * Кабинеты поделены на группы (например, цвета) и электронный ключ агента дает одинаковые права к кабинетам одного цвета: * в какие-то кабинеты он не войдет * куда-то может только забросить дело (в лоток для входящих дел, секретарь оповестит нужных агентов) * где-то может войти и только просмотреть дела (т.е. получает копию дела, на исходное дело никак повлиять не может), а где-то — и оставить свои заметки/комментарии * где-то есть и полный доступ (но дело нельзя испортить, т.е. мы получаем тоже копию дела, но можем поручить секретарю отослать письмо по этому делу) * Некоторые кабинеты для удобства стоят за другими кабинетами, например за кабинетом по починке техники может стоять кабинет по починке именно мониторов: * если секретарь видит, что дело о починке, он поднимается на нужный этаж и идет к кабинету починки техники, * если же понимает, что это не просто техника, а монитор, то он может сам отнести в кабинет по мониторам * если даже и ошибется, то специалисты из кабинета по технике перенесут в соседний кабинет сами * починка мониторов может быть более ответственной/специализированной работой и кабинет по мониторам может иметь: * отдельный цвет доступа * своих узконаправленных специалистов, которым не хочется давать доступ к другой технике (т.е. доступ в кабинет по остальной технике) * в нашем примере: * починка просто техники вообще — основная очередь/кабинет * починка мониторов — вспомогательный кабинет/подочередь * Для работы над делом агент может забрать дело к себе на стол (или секретарь/другой полномочный сотрудник положит ему сразу на стол), т.е. стать владельцем дела * при этом дело не покидает границ кабинета (хотя в жизни у агента не бывает по столу в каждом кабинете) * он может взять любое дело, не обязательно первое * В процессе работы в деле появляются новые данные (их подшивает секретарь): * комментарии/заметки от агентов * копии их писем к клиенту и ответы клиента (ответы с делом сопоставляет тоже секретарь) * другие дела, если их решили объединить с данным делом * и т.д. * Агент может передавать дело другому агенту, относить на подпись и т.д. * В результате над делом работают, пока оно не закроется: * успешно, если задача решена (проблема устранена) * или не успешно (скажем, решить её в данных условиях нельзя или, скажем, надобность в решении отпала) ---++ Базовые операции Подробно рассмотрены на странице, [[SimpleOTRS][посвященной базовым операциям в OTRS]] В частности, о том: * как настраивать внешний вид системы * что/как можно сделать с заявкой В дальнейших сценариях будем предполагать (если не указано другое), что заявка уже открыта (т.е. процедура выбора заявки через дайджест, через ссылку в почте и т.д. - выполнена). ---++ Действующие лица для примеров Чтобы было понятнее, рассмотрим какие разные типажи/роли у нас могут работать с системой. В одном человеке может сочетаться несколько типажей, в зависимости от ситуации может быть один или другой. Администратор: * человек, который может вносить изменения в систему. Сразу можно сказать, что он должен иметь права на запись в группе admins Агенты: * агент-секретарь: * может понять, в какой отдел должна адресоваться заявка и даже запрашивать недостающие данные при наличии инструкции * агент-стажер: * тот, кто еще только учится по данному направлению. Возможно он сильный специалист в другой области. * агент-спец (специальный), для которого общение напрямую с клиентом нежелательно, т.е. это, например, из-за того, что он: * агент-консультант: специалист в узкой области; * агент-авторизатор: разрешает или нет определенные действия другому агенту; * агент-мизантроп/агент-грубиян: может быть хорошим техническим специалистом, но с людьми лучше ему не общаться; * агент-молчун: слабое владение языком клиента (возможно и родным для агента); * агент-наблюдатель: ему требуется доступ на уровне агента, но не желательно, чтобы он мог влиять на систему Клиенты: * клиент-чаво: способен задать вопрос, на который уже вывешен ответ; * клиент-взрыв: быстро обижающийся клиент (понятие относительное, т.к. при столкновении с грубияном в эту категорию можно занести почти всех); Дополнительно: * внешний специалист: он не находится в системе (не является агентом), но потребовалось взаимодействие с ним. ---++ Сценарии ---+++ Универсальный сценарий ---+++ Письмо от клиента-чаво Это простой сценарий, т.к. оператору ничего придумывать не нужно: * Поскольку вопрос стандартный, то на него уже есть стандартный ответ. * Если таких заявок может быть несколько/много, то администратору стоит завести шаблон ответа для часто задаваемых вопросов * о создании шаблона можно посмотреть [[TechOTRS][в технических подробностях об OTRS]] [[TicketAnswerOTRS][Об использовании шаблона при ответе]] ---+++ Согласование/консультация Это как раз тот случай, когда требуется помощь агента-спеца. Примеры: * не хватает знаний (по какой-нибудь узкой теме, т.е. требуется помощь агента-консультанта) * не хватает прав (требуется помощь агента-авторизатора) * и т.д. В этом случае в обработке заявки добавляются дополнительные шаги (т.к. согласований может быть несколько, потребность может возникнуть не сразу и т.д.): * текущий исполнитель каким-нибудь образом передает заявку нужному агенту: * меняя ответственного [[TicketResponsibleOTRS][Подробнее о смене ответственного]] * перенося в очередь согласования, что лучше предыдущего случая, если согласующих может быть несколько. [[TicketMoveOTRS][Подробнее о перемещении в другую очередь]] * согласовывающий агент после этого может: * написать внутреннюю заметку (если информация не предназначена непосредственно для заявителя) * вступить в переписку с заявителем (если это требуется/разрешено) * как завершающее действие — вернуть предыдущему агенту (или передать заявку дальше по аналогичной схеме) ---+++ Консультация с внешним специалистом Похоже на предыдущий пункт, но т.к. внешний специалист не входит в систему (не является агентом),то алгоритм работы немного меняется: * текущий агент пересылает информацию по заявке внешнему специалисту ( [[TicketMailOTRS][через почту, подробнее ...]]) * агент должен сам контролировать процесс решения задачи внешним специалистом (т.е. убедиться, что письмо дошло и т.д.) * внешний специалист отвечает на письмо, ответ автоматически попадает в заявку. * агент принимает решение о дальнейшей обработке заявки. ---+++ Обработка "плохих" заявок Не все сообщения/заявки, которые попадут в систему, являются хорошими. Могут быть: * заявки рекламного содержания (спам) * заявки оскорбительного содержания * и т.д. Возникают вопросы: * как уменьшить/предотвратить (это уже вопрос к администратору OTRS и почтовой системы, поэтому на этот вопрос мы здесь отвечать не будем) * что делать с уже созданными заявками (будем считать, что у нас их несколько, хотя алгоритм подходит и для работы с одной заявкой) Итак, у нас есть несколько плохих заявок: * Агент каким-то способом получает список заявок, в котором есть эти "плохие заявки" (методы рассмотрены в [[TicketBulkActionOTRS][массовой обработке заявок]]) * с помощью [[TicketBulkActionOTRS][уже знакомой массовой обработки заявок]]говорит системе, что они будут: * закрыты неуспешно; * перемещены в мусорную (Junk) очередь; Хотя после этого он станем владельцем заявок (т.к. владельцем заявки автоматически становится тот, кто её стал обрабатывать), но они ему (и другим агентам) не будут мешать, т.к.: * они все закрыты * [[TicketSearchOTRS][при поиске]] всегда можно указать, чтобы поиск не затрагивал очередь Junk
This topic: Main
>
WebHome
>
LikeTechnology
>
StartOTRS
Topic revision:
18 Jan 2015,
RomanKondakov
(raw view)
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki?
Send feedback