Всем привет! Меня зовут Андрей, и это вторая часть моего рассказа об эволюции службы технической поддержки внутренней системы CRM в Росбанке.

В первой части я рассказал, как мы через почту оказывали поддержку нашим сотрудникам в рамках внутренней CRM-системы PRO Business и остановился на описании трех основных проблем, которые шли за нами по пятам и мешали процессу поддержки.

Эта часть будет посвящена довольно длительному и сложному процессу перехода поддержки сотрудников от почты во внутреннюю helpdesk-систему SD. Но, забегая вперед, скажу, что на этом мы не остановились и решили идти дальше, поэтому во второй половине статьи я также затрону процесс перехода от SD к работе с обращениями в Jira. Итак, начнем.

Мне надо вам кое в чем признаться…

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

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

И здесь хочу вам признаться. Как я говорил в первой статье, нашим основным каналом обращений в поддержку PRO Business являлась страничка 911 с ее довольно простенькой формой обратной связи, которая перетекала в письмо на общий почтовый ящик команды. Но тем не менее в нашей helpdesk-системе SD для нашего PRO Business существовала своя определенная группа, и мы как раз перешли в поддержку через SD. Эта группа была нужна для навигации написанных в свободной форме обращений сотрудников. Обращений через SD было 15-20% от общего количества. Их обработкой также занимался я.

Сам по себе SD как общебанковский стандарт очень даже неплох. Это довольно мощная система, которая позволяет делать различные выгрузки, формировать отчеты по заданным параметрам. Даже внутри интерфейса IT специалиста в карточке конкретного обращения по его номеру доступно великое множество самых разных вкладок, которые содержат ту или иную информацию. Это могут быть служебные поля, протокол обращения (история переписки с пользователем-заявителем) и много чего еще.

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

Я никому не открою Америку (но это стоит вспомнить), если скажу, что в любой helpdesk-системе существуют свои определенные шаблоны, через которые любой сотрудник может получить помощь или консультацию. Это может быть, например, шаблон для обращения с просьбой настроить работу какого-то конкретного ПО или проверить работу оборудования на программном или аппаратном уровнях. Или шаблон для обращения в поддержку смежной системы, с которой мы интегрированы, на предмет редактирования в ней определенных данных по клиенту. Шаблон для каждой системы свой, теперь он есть и для нашей. Бурные аплодисменты, представляю вам шаблон D7742!

С банковским стандартом к мировому гиганту

Итак, в нашем распоряжении появился собственный шаблон в SD для обращения сотрудников за помощью. У него есть определенный набор полей: тема, подтема и textarea-поле для свободного описания проблемы с вложениями. И с этого момента мы стали оказывать техническую поддержку PRO Business именно с него; при этом наш почтовый ящик передал эстафету и лишился статуса основного канала обращений.

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

• Все сопутствующие обращению данные (страница, условия возникновения бага, данные для воспроизведения) нам приходилось собирать по «крошкам».

• У нас не было возможности видеть взяли ли коллеги из внутренних команд обращение в работу.

• Не было выстроенной системы приоритетов и SLA, т.е. не было понимания, за какое время нужно решить тот или иной инцидент.

И в контексте второй части этого цикла статей я прокомментирую их.

Первая перечисленная проблема, а именно: отсутствие всех необходимых данных в одном месте была решена. Железно решена. Даже несмотря на то, что сотрудник порой мог не сразу предоставить полные данные, мы видели всю историю переписки с ним в одной вкладке внутри SD.

Вторая перечисленная проблема порождала большое количество вопросов к качеству оказываемой поддержке:

• Кто конкретно взял в работу обращение: команда технической поддержки или профильная внутренняя?

• Как контролировать обработку обращения?

• Как отслеживать обращения, которые были выполнены, но еще не валидированы и не проверены пользователем?

Эти вопросы пока оставим открытыми.

При всем этом имеет место быть один тезис. Дело в том, что все наши внутренние команды для своей работы используют Jira. Я упоминал об этом в первой части цикла статей и говорил, что у них есть ряд задач, которые ходят от статуса к статусу вплоть до полного внедрения изменений в проект. И как быть с теми обращениями, которые требуют вмешательства аналитиков или разработчиков? Создавать задачи на их досках в Jira?

Здесь я хочу плавно подвести к тому, что у нас возникла мысль сделать интеграцию нашего SD с Jira, а именно: при создании обращения по нашему шаблону D7742 происходит запрос в Jira, и на доске нашей платформенной команды создается задача с типом Incident, с которой мы и ведем дальнейшую работу.

Почему был выбран именно такой тип создаваемых задач? Опять же это связано с внутренними командами, которые трудятся над нашим PRO Business. Мы знаем, что в Jira есть свой набор таких типов задач. Это может быть баг, задача, инцидент и много чего еще. И нам нужно было каким-то образом выделить задачи, которые приходят к нам на поддержку, из общего пула задач конкретной команды. Кроме того, у него есть свой workflow, который мы настроили именно под нужны поддержки.

Для Jira мы с командой реализовали новую логику по работе с обращениями пользователей из SD:

1. Сотрудник в SD создает обращение по шаблону D7742.

2. SD передает данные по задаче (инциденту) в Jira и создает задачу в нашей доске платформенной команды.

3. Команда поддержки проводит первичный анализ обращения и пытается решить его самостоятельно. Если ее уровня экспертизы для этого недостаточно, создается клон этой задачи в пространство продуктовой команды, которая отвечает за этот функционал.

Это кастомный механизм, реализованный нашим разработчиком. Для задачи-клона мы, сотрудники поддержки, присваиваем ей приоритет, исполнителя (аналитика или разработчика) и пишем комментарии по обращению. Далее она попадает на доску Jira нужной команды.

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

Но так ли все хорошо? А как быть с контролем времени выполнения обращения? Как быть с нашей третьей проблемой?

Нам нужно решение проблемы любой ценой. Но бесплатно.

Во всей этой цепочке жизненного цикла первым стоит наш SD, и именно он определяет свои сроки по SLA (7-10 дней). И в принципе, можно было бы на них ориентироваться, но мы посчитали их слишком большими и некомфортными для пользователей, чтобы транслировать их нашим сотрудникам.

Поэтому мы взялись за проработку собственных внутрипроектных SLA по решению обращения для системы PRO Business. Мы стремились к компромиссу между решением инцидентов внутри продуктовых команд и разработкой ими бизнес-фич, так как эти два направления деятельности заведомо конкурирующие. Мы определили, что обращения с критическим и высоким приоритетом однозначно должны решаться в срок не более 1 рабочего дня. Система SLA четко фокусирует команды на решение проблемы и повышает лояльность к системе наших пользователей и клиентов.

Приоритеты проставляются в оригинальной задаче и автоматически транслируются во все создаваемые от нее клоны.

Казалось бы, все хорошо. Мы настроили взаимодействие с сотрудниками, которым требуется наша помощь. Если мы не можем решить его обращение силами поддержки, мы обращаемся за помощью к коллегам через механизм создания клонов, в которых нам дают конечный ответ аналитики и разработчики, и мы транслируем этот ответ сотруднику в оригинальной задаче.

Но как сделать так, чтобы аналитик и разработчик не упустил инцидент из внимания? Вовсе не из-за личных причин, а именно в силу человеческого фактора. Ведь помимо его задач в Jira, есть рабочие встречи в корпоративных мессенджерах по той или иной теме, переписка с коллегами из других подразделений.

При этом как отслеживать время выполнения того или иного клона в соответствии с приведенной выше таблицей SLA? Руками прибавлять текущее время к времени создания клона в Jira? Может быть. Но у меня есть способ лучше!

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

Спасибо за прочтение, буду рад прочитать ваши комментарии.