{"id":14284,"url":"\/distributions\/14284\/click?bit=1&hash=82a231c769d1e10ea56c30ae286f090fbb4a445600cfa9e05037db7a74b1dda9","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0430\u043d\u0446\u044b \u0441 \u0441\u043e\u0431\u0430\u043a\u0430\u043c\u0438","buttonText":"","imageUuid":""}

Кейс IQ Dev для страховой компании: сокращение обработки заявок, автоматическая проверка страхуемого теперь 20 мин

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

Как Андрей Долгушин (наш тимлид) помогал службе безопасности одной крупной страховой компании расскажем ниже.

На входе: крупная страховая компания (NDA) , ручной ввод данных и проверка по базам на предмет: мошенничества, задолженности перед СК, банкротства, участия в ДТП и т. д.

Задачи:

  • Сократить время обработки заявок
  • Автоматизировать и ускорить процесс проверки страхуемых (физ. лица, юр. лица, транспортные средства и полуприцепы)

Весь процесс мы поделили на этапы:

  • Распознавание изображений со сканов документов
  • Автозаполнение данных
  • Проверка данных по внутренним и внешним сервисам

1. Распознавание изображений

Заявки в систему заводятся сотрудниками страховой компании несколькими путями:

  • Почта.

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

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

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

Про сам парсер:

Для каждого типа объекта описана «схема» парсера — набор правил (как соотносить поля между шаблоном и заданной моделью данных, их связь между собой, обязательность и правила заполнения) .

  • Внутренняя форма на сайте

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

Было принято использовать сервис DBrain, сам процесс распознавания поделен на 2 этапа: upload (загрузка) и recognize (распознавание)

Upload (Загрузка) .

На первом этапе происходит загрузка файла, получается id задачи в системе DBrain. Т. к. неизвестно какого размера пользователь может загрузить файл, и чтобы не поперхнулся ни dbrain, ни мы, ожидая ответа (а мы помним, что наша задача ускорить процесс обработки) , файл предварительно сжимается до определенного размера. (примерно до 1 МБ) .

Recognize (Распознавание)

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

Итак, мы получили распознанные данные. Что дальше?

2. Автозаполнение данных.

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

Для каждого документа определен список полей при совпадении по которым он считается эквивалентным другому: для физ. лица — это ФИО и дата рождения, для юр. лица — ИНН, ОГРН и тд. Все данные проверяются и соединяются в карту страхуемого.

  • Проверка данных по внутренним и внешним сервисам

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

Проверка выполнялась по критериям:

Для физических лиц:

  • судимость у страхуемого лица
  • проверка страхуемого на наличие информации о мошенничестве (внутренний сервис компании)
  • проверка действительности паспорта
  • проверка страхуемого на наличие информации о мошенничестве (внутренний сервис компании)

Пример проверки физ. лица

Для транспортного средства и полуприцепов:
  • участие в дтп

  • история регистрационных действий

  • проверка по базам розыска

  • лизинг
  • использование в такси

Пример проверки ТС

Для юридических лиц:

  • проверка задолженностей перед СК
  • проверка данных в налоговых органах об организации
  • соответствие предоставленных сведений и сведений, заявленных в налоговых органах

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

А что в итоге?

В итоге мы:

  1. Ускорили процесс проверки заявок и сократили время обработки
  2. Автоматизировали проверки на благонадежность страхуемого для СБ
  3. Автоматизировали проверку во внутренних и внешних сервисах на предмет мошенничества, судимости, использования ТС под такси и тд.

Весь процесс регистрации и проверки страхуемого лица занимает теперь 20 мин.

0
Комментарии
-3 комментариев
Раскрывать всегда