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

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

Простота — это тоже прогресс

Внутренний сервисный портал для сотрудников Росгосстраха — это не совсем про прогресс и прорывные технологии. Это про удобство и скорость работы с уже внедренными в компании программными продуктами и информационными системами.

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

Портал в себе объединил функционал как внешних автоматизированных систем (АИС), так и внутренних. BFF (Back For Front) связывается через специальные адаптеры с REST\WSDL сервисами различных АИС, преобразовывая данные и создавая цепочки вызовов для получения нужного и понятного результата на выходе с минимальным набором атрибутов на входе. Получается некий прокси-сервис с накрученной логикой и обработкой между сотрудником компании перед монитором и набором АИС, где результат состоит из компоновки ответов от опрошенных систем. Схема примерно вот так (очень упрощенно):

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

·         повышения эффективности в работе;

·         сокращения сроков ответа на запрос;

·         получения объективной и не искаженной информации.

Забота над ошибками — как внести корректировки в страховой полис

Теперь давайте рассмотрим, какого рода проблемы и как приходилось решать. Пожалуй, самая понятная для всех история — это ОСАГО. Человеку, который садится за руль, конечно, невдомек, что при оформлении полиса идет обмен данными между страховой компанией и Национальной страховой информационной системой (ранее — с информационными системами Российского союза автостраховщиков).

Когда внедряли информационную систему РСА 2.0, для работы с сервисами Российского союза автостраховщиков использовался только Postman и подобные ему инструменты отправки REST-запросов. Естественно, работать с этим сервисом создания, тестирования, документирования, публикации и обслуживания API могли в компании не все. Разработчики, аналитики, инженеры еще имели навыки такой работы и могли понять, как выполнить тот или иной сценарий, а службы поддержки или представители основного бизнеса — нет. Как следствие к обладающим нужной компетенцией специалистам выстраивалась очередь заявок на решение проблем, требовавших очень быстрого решения.

К примеру, клиент оформлял у нас полис ОСАГО на купленную машину, а в ГИБДД выяснялось, что какие-то пункты в нем не соответствую данным в информационных системах РСА. И в итоге запускалась цепная реакция:

·         клиент звонит своему страховому агенту и спрашивает, что за ерунда происходит

·         агент смотрит в свою программу и видит, что у нас все данные введены корректно

·         агент создает заявку о помощи в решении проблемы через Helpdesk с пометкой «Сроооочно!»

·         оператор первой линии поддержки сам справиться не может и переводит заявку на вторую линию поддержки

·         когда у сотрудника второй линии дойдут руки в череде других срочных заявок до этой, он посмотрит, что не так с договором в НСИС (через Postman)

·         потом он сходит в необходимое подразделение и возьмет там нужные документы

·         отправит запрос в НСИС на исправление ситуации

·         дождется ответа от НСИС

·         проанализирует этот ответ, если есть ошибки — исправит их

·         отдаст ответ в заявку.

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

А ведь иногда подобные проблемы возникают в более серьезном масштабе — например, когда для сверки в ЦБ требуется получить данные нескольких тысяч договоров из НСИС/РСА. Без инструмента решить эту задачу можно в среднем за 2 дня, если ею и только ею будет постоянно заниматься один инженер.

 Вспомнить все — как я поневоле стал разработчиком сервисного портала

Когда в 2020 Российский союз автостраховщиков ввел в эксплуатацию АИС 2.0 вместо предыдущей версии автоматизированной информационной системы, в которой были все данные клиентов по ОСАГО, у нас в компании здорово «полыхнуло». Переход от XML к JSON переделка всех моделей данных и запросов, совершенно другая логика обработки и прочее…

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

 Поначалу заявок было немного, но потом «падает» одна из интеграций, и у нас застревает около тысячи договоров на отправку… Недолго думая, вызываюсь помочь с этой проблемой. И начинаю вспоминать, как писать что-то на PowerShell (да-да, прародителем текущего решения был скриптик на PowerShell)…

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

1)    отсутствие у некоторых коллег сетевых доступов до ресурсов;

2)    большое время занимает подготовка перед запуском скрипта;

3)    под каждый случай нужен свой скрипт

Для победы над второй и третьей проблемой пришлось вспоминать институт и C# …

Так появилась вторая версия текущего решения, написанная на WinForms (C#, ClickOnce). Теперь я мог бы, конечно, со спокойной душой отдать установщик сотруднику и дальше заниматься своей основной работой. Но ведь проблему сетевых доступов я так и не решил, да и к тому же появились новые сложности — с разграничением прав и добавлением новых сотрудников в программу.

В результате была начата разработка текущей версии приложения. За основу был взят ASP.NET.Core (раз начал на C#, то почему бы и не продолжить?) Долго выбирал фреймворк для фронта, но остановился на Blazor. Заманил он меня тем, что позволяет писать обработку событий на фронте так же на C#. То есть, мне не нужно было учить Angular, NextJS, React и прочие популярные JS фреймворки. После чего осталось настроить авторизацию через AD, чтобы гибко управлять доступом и ролями и перенести функционал в новое решение.

 И что получается в итоге, если всплывает описанная выше проблема с полисом ОСАГО?

·         Недовольный клиент звонит страховому агенту.

·         Агент смотрит в свою программу и видит, что у нас все данные введены корректно.

·         Агент создает заявку о помощи в решении проблемы через Helpdesk с пометкой «Сроооочно!»

·         Оператор первой линии, используя Внутренний сервисный портал, моментально получает всю информацию по договору.

·         Оператор первой линии исправляет договор в НСИС.

·         Оператор первой линии закрывает заявку.

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

 Могут ли инновации «потушить» выгорание сотрудников?

Сегодня у внутреннего сервисного портала около 150 активных пользователей — причем, как из служб поддержки, так и из бизнес подразделений. Благодаря этому инструменту некоторые бизнес-процессы удалось упростить более чем на 90%. Так же благодаря интерфейсу на портале некоторые процессы, которые ранее относились сугубо к сфере IT, теперь реализуются сотрудниками, не имеющими отношение к информационным технологиям.

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

И в отдельных случаях — это повышение аналитической способности у сотрудника. Интерфейс сделан специально так, чтобы минимизировать входные параметры и максимизировать выходные данные. К примеру, для поиска по полису ОСАГО мы вводим только его серию и номер, а на выходе получаем полный набор данных из НСИС и учетных систем, включая информацию по убыткам, если таковые у клиента есть.

 Это позволяет оценивать результаты и страхователя с разных сторон.

То есть, тем самым мы не только «тушим» выгорание, но и помогаем сотруднику в какой-то степени повысить свою профессиональную капитализацию как внутри компании, так и в целом на рынке труда.