Введение Эффективное управление деятельностью страховой компании невозможно без предоставления ее менеджменту достоверной учетно-аналитической информации за достаточно длительный период. Помимо всего прочего, необходимость обеспечения полноты и достоверности данных учета бланков строгой отчетности (БСО), договоров и выплат ОСАГО продиктована требованиями Российского союза автостраховщиков (РСА) к функциональности корпоративных информационных систем страховых компаний [1]. Постановка задачи Достоверность информации подтверждается ее валидацией, под которой в рассматриваемом контексте понимается функция автоматизированной системы сбора и обработки учетно-аналитической информации (СОУИ), позволяющая установить идентичность накопленных статистических данных реальным данным управленческого учета [2]. В таких системах указанная функция обеспечивается подсистемами валидации данных (ПВД), от эффективности которых зависит качество учетно-аналитической информации. В моделях ПВД производственного учета используются алгоритмы контроля данных, основанные на уравнении баланса материального потока в производственном процессе, что представляется проблематичным для ПВД страхового учета ввиду практического отсутствия балансовых моделей в его организации. Следует обратить внимание на практическое отсутствие публикаций, посвященных методам и ИТ-решениям в области валидации данных страхового учета, что можно объяснить в целом невысоким уровнем автоматизации страховой деятельности. Среди других причин, обусловливающих сложность моделирования указанных подсистем, следует выделить индивидуальность специфики ведения управленческого учета конкретным страховщиком (страховой компанией) и реализации программного обеспечения для его автоматизации [3]. В связи с вышеизложенным особую актуальность приобретает разработка модели и алгоритмов эффективной ПВД страхового учета. Методология моделирования Страховая учетно-аналитическая информация (страховая информация) является формой консолидированного представления данных операционного страхового управленческого учета и показателей страхования (страховая сумма, страховые премии и выплаты), выраженных в денежных единицах. Следует также отметить, что для ее проверки используются алгоритмы, построенные на принципах форматно-логического контроля документов. В этой связи для разработки модели ПВД страхового учета предлагается использовать основанную на объектно-структурном подходе методологию моделирования проблемно-ориентированных систем СОУИ, адаптированную к особенностям страховой деятельности. Ключевым компонентом данной методологии является объектно-структурная модель СОУИ, представляющая собой ориентированное по информационному потоку линейное дерево, каждый из узлов которого обозначает виртуальный объект - наследник одного из концептуальных классов объектно-структурного подхода: складов, контролеров, агрегатов, их модификаций и комбинаций [4, 5]. С позиций логистического подхода процесс контроля данных страхового учета рассматривается как простое однопередельное производство (рис. 1), ориентированное по потоку страховых документов (договоры страхования, БСО, страховое дело и др.) [6]. Рис. 1. Логистические цепи процесса контроля данных страхового учета Такая имитация позволяет представить ПВД страхового учета как систему электронного документооборота, что создает возможность для применения автоматного подхода на этапе детализации и формализации объектно-структурной модели: модель жизненного цикла (ЖЦ) страхового документа представляется конечным автоматом, который может быть задан с помощью графа или таблицы переходов его статусов (состояний) [7]. На рис. 2 изображена объектно-структурная модель ПВД страхового учета. Рис. 2. Объектно-структурная модель ПВД страхового учета Следует отметить, что свойства базовых концептуальных классов виртуальных объектов методологии объектно-структурного моделирования СОУИ не позволяют в полной мере отразить специфику страхового учета. Для решения данной проблемы используются классы объектов, представляющие собой специализированные модификации производственных концептуальных классов объектно-структурного подхода, имитирующих элементарные звенья логистической цепи процесса валидации данных страхового учета (указаны в скобках): SP1 («Агент», «Клиент»), SP3 («Страховщик») - объекты класса «Страховой портфель» и SK2 - объект класса «Страховой контролер» («Контроль статуса документа») [8]. Дуги D1, D2 обозначают маршрут обработки документа. Класс объектов «Страховой портфель» является аналогом производственного концептуального класса «Склад-модуль», адаптированным к страховой деятельности и имитирующим процессы учета показателей страхования [9]. Валидация входных данных в указанной модели выполняется объектом «Страховой контролер», для описания которого используются концепции теории автоматов, широко применяемых в системах контроля и коммутации информационных потоков [10]. Объект «Страховой контролер» для любого момента времени t = 1, 2, …, T может быть представлен в виде тривиального автомата, поведение которого описывается выражением ZKt = fv [XDt, ψd (W, ZDt-1, E)], где ZK - результат контроля страхового документа (булевый тип, стартовое значение - «Ложь»); fv - логическая функция выходов объекта, обеспечивающая контроль статуса документа и задаваемая в виде алгоритма валидации его данных [11]; XD - строго структурированная упорядоченная последовательность атрибутов обрабатываемого страхового документа (входное слово автомата); ψd - функция переходов ЖЦ обрабатываемого страхового документа; W - тип страхового документа; ZD - статус документа; E - событие (операция), вызывающее его изменение. Далее выполняется отображение теоретико-множественного описания страхового контролера в объектный класс-супертип согласно табл. 1. Таблица 1 Таблица соответствия компонентов теоретико-множественной и объектной моделей страхового контролера Теоретико-множественная модель Объектная модель Состояние автомата, ZK Атрибут: результатКонтроля Функция выходов, fv Операция: контрольСтатусаДокумента Выходной алфавит: Ложь, Истина Тип атрибута: булев Описание функции выходов Спецификация операции: описание алгоритма валидации данных Затем в нотации языка UML строится модель наследования объектов ПВД страхового учета (рис. 3). Рис. 3. Модели наследования объектов ПВД страхового учета Включенный в спецификацию класса-супертипа «Страховой контролер» метод «контрольСтатусаДокумента()» представляет собой обработчик события-триггера и определяется алгоритмом валидации данных страхового документа. На базе созданной модели наследования строится логическая модель ПВД, которая является основой для разработки ее программного обеспечения и реляционной модели данных. Физически страховой контролер реализуется в рамках транзакции контроля статуса страхового документа, обеспечивая ее завершение и продвижение документа по маршруту обработки, если его данные прошли форматно-логический контроль (состояние «Истина»). В противном случае выполняется отмена транзакции и остановка процесса обработки документа (состояние «Ложь»). Представленная методология моделирования использовалась в процессе проектирования ПВД автоматизированной информационной системы (АИС) страхового учета «СМ-Полис» (ОСАГО), разработанной в рамках проекта построения корпоративной информационной системы страховой компании ОАСО «АСтрО-Волга» (г. Тольятти) [12]. Разработка алгоритмов валидации данных страховых документов В общем виде алгоритм валидации данных страхового документа при выполнении страховой операции можно описать так: Шаг 1. Создаем граф или таблицу ЖЦ страхового документа. Шаг 2. Проверяем текущий статус документа на соответствие правилам переходов его ЖЦ. Шаг 3. Если все условия валидации данных документа соблюдены, присваиваем документу новый статус в соответствии с его ЖЦ, завершаем транзакцию и выдаем результат «Истина», иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Следует выделить две основные группы алгоритмов валидации данных страховых документов. I. Алгоритмы валидации данных учета договоров страхования. Следует учесть, что регламент некоторых операций страховой деятельности предусматривает возможность взаимодействия между различными типами страховых документов. Так, бизнес-процессы оборота страховых полисов, относящихся к БСО, являются обеспечивающими по отношению к бизнес-процессам управления договорами страхования, поэтому контроль БСО производится в рамках транзакций контроля договоров страхования. Графы ЖЦ договора страхования и страхового полиса изображены на рис. 4, 5 соответственно (Ed - код события, инициирующего изменение статуса договора). Правила переходов и коды состояний БСО соответствуют техническому заданию РСА. Рис. 4. Граф жизненного цикла договора страхования. Сd - код состояния договора страхования Рис. 5. Граф жизненного цикла БСО «Страховой полис». Сp - код состояния БСО Помимо функции переходов ЖЦ документов параметром алгоритмов валидации является массив данных обрабатываемого документа, структура которого описывается следующим перечнем атрибутов: D = (Did, Cd, Dnd, Dod, Do, Ss, Do, P, I, A, K) - договор страхования, где Did - идентификатор договора; Cd - код текущего статуса документа; Dnd - дата начала срока страхования; Dod - дата окончания срока страхования; Ss - страховая сумма по договору; Do - дата страховой операции; P = (ser, nom, Cp) - страховой полис серии ser, с номером nom и кодом статуса Cp; I = (Iid, Isp) - страховая компания, принимающая договор страхования, где Iid - идентификатор страховщика, Isp - страховой портфель компании; A = (Aid, Abo) - страховой агент, выполняющий операцию c договором страхования, где Aid - идентификатор агента, Abo - остатки БСО агента; K = (Kid, Kbo) - клиент (страхователь) страховой компании, где Kid - идентификатор клиента, Kbo - остатки БСО клиента. Рассмотрим примеры алгоритмов валидации данных договоров страхования. 1. Алгоритм валидации данных при заключении договора страхования (Ed = "ED1"), который состоит из следующих шагов: Шаг 1. Если на момент заключения договора страхования истинно условие Cd = "CD0" и Cp = "002" («Находится у агента»), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 2. Если на дату заключения договора Do истинно условие P ∈ Abo, переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 3. Присваиваем значения Cd = "CD1" («Заключенный договор») и Cp = "003" («Находится у агента»), обеспечиваем выполнение условий P ∉ Abo, P∈Kbo и D∈Isp, завершаем транзакцию и выдаем результат «Истина». 2. Алгоритм валидации данных при переоформлении договора страхования (заключении дополнительного соглашения) с заменой страхового полиса (Ed = "ED2"): Шаг 1. Если истинно условие Cd = "CD1" («3аключенный договор») и Cp = "003" («Находится у клиента»), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 2. Если истинно условие P ∈ Kbo, переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 3. Если истинно условие Dnd < Do < Dod (действующий договор), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 4. Если на дату переоформления договора Do истинно условие Pн ∈ Abo , где Pн = = (serн, nomн, Cpн) - новый страховой полис, переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 5. Присваиваем значения Cp = "009" («Утратил силу»), Cpн = "003" («Находится у клиента») и Cd = "02" («Переоформленный договор»), обеспечиваем выполнение условий Pн ∉ Abo, P ∉ Kbo и Pн ∈ Kbo, завершаем транзакцию и выдаем результат «Истина». 3. Алгоритм валидации данных при досрочном прекращении договора страхования клиентом (Ed = "ED3"): Шаг 1. Если истинно условие Cd = {"CD1", "CD2"} («Заключенный договор» или «Переоформленный договор») и Cp = "003" («Находится у клиента»), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 2. Если истинно условие P ∈ Kbo, переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 3. Если истинно условие Dnd < Do < Dod (договор действующий), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 4. Присваиваем значения Cd = "CD3" («Досрочно прекращенный договор») и Cp = = "009" («Утратил силу»), обеспечиваем выполнение условий P ∉ Kbo и D ∉ Isp, завершаем транзакцию и выдаем результат «Истина». II. Алгоритмы валидации данных учета убытков страховой компании. Несмотря на то, что урегулирование убытков относится к категории бизнес-процессов, обслуживающих договоры страхования, учет убытков и контроль его документов производятся в рамках независимых транзакций. Основным документом, используемым в учете убытков, является страховое дело. Заявленный убыток считается урегулированным, если по нему принято решение о выплате страхового возмещения или обоснованном отказе в нем. Жизненный цикл страхового дела описывается с помощью табл. 2. Таблица 2 Жизненный цикл документа «Страховое дело» Код события, Eu Событие Код статуса, Cu Статус документа EU1 Заявление о страховом случае CU1 Заявленный убыток EU2 Выплата (отказ) страхового возмещения CU2 Урегулированный убыток Пусть U = (Did, Uid, Cu, Sz, De, Dz, Sv, So, Dv) - страховое дело по договору Did, где Uid - идентификатор документа; Cu - текущий статус документа; Sz - заявленная сумма убытка; De - дата страхового случая; Dz - дата заявления о страховом случае; Sv - сумма выплаты страхового возмещения по убытку; So - сумма отказа в выплате страхового возмещения; Dv - дата выплаты страхового возмещения. Рассмотрим примеры алгоритмов валидации данных страхового дела. 1. Алгоритм валидации данных заявленного убытка (Eu = "EU1"), который включает следующие шаги. Шаг 1. Если истинно условие Dnd < De < Dod (заявление об убытке рассматривается только по действующему на дату страхового случая договору), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 2. Если истинно условие Dz ≥ De (убыток заявлен не ранее страхового случая), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 3. Если истинно условие Ss ≥ Sz (заявленная сумма убытка не превышает страховую сумму), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 4. Присваиваем значения Cu = "CU1" («Заявленный убыток»)), обеспечиваем выполнение условия U ∈ Isp, завершаем транзакцию и выдаем результат «Истина»; 2. Алгоритм валидации урегулирования убытка (Eu = "EU2"). Шаг 1. Если истинно условие Cu = "CU1" («Заявленный убыток»), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 2. Если истинно условие Dv > Dz (выплата произведена после заявления убытка), переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 3. Если истинно условие Sz = Sv + So, переходим к следующему шагу, иначе отменяем транзакцию, выдаем сообщение об ошибке и результат «Ложь». Шаг 4. Присваиваем значения Cu = "CU2" («Урегулированный убыток»), завершаем транзакцию и выдаем результат «Истина». Рассмотренные алгоритмы валидации данных страховых документов реализованы на уровне серверной бизнес-логики АИС «СМ-Полис» как полиморфные методы объектов ПВД, что обеспечило простоту ее адаптации к особенностям ведения страхового учета в конкретной страховой компании. Жизненные циклы обрабатываемых страховых документов реализованы в виде таблиц базы данных АИС, поддерживающих функцию ее настройки. Заключение Разработанная на основе предлагаемой модели и алгоритмов ПВД страхового учета в составе АИС «СМ-Полис» прошла успешную проверку в процессе подготовки данных исторических договоров ОСАГО для загрузки в АИС РСА. Так, по сведениям РСА, количество заключенных договоров страхования ОАСО «АСтрО-Волга» и выплат к ним, отвечающих критериям достаточности данных, соответствует установленным нормам. По дополнительным соглашениям установленная норма достоверности исторических данных превышена на 16,1 %. Представленные сведения подтверждают эффективность разработанной ПДВ страхового учета.