18 июля мы организовали митап, темой которого стали актуальные инструменты для техподдержки сотрудников. О том, как эти решения реализованы у них, рассказали трое руководителей поддержки в компаниях из разных отраслей — Александр Денисов и Вячеслав Куксов из Росбанка, Ярослав Сальников из КРОК и Юрий Пчелин из X5 Tech. Далее в посте — текстовая версия всех выступлений.

Зонтик, чатик, кабинетик: прокачиваем портал техподдержки от «фантика» до платформы

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

Сейчас у многих уже внедрен какой-либо ITSM-инструмент — коробочный продукт, который обычно уже включает портал. Но мы решили делать свой, и вот почему.

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

• Нужен мощный поиск — по нескольким базам знаний, новостной ленте, шаблонам заявок, и всё это с хорошей избирательностью.

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

• Имея свой портал, проще сменить одну ITSM-платформы на другую; под капотом одного портала мы сможем эксплуатировать даже не одну, а две ITSM-системы. 

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

Портал можно заказать у подрядчиков, а можно сделать самостоятельно. Мы выбрали второй вариант, чтобы развивать экспертизу внутри банка и быстро реализовывать изменения.

Сформировали ключевые принципы нового продукта.

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

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

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

• Шаблоны старой системы должны быть переработаны, а не просто перенесены.

• Нужно постоянно работать с обратной связью: через трекинг поведения на портале, ненавязчивые опросы и другие инструменты.

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

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

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

Теперь разберем отдельные элементы портала подробнее.

В результатах поиска раздельно выдаются заявки и статьи из базы знаний — она интегрирована из Confluence. Возможность организовать пространства в Confluence расширяет возможности поиска: по отдельным пространствам, по ключевым словам, по теме и описанию. Мы используем поисковый механизм Elasticsearch, о котором многие, наверно, слышали — довольно нагруженный, сложный в настройке инструмент, очень полезный при правильном подходе. На скриншоте выше можно видеть, что Elasticsearch умеет подстраивать выдачу с учетом опечаток.

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

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

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

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

В заключение — вывод, к которому мы пришли в процессе работы над порталом. Чтобы эффект от полного цикла взаимодействия в рамках одного окна был заметен, надо переориентировать команды поддержки с закрытия задач вовремя на закрытие задач с позитивной оценкой. Выглядит очевидным, но этот принцип может легко затереться при эшелонировании задач. Поэтому мы запустили в банке направление, где рассказываем сотрудникам об исследовании клиентского опыта, обмениваемся лучшими практиками с коллегами из бизнеса, решающими похожие задачи. Мы рассчитываем, это поможет увидеть за KPI реального человека, который нуждается в техподдержке, и выстроить сервис «от него».

Также нам помогает сильная экспертиза команды, отвечающей за ITSM. Благодаря ей, мы смогли пройти путь от идеи заказа портала на стороне до создания собственных ролей UI/UX-инженеров. В целом получилось так, что разработка своего решения с нуля оказалась совместима по стоимости с потенциальной доработкой рыночного решения под наши нужды.

Чат-боты и выдача доступа сотрудникам: как мы оптимизируем работу техподдержки КРОК

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

• прокачать информирование сотрудников,

• автоматизировать рутинные задачи сотрудников техподдержки,

• сделать внутренние сервисы удобнее.

На практике это было реализовано в двух направлениях — создание чат-ботов в телеграме и упрощение процедуры получения доступов к файловой системе и добавления в группу рассылки.

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

Одна из полезных функций бота — разблокировка учетной записи. Раньше сотруднику для этого нужно было звонить или идти в поддержку. Так же и с выдачей гостевого Wi-Fi: сделать это с телефона на корпоративном портале, когда вы уже сидите на встрече, довольно неудобно, а звонить в техподдержку долго. Бот решает эти сценарии в один клик.

Следующий бот, о котором стоит рассказать, — это welcome-бот для информационного сопровождения новых сотрудников в первые дни работы. Этот бот облегчает работу HR и руководителей, помогает с онбордингом и разгружает техподдержку. С ним по инструкциям можно настроить необходимые сервисы самому, а не идти в саппорт. Welcome-бот используют 95% новичков. Недавно мы попросили пользователей оценить этих двух чат-ботов, и каждый получил среднюю оценку 4,7 из 5.

Третий важный бот — это бот технической поддержки. Он помогает не только пользователям, но и инженерам саппорта. Бот интегрирован с Jira, так что с его помощью можно оперативно зарегистрировать заявку через телеграм. А затем через телеграм уведомления по заявкам приходят заметно быстрее, чем через почту, поэтому скорость работы и качество сервиса техподдержки растет.

Бот очень актуален для десктоп-инженеров, которые много передвигаются по офису. Теперь им не нужно каждый раз возвращаться на рабочее место, чтобы ответить по новой заявке, а можно сразу переходить к работе по ней. Мы внедрили бот в начале февраля, и там уже успели зарегистрировать почти полторы тысячи заявок; активность продолжает расти.

Еще один бот, который я хочу упомянуть, используется только внутри команды хелпдеска. Чтобы пользователи могли звонить сотрудникам техподдержки, они должны быть залогинены в Cisco Agent. Когда они не залогинены, дозвониться не получается, и уровень сервиса падает. С помощью бота супервайзер может следить за тем, кто залогинен или нет; последние, соответственно, получают уведомления. На время обеда бота можно поставить на паузу, чтобы спокойно отдохнуть.

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

Сейчас всё проще. После создания заявки MPS (Manage Permission System) сама ищет ответственного за папку и присылает ему уведомление. Ответственный за папку своим согласием запускает автоматическую выдачу прав доступа. Цепочка действий сильно уменьшается, и инженеры техподдержки в ней больше не задействованы. MPS самостоятельно удаляет ушедших сотрудников и создает задачи по их замене вручную. Если в кадровой системе у сотрудника меняется фамилия, то через шину данных фамилия автоматически обновляется и в MPS; если где-то автоматическую замену сделать нельзя, то формируется заявка для техподдержки на смену фамилии вручную.

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

Чат-боты и RPA в поддержке ретейла X5 Tech

Работая над IT-поддержкой, нужно понимать, в каком мире мы живем.

До технологических прорывов 1980-х мы жили в эпохе SPOD (steady, predictable, ordinary, definite). Каждый мог овладеть определенной профессией, разобраться, что к чему, и передать дело потомкам. С развитием интернета мир становится менее стабильным, каждому приходится поменять несколько профессий, чтобы удержаться на плаву, получить больше знаний. С эпохой пандемии мы переходим в эпоху BANI (brittle, anxious, nonlinear, incomprehensible). Здесь усилия и результат легко могут быть непропорциональны, и многие модели предиктивного анализа рушатся.

Как на это реагирует IT? Когда-то IT были придатком бизнеса. Затем они начали формироваться в свою вертикаль, которая иногда даже конфликтовала с бизнесом. Постепенно между IT и бизнесом выстроилось партнерство и образовались смешанные команды.

Теперь рассмотрим конкретно IT-поддержку. Мы всё еще любим считать SLA, OLA, затраты, CSI (индекс удовлетворенности), выстраиваем линии поддержки. Но в целом наш подход уже десятилетиями не меняется. Однако пользователи живут уже в BANI-мире, и их требования к техподдержке изменились соответствующим образом:

• нужно решать проблемы онлайн, чтобы не прерывать бизнес-операции;

• нужно решать проблемы без чтения документации;

• нужно иметь возможность влиять на IT-процессы на пользу другим (отзывы, оценки).

В связи этим мы в X5 Tech решили добиться того, чтобы не допускать создания инцидентов в принципе, ловить пользователя до того, как он столкнется с проблемой и создаст заявку на портале поддержки. Так сформировалась воронка недопуска инцидентов:

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

Чат-бот работает через JavaScript в отдельном окошке на сайте, и в нем интегрирована аутентификация ADFS и Keycloak. Популярные сценарии взаимодействия мы выносим в отдельные кнопки диалогов. По необходимости явно указываем нужные элементы интерфейса, как это делается в базах знаний.

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

В рамках интуитивно понятного интерфейса заказчики могут создать любого бота, даже не имея навыков программирования. Это возможно благодаря визуальному no-code редактору J-Graph в рамках основного программного обеспечения; это оснащенная NLU-ядром CAILA (Natural Language Understanding) платформа JAICP компании Just AI для разработки разговорных решений любой сложности. JAICP уже имеет готовые коннекторы с Teams, Telegram и не только,  но здесь возникает вопрос чувствительных данных, поэтому такие внедрения мы пока не делали. Сейчас планируем все-таки сделать омниканальный аналог welcome-бота, в работе которого чувствительные данные не задействованы.

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

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