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