Но прежде чем мы начнем рассматривать развитие системы, давайте взглянем на текущую структуру Вашей системы. Скорее всего, у большинства из Вас используются штатные механизмы. То есть, как систему установили, так ее и эксплуатируете. Service Desk 4.5 можно довести до ума, при этом потребуется не так уж и много сил, главное знать, что Вы хотите увидеть на выходе.
Приступим: Первый, назовем его «Системное изменение», второй, назовем «Правила системы».
Системные изменения: меняем штатный механизм работы системы на тот, что необходим Вам. Сюда мы отнесем «Принцип работы правил. Изменение штатного функционала на нештатный».
Думаю, лучше привести пример: Скажем у Вас 12 app серверов, каждый из которых работает по своим направлениям, кто-то почту разбирает, кто-то с пользователями работает, web-приклад, агент-сервер и т.п. Главное, что их объединяет - это «scheduled tasks», у каждого сервера он свой. На самом деле, это плохо, обратите внимание: каждый сервер занимается свои делом, а тут выходит, что у них есть что-то общее. Изменив системную логику, можно отобрать у каждого сервера данный функционал и направить его на отдельный сервер, который будет работать только с этими объектами.
Вы спросите, зачем это нужно? Ситуация такова, допустим, в Вашей системе включена возможность групповой правки. И есть правила, которые каким-то действием генерируют scheduled tasks, но создание данного scheduled происходит на том сервере, на котором производили изменения. А теперь представьте себе ситуацию, что проверка данного события совпадет с максимальной нагрузкой на систему. Как правило, это утро, если взглянуть на схему изнутри, то можно представить, как плохо становиться серверу, которому нужно обрабатывать не только запросы специалистов, но еще и запросы Scheduled, исполняя при этом еще и правила системы. Т.е нагрузка увеличивается в два раза. Отсюда могут рождаться новые проблемы. Замедление или зависание приклада, повышенная нагрузка на базу данных, ошибки java. Казалось, одна мелочь, а может столько проблем создавать.
Приведу еще один пример системного изменения, формат сообщений в виде html. В штатном механизме система отправляет сообщения в текстовом виде, что не всегда удобно, а порой сообщения имеют свойства съезжать по тексту или накладываться строчками. Внеся небольшие изменения на сервере, который генерирует сообщение, а в правилах написав сообщение в формате html, на выходе мы получим сообщения в нужном нам формате. Выходит, на сервер мы добавили некий фикс, и во всех правилах DB, которые умеют отправлять сообщения, появляется возможность менять формат сообщений (и не только правил).
Правила системы: "Зная механизм работы общей логики системы, Вы можете настроить систему так, как Вам необходимо". Проще на примере. Если специалист запросил информацию у пользователя, в этот момент останавливается срок объекта. После ответа пользователя на запрос, к сроку прибавляется время ожидания от пользователя.
Еще пример. Предположим, у Вас есть механизм отправки запроса на дополнительную информацию от пользователя. Как делает специалист, пишет запрос, нажимает, отправить запрос заявителю или пользователю (это неважно), сообщение уходит. А пользователь - это уже личность, которая парой не поддается никакой логике. Если в письме сообщения большими буквами написано: нажмите на ЭТУ кнопку, еще не факт, что пользователь нажмет на нее и отправит вновь созданное сообщение. Пользователь поступит иначе, он нажмет: ответить и отправит свой ответ. Ему неважно, что данный запрос упадет совсем не туда, куда нужно. Это уже тонкая настройка, если знаешь логику системы, то можно добиться и отработки данных правил. Это исправляется очень просто: в поле тема в отправляемом письме нужно дописать нашу команду на добавление информации, допустим add historyline. Теперь, если пользователь нажмет ответить, сообщение все равно упадет в нужный нам объект.
Конечно, любая система допиливается годами, но ведь и Service Desk на рынке уже не один год. Скорее всего, у большинства из Вас система уже допилена в нужную Вам сторону. Потенциал системы, на самом деле, довольно не мал, но и в нем, как говориться, есть свои как минусы, так и плюсы, что-то приходится допиливать, а что-то просто настраивать.
Вот, например, у Вас обратная связь с пользователем происходит по электронной почте. Я бы посоветовал отказаться от этого механизма. Верное решение - это написание портала, на который нужно загонять всех пользователей. В теле отправляемых сообщений просто ставить ссылки на портал, а в дальнейшем убрать ссылки на создание сообщений.
Какие же плюсы нам дает портал? Пользователи всегда могут знать о всех сбоях, оформить обращение, почитать инструкции, сделать заявки, которые будут соответствовать требованиям заполнения прежде, чем попадут на специалиста. Ведь парой от пользователя требуют очень много технической информации, которую пользователь не заполняет по ряду причин (не знает, или не понимает, что от него хотят). А на портале можно создать подсказку, сделать это поле обязательным для заполнения. На портале мы можем ограничить размер вложения. (и.т.д.)
Механизм согласования заявок на доступ также можно прикрутить к порталу, тогда все согласования будут происходить на портале, и только после того, как оно состоится, на группу исполнителей уже упадет задание на исполнение со всеми согласованиями. Казалось бы, мелочь, а так упрощает жизнь.
Можно сделать сквозную авторизацию, выводить ip пользовательского компьютера, выводить информацию из адресной книги. В общем, максимально отнестись к пользователю с точки зрения удобств обращения в отдел поддержки.
Подведем небольшие итоги. Как мы видим развитие системы - это необходимость, какой бы система ни была. Всегда требуется подстраивать систему под выработанный процесс. Всегда думайте прежде, чем написать правило, к чему оно может привести. Оптимизируйте свои правила так, чтобы они наименьшим путем затрагивали логику системы, это убережет Вас от разного рода ошибок. Пишите правила так, чтобы они были универсальны. Дабы не плодить одно действие под разные правила с учетом доп.условий.
Наблюдайте за состоянием системы по ключевым параметрам в онлайне – это даст общую картинку над состоянием самой системы.
