Характеристики BI-среды
Для обеспечения своевременного и точного доступа к данным аналитическая информационная среда для страховой отрасли должна обладать такими характеристиками, как:
Доступность данных
Интеграция данных
Простота интерпретации данных
Стабильность данных
Совместное использование информации
Доступность данных: В BI-среде должны быть доступны данные по всем видам деятельности компании. Это очень важно, так как большинство необходимых пользователю приложений будут обращаться к нескольким источникам данных. Обычно требуются сведения об агентах, агентствах, «третьих фирмах», отдельных продуктах, кодах схем и транзакциях, операциях с претензиями, о выплатах вознаграждений агентам и целях продаж.
Интеграция данных. Здесь подразумевается возможность объединять различные выборки данных в единое представление. Например, письменные контракты по страхованию жизни обычно хранятся в отдельной системе, а их администрированием занимается другая. Управление контрактами с постоянной и переменной премиями могут также относиться к разным приложениям. Тем не менее, в BI-среде должна поддерживаться интеграция для всех типов данных.
Простота интерпретации данных. BI-среда должна быть удобной для пользователя, помогая ему легко интерпретировать данные и получать на их основе новую информацию.
При оценке простоты интерпретации данных можно использовать следующие показатели:
возможность навигации по данным (можно ли выяснить, каковы выплаты по агентам, агентствам, продуктам и дате транзакции?);
возможность получить детальные данные (можно ли финансовые транзакции по контракту на аннуитет отследить по конкретному событию или временному интервалу?);
изолированность от физического представления данных (можно ли сформировать запрос без детальных знаний относительно форматов файлов и методов доступа?);
единственное определение отдельных элементов данных (гарантирует ли BI-среда, что оплаченные страховые услуги рассчитываются и интерпретируются одинаково, независимо от использования?).
Стабильность данных. В BI- среде данные не должны изменяться с момента их ввода. Например, анализ претензий подразумевает сравнение претензий по данному коду схемы для некоторого клиентского сегмента в течение определенного промежутка времени. Очевидно, что хранения нескольких транзакций по каждому клиенту будет недостаточно для правильной интерпретации данных по претензиям.
Совместное использование информации. BI-среда должна обеспечить простое распространение информации: данные должны использоваться совместно и передаваться внутри предприятия с помощью современных средств (реляционных баз данных, корпоративного интранета и интернета для внешнего доступа). Например, поставщики услуг группового страхования хотят предоставить своим корпоративным клиентам возможность выполнять анализ претензий в online-режиме. Этим страховщикам (и их партнерам) возможность использования информации вместе со своими клиентами кажется важным конкурентным преимуществом. И BI-среда должна его обеспечить.
Как поступить: купить готовое Хранилище или разработать собственное?
Проблему выбора между покупкой готового Хранилища и разработкой собственного можно сравнить с ситуацией, которая имела место раньше, при внедрении учетных систем. Действительно, в середине 80-х— начале 90-х клиент-серверные приложения приходилось, как правило, разрабатывать под конкретны нужды. Но сейчас, по ряду важных причин (стоимость, поддержка, доступность), большинство компаний предпочитают покупать готовые продукты.
Последние десять был только один путь к внедрению BI-среды на основе Хранилища — создание ее с нуля, своими силами. Поэтому многие Хранилища были разработаны с помощью собственных инструментов. Сейчас происходит такой же переход к готовым решениям, какой в свое время претерпели приложения учета и поддержки транзакций в середине и в конце 90-х.
При покупке готового Хранилища есть ряд преимуществ, которые перечислены в таблице 2.
Таблица 2. Преимущества готового Хранилища
| Преимущество | Комментарий |
| Время разработки | Время разработки существенно сокращается, так как большинство компонентов уже встроены и готовы к использованию |
| Сокращение риска | Большинство DW–проектов терпят неудачу, так как разработчикам не хватает опыта. Риск, связанный с разработкой и внедрением Хранилища, существенно снижается при использовании готового приложения, которое уже опробовано в различных ситуациях |
| Надежность модели данных | Модель данных— очень важный участок среды Хранилища. Модель, где отсутствуют определенные сущности, не даст ответа на основные вопросы. Модель же, проверенная на нескольких реализациях, будет более надежной, и, следовательно, выше вероятность того, что широкий спектр приложений будет на ней хорошо работать. |
| Эффективность вложений | Вложения окупятся быстрее по двум причинам. Во-первых, из-за меньшего объема инвестиций, по сравнению с проектом, который делается с нуля. Во-вторых, сократится период разработки, т.е. пользователь получит все преимущества готового решения намного раньше. |
В качестве примера рассмотрим вымышленную
В качестве примера рассмотрим вымышленную страховую компанию Full Life Services (FLS), предлагающую полный спектр услуг страхования жизни. С помощью примерно 1000 агентов фирма обслуживает 2 млн. клиентов, ее активы составляют 15 млн. долларов. Перед компанией возникла перспектива серьезной конкуренции со стороны нового европейского филиала гораздо более крупной страховой компании E-Life (тоже вымышленной).
После проведения маркетингового исследования было выяснено, что конкурент предлагает лучшие премии по определенному классу продуктов страхования жизни с переменной страховой суммой (variable life insurance), а также, что он разработал некоторую маркетинговую кампанию, направленную на клиентов FLS. Кроме того, E-Life использует более активный канал распространения, обеспечивающий непосредственное взаимодействие с клиентом. Прямой доступ через Internet уже налажен в E-Life и контракты подписываются через службу 1-800.
Руководство компании FLS пришло к выводу, что для сохранения своей доли рынка в ближайшие 12 месяцев необходимо выбрать тактику предложения новых разновидностей продуктов и провести дополнительное обучение торгового персонала. Стратегия разработки новой разновидности продукта (новая схема (plan) для старой услуги) — наиболее эффективный подход, так как на продвижение совершенно нового продукта потребовалось бы довольно много времени.
Для решения этой задачи необходима следующая информация:
Менеджерам по продукции необходимо знать, какие схемы страхования жизни с переменной страховой суммой чаще всего выбирались за последние 18 месяцев (по клиентам и регионам).
Менеджерам по продажам требовалась информация о квалификации 20% лучших агентов, которые продвигали эти продукты последние 18 месяцев (по агентствам и регионам).
Очевидно, что доступ к нужной информации станет для обеих групп основой при решении задачи о видоизменении продукта. Руководство отдела продаж будет четко представлять, какими качествами должен обладать нанимаемый агент или чему нужно обучить своих сотрудников, чтобы они лучше продавали страховую услугу.
На данном этапе, как раз и возникает проблема – необходимость получения такой информации.
В случае нашего примера необходимы следующие данные:
Данные по продукту и коду схемы страхования (plan code): первые поступают из системы, работающей под Windows NT, а вторые ? из файлов с мейнфрейма.
Данные по продажам отдельных агентов: хранятся в системе учета выплаты вознаграждений на мейнфрейме в виде набора файлов.
Данные по клиентам: необходимы для формирования четкого представления о клиентах, которые покупают страховые услуги данного типа. Здесь потребуются демографические показатели (доход, возрастная категория, средний семейный доход и т.п.). Эти сведения поступают частично из Dbase-базы под Windows NT, а частично из мейнфрейма.
Данные о каналах распространения: необходимы для того, чтобы соотнести агентов с регионами распространения. Менеджерам понадобится как показатели продаж для каждого из агентов, так и сводная информация по агентствам и территориям. Все эти материалы хранятся в электронной таблице на персональном компьютере исполнительного секретаря.
Профили агентов: необходимы для того, чтобы установить профиль (квалификацию и образование) агентов, продвигавших продукт в течение последних 18 месяцев. Информация поступает из системы управления человеческими ресурсами, написанной под Unix на Oracle.
Очевидно, что выполнение процесса извлечения, очистки, интеграции и хранения корпоративных данных вручную займет много времени и потребует существенных трудозатрат. В результате будет получена выборка плохо интегрированных, ненадежных данных, на основе которых трудно принимать важнейшие бизнес-решения. К сожалению, на сегодня это реальная ситуация во многих страховых компаниях, столкнувшихся с проблемой доступа к информации.
Обычная информационная среда страховой компании состоит из набора систем, вертикально организованных по бизнес-функциям. Сегодня их часто называют «старыми или традиционными» (legacy) системами, так как они в какой-то мере унаследованы от прошлого.
Тем не менее, эти системы чаще всего плохо интегрируются (так как при их проектировании интеграция и не предполагалась). В приведенной ниже таблице представлен возможный перечень вертикально организованных систем:
Таблица 1. Информационная среда страховой компании
| Вертикальная система | Использование | Платформа |
| Система управления взаимодействием с клиентами | Хранит информацию о клиентах и взаимодействии с ними. Используется менеджером для планирования работы агента | Обычно ПК |
| Системы иллюстрирования | Используются для того, чтобы агент мог дать соответствующие иллюстрации и пояснения клиенту | Обычно ПК |
| Система подписи и оценок | Используется для ввода контрактов, оценки страховых премий и полисов | Обычно работают на мейнфреймах. Доступ агентов через удаленные терминалы |
| Система управления полисами | Используется для управления действующими контрактами | Обычно на мейнфреймах |
| Система управления аннуитетом | Используется для управления контрактами на аннуитет. Может состоять из двух компонентов: для администрирования контрактов и для администрирования портфеля активов | Администрирование контрактов обычно пишется на ПК, а администрирование портфеля — на мейнфрейме |
| Система управления претензиями и выплатами | Используется для управления претензиями по контрактам. | Обычно на мейнфреймах |
| Система учета агентских вознаграждений | Используется для управления выплатой вознаграждений агентам и брокерам. Не связана с клиентской системой и учетом контрактов (полисов и аннуитетов) | Обычно на мейнфреймах |
Наконец, большинство этих систем не хранят исторические данные. Например, в системе управления полисами нет возможности поддерживать историю транзакций, выполненных по конкретному контракту. Для договора хранится только его текущее состояние.
Решение проблемы
Очевидно, что для решения проблемы необходима BI-среда, предоставляющая как текущие, так и исторические данные, необходимые для выполнения анализа и поддержки принятия решений.
В следующих подразделах мы рассмотрим ее характеристики, благодаря которым она будет способна устранить все перечисленные выше сложности.
Решение проблемы— Хранилище данных
Рассмотрим подходы, применявшиеся ранее для решения проблемы доступа к данным.
Прямой доступ к оперативным данным. При таком подходе пользователи получали прямой доступ к оперативным данным в информационной среде. Однако для этого подхода характерен ряд проблем: недостаточное обеспечение безопасности, плохая интегрированность источников данных, а также сложности при доступе к требуемой информации.
Извлечение оперативных данных. В основе этого подхода лежит регламентируемое извлечение данных из оперативных систем. Однако и здесь наблюдается недостаток интегрированности, а также трудности с большими объемами данных и неудобство их использования. Поэтому данный подход оказался мало применимым на практике.
Модули поддержки принятия решения в оперативных системах. Такой подход стоит дорого, а работает хорошо только в тех случаях, когда оперативные системы полностью интегрированы вокруг центральной базы данных. Что случается довольно редко, поскольку большинство страховых компаний пользуются продуктами разных поставщиков или разрабатывают их самостоятельно. Кроме того, стандарты взаимообмена финансовыми и страховыми данными и транзакциями пока находятся на стадии разработки. Большинство систем на данный момент времени не работают с этими стандартами.
Хранилище данных. В Хранилище интегрируются и централизованно хранятся предметно-ориентированные данные из систем обработки транзакций. Здесь содержится информация за предыдущие периоды, которую можно легко извлечь и использовать для проведения анализа и принятия решений.
Из всего сказанного выше (с учетом текущего состояния развития информационных технологий) очевидно, что Хранилище данных — наилучший путь к решению проблемы доступа к информации в страховании, как для конечного пользователя, так и для специалиста по информационной поддержке.
В этой статье рассматривались проблемы,
В этой статье рассматривались проблемы, с которыми сталкиваются пользователи в страховых компаниях при попытке доступа к информации, необходимой для принятия решений. Было показано, что вопрос своевременного получения интегрированных данных со временем встает все острее и приобретает огромную важность.
Проанализировав различные подходы к проблеме доступа к информации, мы выяснили, что Хранилище данных оказывается самым выгодным решением.
[1]1-800 service ? служба специальных бесплатных номеров 1-800.
