Как сервис-провайдер делал свой Service Desk

    Всем привет! Меня зовут Алексей Волков. Bместе с моим коллегой, разработчиком Александром Соловьевым (alsov), мы делаем внутренние веб-сервисы в DataLine. Этой осенью мы запустили свой сервисдеск на замену BMC Remedy. В посте расскажу, почему мы отказались от готового решения и сделали все сами.


    В среднем в сутки через сервисдеск проходит 450 заявок.

    Чем нам не угодил Remedy?


    Remedy я начал заниматься практически сразу, как попал в DataLine. После неоднократных попыток допилить его под наши задачи мы решили сделать свой сервисдеск. Вот не очень короткий список причин, по которым мы решили отказаться от Remedy Action Request System от BMC:

    Неудобный интерфейс. Чтобы зарегистрировать заявку, взять ее в работу и отметить ее разрешение, приходилось сделать 100500 кликов.


    Страница с инцидентом. Взять хотя бы поля для содержания сообщения, которое нужно было открывать в специальном окне.


    Целый каскад вкладок нужно открыть, чтобы написать решение или перенаправить инцидент другому исполнителю.

    Интеграция с другими клиентскими интерфейсами и какие-либо доработки предполагали еще те танцы с бубном. ПО проприетарное, места для маневров почти не было. Единственной лазейкой были веб-сервисы, которые умели общаться с Remedy, но они были очень капризными и нестабильными. Какие-то вещи мы делали совсем вручную и топорно: помню, как настроили выгрузку отчетов по инцидентам с помощью селектов из базы.

    Конечно, был и другой путь: нанять подрядчика и исполнить любой свой каприз. На рынке на тот момент был всего один подрядчик по этому ПО, и он об этом знал. Производственные процессы корректируются, и постоянно нужны были бы доработки. С учетом этого ценник получался негуманным и начинался от 5 млн.

    Не хватало лицензий. Когда-то на заре DataLine мы купили 100 лицензий. С тех пор компания сильно выросла. Лицензии были конкурирующими. Все чаще возникали ситуации, когда инженеру приходилось ждать освобождения лицензии, чтобы начать делать свою работу. Собственно, это и стало последней каплей.

    Фиксация всех действий по инциденту. Мы хотели, чтобы все, что касается технической поддержки наших клиентов, было отражено в сервисдеске. Remedy же фактически только регистрировал запросы. Вся настоящая работа по инциденту велась в почтовой переписке, по телефону, в курилке – где угодно, но не в Remedy. Особенно, если это была комплексная заявка и задействовала специалистов из нескольких отделов. Вопрос то решали, но следов этого в Remedy не оставалось. В результате инцидент был задокументирован фрагментами, а иногда и вовсе не отображался в Remedy. Контролировать, разбираться и анализировать что-либо было очень сложно.

    Сервисдеск 2.0


    Функции Remedy заменить было просто. Сверхзадача нового сервисдеска – затащить всю активность по технической поддержке в «одно окно»: контакты, рабочую переписку, документы. Мы хотели получить своего рода логирование всего, что происходит после того, как клиент отправляет заявку к нам на саппорт. Попутно мы хотели автоматизировать многие вещи, чтобы снизить нагрузку на первую линию поддержки и исключить по максимуму человеческий фактор.

    Вот самые важные из тех функций, что мы реализовали в новом сервисдеске:

    Передача инцидента. К нам часто приходят комплексные заявки, которые по цепочке выполняют специалисты разных отделов. Из самого простого – заявка на физический доступ к оборудованию в дата-центре. Сначала диспетчер выписывает пропуск, потом передает данные клиента и номер пропуска дежурному инженеру, который встречает и сопровождает клиента в дата-центре. Есть запросы, которые последовательно отрабатывают 5 отделов.
    Для всех таких случаев в интерфейсе появилась отдельная кнопка «Передать».



    Переписка с клиентом и коллегами. Эта функция как раз для того, чтобы переписка по инциденту не «утекала» в почту и вся история общения сохранялась у нас.

    Пока тут все очень минималистично. В планах – сделать полнотекстовый редактор с возможностью загрузки файлов, таблиц и пр.



    История назначений и история всех действий по инциденту. Эти вкладки помогут разобраться в спорных вопросах и внутренних расследованиях. В данный момент я выгружаю отчеты из истории, чтобы отслеживать, как часто диспетчеры допускают ошибки при назначении инцидента на профильную группу.



    Так выглядит история назначений по внутреннему инциденту «Увольнение сотрудника».


    История инцидента. Тут еще будем наводить красоту, но главная задача уже решена – все логируется.

    Наблюдатель. Бывает, что в письме-заявке клиент пристегивает в копию заинтересованных лиц. Все эти товарищи будут появляться во вкладке «Наблюдатели» и следить за исполнением данной заявки. Им будут приходить отбивки о статусе запроса, при желании они смогут переписываться с нашей техподдержкой. Внутри компании эта функция тоже востребована: сервис-менеджеры могут вписаться в любой запрос своего клиента и следить за его исполнением.
    Список наблюдателей можно редактировать: удалять и добавлять новых.



    Шаблоны инцидентов. Типовых запросов достаточно много. Чтобы не заполнять десятки раз на дню заявку на пропуск или уборку мусора, мы добавили возможность создавать шаблоны инцидентов. Нужно только нажать кнопку «Создать инцидент», и откроется предзаполненный шаблон с прописанным исполнителем, типом, приоритетом и статусом.

    В работе дата-центров много регулярно повторяющихся заявок: обходы, тестирования, проверки инженерного оборудования по чек-листам и пр. Для всего этого настраиваются автоинциденты, которые автоматически попадают в трекер с заданной периодичностью.



    Аналитика. В Remedy не было встроенных средств аналитики, ничего нельзя было выгрузить штатными средствами. Здесь мы предусмотрели выгрузку всего и вся для последующего анализа. Например:

    • количество запросов в сутки;
    • скорость реагирования;
    • просрочка запросов;
    • типы запросов;
    • загрузка по отделам;
    • работа диспетчеров;
    • частота и качество возникающих проблем в разрезе клиентов;
    • разнообразные зависимости, например, скорости исполнения от типа запроса.

    Чуть позже хотим сделать дашборды с диаграммами и графиками, чтобы без всяких выгрузок и колдовства в Excel получать картину о происходящем в техподдержке.


    Отчеты можно сформировать прямо в сервисдеске с помощью фильтров.


    Выгрузка данных в различных форматах.


    Можно выбрать поля, которые будут отображаться в выгрузке.

    API для интеграции с другими внутренними сервисами. Из простого: сервисдеск подтягивает информацию из справочников с перечнем компаний-клиентов, договоров, списком заказанных услуг и ответственных лиц, которые могут направлять запросы. Раньше приходилось сначала сверяться с отдельным файлом, чтобы определить, является ли написавший клиентом и может ли он писать запросы от компании.

    «Обход дежурной смены» – еще один наш внутренний сервис, с которым теперь умеет взаимодействовать сервисдеск. Это электронный чек-лист, по которому дежурные и инженеры эксплуатации несколько раз в день осматривают дата-центры на предмет поломок и непорядка. Ситуация для примера: во время обхода дежурный наткнулся на клиентскую стойку с неправильно установленным оборудованием. Он просто делает соответствующую пометку в программе «Обход», и в сервисдеск автоматически прилетает инцидент по проблеме. Дежурный идет дальше по маршруту обхода, а проблему со стойкой уже начинают решать.


    По любому из пунктов чек-листа можно создать инцидент.


    Форма для инцидента внутри ПО «Обход». Сверху висят инциденты в работе по этому же объекту.

    По мелочи. Все самые частые типы запросов мы вывели на страницу интерфейса. После выбора приоритета пользователь видит дедлайн и прогресс-бар, показывающий сколько времени у него осталось на исполнение инцидента.



    Внедрение


    Во время опытной эксплуатации мы тестировали работу сервисдеска на внутренних заявках. Около месяца тренировались на отделах АХО, капитального строительства, производства и управления сервисом. Внешние заявки и заявки других отделов по-прежнему ходили через Remedy.

    Потом мы договорились с тремя клиентами, чтобы обкатать обработку внешних заявок. Вот тут и случились первые проблемы.

    Когда только начали делать новый сервисдеск, я лелеял надежду, что наш умный почтовый парсер сможет регистрировать запросы, раскидывать их по профильным отделам, подшивать сообщения по одному и тому же вопросу в один инцидент. В перспективе это означало отказ от диспетчеров на обработке письменных запросов. В Remedy люди очень привыкли полагаться на почтовую переписку, ее было больше, чем мы предполагали. На тестовых испытаниях парсер не справился: он мог перепутать отделы при назначении запроса, новые сообщения по уже открытому инциденту он регистрировал как новые инциденты. Были и более тривиальные сложности: парсер не мог прочитать письмо, пришедшее от почты с сертификатом; не понимал нестандартную кодировку и присылал текст из вопросов.

    Пришлось добавить ручной труд – появилась Диспетчерская. Это чистилище для всех заявок, пришедших на support@dtln.ru. Оттуда диспетчеры вручную распределяют заявки по отделам.



    На стороне клиента логика взаимодействия с техподдержкой осталась прежней, изменился только вид отбивок. В первые дни с ними было несколько накладок, во основном из-за некорректных контактных данных в справочниках. Так у одного из клиентов было 23 ответственных лица и на всех один общий email, типа info@. Сервисдеск послушно всех оповестил, выполнив за час дневную норму по входящим на этом почтовом ящике.

    Что дальше?


    В ближайших планах – интеграция с Личным кабинетом. Вся переписка и история обращений будет отображаться в профиле клиента. Теоретически это шанс исключить почту из общения с техподдержкой и окончательно затащить клиента в наш веб-интерфейс. Посмотрим, как оно приживется в жизни.

    Внедрение параметризованной заявки. Есть запросы, которые содержат много параметров и значений, и важно ничего в них не перепутать. Например, когда клиент просит добавить виртуальных ресурсов в пул или создать виртуальные машины определенных размеров. Для таких случаях мы планируем сделать конструктор с параметрами. Он будет автоматически парсить подобные клиентские запросы, пришедшие по почте. Его же будут использовать диспетчеры, когда принимать заявку по телефону.


    Вот так выглядит параметризованная заявка.

    Оценка работы техподдержки. Пресловутое «оцените наш сервис по пятибалльной шкале» с возможностью написать в свободной форме, все, что клиент думает о нашем сервисе.

    Ту самую Диспетчерскую, которая возникла как костыль в помощь почтовому парсеру, хотим развить в полноценное автоматизированное рабочее место диспетчера (АРМ). Сейчас диспетчеру приходится заглядывать в различные интерфейсы (учет оборудования, список ответственных лиц, услуги по клиенту), чтобы собрать нужную информацию по клиенту. В АРМ же будет все в одном окне: инциденты клиента, контакты, договора, заказанные услуги и их параметры и пр. данные.

    Ну и не теряем надежду на автоматическое распределение заявок по отделам. Сейчас думаем в сторону системы хэштегов для почтового парсера.

    ***
    В боевом режиме сервисдеск работает с ноября, и все это время я наблюдаю стабильное увеличение количества инцидентов (+40%), в первую очередь за счет внутренних запросов. Смею надеяться, что это из-за того, что новый сервисдеск более дружелюбный во всех отношениях и запросы перестали проскакивать мимо него.

    Еще один профит нового сервисдеска – это гибкость. Мы уже сделали несколько кастомных решений для отдельных клиентов, чтобы проинтегрироваться с их внутренними сервисдесками или просто подстроиться под их производственные процессы. Раньше на это ушли бы месяцы и миллионы, а теперь все, что нужно, – это письмо своему разработчику и 1-2 недели в зависимости от сложности задачи.
    DataLine
    144,00
    Экосистема на базе дата-центров TIER III
    Поделиться публикацией

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

      0

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

                        Самое читаемое