Как стать автором
Обновить

Комментарии 26

А есть ли у тикетницы client side? Например, чтобы клиент отслеживал свой тикет в ЛК? Когда пытался пользоваться ЛК Даталайна видел только не очень полезные разделы, а попытка создать тикет возвращала java-потроха.


Делали ли какие-то способы доставки уведомлений операторам, кроме email? События браузера, push? Как оно переварит/переваривает, условно, 1M+/10M+ (порядки можно придумать самостоятельно) тикетов? Какой вообще запас производительности/прочности и что под капотом?

У «тикетницы» есть api, а у наших клиентов скоро будет новый Личный кабинет – там это все и сойдется. Полнофункцонально.

Способы доставки информации развиваем. Скоро будет чат-бот, например. У Личного кабинета будет мобильная версия, там сделаем push-нотификацию.

Решение построено на кластере. Сейчас в нем два плеча, по необходимости добавим новых.
Одно плечо на тесте в течение часа было нагружено 2 тыс. тикетов с аттачами и более 100 тыс. get-запросов – полет нормальный.
Я правильно понял, что систему писали два человека? А сколько времени заняло, если не секрет?
А какой-нибудь GLPI не было идеи обработать напильником?
Сервисдеск — это 50% программного кода и 50% выстраивания внутренних процессов компании, связанных с ним :)
Я бы сказал, что 70% процентов — процесс и 30 — код :)
Обычно и я эти цифры называю, прямо вот в копеечку. тут просто поскромничал :-)
Да, два человека. 9 месяцев ушло до внедрения, при загрузке ~60%
Писалось не на ровном месте – есть и свое готовое ядро, на котором построены другие информационные системы, и старые наработки в области «сервис деск» из прошлой жизни.
Решение писать свой SD приняли после анализа бизнес-требований, составления ТЗ, проверки существующих систем SD и финансовых расчётов или как обычно — нам не нравится наша текущая программа, значит будем писать свою?
Я это к тому веду, что нормальные SD умеют заявки юзеров передавать другому сотруднику и в них есть возможность запуска заранее определённых процессов, которые назначают задачи. Это то, как я понял, что у Вас зовётся «комплексной заявкой». Просто передавать заявку только потому, то кто-то должен выписать пропуск, есть не очень хорошо и даже не правильно.
В рамках SD — обходы, тестирование обычно являются повторяющимися (регламентированными) задачами, а не заявками.
Интеграция Вашей SD с используемой системой мониторинга планируется или уже сделана?

PS. Во время чтения таких тем-описаний на ум сразу приходим ITIL/ITSM.
Все перечисленное, без исключения, участвовало в принятии решения. И анализ процессов, и знакомство с рынком подобных продуктов, и финансовые расчеты – куда без них. И текущая система весьма не устраивала, и понимание «мы можем» тоже наличествует.

Приведенный пример «последовательной» заявки (выписать пропуск, назначить ответственного за встречу, встретить-проводить) самый простой пример – его проще обезличить для публикации.
Более сложные процессы, охватывающие действительно «композитные» заявки, сейчас нами разрабатываются. Там будет и параметризованный вход, и параллельное исполнение разными подразделениями. Визуально так: заявитель выбирает процедуру, заполняет вводные – далее процесс продолжается автоматически и параллельно.

Обходы – да, совершенно регламентная процедура. А вот проблемы, выявляемые на обходах, чистая «нештатка».
Связка Обходы-СД автоматическая и работает по заранее определенным процедурам. То, что эти процедуры проводятся через Сервисдеск – так у нас заведено.
Всегда меня коробило то, что в галактике DataLine всё называется инцидентом. Ну это помимо того, что сотрудники DC на запрос «демонтировать адаптеры из серверов» могут просто их вынуть из стойки — реальный случай в моей практике ))

Но работу автор с коллегами проделал, несомненно, огромную.
Да, вы правы! Самого немного коробит от термина «инцидент». При том, что в системе типов заявок полтора десятка, и они теперь очень активно используются.
Но «исторический» термин «инцидент» вместо «заявка» прижился, и уходить не собирается. :-)
А мне «Задача» вместо «Заявка» в последнее время больше нравится использовать.
Интерфейс постоянно бросается в глаза кусками Redmine. Это вдохновление, или ядро его?

Признаться Redmine изрядно пользовались, но его интерфейсом не руководствовались. Код же целиком написан на Lucee.

почему не стали внедрять готовое решение от другого вендора? например Atlassian Jira Service Desk. умеет все то что вы сделали прямо из коробки.

Atlassian Jira Service Desk попробовали, но внедрять не стали. Показался чрезмерно запутанным интерфейс, а нам за него сажать диспетчеров, и весьма много доработок под процессы компании. Посидели-посчитали и решили, что по времени то на то и получится.


Напомню, у нас на тот момент уже было наше готовое ядро с массой поддерживаемых функций, вполне прижившееся в компании, и старые наши же разработки в области сервисдеск, уже применявшиеся нами по назначению… не соврать лет 10 назад ;-)

Дополню, пожалуй еще, про Atlassian Jira Service Desk.
Тут подумал еще раз, и решил, что сроки разработки-внедрения в случае AJSD, пропорция 80 на 20, примерно, поменялись бы местами, и к данному моменту сотрудники компании меня бы уже прокляли :-)
а почему не взяли Redmine? чем он не подошел Вам?
Насколько я помню Сервисдеск для Редмайна существует в виде плагина? Поправьте — если это не так. Признаюсь не смотрел в его сторону, теперь пожалуй поздно. Но в целом, несмотря на мои теплые чувства к Редмайну, и 4 года честно в нем отработанных, думаю было бы как с AJSD. Я был бы проклят к концу внедрения. :-)

Так же, видя запросы от внутренних пользователей, понимаю, что столько чудесных схем движения заявок, хитро-придуманных ограничений, маршрутов, я бы не реализовал на чужом, готовом софте.
Для такого простого функционала, как вы написали можно было использовать Zendesk support тариф Team за 19$/месяц. На 100 человек 1900$/месяц.
Запускается за неделю, переживает нагрузку в тысячи заявок в день. Используется в Yandex.Taxi, Avito.
Могу помочь с настройкой.
В статье далеко не все упомянуто из функционала :-)
Онлайновые версии СД не рассматривали в принципе. Такие требования.

Все описанное вами умеют делать многие ITSM решения. Jira Service Desk не идиальный пример, есть много куда более развитых решений.

Смотрели. Но это было года 4 назад. Тогда он показался весьма куцым. Сейчас же, смотрю, во фьючес весьма богато расписано.

Т.е. вы начали писать свой СД примерно год назад, но в плане сравнения с другими продуктами вы использовали устаревшие данные (3-4 года в случае с МЕ СДП ) ??
Интерсная логика :)

Нормальная логика. Я не мониторю круглые сутки текущее развитие «всех 10 конкурирующих продуктов». У меня нет на это времени )))

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.