Как-то раз, бороздя просторы интернета в поисках новых идей, я наткнулся на статью на Хабре Как мы написали helpdesk. В данной статье было описание системы очень похожей на ту, которую я создаю уже больше полугода. И я решил о ней написать.
Поставленные задачи:
- Вся работа специалистов сводится к работе по заявкам
- Разные типы проблем для заявок
- Разные специалисты, решающие разные типы проблем заявок
- Наличие диспетчеров, распределяющих заявки специалистам
- Ведение временного учета по занятости специалистов
- Отчеты о занятости специалистов
- Отчеты по заявкам
- Возможность отказываться или переназначать заявку
- Создание занятости специалистом без привязки к заявке
- Корректная работа на OS Linux/FireFox 2.0 (ну ооочень старые компьютеры, составляющие 90% всех пользователей, а это около 1000шт)
- БД — Sybase SQL Anywhere 11
- PHP — 5.3
Что было...
Придя в данную организацию 4 года назад, я познакомился с имеющейся системой заявок. Она решала все необходимые задачи, за исключением того, что все отчеты о занятости/безделии решающих проблемы специалистов оставалась начальству неизвестна. И так уже сложилось, что было 3-4 диспетчера, отвечающих за распределение этих самых заявок специалистам. Ведь не каждый пользователь, создавший заявку, может верно указать её тип. То ли от лени, то ли от незнания, из-за чего автоматическое распределение периодически давало сбой. Всё работало отлажено даже в самых старых браузерах старейших юникс систем, в частности ff 2.0.
Со временем, появилась необходимость сделать надстройку над уже имеющейся системой, которая будет отслеживать сколько времени специалист тратит на решение заявки. И, как итог, вывод отчета по специалистам и их деятельности.
Взвесив все «за» и «против», решили делать всё с чистого листа.
Как закалялось сталь
Как и во всех проектах данной организации, в основе лежит БД Sybase SQL Anywhere. А из плюсов у нее:
- Триггеры
- Эвенты
- Полноценные процедуры и функции с возможностью писать/читать файлы
- Встроенный sendmail
- Отличная скорость работы
- Удобный «руль» — Sybase Central
- Поддержка Watcom SQL и Transact SQL
- Подключение таблиц из удаленных БД
- Много всяких мелких плюшек...
Обоснованность выбора именно SQL Anywhere еще и в том, что планируется, что данная система вырастет ищи и до PowerBuilder и Android версии. Именно поэтому использование процедур — более рационально. Написав весомую часть всей логики в БД, остается лишь «дёргать» её из разных платформ и разных приложений.
Веб-сервер сделали из обычного Apache + PHP 5.3 на CentOS.
Схема файлов очень похожа на то, как реализовано в посте из ссылки в начале поста. Имеется:
- главный php-файл, обрабатывающий все запросы ajax, дёргая БД
- javascript-файлы, для обращения к php с последующей отрисовкой страниц
- сами html-страницы.
Все значки на сайте реализованы на FONTAWESOME — крайне удобная вещь!
Приступая к работе, спроектировали примерную схему самой БД, которая, в итоге, очень отдалилась от исходного варианта.
Как это работает
Рабочий стол всей системы делится на два основных составляющих:
- Для всех пользователей — менеджер заявок
- Для обычных пользователей — создание/отслеживание
- Для специалистов — отслеживание своих заявок
- Для диспетчеров — распределение заявок + отслеживание своих заявок
Для администраторов — полный «руль» системы(в разработке...)
- Для специалистов и диспетчеров — менеджер заданий
Менеджер заявок
Жизненный путь заявок. Создание с выбором типа ошибки (программы, оборудование, 1С ...). Распределение диспетчером специалисту. При распределении заявки конкретному специалисту, у него появляется задание, к которому прикрепляется данная заявка. Далее три пути:
- Специалист выполняет и закрывает задание (следовательно, заявку), тогда заявка попадает на утверждение закрытия создателю
- Специалист отказывается от выполнения, указывая, что, например, эта ошибка не по его части, после чего заявка снова становится не распределенной, давая диспетчеру возможность указать другого специалиста.
- Специалист, при необходимости, сам передает задание (следовательно, заявку) другому специалисту
Создатель заявки уведомляется и, войдя в систему и отобразив информацию по данной заявке, может:
- Подтвердить закрытие. Проблема успешно решена.
- Отказать в закрытии, указав причину или добавив сообщение в переписку, после чего заявка снова возрождается у ранее назначенного специалиста.
Создание заявки:
Просмотр полной информации диспетчером о любой заявке или просмотр специалистом о своей заявке:
Менеджер заданий
Упор сделан на то, чтобы специалист мог планировать, указывать и рассчитывать время, которое он тратит на то или иное задание. В визуальном представлении это был обычный календарь с отметками заданий на нем.
Просмотр списка завершенных заданий:
Просмотр списка актуальных заданий:
Просмотр информации о задании:
Приступая к работе над заявкой, специалист нажимает кнопку «приступить», она же play(треугольник) и берется за дело. По завершению, он нажимает «завершить», она же stop (квадрат). После чего заявка попадает на утверждение пользователю, создавшему её.
Тут доступны комментарии, которые хранятся исключительно у этого задания (например, можно указать «не забыть полить фикус, лишь потом приступать»); переписка — это сообщения для общей дискуссии между создателем и специалистом, которые, так же, может просматривать и добавлять диспетчер (например, для выяснения подробностей ошибки); служебные комментарии — переписка между диспетчером и специалистами, работающими по данной заявке (например, пояснение «не получится сделать, нужно больше железа») — данная информация их технических соображений скрывается от создателя заявки.
Создавать задания специалист и диспетчер может сам, без привязки к заявке, что бы указать иную занятость, например, «поехал за закупкой не хватающего товара». Данная занятость тоже будет отображена на временной шкале занятости.
Приступать к заданию можно неограниченное количество раз, тем самым регулируя очередь выполнения и их продолжительность.
По итогам работы, можно высчитать, сколько времени специалист тратил на задания в выбранный временной промежуток, будь то день, месяц или год. В отчете по занятости отображается, сколько рабочих часов в выбранном периоде, сколько специалист проработал всего, сколько в рабочее время и сколько в нерабочее время (нередко и такое).
Содержимое отчетов:
- Статистика специалистов
- Общее количество заявок
- Время в работе
- Места ошибок
- Типы ошибок
- Создатели заявок
На данной стадии есть много проблем и вопросов по созданию отчетов, поэтому, этот раздел скучен и примитивен и содержит только цифры. Не приложу ума, как бы это сделать все информативнее и приятнее.
Из минусов:
- Пока неясно, как регулировать активность специалистов, что бы они не оставляли задания в состоянии «в работе», уходя домой, забыв, нажать «приостановить» (паузу). Из-за данной проблемы, в отчетах иногда бывают трудаголические цифры, о безумных переработках
Предлагайте свои варианты в комментариях!
Из плюсов:
- давно реализованы уведомления на socket'ах
- быстрая скорость работы в целом, т.к. все данные подгружаются в ajax и вставляются в уже загруженную страницу
- быстрая отдача информации от БД — до 0.4 секунд на выборку 1000 строк по массе параметров с последующим формированием JSON ответа
- хорошая защищенность от взломов
- все уведомления для разгрузки базы, падают в таблицу актуальных писем, которые рассылаются раз в 2 минуты
В планах огромная работа:
- подключение ip-телефонии для автоматических уведомлениях об изменениях в заявках
- автоматическое распределение заявок при простое диспетчера
- автоматическое формирование квартальных отчетов с отправкой по e-mail заинтересованным лицам
- навести «красивости»
- добавление административного раздела
- и прочее..
Хочу пометить, что отсутствие красоты данной системы связано с тем, что она была изначально ориентирована исключительно для внутреннего пользования и выход на внешний рынок не планировался, в связи с чем, не имею пока что возможности предоставить даже тестовый доступ к системе.
Жду ваших вопросов и отзывов!
Автор: mad_jerico
