Есть продукты, которые можно взять и использовать, но с небольшой модификацией «под себя». Так вот система заявок или helpdesk как раз к таким вещам не относится. Точнее, мы для себя не нашли подходящий продукт и решили сделать сами.
Изначально, у нас были исходные от которых отталкивались и позже выдвигались требования:
- Чуть больше 2000 пользователей, которые не будут участвовать в системе заявок, но статистику обращения которых нужно фиксировать
- Около 30 человек персонала, которые делятся на 3-4 отдела, в котором по начальнику и все они имеют доступ к хелпдеску
- Система только для внутреннего корпоративного использования
- Извещение по email/sms
- Отчётность и статистика
- База пользователей (идеально взять с ActiveDirectory, хотя бы частично)
Если у Вас такие же исходные, возможно Вам эта статья и система помогут.
Позиция меня, как разработчика основывалась на сегменте готовых opensource продуктов, поддерживающих php & mysql. Изначально были рассмотрены: OsTicket, который достаточно прост, но в тоже время много функционален, что в свою очередь является минусом (много лишнего «выпиливать и прятать», а то что необходимо — дописывать). А так же более серйозное решение — OTRS, которое имеет встроенный инструмент работы с LDAP. В нём особенно понравилась форма создания заявки, в которой при вводе ID клиента подтягивалась вся информация о нём. И поэтому захотелось «золотой середины». Общий вывод таков, что под конкретные требования не подходит не один из них, но у последнего ввиду интерфейса хотя бы можно игнорировать часть требований. Имея небольшой опыт разработки php/jquery-проектов, я решился написать свою систему.
Основными задачами были: учёт всех заявок, отчётность и контроль со стороны руководства, в какой стадии находится та или иная задача. К примеру, начальник отдела мог с вечера определить задачи на следующий день для своих подчинённых, выбрав для них приоритет. А подчинённые, прийдя на работу, могли сразу видеть список задач и в течении определённого времени их выполнять.
Как такового чёткого технического задания у нас не было. Поэтому мы примерно определили структуру системы и её модулей.
Как видно из модели, хотелось так же использовать систему «личных сообщений» пользователей. Но в будущем эта затея отпала, зато вместо неё мы решили добавить:
- Комментарии на странице заявки, для того что бы можно было обсуждать заявку или отписываться по её выполнению
- Разделить заявки на 3 категории: Входящие, Исходящие, Архив (в который заявки автоматически попадают по истечению какого-то времени, при статусе «выполнено»)
- Центр знаний (раздел, в котором можно было бы найти ответы на интересующие вопросы, решить проблему не создавая заявку. Тут могут быть инструкции, руководства, документация)
- Блокнот (для хранения личных заметок и записей, с возможностью делиться ссылкой на них)
- Логирование всех действий пользователей
Немало времени и работы уделялось процессу создания заявки. Как я уже писал выше, понравился подход в OTRS. Поэтому, что бы при звонке клиента можно было идентифицировать его, узнав о его предыдущих заявках и числу обращений, необходимо было наполнить базу клиентов. У нас часть информации о клиентах хранилась в Active Directory, другая часть — в телефонном справочнике формата doc. В AD были только: ФИО, логин, email и группа (подразделение). В справочнике doc были: ФИО, тел, кабинет. Вместе они дополняли друг друга. В этих двух источниках, единицы информации могли и не совпадать. К примеру, в LDAP находилось около 2000 записей, а в справочнике — 1200. Из них совпало ~1000. Ну и этого было достаточно.
Наполнение базы клиентов
Процесс определился в несколько этапов:
- Импорт из AD был путём PHP. Стандартно подключались в LDAP, вытягивали нужную информацию.
- Импорт из doc-справочника был куда интереснее. Сначала перенесли нужные данные таблиц в xls, отформатировали и сохранили в CSV.
- Далее импорт в 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.
Автор: rustem_ck
Спасибо!!!