Как мы написали helpdesk

Есть продукты, которые можно взять и использовать, но с небольшой модификацией «под себя». Так вот система заявок или helpdesk как раз к таким вещам не относится. Точнее, мы для себя не нашли подходящий продукт и решили сделать сами.





Изначально, у нас были исходные от которых отталкивались и позже выдвигались требования:

1. Чуть больше 2000 пользователей, которые не будут участвовать в системе заявок, но статистику обращения которых нужно фиксировать


2. Около 30 человек персонала, которые делятся на 3-4 отдела, в котором по начальнику и все они имеют доступ к хелпдеску


3. Система только для внутреннего корпоративного использования


4. Извещение по email/sms


5. Отчётность и статистика


6. База пользователей (идеально взять с ActiveDirectory, хотя бы частично)

Если у Вас такие же исходные, возможно Вам эта статья и система помогут.

Позиция меня, как разработчика основывалась на сегменте готовых opensource продуктов, поддерживающих php & mysql. Изначально были рассмотрены: OsTicket, который достаточно прост, но в тоже время много функционален, что в свою очередь является минусом (много лишнего «выпиливать и прятать», а то что необходимо — дописывать). А так же более серйозное решение — OTRS, которое имеет встроенный инструмент работы с LDAP. В нём особенно понравилась форма создания заявки, в которой при вводе ID клиента подтягивалась вся информация о нём. И поэтому захотелось «золотой середины». Общий вывод таков, что под конкретные требования не подходит не один из них, но у последнего ввиду интерфейса хотя бы можно игнорировать часть требований. Имея небольшой опыт разработки php/jquery-проектов, я решился написать свою систему.

Основными задачами были: учёт всех заявок, отчётность и контроль со стороны руководства, в какой стадии находится та или иная задача. К примеру, начальник отдела мог с вечера определить задачи на следующий день для своих подчинённых, выбрав для них приоритет. А подчинённые, прийдя на работу, могли сразу видеть список задач и в течении определённого времени их выполнять.

Как такового чёткого технического задания у нас не было. Поэтому мы примерно определили структуру системы и её модулей.



Как видно из модели, хотелось так же использовать систему «личных сообщений» пользователей. Но в будущем эта затея отпала, зато вместо неё мы решили добавить:

• Комментарии на странице заявки, для того что бы можно было обсуждать заявку или отписываться по её выполнению


• Разделить заявки на 3 категории: Входящие, Исходящие, Архив (в который заявки автоматически попадают по истечению какого-то времени, при статусе «выполнено»)


• Центр знаний (раздел, в котором можно было бы найти ответы на интересующие вопросы, решить проблему не создавая заявку. Тут могут быть инструкции, руководства, документация)


• Блокнот (для хранения личных заметок и записей, с возможностью делиться ссылкой на них)


• Логирование всех действий пользователей

Немало времени и работы уделялось процессу создания заявки. Как я уже писал выше, понравился подход в OTRS. Поэтому, что бы при звонке клиента можно было идентифицировать его, узнав о его предыдущих заявках и числу обращений, необходимо было наполнить базу клиентов. У нас часть информации о клиентах хранилась в Active Directory, другая часть — в телефонном справочнике формата doc. В AD были только: ФИО, логин, email и группа (подразделение). В справочнике doc были: ФИО, тел, кабинет. Вместе они дополняли друг друга. В этих двух источниках, единицы информации могли и не совпадать. К примеру, в LDAP находилось около 2000 записей, а в справочнике — 1200. Из них совпало ~1000. Ну и этого было достаточно.

Наполнение базы клиентов

Процесс определился в несколько этапов:

1. Импорт из AD был путём PHP. Стандартно подключались в LDAP, вытягивали нужную информацию.


2. Импорт из doc-справочника был куда интереснее. Сначала перенесли нужные данные таблиц в xls, отформатировали и сохранили в CSV.


3. Далее импорт в MySQL-таблицу делал php-скрипт, который в цикле перебирал LDAP-записи и sql-записи и сравнивал ФИО (это единственное, что у них было общее).

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

Кодинг

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



Для меня, такая организация «общения» файлов показалась более логичной и простой. Всё расположено там, где ему место. Файл actions.php в основном состоит из блоков-действий, вроде «создать заявку», «блокировать заявку», «добавить клиента» и т.д. К нему посылается POST-запрос с определённым именем, который и вызывает нужную часть кода. Что касается описания событий на странице, то за это отвечает core.js.

Движение заявки

О движении самой заявки, стоит рассказать детальнее. Как правило выделяют из всего персонала 1-2 человека-оператора или дежурных, которые и принимают заявки: 80% в телефонном режиме, 20% на месте. Мы всегда придерживались мнения, что важно решить проблему ещё до создания заявки. И если эта проблема/задача не в компетенции сотрудника, то он её направляет на профильный отдел или конкретному человеку. Если получатель заявки выбран отдел, то такую заявку увидят все, кто входит в этот отдел (и конечно начальник отдела). Если же выбран конкретный человек, то такую заявку увидит этот человек и его начальник. Остальным же пользователям отдела заявка будет не видна.



Идея заключается в том, что бы заявка не оставалась без внимания и её статус выполнения всегда мог наблюдать начальник отдела.

В процессе разработки было решено делать 3-х уровневую систему прав пользователей.



Суть заключается в том, что главный Администратор видит заявки всех отделов и всех пользователей. Координатор состоит в определённом отделе(-ах) и видит заявки всех пользователей именно этого отдела(-ов). Пользователь видит только те заявки, которые направлены в его отдел (всем) или конкретно ему. Заявки другим пользователям со своего отдела он не видит.

Спустя время, мы столкнулись с коллизией: пользователи физически входили в один отдел, но фактически работа была смежной с другими отделами. И им необходимо было видеть заявки других отделов, но с разными правами. Так родилась идея «вертикально-горизонтальной» ориентации прав доступа. По вертикали — это были права пользователя: админ/координатор/пользователь. А по горизонтали — это список тех отделов, в которые он мог входить с общими правами. Логической точкой пересечения этих прямых и были общие права доступа в систему.

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



Для работы всплывающих сообщений мы на определённых страницах посылаем каждые 2 секунды ajax-запрос в 208 байт, который спрашивает у скрипта на сервере: «есть ли что-то новое для пользователя?» и если есть, то клиент получает json-ответ. Конечно, для полной «красоты», это делается через сокеты. Но пока мы к этому не пришли. Так же добавили эффект мерцания title-страницы и заголовок вкладки явно кричал: «тут что-то обновилось, обрати внимание».

Совсем недавно у нас внедрили jabber-месенджер. Поэтому мы сразу подключили helpdesk к нему и теперь извещения о новых заявках приходят и в джабер. Часть сотрудников не находится на своих рабочих местах, а работают с клиентами (устанавливают софт, обслуживают технику). Поэтому к ним особое внимание по извещению о новых заявках. Самый оптимальный и простой способ это sms-извещение. Нашли удобный сервис и через его API интегрировали нашу систему.

Интеграция

Важным моментом было получение доступа к системе заявок, существующих пользователей IT-подразделения. Мы создали белый список login/email. Суть его заключалась в следующем: человек при входе через web кликает на ссылку «первый вход», и вводит только свой ldap-логин. На его доменную почту приходит письмо с созданным паролем и ссылкой, на которую он переходит и получает полноценный доступ к системе. Таким образом снялась задача с администратора системы каждому выдавать учётные записи.

Что у нас вышло?

• Многоуровневая система прав пользователей


• JQuery-ориентированая структура интерфейса


• Возможность регистрации в системе из «белого списка» e-mail адресов


• Извещение о новых заявках по e-mail, sms, и другим системам


• Пользовательские настройки


• Поддержка языков: Украинский, Русский, Английский


• Всплывающие сообщения о событиях с заявками (как в VK)


• Центр знаний — раздел для файлов документации, инструкций и хелпов со структурой прав


• Блокнот — личный блокнот пользователя с возможностью делиться ссылкой


• Статистика заявок


• «Умное» создание заявок по номеру, ФИО, логину клиента


• Приоритеты заявок


• Комментарии и чат в заявке


• Полное логирование всех действий всеми пользователями заявки


• И другое...

Заключение.

На сколько удобно и оправдано было написание такой системы покажет время. А пока мы стараемся не превращать её в «монстра», но в тоже время добавить некоторые возможности: добавление загрузки файлов к заявке, статистика и другие вещи. Моё личное критичное мнение заключается в том, что система вполне рабочая, но с кодом ещё необходимо поработать. Мне будет очень приятно услышать Вашу критику и замечания, а так же увидеть Ваш вклад в развитие проекта.

Github: link.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.