Как-то раз, бороздя просторы интернета в поисках новых идей, я наткнулся на статью на Хабре Как мы написали helpdesk. В данной статье было описание системы очень похожей на ту, которую я создаю уже больше полугода. И я решил о ней написать.
Поставленные задачи:
Вся работа специалистов сводится к работе по заявкам Разные типы проблем для заявок Разные специалисты, решающие разные типы проблем заявок Наличие диспетчеров, распределяющих заявки специалистам Ведение временного учета по занятости специалистов Отчеты по заявкам и о занятости специалистов Возможность отказываться или переназначать заявку Создание занятости специалистом без привязки к заявке Поддержка OS Linux/FireFox 2.0 (~ 90% всех пользователей) БД — 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-телефонии для автоматических голосовых уведомлений об изменениях в заявках подключение SMS-шлюза для автоматических уведомлений об изменениях в заявках автоматическое распределение заявок при простое диспетчера автоматическое формирование квартальных отчетов с отправкой по e-mail заинтересованным лицам навести «красивости» добавление административного раздела и прочее..
Хочу пометить, что отсутствие красоты данной системы связано с тем, что она была изначально ориентирована исключительно для внутреннего пользования и выход на внешний рынок не планировался, в связи с чем, не имею пока что возможности предоставить даже тестовый доступ к системе.
В следующем посте постараюсь описать программную часть составляющего.
Жду ваших вопросов и отзывов!
UPD:
Исходники на ГитХабе http://habrahabr.ru/post/251657/
Добавить комментарий