Цифровая сервисная платформа НСИС: многоролевой личный кабинет, электронная подпись и интеграция с АИС страхования

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

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

Проект НСИС изначально выходил далеко за рамки разработки корпоративного сайта.

Пользователю необходимо не только получить информацию о компании или страховании, но и решить конкретную задачу: проверить полис ОСАГО, узнать КБМ, получить страховую историю, найти сведения о страховом случае, сформировать обращение или выполнить юридически значимый запрос.

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

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

О заказчике

АО «Национальная Страховая Информационная Система» — оператор автоматизированной информационной системы страхования.

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

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

Задача

Необходимо было создать не набор информационных страниц, а полнофункциональную цифровую платформу с несколькими связанными контурами:

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

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

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

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

Спроектировали пользовательские сценарии до разработки интерфейсов

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

Физические лица работают со страховой информацией, полисами, страховыми случаями, КБМ, страховой историей и обращениями.

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

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

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

СМИ используют пресс-центр и сервис обращения в пресс-службу.

Соискатели работают с карьерным разделом и вакансиями.

Для основных сценариев подготовили User Flow, структуру портала и интерактивные прототипы.

Отдельные UX-гипотезы проверили на пользовательском тестировании. В частности, уточнили структуру навигации, видимость специализированных разделов и сценарии, в которых перед авторизацией пользователю необходимо сначала понять назначение и статус НСИС.

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

Построили информационную архитектуру вокруг пользовательских задач

Структуру публичной части формировали не по внутренней организационной структуре НСИС, а по пользовательским сценариям.

В портал вошли:

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

При этом страницы не проектировались как набор жестко заданных шаблонов.

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

Это позволило сохранить единый дизайн и одновременно дать редакторам возможность самостоятельно формировать новые страницы в CMS.

Публичная часть стала полноценным сервисным слоем

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

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

Проверка наличия ОСАГО по транспортному средству

Пользователь может проверить наличие активного договора ОСАГО по данным автомобиля.

Для поиска достаточно указать один из идентификаторов:

• государственный регистрационный знак;
• VIN;
• номер кузова;
• номер шасси.

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

Проверка ОСАГО для конкретного водителя

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

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

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

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

Проверка статуса полиса ОСАГО

По серии и номеру полиса пользователь может проверить его статус и получить основные сведения:

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

Проверка полиса по QR-коду

Для полисов ОСАГО предусмотрен отдельный сценарий с QR-кодом.

Пользователь сканирует QR-код мобильным устройством и переходит на портал НСИС.

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

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

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

Публичная часть и личный кабинет работают как единый продукт

Логика главной страницы зависит от состояния пользователя.

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

После авторизации портал становится персональным интерфейсом.

Для авторизованного пользователя проектировался дашборд с данными страхования: полисами, транспортными средствами, связанными персонами, ДТП и КБМ.

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

Например, выбор конкретного транспортного средства позволяет перейти непосредственно к связанным с ним полисам.

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

Многоролевый личный кабинет

Личный кабинет НСИС — один из наиболее функционально сложных контуров проекта.

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

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

В системе предусмотрены три основные роли:

• Физическое лицо — PERSON;
• Юридическое лицо — ORGANIZATION;
• Арбитражный управляющий — ARBITRATION_TRUSTEE.

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

Физическое лицо

Для физического лица предусмотрена авторизация через ЕСИА / Госуслуги.

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

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

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

Юридическое лицо

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

Система:

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

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

Арбитражный управляющий

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

Авторизация также выполняется с использованием УКЭП.

После идентификации система дополнительно проверяет полномочия пользователя через АИС «Сведения о банкротстве».

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

Переключение ролей

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

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

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

Специализированный сервис для арбитражных управляющих

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

После проверки полномочий пользователь переходит в раздел запросов и выбирает тип должника:

• физическое лицо;
• юридическое лицо.

Система формирует соответствующую форму и проверяет введенные данные:

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

После заполнения запрос должен быть подписан УКЭП.

Сайт проверяет наличие КриптоПро и доступных сертификатов, пользователь выбирает подпись, после чего формируется открепленная подпись CADES-BES.

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

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

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

Работа со страховой историей

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

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

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

Поддержали УНЭП и УКЭП

Способ подписания определяется ролью пользователя и контекстом работы.

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

Госключ / УНЭП — используется для соответствующих сценариев физического лица.

КриптоПро / УКЭП — используется на desktop-устройствах при наличии действующего сертификата.

Для юридического лица подписание запроса выполняется с использованием УКЭП.

Система учитывает:

• роль пользователя;
• способ первоначальной авторизации;
• данные профиля;
• наличие ЕСИА ID или СНИЛС;
• тип устройства;
• наличие КриптоПро;
• доступность сертификата УКЭП.

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

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

Реализовали работу с КБМ

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

Пользователь запускает запрос из личного кабинета.

Запрос передается на backend, после чего интерфейс контролирует состояние его обработки и получает рассчитанное значение КБМ.

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

Полисы, страховые случаи и обращения

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

Полисы

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

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

Страховые случаи

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

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

Обращения

Обращения собраны в отдельном журнале.

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

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

Поиск и фильтрация реализованы как общий механизм

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

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

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

Интеграционная архитектура

Пользовательский интерфейс портала отделен от внутренних сервисов НСИС.

Для взаимодействия используется backend-for-frontend — BFF.

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

Пользователь → Сайт → BFF → сервис НСИС / АИС → BFF → Сайт.

Через интеграционный слой реализованы:

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

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

Реализовали асинхронную обработку длительных операций

Часть запросов не может быть обработана мгновенно.

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

Сайт:

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

Используются состояния:

• PROCESSING;
• DONE;
• ERROR.

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

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

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

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

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

В административной системе согласия существуют как отдельная версионируемая сущность.

Для каждого согласия можно хранить:

• тип;
• код;
• версию;
• текст;
• дату начала действия;
• срок действия;
• историю изменений.

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

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

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

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

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

На основании этих данных могут персонализироваться:

• сторис;
• материалы пресс-центра;
• поисковые подсказки;
• отдельные информационные блоки.

Для неавторизованных пользователей механизм учитывает согласие на использование cookie.

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

Разработали продуктовую дизайн-систему

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

Мы сформировали UI-kit и единые правила для:

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

Основной принцип визуальной концепции:

«Чистота и технологичность в сочетании с мягкостью и человечностью».

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

Основным шрифтом стал Onest.

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

Разработали специализированную CMS

Отдельным большим контуром проекта стала административная система.

Она предназначена не только для публикации страниц и новостей.

CMS позволяет управлять:

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

Роли и права

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

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

• просмотр;
• создание;
• изменение;
• удаление.

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

Управляемые формы

Формы существуют в CMS как управляемые сущности.

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

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

Компонентные страницы

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

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

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

Формализовали контроль качества

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

Мы подготовили отдельные программы и методики испытаний для:

• публичной части;
• административной части;
• личного кабинета.

Программа испытаний публичной части и CMS содержит более ста страниц.

В ней зафиксированы условия проведения проверок, тестовые сценарии и критерии успешности.

Для публичной части проверялись в том числе:

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

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

Отдельно испытали личный кабинет

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

Проверялись:

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

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

Решение прошло приемо-сдаточные испытания

Публичная часть портала прошла приемо-сдаточные испытания 1 апреля 2024 года.

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

Отдельные приемочные испытания личного кабинета прошли 29 мая 2024 года.

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

Национальная Страховая Информационная система

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

Результат

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

Она объединяет:

• публичный информационный портал;
• публичные сервисы проверки страховых данных;
• многоролевый личный кабинет;
• сценарии физических лиц;
• сценарии юридических лиц;
• специализированный кабинет арбитражного управляющего;
• ЕСИА;
• УКЭП и КриптоПро;
• Госключ и УНЭП;
• асинхронные запросы к информационным системам;
• персонализацию;
• продуктовую дизайн-систему;
• специализированную CMS;
• управление ролями и согласиями;
• формализованное приемочное тестирование.

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

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