Після 20 -ти років існування ОСАЦВ в Україні достовірна , загальнодоступна статистика , необхідна для визначення значень коефіцієнтів , визначення вартості поліса відсутня.
Тому й проблеми на ринку починаються вже при рівні виплат у 39 % - одні компанії зазнають збитків , інші отримують надприбутки , в одному регіоні ОСЦПВ збиткове , в іншому прибуткове. У той же час, наприклад , російський ринок ОСЦПВ працює на збитковості 77 % , а багато країн - до 90 %. За величиною покриття , якості врегулювання , витрат на ведення справи , реальному захисту учасників дорожнього руху України знаходиться на останньому місці в Європі.
Першу реально працюючу базу даних МТСБУ з достовірною статистикою і внутрішню ІТ -систему бюро створила компанія « Українські страхові інформаційні системи» , що має багаторічний досвід автоматизації бізнес- процесів ОСЦПВ як в МТСБУ , так і в десятках страхових компаній України ( інформаційна система INSCOM ) .
У 1998 році в МТСБУ вперше на українському ринку була створена і функціонувала база даних по полісах та виплат ОСЦПВ і Зеленої карті. Є позитивний досвід - страхові компанії отримували спеціалізовані бюлетені зі статистичними звітами по збитковості в різних розрізах .
За весь час існування МТСБУ формалізації та автоматизації внутрішніх бізнес - процесів приділялася абсолютно недостатня увага - відсутня концепція , бюджети , плани , терміни, відповідальні .
В останні 2 роки розвиток внутрішньої інформаційної системи взагалі заморожено , незважаючи на реальні потреби та надані заявки на доопрацювання співробітників юридичного відділу , відділу виплат , бухгалтерії.
Необхідно повернутися до суті бази даних , закладеної в Законі , спільними зусиллями визначити її цілі та шляхи їх досягнення .
Пропонуємо обговорити суть бази даних , її мети. У Законі сказано: « містіть Відомості про чінні та пріпінені договори обов'язкового страхування цивільно-правової відповідальності , Страхові випадка , что малі місце , транспортні засоби та їх власніків ».
Цілком очевидно , що інформаційна система МТСБУ і методи взаємодії з даними повинні відповідати прийнятій архітектурі державної системи "Електронний уряд" , і тільки спільними зусиллями ми зможемо реалізувати дану задачу якісно і в строк.
Пропозиції щодо вдосконалення Централізованої бази даних МТСБУ
Для успішної реалізації бази даних необхідно приділити увагу всьому ланцюжку формування даних - від введення на місцях до завантаження даних в ЦБД . Головне завдання - максимально оперативно (день -в -день ) формувати дані на місцях. Це основне завдання , і для її вирішення необхідно:
1 Проста структура файлів , що формуються в страхових компаніях - . Тільки необхідні для централізованого обліку поля.
2 . Однозначну , простий і незмінний алгоритм ( логіка) формування даних , описаний в одному документі. Тобто хороша методологія .
3 . Організаційна та технічна допомога страхового ринку з формування інформації по кожному полісу і кожній виплаті , оперативної передачі в МТСБУ.
4 . Ухвалення всіх переданих даних і допомогу страховим компаніям в недопущенні помилок надалі .
Отже , основна мета - своєчасність передачі і достовірність (чистота ) даних в ЦБД . Це і є вимога Закону . Водночас , замість виконання положень Закону ставляться інші завдання - реалізація в рамках ЦБД елементів бухгалтерського обліку , фінансова звітність , закриття періодів , облік бланків по агентам і навіть зберігання в ЦБД скан -копій європротоколів . Ці Завдання не мають відношення до Закону , а їх виконання відволікає ресурси і час від виконання вимоги Закону , ускладнює і робить неможливим на практиці їх виконання.
Навіть за наявності бази даних вимоги Закону можуть бути взагалі не виконані , якщо відсутня цілісність і лаконічність побудови облікової моделі . Реалізація не повинна бути громіздкою , складною , методологія повинна бути простою і однозначною , необхідно виключити невластиві функції , спростити дані і логіку.
В іншому випадку ці чинники перешкоджатимуть і робити неможливим своєчасний збір достовірних даних від страховиків . ЦБД , поки не реалізовано підтвердження поліса в режимі он- лайн. Поки агенти продають поліси «в полі» повинна пропускати всі дані - не перешкоджати потраплянню в ЦБД вже наявної інформації про реальні полісах і здійснені виплати . Зараз опис структури переданих таблиць та переліку помилок містить 114 сторінок - 104 поля в полісі , 70 полів у виплатах , контроль 160 помилок.
Неоднозначні методи обліку взагалі можуть зробити неможливим статистичну обробку вже внесених даних , а всю виконану роботу - безглуздою.
Зараз у базі даних змішалися різні коди для позначення одного і того ж , в т.ч. і в рамках однієї компанії. Застосування кодів довідників , які не відповідають природним даним ( присутніх у полісі або в Законі ) , вводять в оману і приводять до спотворення даних:
1 . Потрійні коди (причому мають однакове написання в різних реалізаціях , але позначають різні типи) типу ТЗ.
2 . Подвійні коди статусів договорів .
3 . Невідповідність коду зони коду , прописаному в Законі .
4 . Різні коди типів транспортних засобів для внутрішнього страхування і ЗК .
5 Чи не відповідність терміну дії в інструкції не відповідає реальному , природному терміну і призводить до спотворення даних: . 2 - 1 місяць , 3 - 2 місяці ... 13 - 1 рік.
6 Принцип списання бланків датою введення даних - . Отримати об'єктивний звіт по звітному місяцю неможливо.
7 . Використовувані довідники населених пунктів реєстрації ТЗ та марок / моделей МТСБУ не підтримуються.
8 . Відображення даних про кількість і суму заявлених і врегульованих страхових подій має в ЦБД своє трактування , яка відрізняється від звітності Нацкомфінпослуг . В результаті достовірно порахувати відсоток врегулювання неможливо.
Це далеко не повний перелік особливостей методології , які роблять неможливим проведення достовірного аналізу по базі даних . Необхідно детально прописати методологію обліку отриманих / нарахованих премій , врахування премій при переоформленні. Проблема системи бонус- малус , яка є ключовою в даному виді страхування зайшла в глухий кут у силу неможливості бази даних виконувати одну з найважливіших функцій щодо стимулювання страхувальників до безаварійної їзди.
Після 10 років з моменту прийняття Закону про ОСЦПВ залишається проблема достовірності інформації в базі даних , і , як наслідок , цінність її для учасників ринку практично нульова.
У результаті вдосконалення ЦБД технології обліку в СК відкочуються назад - під страхом покарання за невідповідність цифр ( автоматично це зробити вже практично неможливо) звіти знову коригуються вручну , за принципом «чого зволите » ( хочете таку цифру - таку отримаєте ) . Замість інформаційних технологій обробки даних в ОСЦПВ приходить « ручне управління» .
Зараз на страховому ринку розглядається рішенні по скасування коефіцієнту бонус- малус у зв'язку « з відсутністю даних в централізованій базі даних для його розрахунку » і « неможливості його розрахунку по базі даних».
Перелік модулів внутрішньої ІТ -системи МТСБУ
1 . Модуль « Внутрішнє страхування»
Модуль реалізує облік виплат за договорами внутрішнього страхування і виплат страхових компаній у разі банкрутства ( збір інформації про страховий випадок , винуватця , потерпілому ) , облік вхідних документів , необхідних для врегулювання справи , формування вихідних документів (листи винуватцю , потерпілим , накази на виплату ) . Контроль виконання завдань співробітниками МТСБУ.
2 . Модуль « Міжнародне страхування »
Модуль реалізує облік виплат за договорами «Зелена карта» на території України . Функціональні можливості модуля аналогічні попередньому модулю . Також є додаткові можливості розрахунку платежів ( розрахунок гонорару , пені , автоматичне виставлення гарантійних вимог) , облік резервів .
3 . Модуль « Центр зв'язку »
Модуль реалізує облік звернень громадян. Аналітичний блок системи представлений модулем звітів , (звіти по регламентних виплат , звіти з контролю надходжень , позовів , звіти за класифікацією звернень) . Є можливість як табличного , так і графічного відображення даних , а також реалізовані звіти у вигляді зведених таблиць , які дають можливість створення індивідуальних звітів і їх збереження .
4 . Модуль «Правова допомога »
Модуль призначений для обліку справ , які контролюються Юридичним департаментом ( монторінг заборгованостей , моніторинг позовів , збір інформації від представників в режимі он- лайн).
5 . Модуль «Зв'язок з бухгалтерією»
Зв'язок з бухгалтерією для всіх облікових завдань - створення , імпорт банківських виписок , автоматичний розподіл платежів .
6 . Модуль «Представники »
Веб -модуль призначений для введення представниками інформації по ходу врегулювання регресних справ в режимі он- лайн за допомогою веб -технологій та інтеграції введених даних в інформаційну систему юридичного департаменту для подальшої роботи.
7 . Модуль «Зв'язок з блоком представники»
Двосторонній зв'язок бази даних INSCOM - МТСБУ з базою даних веб -модуля «Представники ».
Пропозиції щодо збільшення ефективності страхування ОСЦПВ (Не всі з перелічених пропозицій є безперечними )
Створити ефективну систему ОСЦПВ можна тільки шляхом визначення цілей і шляхів з досягнення . В іншому випадку українське ОСЦПВ так і залишиться на задвірках Зеленої Карти , а громадяни платитимуть більше 50% посередникам і залишатися незахищеними перед великими ризиками та неплатоспроможністю системи ОСАЦВ. Українське ОСЦПВ втратило передові позиції і скотилося на останнє місце в Європі за основними показниками
Ринок ОСЦПВ кожен день " проїдає " 4 млн. грн. ( Зі статистики МТСБУ за 2012 г 2436313316 (премії) - . 974046468 (виплати ) = 1462266848 ( різниця ) і розділити на 365 днів Отримуємо 4 000 000 . ).
У розвиток , у підвищення ефективності даного виду з цієї суми не інвестується практично нічого .
Відсутні інвестиції в європейську методологію , в он- лайн технології , в адаптацію законодавства , в ефективні бізнес -процеси. Якщо зараз не зайнятися питаннями ефективності всієї системи при підвищенні вартість життя і підвищення вимог по компенсації реальних збитків по «залізу » ринок буде банкрутом . При існуючому механізмі реальний захист постраждалих на дорогах реалізувати нереально.
Причина такої ситуації - громіздкий , витратний механізм проведення даного виду страхування.
Конкретні пропозиції по "автоцивілці":
1 Реалізувати ефективну методологію на основі європейської - . Взяти за основу законодавчу базу і методологію Польщі , Чехії.
2 . Визначити ліміти достатні для покриття можливих збитків ліміти відповідальності . Держава повинна піклуватися про захист своїх громадян ( розмір страхових сум для покриття можливих збитків) .
3 . Реалізувати однозначну й працездатну на практиці методику бонус- малус .
4 . Зробити єдиний поліс ОСЦПВ і " Зеленої Карти " , як у всіх європейських країнах , наприклад «Дорожнє страхування» або «Зелена Карта » А так само більш дешеве " Прикордонне страхування".
5 . Співвідношення платежів і виплат д.б. на рівні європейської практики . Даний вид не повинен приносити надприбутків (збитковість повинна бути на рівні 80-90 %).
6 . Строки виплат повинні бути обмежені. Спочатку плати - потім розбирайся .
7 . Контроль полісів і перерв у страхуванні робити по базі даних ( ЦБД ) без залучення ДАІ .
8 Чи не виплачувати готівкою - . Тільки ремонт (виняток шахрайства страхувальників ) .
9 Не приймати гроші за поліси готівкою - . Тільки переклад (виняток шахрайства агентів) .
10 . Впровадити європротокол для збитків будь-якого розміру .
11 . Відпустити тарифи - тарифів не існує , методики визначення теж. Ціни вільні . Деталі розрахунку тарифу СК клієнтові не повідомляє
12 . Забезпечити гарантії виплат шляхом постійного контролю резервів СК.
13 . Забезпечити контроль витрат СК з докладною деталізацією - на що витрачаються зібрані премії .
14 . Забезпечити відповідальність страхових компаній за своєчасність і повноту виплат.
15 . Забезпечити відповідальність автовласників за обман страхових компаній.
16 . Скасувати безкоштовні і « дешеві» ( 50 %) страховки - це суперечить принципу страхування.
17 Зменшити витрати на ведення справи - . Спростити , оптимізувати і автоматизувати всі процеси в ОСЦПВ .
18 . Використовувати електронний поліс. Чи не паперовий , що не пластиковий , а електронний - з необов'язковим роздрукуванням на чистому аркуші паперу.
19 . Страхувати лише за допомогою комп'ютера з он- лайн доступом до бази даних.
20 . Використовувати системи електронних платежів для оплат поліса.
21 . Повернути попередню редакцію про 5 % від страхової суми , а не від виплати .
22 . МТСБУ при насплат СК (протягом 90 днів) повинна протягом місяця само оплатити збиток і мати регрес до СК аж до відкриття справи про банкрутство.
23 . При процедурі банкрутства СК Бюро повинно мати право уточнювати кредиторські вимоги залежно від виплачених збурень. Вся система повинна бути схожа на систему гарантування в банках - недоступність вкладу , призупинення ліцензії або виключення з членів Бюро - відразу МТСБУ починає виплати. Тоді не буде ніяких структур , які викуповують борги СК , тому що зараз вони практично роблять за Бюро цю роботу , ущемляючи постраждалих , а такого побут не повинно.
24 . Внесок до 200 тис. євро.
25 . Удосконалити методику платоспроможності членів Бюро .
26 . Ввести моніторинг відмов страховиків .
27 Публікація на сайті фінансової звітності МТСБУ - . Розміщення резервів , фінансові показники.
28 . Реалізувати (а не скасовувати) КБМ з розрахунком по базі даних , поліси продавати тільки з КБМ , отриманим з бази даних.
29 . Підняти ліміти до 1 000 000 грн.
30 . Удосконалювати методику виплат по життю і здоров'ю.
31 . Дві окремі організації - власне Бюро та Гарантійний фонд . Зараз це все в одному МТСБУ.
32 . Спори вирішувати зверненням до нейтрального примирительному органу або до комісії по страхових спорах .
33 Назва виду страхування для практичного використання - . " Дорожнє страхування " або " Дорожньо-транспортна страхування". У нас - ОСАЦВ.
Для побудови європейської , високотехнологічної , ефективної системи захисту потерпілих на дорогах України необхідно залучати професіоналів. Спільними зусиллями українське ОСЦПВ можна вивести на передові позиції. Учасникам страхового ринку необхідно об'єднати зусилля з реформування і розвитку страхового ринку України в частині вдосконалення механізму проведення ОСЦПВ, а так само внутрішніх бізнес - процесів МТСБУ.
