«Кочки и ухабы» электронных инструментов ОСАГО

«Кочки и ухабы» электронных инструментов ОСАГО

В современном мире многие процессы упрощаются благодаря интернет-технологиям. Всё больше решений реализуется в области виртуальных коммуникаций. И в сфере страхования автогражданской ответственности не обошлось без использования плодов технического прогресса. Огромные информационные потоки требуют применения современных возможностей для решения текущих задач по оптимизации системы ОСАГО. При грамотном и профессиональном подходе автоматизация алгоритмов взаимодействий участников рынка может привести к существенным плюсам. Это и электронный документооборот, позволяющий добиться значительной экономии времени; и уменьшение степени влияния субъективных факторов; и, в конце концов, снижение расходов всех вовлечённых сторон.

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

Прямое возмещение убытков (ПВУ)

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

Недочёты в реализации задумки выявились сразу. Дело в том, что в качестве компенсации между страховыми компаниями фигурировали фиксированные суммы, не зависящие от реального убытка. Да, размер этих сумм являлся средним для конкретного региона и был статистически обоснован. Но, тем не менее, такая особенность кому-то из страховщиков давала возможность заработать, а кого-то откровенно тянула в минус. «Нежелательного» пострадавшего при этом могли попросту гонять между организациями. Если человек получал письмо с отказом в ПВУ от своей страховой компании — он не мог проверить соответствие данного документа информации в электронной базе. А если отказ в акцепте страховщика виновника действительно имел место — его правомерность также оставалась «за семью печатями».

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

Коэффициент бонус-малус (КБМ)

«Коэффициент бонус-малус» существенно влияет на расчёт ОСАГО. Данная величина учитывает страховую историю, в зависимости от которой стоимость полиса может отличаться в разы. Несовершенство системы информационного обмена между страховщиками долгое время приводило к практической несостоятельности КБМ. По сути, на рынке можно было найти возможность страхования с максимально возможной (теоретически) скидкой за безубыточность без подтверждения её обоснованности. При этом сотрудники страховых компаний сознательно шли на нарушения, понимая практическую недоказуемость оных.

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

И речь здесь даже не идёт о каких-то кратковременных сбоях в работе общей базы и иных эпизодических вопросах технического характера. Гораздо важнее тот факт, что очень многие водители, имея за плечами годы безаварийной езды, не находятся в системе при оформлении очередного полиса. Чаще всего причинами таких случаев являются ошибки при занесении личных данных в программу операторами страховщиков. Удивительного здесь ничего нет: при обработке десятков полисов в день сложно сохранить максимальную степень внимания на всём протяжении рабочего времени. Да и в первичных страховых документах данные бывают указаны весьма небрежно. Пропущенная буква или опечатка в дате рождения просто не позволит идентифицировать водителя при запросе на основе верных сведений.

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

Техосмотр (ТО)

Без действующего технического осмотра полис ОСАГО — за некоторыми исключениями — не может быть оформлен. А с 01 июля 2014 года наличие диагностической карты (талона) необходимо проверять через онлайн сервис РСА. Так гласит статья 29 ФЗ-170 от 01.07.2011, и в данном случае Российский Союз Автостраховщиков реализовал соответствующую возможность вовремя. Такое новшество видится весьма удобным. Но после запуска электронного сервиса выяснилось, что далеко не все диагностические карты оказываются подтверждёнными ресурсом РСА — даже при том, что их «узнаёт» при проверке непосредственно ЕАИСТО («первичный» электронный каталог техосмотров).

С чем связан подобный факт? Дело в том, что в системе РСА изначально была реализована некая «нормализация» — для удобства унифицирующая некоторые символы. Она включает в себя определённые правила:

Преобразование строчных букв к верхнему регистру.
Преобразование следующих букв кириллицы к букве латинского алфавита, идентичной по написанию: А, В, Е/Ё, К, М, Н, Р, С, Т, У, Х.
Преобразование букв кириллицы и латиницы «O» в «0» (ноль).
Преобразование латинской «L» в «1» (единицу).
Преобразование латинской «I» («i») в «1» (единицу).
Преобразование буквы кириллицы «З» в цифру «3».
Допустимые специальные символы и пробел должны обрезаться.
Строки, содержащие серию и номер документа, должны объединяться.


То есть, номер VIN, поступивший в систему РСА для проверки наличия ТО, может быть автоматически изменён перед отправкой в ЕАИСТО, где подобная «нормализация», разумеется, никогда не действовала. Как результат — в каталоге изменённый идентификационный номер не находится, и техосмотр не подтверждается. Судя по результатам практической работы над сервисом, описанный недочёт был полностью или частично устранён. Тем не менее, мы снова сталкиваемся с ситуацией, когда внедрённый инструмент дорабатывается уже после официального «выпуска в свет». А заложниками ситуации, к сожалению, традиционно являются непосредственные участники рынка «автогражданки».

Неизбежность или?..

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

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

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: