Привет, Хабр! Меня зовут Павел Родичев, я тимлид технической поддержки в СберМаркете. Эта статья — о том, как мы интегрировали в Jira систему, которая для этого не предназначена, и сократили время на нотификацию пользователей.
В мире корпоративных информационных технологий каждое новое внедрение — это не только возможность повысить КПД сотрудников, но и вызов для команды саппорта. Особенно с уходом Atlassian из России: вендор перестал поставлять плагины для Jira, и компаниям приходится сочинять их самостоятельно. Если, конечно, у них есть для этого разработчики.
В СберМаркете есть команда Jira-разработчиков, и это дает нам больше свободы в управлении проектами, а соответственно — мотивирует творчески подходить к ServiceDesk. Сейчас покажу на конкретном примере.
Из чего родился кейс
Разные команды СберМаркета работают с разными операторами электронного документооборота. Каждая выбирает более удобную систему именно для себя — как правило, ту, с которой знакомы члены команды. Летом 2022 года к списку операторов добавился еще один — Terralink.
Наш ServiceDesk не мог взять техническую поддержку Terralink на себя: для этого требуется целая команда с опытом работы именно на этой платформе. Поэтому с любыми проблемами, возникающими в процессе ЭДО, нужно идти к специалистам Terralink.
Какие это проблемы? Иногда — дубли документов. Иногда — ошибки, связанные с тем, что контрагенты работают с другими операторами ЭДО. Документы проходят через чужие 1С, а там могут быть не настроены соответствующие поля. Иногда подписание банально не проходит, хотя пользователь вроде бы все сделал правильно.
Загвоздка в том, что Terralink обладает недостаточно продуманной нотификацией. Сотрудники СберМаркета не могли общаться с инженерами напрямую: для этого было необходимо использовать специальный адрес электронной почты. Поэтому все исходящие и входящие запросы сначала проходили через меня, а уже потом достигали реципиентов. Честно говоря, было жутко неудобно.
Сделали слона из мухи?
Возможно, ошибки составляют небольшой процент в общем объеме нашего сотрудничества с Terralink. Тем не менее ручная обработка тормозила процессы. Я мог потратить больше часа в день только на пересылку писем. Кроме того, наши сотрудники не могли оперативно получить обратную связь в критические моменты.
Скажем, СберМаркету нужно ASAP заключить договор. Сотрудник запускает ЭДО после 19:00 в будни или в выходной день — и сталкивается с ошибкой. Техподдержка Terralink круглосуточная, но напрямую к ней обратиться нельзя. Проблема решается только в рабочее время нашего ServiceDesk. Пахнет издержками, правда?
С августа 2022 года мы завели больше 450 тикетов с ошибками. Считай, два десятка ошибок в месяц, для каждой — переписка. Чтобы упростить взаимодействие СберМаркета с техподдержкой Terralink (и освободить себя от роли секретаря), год назад я решил спроектировать интеграцию для Jira и электронной почты.
Кастомная интеграция
Я взвесил возможности интеграций в Jira и написал следующий алгоритм:
Пользователь Jira создает в ServiceDesk задачу с компонентом Terralink.
Система через встроенный email-сервер Jira отправляет с нашего специального адреса на специальный адрес Terralink электронное письмо. В теме письма — номер тикета (генерируется автоматически по порядку) и заголовок задачи, внутри письма — описание проблемы.
Пример темы: SD-251250 Долгое время формирования документов в АРМ делопроизводителя
Техподдержка Terralink отправляет ответ, сохраняя цепочку.
Re: SD-251096 Долгое время формирования документов в АРМ делопроизводителя
Не подписаны документы за 9 сентября.
Jira фиксирует текст ответа в комментариях к задаче внутри ServiceDesk.
Если сотрудник пишет ответ в задаче, то алгоритм повторяется.
Получается чатик через Jira, который не требует ручной проверки электронной почты.
Помимо учетной записи, которая предназначалась для отправки электронных писем на адрес Terralink, я попросил создать вторую учетку — для проверки корректности отправляемых данных.
Вот так это выглядит в виде схемы:
С точки зрения кода в этом решении нет ничего сложного. Однако мы не могли бы его внедрить, не будь в СберМаркете Jira-разработчиков. Примите к сведению, если вы раздумываете, нужны ли таковые вашей компании :)
Что мы получаем?
Раньше сотруднику, работающему в ЭДО, при столкновении с ошибкой требовалось составить заявку в наш ServiceDesk и ждать, пока я доберусь до этого тикета. До отправки запроса в Terralink могло пройти несколько часов или даже больше суток. Аналогично обстояла ситуация с занесением ответа от техподдержки.
Интеграция работает уже год и не требует никаких правок. Заявка от сотрудника СберМаркета моментально улетает в техническую поддержку Terralink, ответ от поддержки моментально фиксируется в Jira. А я трачу всего пять минут в неделю на проверку работоспособности системы. Сто́ит ли говорить, что это в лучшую сторону сказалось на моей продуктивности?
Креативный подход и техническая экспертиза — ключ к тому, чтобы ServiceDesk не тратил время бессмысленно. Надеюсь, наш кейс послужит уроком или вдохновением для других компаний. Внутренней поддержке следует спрашивать себя, насколько эффективны шаблонные решения, и при необходимости от них уходить. Гибкость — важное правило успешного менеджмента.
А вы сталкивались с подобными вызовами? Если да, расскажите в комментариях :)
Tech-команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
Комментарии (3)
SpaceGod
19.06.2024 11:48Плагины можно скачать и пропатчить, а потом юзать спокойно и не платить либо обойтись таким костылем)
Thomas_Hanniball
Скажем так. Это не решение проблемы, а всего лишь небольшой костыль или workaround.
Решением проблемы является внедрение нормального Service Desk со стороны Terralink, чтобы клиенты могли оставлять свои заявки в нём, а не через e-mail.
Strange321 Автор
Даже имея ServiceDesk Terralink это не уберет ручной работы сотрудников технической поддежки. Сделать коннекторы между двумя ServiceDesk системами будет невозможно из-за соображений безопасности.