Разработка сервиса урегулирования претензий в личном кабинете СОГАЗ

1. Вводная задача от заказчика, проблематика, цели

О компании

Страховая группа «СОГАЗ» основана в 1993 году и является одним из лидеров российского страхового рынка.

СОГАЗ предлагает более 100 программ страхования для физических лиц и предприятий различных отраслей. Региональная сеть группы включает более 1000 подразделений и офисов продаж по всей России.

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

Задача

СОГАЗ требовалось расширить функциональность существующего личного кабинета и создать новый цифровой канал для урегулирования претензий.

Клиент должен был получить возможность пройти весь основной процесс дистанционно:

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

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

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

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Не просто форма, а полноценный цифровой процесс

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

Состав и логика формы зависят от того:

• кто подает претензию — физическое или юридическое лицо;
• действует пользователь лично или через представителя;
• на каком основании действует представитель;
• кем является заявитель по отношению к договору и страховому случаю;
• какие сведения уже существуют в информационных системах СОГАЗ;
• какие документы необходимо запросить именно для выбранного сценария;
• каким способом должны быть подтверждены полномочия пользователя.

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

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

Новый раздел «Мои претензии»

В существующий личный кабинет СОГАЗ мы встроили отдельный функциональный раздел «Мои претензии».

Он объединяет два основных пользовательских сценария:

Подать новую претензию — последовательное прохождение процесса от идентификации заявителя до формирования и отправки комплекта документов.

История претензий — работа с уже зарегистрированными обращениями, их статусами, документами и сообщениями.

Сервис поддерживает подачу новых претензий, добавление документов, просмотр истории, отслеживание статусов и отзыв претензии.

Авторизация и идентификация пользователя

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

Для подтверждения личности и определения доступного пользователю сценария была реализована работа с ЕСИА и электронной подписью.

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

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

УКЭП, КриптоПро и машиночитаемые доверенности

Одной из наиболее технически сложных частей проекта стала проверка полномочий представителей юридических лиц.

Сервис должен определить, кому принадлежит сертификат электронной подписи: юридическому лицу, ИП или физическому лицу — представителю организации.

Для этого анализируются атрибуты сертификата, включая ИНН и ОГРНИП.

Для представителей дополнительно реализована работа с машиночитаемыми доверенностями.

Система проверяет МЧД и сопоставляет сведения из доверенности с данными сертификата электронной подписи. Для предусмотренных проектом форматов МЧД анализируются в том числе ФИО, СНИЛС и ИНН. Также предусмотрена проверка полномочий подписанта.

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

Динамическая форма подачи претензии

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

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

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

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

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

Работа с документами

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

В рамках проекта реализована работа с:

• печатной формой претензии;
• документами пользователя;
• банковскими реквизитами;
• доверенностями и МЧД;
• согласиями;
• дополнительными документами;
• ответами и запросами страховой компании.

Сервис формирует PDF-документы на основании заполненных пользователем данных, управляет приложениями и передает документы через интеграционный слой в корпоративные системы СОГАЗ. Архитектура микросервиса предусматривает генерацию PDF, обработку файлов, асинхронную отправку и получение статусов.

Юридически значимый электронный документооборот

Отдельным контуром проекта стала реализация электронного взаимодействия между заявителем и страховой компанией.

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

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

История и контроль рассмотрения претензий

После подачи претензия не исчезает из личного кабинета.

Мы реализовали историю обращений, где пользователь может видеть:

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

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

Статусы синхронизируются с внутренним процессом рассмотрения. Пользователь получает понятное отображение движения претензии — от регистрации и рассмотрения до направления ответа или отзыва.

Двусторонняя коммуникация

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

В процессе рассмотрения сотрудникам СОГАЗ может потребоваться дополнительная информация или документы.

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

Пользователь может:

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

История такого взаимодействия сохраняется в карточке обращения вместе с регистрационными номерами и документами.

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

Архитектура решения

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

В существующую CMS 1С-Битрикс был разработан отдельный модуль, связывающий пользовательский интерфейс с сервисом претензий через JSON API. Модуль включает компоненты формы, списка и детальной карточки претензии и обеспечивает взаимодействие с сервисным слоем.

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

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

Интеграции с корпоративными системами

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

В интеграционный контур проекта вошли:

• ЕСИА — идентификация пользователей;
• КриптоПро — работа с сертификатами электронной подписи;
• сервис личного кабинета — получение доступных данных пользователя и договоров;
• интеграционная шина СОГАЗ;
• корпоративная учетная система;
• система электронного документооборота Documentum;
• сервисы формирования и подписания документов;
• DaData — получение и проверка отдельных справочных данных.

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

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

Асинхронная обработка и устойчивость интеграций

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

Поэтому отправка претензий спроектирована с использованием очередей и асинхронной обработки.

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

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

Журналирование и прослеживаемость операций

Для финансового и страхового сервиса важно иметь возможность восстановить последовательность обработки операции.

Мы предусмотрели журналирование ключевых событий:

• прохождение авторизации;
• результаты проверки ЕСИА;
• загрузка и проверка УКЭП;
• загрузка и проверка МЧД;
• результаты валидации;
• формирование и отправка претензии;
• обмен с интеграционной шиной;
• получение списка и детальной информации;
• отправка дополнительных сообщений.

Для критических операций логируется прохождение отдельных этапов процесса.

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

Разработка полностью в контуре СОГАЗ

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

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

Исходный код проекта и история изменений размещались в корпоративном GitLab СОГАЗ. Для разработки и тестирования использовались отдельные контуры, а в непродуктивных средах запрещалось использование продуктивных данных. Доступ из сред разработки и тестирования к продуктивной инфраструктуре также был разделен.

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

Безопасная разработка как часть процесса

Требования информационной безопасности в этом проекте не были отдельной проверкой перед релизом — они были частью самого процесса разработки.

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

• разделению dev-, test- и production-контуров;
• разграничению доступа;
• работе с персональными данными;
• персонализированным учетным записям;
• защищенному межсервисному взаимодействию;
• журналированию событий;
• управлению исходным кодом;
• автоматизированному процессу установки обновлений;
• управлению рисками перед промышленным вводом;
• контролю уязвимостей и обновлений безопасности.

Отдельные требования проекта распространялись на соблюдение 152-ФЗ, законодательства об электронной подписи и требований к электронному взаимодействию страховщика и страхователя.

Команда «Цифрового Элемента»

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

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

• бизнес- и системные аналитики;
• UX/UI;
• frontend-разработчики;
• backend-разработчики;
• специалисты по 1С-Битрикс;
• QA-инженеры;
• DevOps;
• руководитель проекта.

«Цифровой Элемент» закрывает эти компетенции собственной командой и может вести подобные проекты от анализа требований и проектирования до разработки, интеграционного тестирования и ввода изменений в эксплуатационный процесс заказчика.

Это было важно и на этапе выбора подрядчика: требования СОГАЗ отдельно предусматривали наличие собственного штата backend- и frontend-разработчиков, тестировщиков, проектировщиков, дизайнеров и аналитиков, а также опыт работы с финансовыми организациями и интеграционными проектами.

Процессы для финансовых и страховых компаний

Работа внутри инфраструктуры крупной финансовой организации требует умения встроиться в процессы заказчика, а не пытаться заменить их собственными.

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

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

Для «Цифрового Элемента» такой формат работы является частью процессов разработки проектов для компаний финансового и страхового сектора.

3. Результаты сотрудничества

В личном кабинете СОГАЗ появился отдельный цифровой сервис, который объединяет весь основной цикл работы с претензией:

Идентификация → выбор роли → заполнение данных → загрузка документов → электронная подпись → регистрация → рассмотрение → дополнительная коммуникация → получение результата.

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

При этом архитектура разделяет пользовательский интерфейс, бизнес-логику и интеграционный слой, а разработка выполнена внутри защищенного контура СОГАЗ с учетом требований информационной безопасности.

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