Comments 26
А есть ли у тикетницы client side? Например, чтобы клиент отслеживал свой тикет в ЛК? Когда пытался пользоваться ЛК Даталайна видел только не очень полезные разделы, а попытка создать тикет возвращала java-потроха.
Делали ли какие-то способы доставки уведомлений операторам, кроме email? События браузера, push? Как оно переварит/переваривает, условно, 1M+/10M+ (порядки можно придумать самостоятельно) тикетов? Какой вообще запас производительности/прочности и что под капотом?
Способы доставки информации развиваем. Скоро будет чат-бот, например. У Личного кабинета будет мобильная версия, там сделаем push-нотификацию.
Решение построено на кластере. Сейчас в нем два плеча, по необходимости добавим новых.
Одно плечо на тесте в течение часа было нагружено 2 тыс. тикетов с аттачами и более 100 тыс. get-запросов – полет нормальный.
А какой-нибудь GLPI не было идеи обработать напильником?
Писалось не на ровном месте – есть и свое готовое ядро, на котором построены другие информационные системы, и старые наработки в области «сервис деск» из прошлой жизни.
Я это к тому веду, что нормальные SD умеют заявки юзеров передавать другому сотруднику и в них есть возможность запуска заранее определённых процессов, которые назначают задачи. Это то, как я понял, что у Вас зовётся «комплексной заявкой». Просто передавать заявку только потому, то кто-то должен выписать пропуск, есть не очень хорошо и даже не правильно.
В рамках SD — обходы, тестирование обычно являются повторяющимися (регламентированными) задачами, а не заявками.
Интеграция Вашей SD с используемой системой мониторинга планируется или уже сделана?
PS. Во время чтения таких тем-описаний на ум сразу приходим ITIL/ITSM.
Приведенный пример «последовательной» заявки (выписать пропуск, назначить ответственного за встречу, встретить-проводить) самый простой пример – его проще обезличить для публикации.
Более сложные процессы, охватывающие действительно «композитные» заявки, сейчас нами разрабатываются. Там будет и параметризованный вход, и параллельное исполнение разными подразделениями. Визуально так: заявитель выбирает процедуру, заполняет вводные – далее процесс продолжается автоматически и параллельно.
Обходы – да, совершенно регламентная процедура. А вот проблемы, выявляемые на обходах, чистая «нештатка».
Связка Обходы-СД автоматическая и работает по заранее определенным процедурам. То, что эти процедуры проводятся через Сервисдеск – так у нас заведено.
Но работу автор с коллегами проделал, несомненно, огромную.
Но «исторический» термин «инцидент» вместо «заявка» прижился, и уходить не собирается. :-)
Atlassian Jira Service Desk попробовали, но внедрять не стали. Показался чрезмерно запутанным интерфейс, а нам за него сажать диспетчеров, и весьма много доработок под процессы компании. Посидели-посчитали и решили, что по времени то на то и получится.
Напомню, у нас на тот момент уже было наше готовое ядро с массой поддерживаемых функций, вполне прижившееся в компании, и старые наши же разработки в области сервисдеск, уже применявшиеся нами по назначению… не соврать лет 10 назад ;-)
Так же, видя запросы от внутренних пользователей, понимаю, что столько чудесных схем движения заявок, хитро-придуманных ограничений, маршрутов, я бы не реализовал на чужом, готовом софте.
Запускается за неделю, переживает нагрузку в тысячи заявок в день. Используется в Yandex.Taxi, Avito.
Могу помочь с настройкой.
Все описанное вами умеют делать многие ITSM решения. Jira Service Desk не идиальный пример, есть много куда более развитых решений.
А на https://www.manageengine.com/products/service-desk/ не смотрели?
Умеет многое из коробки!
Т.е. вы начали писать свой СД примерно год назад, но в плане сравнения с другими продуктами вы использовали устаревшие данные (3-4 года в случае с МЕ СДП ) ??
Интерсная логика :)
Как сервис-провайдер делал свой Service Desk