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

АВТОМАТИЗАЦИЯ УРЕГУЛИРОВАНИЯ УБЫТКОВ. ПРОЦЕССНЫЙ
ПОДХОД
Антон Старовойтов, директор по развитию в странах СНГ VData Software-Entwicklung GmbH,
Мюнхен, Германия
E-mail: a.starovoytov@vdata.de
Урегулировать нет времени учитывать
Где в данном предложении поставит запятую Ваш департамент урегулирования убытков?
Андеррайтеры? IT-департамент? Вы сами?
Существует два основных подхода к автоматизации деятельности компании. Первый –
учетный – заключается в последовательной регистрации всех данных, которые относятся к тому
или иному бизнес-процессу, в базе данных информационной системы. Как правило, такой учет
осуществляется пост-фактум – когда сам бизнес-процесс, к которому эти данные относятся, уже
завершился.
На первый взгляд, такой подход имеет как свои недостатки, так и определенные
преимущества. Так учетная система прекрасно выполняет функции, связанные с аналитикой и
формированием отчетности, конечно, при условии, что все необходимые данные для этого в
ней имеются. К другим преимуществам, например, можно отнести то, что если реализацией
бизнес-процесса и внесением данных по нему в учет занимаются разные люди, то скорость
реализации "полезной части" бизнес-процесса в общем случае возрастает, так как
представители бизнеса не нагружаются дополнительными рутинными учетными задачами.
Однако в этом случае необходимо нанимать отдельных сотрудников, которые бы занимались
исключительно статическим "вбиванием" накопленной информации в базу данных системы.
Но, как правило, компании не идут на такие дополнительные расходы, и вместо этого
дают представителям бизнеса заманчивую возможность поработать с учетной системой в виде
неоплачиваемого бонуса по окончании рабочего дня. Эффект от такого внедрения предсказуем.
От снижения производительности сотрудников, задержек с поступлением информации в учет и
всеобщего недовольства до полного неприятия внедрения системы автоматизации,
саботирования и увольнений. Представьте себе квалифицированного урегулировщика,
вынужденного после работы "подрабатывать" перепечаткой информации из подготовленных им
за день страховых дел, актов и приказов на выплату в учетную систему.
Другие недостатки учетного подхода к автоматизации деятельности компании связаны с
оперативностью внесения данных в учетную систему и качеством этих данных. Проблемы
оперативности могут быть связаны как с физическими ограничениями скорости передачи
данных из территориально удаленных подразделений в учетное подразделение Головного
офиса компании, так и с низкой пропускной способностью отдела учета Головного офиса,
который не в состоянии оперативно обработать данные, поступающие со всей территории
Российской Федерации.
В первом случае данные о заключенном договоре, равно как и его оригинал, могут
приходить в Головной офис с большой задержкой. В ряде компаний такая задержка может
доходить до месяца. Естественно, это негативно сказывается на актуальности данных компании
и связанных с этим бизнес-процессах. Так, финансовое управление не может корректно
рассчитать резерв незаработанной премии, объекты, которые требуют перестраховочной
защиты, включаются в бордеро премий несвоевременно, а управление урегулирования может и
не подозревать о существовании такого договора в принципе, не говоря уже о статусе проплат
по нему.
Вариантом решения данной проблемы при учетном подходе может быть передача
информации в электронном виде: отсканированные договора, фотографии, материалы дел по
урегулированию, приложенные заявления, справки и другие документы. Но в этом случае все
равно нужно выделять человека, который бы все это сканировал и высылал в Головной офис,
при этом необходимо иметь хорошие каналы передачи данных и человека в Головном офисе,
способного разобраться в ворохе асинхронно поступающих со всех филиалов электронных
писем.
Скорее всего компания в этом случае прийдет к другой проблеме – ограниченным
возможностям обработки информации отделом учета Головного офиса. В результате данные,
даже если они и будут поступать в отдел учета вовремя, все равно появятся в учетной системе с
задержкой. К тому же, это не исключает дублирование и отсутствие переиспользования
вводимой информации.
Отдельным вопросом является качество получаемых данных. Как правило, информация,
содержащаяся в выписанном полисе или договоре, является менее информативной чем та,
которая использовалась на этапе его заключения. В качестве примера можно привести
коэффициенты, использовавшиеся при расчете тарифа, которые "пропадают" после выписки
полиса, или уточнения по основной стране пребывания для страхования выезжающих за рубеж,
у которых в полисе фигурирует только "Европа" или "Весь мир". Такого рода неточности,
конечно, не являются критичными, но лишают компанию возможности получать расширенную
аналитику, например, по убыточности по той или иной стране пребывания, акционным
продажам, тарифным планам и т.д.
Более критичным является отсутствие ключевой информации о клиенте или договоре,
когда в учет вносится только информация, которая, грубо говоря, нужна для выплаты комиссии,
т.е. страховой платеж, процент комиссионного вознаграждения и его получатель, а детальная
информация по клиенту, объектам и рискам либо не вносится вообще, либо вносится "для
галочки". Иногда, правда, это бывает оправдано. Так, если ИНН или контактный телефон
клиента нигде в договоре или полисе не фигурирует, то и вносить его в учет неоткуда. А
попытки компаний все-таки заставить эти данные вносить путем установки таких полей ввода в
учетной системе обязательными для заполнения приводит к тому, что данные берутся "с
потолка" и в результате в системе имеем неактуальную информацию.
Неактуальность в свою очередь приводит к проблеме идентификации клиента, например,
наличия в базе нескольких сотен клиентов с ИНН, состоящим из всех единичек, "раздвоение"
клиента, которого один сотрудник ввел в систему как "Наталья", а другой как "Наталия" и т.п.
Такое дублирование информации существенно усложняет возможность просмотра истории
убыточности по конкретному клиенту либо построения отчетов в разрезе количества клиентов
или договоров и убыточности по ним. Подводя итоги, в результате имеем разросшуюся в
размерах базу данных с частично неактуальной информацией, поступающей в нее со
значительными задержками. Такова цена "оперативности" реализации бизнес-процесса
соответствующим сотрудником, который не использует информационную систему в ходе
реализации самого процесса решения своих задач.
Процессный подход к автоматизации деятельности компании предусматривает поддержку
информационной системой самих бизнес-процессов компании, т.е. работа осуществляется не
где-нибудь в разрозненных офисных приложениях, клиентах электронной почты или в
телефонном режиме, а внутри самой информационной системы, используя данные, которые
есть в системе по данному клиенту или договору, и автоматически добавляя к ним новую
информацию в ходе реализации каждого бизнес-процесса.
По сути, все подразделения и сотрудники компании работают в едином интегрированном
информационном пространстве, которое объединяет данные и процессы и позволяет
устанавливать и использовать взаимосвязи между ними. Однако, такой подход накладывает
определенные требования и ограничения к самой системе, технической инфраструктуре,
организации работы сотрудников и к ним самим.
Первое и самое важное требование – функциональность системы должна реализовывать
процессный подход. Если инструмент не позволяет реализовать поставленную задачу, то
бесполезно требовать от сотрудников его эффективно использовать. Для этого в нем
обязательно должны быть предусмотрен электронный документооборот и внутренняя система
обмена информацией, напрямую связанные с хранящимися в системе данными.
Второе требование вытекает из первого: техническая инфраструктура системы должна
предоставлять возможность обмениваться информацией в режиме реального времени, иначе
теряется весь смысл поддержки бизнес-процесса. Таким требованиям отвечают online-системы,
использующие в качестве среды передачи данных сеть Internet. Как правило, интерфейс таких
систем отображается в виде Web-страниц в браузере и не требует установки программного
обеспечения на клиентских компьютерах. Это существенно упрощает поддержку системы и
установку ее обновлений, а также позволяет работать с системой с любого компьютера,
подключенного к Internet.
Что касается организационных требований, то необходимо обязать сотрудников изучить
систему и работать только в ней! Всегда, в любых ситуациях! На первых порах будет активное
противостояние. Будут аргументы вроде: "у меня и так куча работы, вон сколько открытых
страховых дел лежит, и каждый день еще новую пачку завожу, а тут вы со своей системой".
Если на этом этапе пойти на поводу у сотрудников, прийдем к тем же проблемам, что и в
типичной учетной системе. Все преимущества, связанные с online-работой, останутся
невостребованными, а система будет использоваться так же эффективно, как мобильный
телефон для забивания гвоздей, – результат, конечно, будет, но все возможности использования
мощного интеграционного и коммуникационного инструмента будут утрачены.
Типичные задачи автоматизации урегулирования убытков и пути их решения
В данном разделе мы рассмотрим типичные проблемы и задачи, которые возникают на
разных этапах бизнес-процесса урегулирования убытков, и пути их решения. В качестве
примера возможной реализации поддержки соответствующих бизнес-процессов в рамках
программного обеспечения будут приведены решения на базе Web-базированной системы
ProfITsoft BACK-OFFICE, которую мы предлагаем для внедрения в рамках комплексной
автоматизации страховых компаний на территории стран СНГ.
Регистрация уведомления о страховом событии
Проблема на данном этапе заключается в том, что контакт-центр далеко не всегда может
идентифицировать договор, к которому данное страховое событие относится. Причиной может
служить как банальное отсутствие на тот момент договора в учетной системе (решается путем
применения процессного подхода к автоматизации бизнес-процесса продаж), так и
невозможность идентифицировать клиента или договор (в экстремальной ситуации не
вспомнишь, как тебя зовут, не то что номер своего полиса или хотя бы где он лежит). Во втором
случае, если поиск по ФИО, номеру договора или данным по застрахованному объекту,
например, государственному регистрационному номеру транспортного средства, не дал
положительных результатов, данные по уведомлению могут быть занесены вручную, с
дальнейшим их уточнением после того, как клиент пришел в офис писать заявление. Таким
образом, уведомление о страховом событии будет в любом случае зарегистрировано в системе,
а в случае, если клиент в страховую компанию потом так и не обратится, такое уведомление
будет автоматически переведено в архив по истечении определенного срока.
Рисунок 1 – Создание уведомления о страховом событии в системе ProfITsoft BACK-OFFICE
На рисунке 1 представлен внешний вид части страницы регистрации уведомления. В
случае, если номер договора выбирается из базы данных, то данные по объекту и
застрахованным рискам автоматически загружаются из договора. Дата и время происшествия
по умолчанию подставляются равными дате принятия уведомления (автоматически
подставляется дата его создания в системе). На этом же этапе можно выбрать урегулирующее
подразделение, которое будет затем заниматься данным делом.
Хранение и контроль документов, приложенных делу
Каждый вид страхования, риск и подриск предусматривает свой набор типовых
документов, которые должны быть приложены к делу или направлены в различные инстанции,
как, например, запрос в ГИБДД, а также данных, на основании которых производится расчет
суммы страхового возмещения, формируется страховой акт и приказы на выплату. Кроме этого
в деле могут присутствовать дополнительные документы, необходимые для данного
конкретного страхового случая. Как правило, для большинства документов существует
граничный срок их предоставления страховщику. Задача системы автоматизации состоит в
структурированном хранении всех документов в привязке к страховому делу и контроле сроков
их предоставления, с рассылкой соответствующих напоминаний и уведомлений ответственным
сотрудникам в случае возможных задержек.
Рисунок 2 – Документы, приложенные к страховому делу в системе ProfITsoft BACK-OFFICE
Полезной функциональностью системы также является детальная история всех действий,
которые производились со страховым делом. Это поможет выявить мошенничество, связанное
с подменой документов в деле – система в любом случае будет хранить все ранее приложенные
версии документов.
Распределенная работа над страховым делом
Важной частью процесса является возможность работы с одним и тем же делом
нескольких сотрудников, находящихся в различных подразделениях компании. Например, дело
может быть заведено в филиале в одном городе, а затем передано в другой филиал, в котором
был заключен договор. Или вообще в филиалах только формируется пакет документов, а
решение о выплате принимается в Головном офисе, при этом начал рассматривать дело один
сотрудник, потом он заболел, и теперь дело нужно передать другому сотруднику. Здесь должен
быть задействован механизм электронного документооборота системы в рамках единой базы
данных с online-доступом.
Благодаря им дело может мгновенно передаваться от одного сотрудника к другому, из
региона в Головной офис, точнее — само дело все так же хранится в едином Onlineпространстве системы — изменяется только его текущий «владелец». При этом системой
автоматически фиксируется: кто, когда и кому передал дело, сколько оно «пролежало»
непринятым, сколько времени потратил на работу с делом тот или иной сотрудник. Такую
детальную историю хорошо иллюстрирует рисунок 3.
Рисунок 3 – Детальная история работы над делом в системе ProfITsoft BACK-OFFICE
На рисунке видно, что время принятия дела, т.е. время с момента, когда дело стало
доступным сотруднику, и до момента, пока он принял его в работу, в первом случае составило
59 минут. В реальности это время может составить несколько дней или даже недель. В случае,
если это обусловлено "забывчивостью" сотрудника, страница системы "Мои документы",
которая отображается каждый раз при входе сотрудника в систему, будет ему сообщать о
количестве дел в работе, непринятых и отданных другим урегулировщикам (Рисунок 4).
Рисунок 4 – Фрагмент страницы "Мои документы" в системе ProfITsoft BACK-OFFICE
Начальнику отделов урегулирования либо другим уполномоченным лицам доступна
подробная статистика о том, сколько дел в каком статусе находилось у какого исполнителя на
любой момент времени. Таким образом, можно в пару щелчков мышки получить отчет о
загрузке и эффективности работы сотрудников отделов урегулирования по всей компании.
Автоматическая связь процесса урегулирования с модулем учета резервов
Для получения актуальной информации о размере резерва заявленных, но
неурегулированных убытков в режиме реального времени, процесс урегулирования должен
поддерживать автоматическое изменение суммы резерва убытка при добавлении
урегулировщиком данных по каждому потерпевшему, с последующей ручной корректировкой
этой суммы по мере поступления дополнительной информации (актов экспертизы и т.п.) и
автоматическим уменьшением ее при каждой выплате возмещения. При этом, желательно
хранить полную историю изменения суммы резерва убытка по каждому потерпевшему.
Естественно, урегулировщику необходимо знать текущее значение лимита ответственности и
франшизы по договору. На рисунке 5 представлена страница ручной корректировки резерва
убытка по потерпевшему. Система осуществляет контроль минимального значения резерва с
учетом всех страховых актов для данного потерпевшего.
Рисунок 5 – Ручное редактирование резерва убытка для потерпевшего в системе ProfITsoft
BACK-OFFICE
Автоматизация медицинского ассистанса
Не секрет, что урегулирование по добровольному медицинскому страхованию
существенно отличается не только от урегулирования по имущественному страхованию, но и от
урегулирования по другим видам личного страхования. Для качественной автоматизации
данного процесса необходима поддержка полного цикла сопровождения договоров
добровольного медицинского страхования, начиная от их регистрации в системе и внесения
изменений в списки застрахованных лиц, и заканчивая автоматизацией работы собственно
медицинского ассистанса – регистрации обращений, работы с ЛПУ и т.д.
Системой BACK-OFFICE поддерживается настройка различных медицинских услуг,
организация их в пакеты и программы ДМС, а также ввод и контроль лимитов по ним. С целью
облегчения ввода данных, списки застрахованных лиц могут подгружаться в систему из Excelфайлов.
Для каждого застрахованного лица в системе создается своя карточка, просмотр которой
доступен врачам-координаторам при поступлении обращения на телефон «горячей линии». При
этом им отображается полная история обращений данного лица и текущее значение лимита по
каждой из программ. Каждое новое обращение детально протоколируется в системе.
Существует возможность группировать обращения в рамках одного диагноза и закрывать все
выплаты по одному конкретному случаю заболевания одним страховым актом, при этом
автоматически контролируется остаток страховой суммы. Для VIP-клиентов могут быть
настроены особые условия обслуживания.
Рисунок 6 – Регистрация обращения застрахованного лица в системе ProfITsoft BACK-OFFICE
В системе также ведутся справочники ЛПУ и аптек, поддерживается формирование
приказов на выплату за определенный период на каждое ЛПУ или аптеку по всем услугам,
которые были предоставлены застрахованным лицам за этот период. Имеется возможность
согласования с ЛПУ времени обращения клиента, ведется подробный журнал обращений.
На рисунке 6 представлен внешний вид страницы регистрации обращения
застрахованного лица врачом-координатором.
Взаимодействие с внешним ассистансом при страховании выезжающих за рубеж
В странах Западной Европы уже достаточно давно существует понятие "электронного
полиса". По аналогии с электронным билетом на самолет, бумажный документ становится
необязательным, так как все данные хранятся в единой базе, и все, кому эти данные могут
понадобиться, имеют к такой базе доступ. Так, ассистанс может зайти через Internet в систему,
ввести номер полиса застрахованного или найти его по данным загранпаспорта, и посмотреть,
существует ли страховая защита в принципе, и если да, то на каких условиях.
Дальше можно зарегистрировать в системе уведомление о страховом событии, которым
будет заниматься отдел урегулирования по возвращении клиента.
Заключение
Мы рассмотрели основные особенности процессного подхода к автоматизации
урегулирования убытков по сравнению с традиционными учетными системами. Однако, мало
просто купить хорошую систему в красивой коробке. Главное – правильно ее внедрить.
Под внедрением здесь подразумевается первоначальная настройка системы под бизнеспроцессы и страховые продукты именно Вашей компании, обучение сотрудников работе с
системой, их мотивация на работу в системе. Последнее, если не рассматривать только
материальные аспекты в виде бонусов или взысканий, возможно только в случае, если система
будет им действительно помогать в работе. А достичь этого можно только при условии, что
заложенные в системе бизнес-процессы будут всегда актуальны, то есть будут соответствовать
тому, чем занимаются Ваши урегулировщики в рамках повседневных обязанностей. И не
только сегодня, но и завтра. Поэтому качественная и оперативная поддержка системы имеет
решающее значение.
Но здесь могут быть свои сюрпризы и подводные камни. Одни компании отдают Вам
коробку с программным обеспечением и ящик с инструкциями к нему и говорят, что Вы
можете сами все настроить. И Вы, конечно, сможете, если для этого нанять целый штат
программистов. Но насколько это целесообразно? Ведь каждый должен заниматься своим
делом.
Другие говорят, что без проблем Вам все настроят в рамках отдельного договора на
сопровождение, но когда возникает необходимость в изменениях, просят у Вас такие деньги и
называют такие сроки реализации изменений, что об актуальности и оперативности говорить не
приходится – слишком долго, да и дорого все делать.
И последнее. Экономический эффект от внедрения системы автоматизации зависит не
только от выбора самой системы и усилий IT-департамента, но и от позиции руководства
компании, которая в том числе заключается в правильном выборе руководителя проекта
внедрения, с глубоким пониманием бизнес-процессов компании, и наделения его достаточными
полномочиями для координации работы ответственных по направлениям. Только в этом случае
можно ожидать успешного завершения внедрения в компании.