Creacin de un DataWareHouse Financiero, y su Apoyo en la Gestin de la Compaa

MARIA CRISTINA VELIZ BELLO

Resumen
Resumen.- La compaa en la cual est inmerso este caso, es una empresa del rea de Servicios Financieros. Uno de sus negocios ms importante es el de Seguros de Vida y Seguros Generales. A la fecha esta empresa se encuentra desarrollando un cambio tecnolgico a nivel de toda la organizacin, pues ha definido la tecnologa como uno de los pilares para la implementacin de su misin organizacional. Este trabajo se enfocar en el rea de Estudios Financieros, encargada de proveer informacin del comportamiento del negocio en forma mensual, a los niveles gerenciales y a los dueos de la compaa. Este comportamiento queda reflejado en informes con los movimientos de activos y pasivos generados durante el mes, y con el contraste de ellos, con los presupuestos anuales y mensuales definidos. Esta informacin ayuda en la identificacin de nuevas reas de inversin, como tambin en los riesgos asumidos tanto a corto, mediano y largo plazo por la compaa. Para la generacin de estos informes, la compaa debe rescatar toda la informacin generada por los distintos vehculos financieros durante un mes (venta de productos y servicios, gastos, inversiones nuevas, siniestralidades, cesiones de responsabilidad a terceros, reserva de capital para soportar situaciones de riesgo, entre otras) y contrastarla con el presupuesto de la compaa. Las fuentes de informacin corresponden a todos los Sistemas (Sw) Operacionales que soportan el negocio, la mayora de ellos en proceso de renovacin tecnolgica, adems de la generacin de informacin manual a partir de los datos operacionales. Dado este contexto, el objetivo del presente trabajo es crear un DataWareHouse que resuma la informacin de anlisis del negocio y permita generar informes de gestin, utilizando para ello la herramienta EPM de Peoplesoft. Como parte del proyecto, se construirn los extractores de informacin o ETLs, y se poblar el modelo definido para el DataWareHouse. Sobre este ltimo se crearn los cubos de gestin.

Abstract
The company to witch this case is related to, is financial services company. One of its main business are the Life Insurance and the General Insurance. To date, this company is developing a technological change through out all the organization, because it has defined as one of the organizations main mission, the state of the art technological support for the business. The area were this document if focus in, is the Financial Studies area, which is in charge of providing the information relative to the business behavior, on a monthly basis, to the management levels and to the company owners. This behavior is stated in reports of assets and liabilities movements, generated monthly and are compared to the month and annual budgets. This information helps to identify new investments areas, and the assumed short term, middle term and long term risks for the company. To generate the reports, the company has to gather all the information delivered by different financial means during a month (product and services sales, expenses, new investments, responsibilities transferred to third parties, capital reserves to support risk situations, among others) and are compared to the company budget. The information sources are all the operational systems that support the business, most of them are currently in technological renewal process. Other sources are the manual information generated from operational data. In this context, the objective of the current assignment is the creation of a DataWareHouse that summarizes the business analysis information, which will allow the management report generation with the EPM tool from Peoplesoft. As part of this project, it will be built the ETLs (information extractors) and the defined model will be populated for the DataWareHouse. On top of this, the management cubes will be created.

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

Keywords DataWareHouse; DataMart; Modelo de Gestin; Transacciones de Seguros.

pas (22 incluido Santiago), para ofrecer a los clientes la mejor cobertura y rpida atencin. A.1. Estructura Organizacional

I.

INTRODUCCIN

Este documento tiene por objetivo mostrar un caso de construccin de un DataMart Financiero implantado en una empresa de Seguros. Esta empresa decidi dar valor agregado a la data operacional que maneja mensualmente, sin embargo, no midi los problemas derivados de un cambio de plataforma tecnolgica que cruzaba en ese momento a toda la organizacin. Solo consider el uso de las tecnologas adquiridas y la necesidad de dar respuestas sobre el comportamiento del negocio, sin contar con una base slida de datos operacionales, como lo exige el implante de productos de gestin de este tipo. Los resultados obtenidos, se muestran a continuacin.
II. DESCRIPCIN DEL PROBLEMA

La organizacin est dividida en 5 grandes reas de negocio, a travs de las cuales es administrada:
a) Gerencia Comercial

Corresponde al rea donde se define cada nuevo producto que la compaa crea, a partir del marco de rentabilidad definido por la empresa y pensando en la administracin del patrimonio del cliente y de la seguridad del mismo. En esta rea adems se administra a toda la fuerza de venta, la cual corresponde al 65% del personal de la organizacin.
b) Gerencia de Finanzas

Administra la cartera de inversiones de la organizacin, y es el rea encargada de las transacciones comerciales en la Bolsa de Valores.
c) Gerencia de Control Financiero

A. Descripcin de la Organizacin La empresa en la cual est inmerso este caso, es el mayor conglomerado no financiero del pas y uno de los mayores grupos aseguradores del mercado, cuyo campo de accin se relaciona principalmente con dos conceptos orientados al cliente: Seguro y Patrimonio. Est formado por varias compaas, las cuales ofrecen al mercado productos y servicios en las reas de: Seguros de Vida Seguros Generales Rentas Vitalicias Crditos Hipotecarios Crditos de Consumo Corredores de Bolsa Administracin de Fondos Mutuos La misin de esta organizacin es: Ofrecer al cliente las mejores oportunidades de inversin y asegurar el patrimonio de ste, ante situaciones inesperadas. La organizacin cuenta con un gran respaldo financiero y patrimonial para asegurar su permanencia en el tiempo, cuya clasificacin de riesgo AA+ 1 refleja la solvencia y la capacidad para responder a las obligaciones para con sus clientes. La organizacin tiene cobertura a nivel nacional con una amplia red de sucursales y oficinas en las ciudades ms importantes del

Contiene las reas de anlisis de los movimientos operacionales y comerciales, y el estudio de la informacin para luego presentar el comportamiento de la organizacin a los directores de la misma.
d) Gerencia Tcnica

Es la encargada de efectuar los estudios actuariales tanto a los productos existentes como a los nuevos productos.
e) Gerencia de Servicios

Con el objeto de mejorar la calidad de los servicios prestados a los distintos clientes del holding y aprovechar las sinergias que se producen al unir actividades de la misma naturaleza (aprovechamiento de economas de escala y racionalizacin de estructuras organizacionales), se cre la Gerencia de Servicios, agrupando bajo sta a las reas de: Administracin e infraestructura, Informtica, Operaciones y Recursos Humanos. A.2. Descripcin Breve del Negocio de Seguros El negocio ms importante para el holding es el de seguros, pues a travs de l se establece la relacin de la organizacin con muchos de sus clientes.

Superintendencia de Valores y Seguros, clasifica a las Compaas de Seguro segn el riesgo que son capaces de asumir. En particular la clasificacin AA+ considera a una empresa estable, fuerte y slida. Muy fuerte en pago de reclamaciones de los asegurados.

En el negocio de seguros se mantienen 4 lneas importantes de productos:

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

Seguros de Vida, con una amplia gama en seguros de: Ahorro, Accidentes, Muerte, Oncolgicos, Familiares, de Salud, entre otros. Seguros Generales, orientados a bienes materiales como automviles y casas. Rentas Vitalicias, orientados a entregar una Renta o Jubilacin a las personas una vez terminada su vida laboral. Seguros Colectivos, orientados a empresas o instituciones que desean asegurar a su grupo de trabajadores o colaboradores, como parte de los servicios laborales entregados. El flujo de una pliza de seguro se puede entender a travs de la siguiente figura:

los cuales puede pasar una pliza en su vida en la Compaa, los cuales sern tratados dependiendo de la situacin, por ejemplo: Aumento o disminucin del nmero de asegurados. Cambios en capital asegurado. Siniestro de alguno de los asegurados. Rescate del monto en ahorro, luego de cierto tiempo de vida de la pliza. A.3. Herramientas Tecnolgicas existentes a Octubre 2003 A esta fecha, la organizacin cuenta con las siguientes herramientas para apoyar el negocio del holding: a.- Base de datos relacional Ingres en versin OpenIngres 2.0, con su herramienta cliente llamada Vision, que en conjunto permiten el desarrollo de aplicaciones que operan sobre sistema operativo VMS, permitiendo interfaz usuaria del tipo emulacin por terminal. La gran mayora de las aplicaciones estn operando hasta este momento sobre dicha plataforma, todas orientadas a la administracin de los seguros, por tanto, los usuarios que las manejan se encuentran en el rea Operacional de la compaa. Por tiempo de respuesta de la plataforma Ingres, y dado que las aplicaciones han sido creadas a medida que surge o se modifica algn tipo de producto en el rea de Seguros, no se cuenta con una base de datos unificada para la administracin de los seguros. Las cuatro reas detalladas en el punto A.2., operan por separado, por tanto, cada vez que se desea contar con un consolidado de informacin es necesario generar los informes utilizando para ello la ayuda de un analista de la Gerencia de Informtica, o efectuando consultas por separado a las distintas bases de datos y luego unificar la data obtenida a travs de planillas Excel o bases de datos Access. Adems, los sistemas desarrollados a la fecha no registran la informacin operacional como perteneciente a un mes de proceso, por tanto, la produccin del mes se identifica a partir de la fecha de comienzo de vigencia de una pliza. b.- Base de datos relacional Oracle, se est convirtiendo en el administrador de base de datos de la compaa, sin embargo, las aplicaciones que operan sobre ella en estos momentos corresponden todas al back office de la empresa, es decir: Contabilidad. Recursos Humanos. Aplicaciones de apoyo al Cliente Interno.

Cotizacin

Propuesta

Pliza

Administracin de la Pliza

Figura 1 : Lnea de tiempo del flujo de una pliza Cotizacin, ocurre en el momento en que el vendedor entrega una opcin de seguro a un cliente a un valor mensual determinado, basado en el producto deseado por el cliente y las variables exigidas por el negocio (nmero de asegurados, edades de los asegurados, coberturas involucradas en el producto, entre otras). La cotizacin indicar un valor mensual denominado Prima, que el cliente deber cancelar por el seguro, el cual se calcular en base a factores como: a la edad del cliente, la edad de los asegurados que quiera adicionar, las diferentes coberturas que desea incluir (salud, oncolgica, muerte, accidente, entre otras), las condiciones del mercado al momento de contratar el seguro, montos a rescatar a futuro si se quiere contar con un seguro con ahorro, etc. Propuesta, una vez que el cliente ha aceptado la cotizacin indica que desea contratar el producto y por tanto efecta el pago de su primera prima o monto mensual asociado al producto evaluado. Sern a continuacin evaluados los antecedentes del Cliente, para revisar si no tiene alguna prescripcin que impida la toma del seguro. Pliza, una vez que los antecedentes del cliente han sido evaluados y se aprueba la solicitud de ste, pasa a contar con una pliza en la compaa. Administracin de la pliza, corresponde a la administracin de los diferentes estados por

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

c.- Base de Datos Sql Server, es ocupada en el rea de Inversiones, dado que toda la plataforma de inversiones est montada sobre una aplicacin Cliente/Servidor, que opera sobre esta base de datos. Esta compaa es la nica organizacin a la fecha en Chile que tiene como base de datos corporativa, a Ingres. Esto es una desventaja, pues esta base de datos est descontinuada como DBMS en el mercado nacional e internacional, ya slo se vende como adicional de pequeas aplicaciones. A.4. Cambio Tecnolgico implementado en la Organizacin La organizacin hasta el ao 2001 estaba enfocada a la administracin de sus productos, sin considerar a la tecnologa como una herramienta de apoyo. Por ello, mantena una Subgerencia de Informtica con una dotacin alta, en la cual se destacaba un gran nmero de programadores, y la tendencia era desarrollar y mantener sistemas que apoyaran la operacin diaria de la organizacin.2 Los anlisis de informacin se efectuaban a travs de consultas tanto de los usuarios como de los programadores, a las bases de datos relacionales de la compaa, y por tanto, la administracin de estos resultados se efectuaba con herramienta de escritorio como Excel. Desde el ao 2001 en adelante se comenz a gestar un cambio en la orientacin de la organizacin, cambiando la definicin y la misin de sta por una orientacin hacia el cliente (interno o externo). La aplicacin de esta iniciativa se llev como un cambio cultural al interior de la misma, para cambiar el esquema de procesos por el de Servicio al Cliente. Con ello se comenzaron a cambiar los distintos procesos al interior de la organizacin. La organizacin defini como parte de su misin el apoyarse en Tecnologas de la Informacin para mejorar los servicios ofrecidos tanto interna como externamente. En este cambio se analizaron los diferentes procesos organizacionales y las herramientas con las cuales se contaba hasta esa fecha. Se efectuaron anlisis costo/beneficio pensando en contar con herramientas tecnolgicas que pudiesen ser traspasadas, en su operatoria y obtencin de informacin, al usuario. El perfil del grupo de informtica se cambi, creando una Gerencia de Informtica, y orientando la labor de las personas que trabajaban en ella a considerar a los usuarios como sus reas clientes, para las cuales se
A Octubre del 2003 esto sigue ocurriendo, pero los servicios de programacin se han externalizado, contando con dos proveedores a los cuales se les encarga esta actividad.
2

deben identificar las mejores tecnologas existentes en el mercado que apoyen la actividad diaria y que entreguen valor agregado, no slo en la resolucin de los procesos operativos, sino que tambin en la integracin de los datos para as poder efectuar gestin sobre ellos. De esta manera parti en el ao 2001, un proyecto que cruza a toda la organizacin y que plantea desde el punto de vista de base de datos, considerar a Oracle como el motor corporativo, y que las aplicaciones que se inserten en la organizacin sern consideradas tomando en cuenta la siguiente lnea: Compra e implante de paquetes. Desarrollos con un proveedor externo. Arriendo de recursos para desarrollos internos. En esta nueva lnea de negocios, el primer cambio que parti fue identificar una plataforma de seguros que soporte el negocio actual y que permita contar con una base de datos unificada de informacin, de manera de concentrar la informacin de los productos contratados por un cliente, hacer seguimiento a l y ofrecer nuevas alternativas de negocio, dependiendo del segmento de mercado en el cual ste se encuentre; adems permitir de forma rpida la incorporacin de nuevos productos, sin caer en mantenciones de los sistemas. Cambiando la plataforma de seguros, todas las reas asociadas a ella (Comercial, Control Financiero, Operaciones) se ven afectadas, pues mejoran la obtencin de informacin y pueden entregar a su vez mejores y ms oportunos servicios a cada uno de sus clientes directos. Este es a la fecha el proyecto principal de la compaa, cuya fecha de trmino es Diciembre del 2003 y del cual se desprenden otro grupo importante de proyectos actualmente en desarrollo. B. Identificacin y Operacin Actual rea Problema del

La Gerencia de Control Financiero, como su nombre lo indica es la encargada de analizar y controlar los montos de produccin de todos los negocios del holding y contrastarlos con los gastos e inversiones que ste realiza. Estos anlisis son presentados en forma mensual al directorio para su conocimiento, a partir de sta se aprueban presupuestos extras y nuevas inversiones que el holding desee efectuar.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

Las reas que componen esta Gerencia corresponden a: Subgerencia de Gestin. Subgerencia de Contabilidad. Subgerencia de Control de Inversiones. El rea donde se centra el problema corresponde al Departamento de Informacin Financiera, que depende de la Subgerencia de Gestin. El trabajo de esta rea est orientado a 4 tpicos principalmente: Apoyar en la definicin de presupuesto del holding. Controlar los presupuestos asignados. Analizar la produccin mensual del holding y contrastarla con los gastos y presupuestos del perodo. Entregar los anlisis de la informacin operacional de la compaa. Los resultados de estas actividades son entregados en forma mensual al directorio. B.1. Apoyar en la Presupuesto del Holding Definicin del

Excel son administradas por el departamento antes indicado, y la confidencialidad de esta informacin se asegura, dejando en un directorio de red la informacin, al cual slo tienen privilegio de acceso (de tipo lectura o escritura), algunos usuarios. B.2. Controlar los Presupuestos Asignados

Los presupuestos asignados cada ao, se definen como presupuestos de gastos fijos y presupuestos de inversin, cuyas caractersticas principales se detallan a continuacin:
a) Gastos Fijos

La definicin de presupuesto del holding se efecta anualmente entre los meses de Octubre y Noviembre de cada ao. Durante este perodo, las reas usuarias reciben de parte del Departamento de Informacin Financiera, los montos presupuestados el ao anterior, los porcentajes de aumento o disminucin de presupuesto que existir en el ao en curso, y a partir de estos datos, las reas usuarias deben entregar el presupuesto que definirn para el siguiente ao. Como parte de este presupuesto se deben considerar: Gastos fijos (dotacin nueva, remuneraciones, luz, telfono, viticos, etc.) Presupuestos segn el margen del negocio (principalmente lo llevan las reas Comerciales y Operacionales). Proyectos que el rea usuaria desee realizar. Herramientas tecnolgicas que el rea desea incorporar.3 La administracin de las definiciones presupuestarias de la compaa, son llevadas todas en forma manual. El Departamento de Informacin Financiera prepara la informacin en planillas Excel, utilizando un formato que tiene aproximadamente 7 aos y a los cuales slo se le incluyen modificaciones cada ao. La consolidacin de los presupuestos para obtener el presupuesto del holding, tambin es efectuada en forma manual. Las planillas
En los dos ltimos puntos, las reas son apoyadas por la Gerencia de Informtica, en la determinacin de los presupuestos tecnolgicos, dichas herramientas estarn relacionadas con los proyectos informticos a desarrollar.
3

Se administran todos los gastos de las reas del holding (telfono, remuneracin, taxis, viticos, entre otros), los cuales se contrastan con el presupuesto mensual definido. Esta operacin se administra con un sistema denominado Gastos y Presupuestos, que es un desarrollo interno en plataforma Cliente/Servidor (en Visual Basic con Base de Datos Oracle). El objetivo de este sistema es almacenar los presupuestos de gastos, mensualmente conectarse al Sistema Contable y recuperar los gastos efectuados en forma mensual por cada rea de la organizacin (identificada por un nmero de Centro de Costo) y generar informes detallados, en los cuales se contrasta lo presupuestado y los gastos efectuados por cada Centro de Costo. Cada rea debe mantener revisada en forma mensual esta informacin. El Departamento de Informacin Financiera se encargar de levantar las alertas correspondientes, cuando existan diferencias entre lo presupuestado y lo real.
b) Presupuesto de Inversin

Se maneja de manera similar al anterior, identificando si los movimientos como activos fijos o transitorios. Los tems que se controlan bajo este esquema corresponden a: Proyectos Informticos. Proyectos de Infrestructura. Gastos que se identifican como parte de los productos ofrecidos por la compaa (denominados Gastos al Margen). La funcin de Presupuesto de Inversin no posee un sistema computacional que permite su administracin, todo es llevado en planillas Excel.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

B.3. Analizar la Produccin Mensual del Holding y Contrastarla con los Gastos y Presupuestos del Perodo Esta actividad ocupa gran cantidad de tiempo del Departamento en estudio. El objetivo de esta funcin es recopilar la informacin de la produccin del holding en todos sus negocios (especificados en el punto A), y contrastarla con los gastos y presupuestos asociados a los negocios (gastos y presupuestos del perodo). A partir de este contraste se generarn: Los informes mensuales al directorio. Cuadro comparativo de la informacin recopilada, con lo informado a la Superintendencia de Valores y Seguros (SVS), por las distintas reas. El Estado Financiero del Holding, publicado una vez al ao. La informacin del negocio a rescatar es principalmente la asociada al rea de Seguros, esto pues por disposicin de la SVS, las compaas del rubro deben mantener siempre un patrimonio que refleje situaciones de riesgo de los asegurados, a los cuales puedan responder sin poner en riesgo la solvencia de la compaa. Para ello, desde el rea de Seguros se debe analizar informacin como la siguiente: Produccin del perodo, lo cual corresponde a toda la venta del mes (tanto de Seguros de Vida como de Generales), adems de los cargos mensuales que se generan a los clientes por concepto de prima a pagar. Recaudacin del perodo, corresponde a los ingresos de dinero por concepto de pago de prima de los clientes. Siniestros Pagados en el perodo, corresponden a compromisos pagados a clientes durante ese tiempo, por concepto de situaciones de riesgo vividas por el cliente, y para la cual, posee una cobertura en la compaa. Estos pueden ser muerte, accidente con perdida de alguna parte del cuerpo, accidente de un bien como vehculo o casa, gastos mdicos, entre otros. Pago a Reaseguradores, no todo el riesgo es absorbido por la compaa, parte de este es traspasado a terceras compaas la gran mayora de ellas internacionales, por tanto, se debe efectuar pagos a los terceros por la parte del negocio de la cual ellos se hacen responsables. Pago de Comisiones, los agentes de venta reciben un pago por el negocio captado y dependiendo del tipo de negocio y mantencin del cliente en el tiempo, se le

cancela un bono adicional en forma mensual, trimestral o anual. Prstamos y Rescates, cuando el producto de una pliza de vida considera ahorro, es posible efectuar rescates parciales o prestamos sobre el monto ahorrado en la compaa de seguros. Esto genera por tanto, un recalculo de tasas y montos sobre la prima pagada en forma mensual. Identificacin de Montos de Reserva, corresponde a montos sobre las plizas de vida, rentas vitalicias, o de seguros generales, que la compaa est obligada a reservar para situaciones crticas, y que no deben interferir en la solvencia de la compaa. Monto de Pensiones pagadas beneficiarios de Rentas Vitalicias. a

La forma de analizar esta informacin es totalmente manual, las fuentes de informacin son bsicamente 2 grupos: Sistemas Operacionales del negocio de Seguros. Contabilidad, la cual agrupa la informacin de los negocios de inversiones para registrar los ingresos que fueron obtenidos a travs de ellos. Respecto de los sistemas operacionales de la plataforma de seguros, como se especific en el punto A.3., no conviven bajo una sola base de datos unificada, por tanto, cada rea duea de los distintos tipos de informacin se encarga de enviar al Departamento de Informacin Financiera planillas Excel, estas contienen el movimiento del mes para el tipo de informacin requerida por el Directorio. Esta informacin es entregada agrupada por una clasificacin de informacin, ya comn al interior de la organizacin: Ramo, corresponde al grupo de informacin que se informa. Producto, corresponde a los distintos productos ofrecidos por la compaa y que caen bajo el ramo especificado. Plan, corresponde a la agrupacin de coberturas (accidente, oncolgica, ahorro, salud, dental, u otra), que clasifica el plan evaluado.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

El siguiente ejemplo detalla aun ms esta agrupacin de informacin:

Ramo Producto Simple Dotal Vida Opcin Mayor Rentas Vitalicias Vehculo Sobrevivencia FullCar Doble Incluye oncolgico No incluye oncolgico Simple Garantizada Plan

de la venta del mes de anlisis o de meses anteriores. De la misma manera si el registro es un siniestro, endoso, recaudacin, comisin, u otro de los tems antes especificado, uno de sus registros quedar con la fecha en que ocurri la operacin, a partir de ello, se define como parte del mes o de otro perodo de anlisis. Los cierres de mes de las distintas reas involucradas son a la fecha manejados en forma intuitiva, todos conocen que un determinado proceso se ejecuta en un rango de fechas de comienzos de mes. Durante los primeros quince das del mes son ejecutados todos los procesos de cierre operacional. Este proceso dura bastantes das, pues se da una holgura a cada rea operacional a que revise su informacin y la pueda reprocesar. Un calendario que identifica algunos procesos operacionales, se detalla a continuacin:
Proceso Fecha del mes en que se ejecuta Observaciones Clculo de riesgo de polizas nuevas de Vida y Colectivos, para el mes anterior Clculo de riesgo de plizas nuevas de Rentas Vitalicias, del mes anterior Identificacin de la recaudacin del mes anterior Siniestros generados y pagados en el mes anterior Clculo de las comisiones del mes anterior No se permiten ms ingresos de movimientos del mes anterior.

Figura 2 : Clasificacin de Informacin del Negocio

Este departamento consolida la informacin y la contrasta o complementa con lo informado a Contabilidad, a partir de las agrupaciones como el ejemplo especificado anteriormente (Figura 2), y con ello confecciona los informes mensuales del comportamiento del negocio, estos sern revisados finalmente por el Directorio del holding. Todo este trabajo (al momento del desarrollo de este proyecto) es efectuado en forma manual. C. Detalle del Problema Para entregar la informacin anterior, las reas operacionales deben efectuar sus cierres de mes. Como parte del proceso de cierre, deben informar al Departamento de Informacin Financiera, del movimiento del mes. El esquema siguiente identifica a las reas involucradas en la entrega de informacin:
Siniestros Generacin de los cargos del mes Prestamos y Rescates Gastos mdicos Gastos Judiciales Recuperos y Salvatajes

Clculo de Reserva Matemtica 1er da del nuevo mes Clculo de Reserva de Plizas de Rentas Vitalicias Recaudacin Siniestros Comisiones Cierre Contable 5 del mes 5 y 8 del mes 8 y 10 del mes 10 al 13 del mes 13 al 15 del mes

Figura 4 : Calendario de Procesos Operacionales.

Algunos problemas que ocurren a partir de los cierres operacionales: Los registros que participan en cada uno de los cierres operacionales, no quedan marcados, por tanto, cualquier intervencin sobre el valor de la fecha utilizada para considerar al registro en el proceso, puede afectar a que los resultados de un cierre no cuadren, si ste es ejecutado nuevamente en otro instante de tiempo. Por lo general, los usuarios operacionales permiten el ingreso de movimientos asociados al mes anterior durante los primeros das del mes siguiente, algunas veces los valores son ingresados despus de generado el cierre operacional. Si algn otro proceso a tomado datos del cierre afectado antes del ingreso de datos, no ser consistente con el universo de datos tomado en el tiempo cero.

Cobranza

Siniestros

Administracin de Rentas Vitalicias

Beneficios y Siniestros Previsionales

Gerencia Tcnica Departamento de Informacin Financiera

Reservas Reaseguros

Propuestas y Plizas Del mes

Colectivos

Administracin de Seguros Colectivos

Suscripcin

Contabilidad
Inversiones Crditos Hipotecarios Pago de Remuneraciones Gastos del Mes

Comisiones
Pago de Comisiones

Figura 3 : reas Operacionales encargadas de entregar informacin.

Como no existe base centralizada de datos a la fecha (esta unificacin es parte del proyecto Cambio Plataforma, especificado en el punto A.4.), las reas operacionales poseen procesos de Cierre de Mes, sin embargo estos procesos no validan una secuencia de cierre, y adems la nica forma de identificar los movimientos del mes, es que en la base de datos operacional, todos los movimientos son almacenados en relacin a la pliza a la cual estn asociados. Esto implica que si la pliza es parte de la venta del mes, tendr un registro indicando la fecha de inicio de vigencia en la compaa. A partir de este dato se puede conocer si es parte

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

Los datos operacionales son entregados al rea de estudio, entre el 15 y 20 de cada mes, por lo cual el tiempo para procesar y analizar la data antes de la entrega de los informes de gestin es mnimo, y normalmente las descuadraturas entre las distintas informaciones, son detectadas a olfato (por conocimiento de como se mueven las cifras en el tiempo), o simplemente no son detectadas. Este es un problema para el cual se viene buscando solucin hace bastante tiempo, pues dado el movimiento de esta organizacin, no es posible establecer medidas que permitan analizar el movimiento de los datos en un mes, lo cual puede llevar a tomar malas decisiones de inversin. C.1. Primera planteado solucin al problema

III. SOLUCIN PROPUESTA

A. Cmo se gest la solucin al problema de los Informes de Gestin? La solucin propuesta nace a comienzos del ao 2002 y como parte de la renovacin de la plataforma de back-office de la compaa. El proyecto de Cambio de Plataforma cambio de los sistemas operacionales asociados al negocio de los seguros sigue avanzando, pero se comienzan a levantar requerimientos de parte de las reas de: Contabilidad RRHH Inversiones Call Center Todas ellas manifiestan cambiar los sistemas existentes, pensando que cuando la plataforma operativa estuviese terminada se deba contar con sistemas actualizados que se conectaran a la nueva plataforma operacional, de esta manera se propuso efectuar un cambio tecnolgico en todas las aristas de la compaa. Lo que nadie midi en su momento era la cantidad de sistemas en desarrollo durante el mismo tiempo y como stos se cruzaran en sus respectivas implantaciones. En comparacin con la alternativa desarrollada en el ao 2001 (ver C1.), la lgica de extraer datos luego de un cierre operacional y almacenar stos en un repositorio centralizado para efectuar consultas de gestin, se mantiene. Lo que cambia es el anlisis detallado respecto de la informacin a extraer desde los sistemas operacionales (se identifican los conceptos del negocio que se requiere extraer). Los Sistemas Operaciones se piensan sustentados sobre una plataforma unificada, las herramientas tecnolgicas que se utilizarn poseen una base conceptual de anlisis de gestin, esto es se basan en los conceptos de DataWareHouse y DataMart. A.1. Definicin de la plataforma de BackOffice Durante el ao 2002 se evalan distintos proveedores de Software pensando en contar con una plataforma nica estable que provea los distintos mdulos buscados, y que adems fuera reconocida a nivel mundial. Estos ltimo dado que los Software existentes en la compaa deben agregar valor a sta, pues se consideran como activo tecnolgico.

En el ao 2001 se comenz a gestar la idea de contar con un repositorio centralizado de informacin, de tal manera de rescatar informacin proveniente de los sistemas operacionales que aportara a la construccin de informes de gestin. Se identificaron en esa fecha todos los sistemas operacionales que deban aportar informacin, y se propuso crear una base de datos con un modelo relacional simple, capaz de almacenar los datos relevantes para la gestin. Se procedi entonces a modificar los procesos de cierres operacionales, pues mucha de la informacin detectada no quedaba 4 almacenada en el modelo de datos operacional, pues ste slo efecta procesamiento en lnea o batch, los resultados de stos corresponden a reportes operacionales cuyos totales son traspasados a planillas Excel y luego enviados al rea de estudios. Por tanto, se intervinieron los programas de cierre para permitir que la informacin de los reportes se traspasara a archivos ASCII, los que eran tomados por procesos de carga y llevados a la base de datos de informes de gestin. Sobre sta los usuarios del rea de estudios levantaban consultas a travs de la herramienta Access, para obtener lo deseado. Sin embargo, esta solucin no prosper, pues si bien los sistemas operacionales consideran cierres de mes, estos no dejan bloqueados los datos que participan de estos procesos, por tanto, los usuarios operacionales seguan interviniendo la informacin despus de estos cierres, con lo que finalmente no se lograba obtener cuadratura y consistencia de cada periodo analizado.

A la fecha aun existe estos sistemas operacionales en rgimen normal, el cambio de la plataforma operacional est programado para que entre en vigencia a comienzos del ao 2004

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

La plataforma elegida es Peoplesoft, la cual provee entre otros, la siguiente lista de Software: ERPFinanciero Orientado a apoyar la funcionalidad contable (contabilidad, tesorera, cuentas por pagar, proveedores, entre otros) Orientado a apoyar funciones de Recursos Humanos a partir del manejo de competencias de los empleados. Orientado a apoyar las labores de Call Center y manejo de segmentacin de clientes. Provee un DataWareHouse, herramientas de generacin de DataMart y anlisis de informacin multidimensional, reportes y herramientas ETL

Muchas organizaciones comienzan el implante de su DataWareHouse, a partir de la construccin de DataMart, y en forma incremental llegan a la conformacin del DataWareHouse. Lo relevante de este proceso es tener clara que tecnologa se usar5. La metodologa de implantacin de un DataWareHouse o DataMart, considera que para implantar un elemento de este tipo en la organizacin, debe existir un trabajo previo de identificacin de los datos que aportan valor al negocio a revisar. Para ello se debe contar con los mejores elementos funcionales participantes de un proyecto de esta ndole. Adems ellos deben tener claros los lineamientos organizacionales respecto a los resultados esperados, y el grupo de datos a analizar. Pensando que para llevar a cabo con xito un proyecto de DataWareHouse, es vital considerar al inicio de la construccin 3 factores[CWOLFF2002]: Recursos Humanos con conocimiento de la organizacin y claridad en los requerimientos establecidos. Tecnologa capaz de soportar el almacn de datos que se propondr Disciplina en el trabajo diario. Estas disciplinas son usadas para asegurar la calidad, lograr sinergia, una mejora continua en el trabajo del equipo durante todo el proceso de desarrollo. Bajo esto, los siguientes factores son imprescindibles de llevar a cabo en la implantacin de un DW: Establecer prcticas de trabajo efectivo en el equipo de trabajo participante en el proyecto, para poder lograr metas compartidas. Establecer estndares, convenciones de calidad de los datos y cmo sern los resultados esperados. La construccin de un DataWareHouse es un proceso basado en datos provenientes desde diversas fuentes que se integran de acuerdo a la definicin de estrategia del negocio de cada rea, con el objeto de obtener anlisis de informacin de sus procesos de negocio. Por lo general, incorporan 3 pasos [IDC2002]:

RRHH

CRM

EPM

B. Metodologa de Desarrollo B.1. Conceptos asociados Conformacin de un DataMart a la

La tecnologa de los almacenes o DataWareHouse, se encuentra dentro de la lnea de evolucin de las bases de datos hacia una mayor funcionalidad e inteligencia. El DataWareHouse pretende dar un soporte a la organizacin para proporcionarle una buena gestin de sus datos, que ayude en la toma de decisiones estratgicas y tctica.[JOAQ2002] Un DataWareHouse es un repositorio centralizado de datos, donde se almacena la informacin relevante para la gestin de la organizacin, no es una rplica de las bases de datos operacionales. Deber ser modelado pensando en todas las respuestas que la organizacin desea tener, a partir de su operacin diaria. Su alimentacin ser temporal (quincenal, mensual, trimestral), dependiendo del intervalo de tiempo que la organizacin requiera recolectar datos para dar respuesta a sus inquietudes de gestin. Entre las herramientas de gestin adems de los DataWareHouse, existe el concepto de DataMart, el que corresponde a un repositorio reducido de informacin, el cual concentra los datos relevantes y responde a las inquietudes de gestin de una parte de la organizacin o departamento.

De no existir claridad en este proceso, la organizacin terminar con una gran variedad de herramientas tecnolgicas que soportan los diferentes DataMart existentes, no llegando a conformar el DataWareHouse deseado.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

10

Generacin del DataWareHouse, identificar los datos relevantes para la construccin del DataWareHouse. Administracin de DataWareHouse, almacenar datos en el tiempo, con un nivel de frecuencia de carga y con querys optimizados de extraccin de datos desde los sistemas operacionales. Acceso al DataWareHouse, contar con herramientas de query, reportes o anlisis multidimensional, que entreguen al usuario final la informacin relevante para su anlisis. La figura siguiente esquematiza estos pasos:

Analizando las nuevas herramientas existentes en la organizacin y pensando en que sobre ellas se construir el DataWareHouse corporativo, se aprob la idea de comenzar la implementacin del DataMart Financiero como proyecto piloto y definir que el modelo sobre el cual se sustentar, deber ser ajustable a los proyectos que se pretende llevar a futuro. Las primeras actividades definidas en esta implantacin correspondieron a: Identificar el grupo de usuarios participantes, que debiera tener un grado alto de conocimiento en el negocio y en el resultado esperado. Identificar un equipo informtico con conocimiento en la nueva plataforma operacional, que apoyara en la identificacin de los datos relevantes y su extraccin. Identificar un equipo de proveedores con conocimiento en la herramienta escogida, y con implantes en proyectos de este tipo (Business Intelligence). Con esta base establecida, las siguientes actividades comenzaron a desarrollarse: 1. Identificar los actuales reportes entregados en forma mensual y la informacin que stos contienen. Se efectu un levantamiento de todos los reportes existentes categorizndolos por rea del negocio a la cual dan respuesta, y la informacin que contienen. Se identific un total de 140 reportes, todos los cuales eran llevados por los usuarios en planillas Excel entrelazadas, que permitan finalmente generar el reporte consolidado entregado en forma mensual. Estos reportes se ordenaron segn el rea de negocio a la cual respondan: AFP Seguros Colectivos Rentas Vitalicias Seguros no Tradicionales (seguro de Ahorro y APV) Vida Individual Gastos Fijos Presupuestarios

Paquetes de Aplicaciones BD Produccin

ACCESO AL WAREHOUSE

Extraccin De Datos

Data Warehouse

Querys y Reportes

GENERACIN DEL WAREHOUSE

Transformacin De Datos

Anlisis Multidimensional Data Mart Aplicaciones de Anlisis

ADMINISTRACIN DEL WAREHOUSE

Figura 5 : Pasos en la construccin de un DataWareHouse

B.2.

Metodologa usada en este proyecto

La definicin del proyecto como DataWareHouse, se origin dado el nombre de la herramienta usada para este propsito, sin embargo, lo que se est en proceso de implementar es un DataMart Financiero, pues slo se est identificando la data necesaria para generar informacin a analizar por un rea de la compaa, no se est involucrando a toda ella. Las necesidades de las restantes reas estn comenzando a aparecer. El desarrollo de este DataMart naci dado que una vez puesta en produccin la nueva plataforma operacional, el rea en cuestin debe seguir entregando los anlisis del negocio en forma mensual al directorio.

Plataforma Operacional Actual

INFORMES Entrante

Plataforma Operacional Nueva

Con el cambio de plataforma operacional, se debe mantener la consistencia en el flujo de informacin existente a la fecha

Figura 6 : Esquema de informes al Directorio.

Saliente

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

11

2.

Detallar las fuentes actuales de entrega de datos. Dado que la informacin se recibe en forma manual, se identificaron todas las fuentes actuales de datos, y se categorizaron segn los datos detectados a partir de los reportes identificados. Esta categorizacin fue smil a la indicada en el punto anterior. Homologar sistemas operacionales actuales y nuevos. A partir de las fuentes actuales detectadas, se analiz como y donde se encuentra esta funcin en la nueva plataforma operacional. Detectando de esta manera la parte del modelo de datos donde sta se encuentra. Anlisis de la herramienta sobre la cual se efectuar la implementacin, a partir de un flujo de informacin. Se efectuaron presentaciones al rea usuaria de la forma de operar con la nueva herramienta y como esta era capaz de satisfacer las necesidades, de esta manera se entreg todo el conocimiento para no generar falsas expectativas respecto de los resultados que se obtendrn del proyecto. En esta actividad los usuarios pudieron observar el cambio que se experimentar en la forma de obtener la data de anlisis, y como la herramienta apoyar el trabajo que a la fecha es realizado en forma manual. Definicin de las transacciones a desarrollar. El equipo en conjunto defini las transacciones que se desea obtener desde los sistemas operacionales. Con esta definicin se gener el modelo de datos sobre el cual se procedera a la creacin del DataMart y reportes solicitados. Creacin de formatos de extraccin de datos o ETL. Se definieron los formatos de carga de informacin a partir de una herramienta de ETL (Extraction Transformation Loader) denominada Informtica, a partir de las fuentes de informacin detectadas. Luego de esto, se comenzaron a construir los programas de extraccin de los mismos. Proceso de transformacin de los datos, construccin de los reportes y cubo de anlisis. Sobre el modelo de datos definido, se comenz la construccin de un proceso capaz de sumarizar el detalle de los datos capturados y que contiene la lgica del anlisis al cual se desea llegar. Sobre el nuevo modelo generado, se construyeron

los reportes y se prob la generacin del cubo de anlisis6. El cuadro siguiente resume los tiempos involucrados en estas actividades.
A ctividades Identificar equipoparticipante Identificar actualesreportes D etallar fuentesactualesdeentregade inform acin H ologar sistem operacionalesactuales om as y nuevos A nlisisdelaherram sobrelacual se ienta efectuarlaim entacin plem D efinicindelastransacciones adesarrollar C reacindeform deextraccindedatos atos oE TL's P rocesodetrasform acinde datos,construccindereportesy cubode anlisis P ruebasdeusuario V alidacindel m odelo M arzo A bril M ayo Junio Julio A gosto S eptiem bre s1 s2 s3 s4 s1 s2 s3 s4 s1 s2 s3 s4 s1 s2 s3 s4 s1 s2 s3 s4 s1 s2 s3 s4 s1 s2 s3 s4

3.

4.

Figura 7 : Plan de trabajo para el proyecto.

Se mantuvo en todo momento dos bases de datos operativas, la primera donde los desarrolladores construan procesos, segn la etapa del proyecto en la cual se encontraban, y la segunda orientada slo a pruebas de usuario, con privilegios restringidos en su acceso. De esta manera se mantenan estabilizadas las pruebas que los usuarios estuviesen desarrollando. C. Descripcin de la Herramienta Utilizada La herramienta utilizada para este proyecto corresponde a la herramienta Enterprise DataWareHouse de la empresa Peoplesoft. Este Software es un paquete integrado que contiene herramientas de: Almacenamiento de datos ETL (extraccin, trasformacin y carga) de los datos desde las fuentes orgenes al modelo de anlisis del negocio, definido. Herramientas de anlisis multidimensional y construccin de reportes. Sus principales caractersticas son: Integracin de todas las herramientas participantes de un DataMart (ETL, almacenamiento, construccin de reportes). Opera en ambiente Browser, lo cual ayuda en la centralizacin de instalacin de nuevas versiones, y por tanto, no se requiere actualizar los PCs de los usuarios con acceso a esta plataforma. Est definida en una administracin por capas, lo que independiza al modelo y almacn de datos, de las funciones de trabajo sobre los datos. Sin embargo, esto
6 La herramienta de Peoplesoft que e est usando para la construccin de este DataMart tiene la facilidad de crear un cubo de anlisis multidimensional que puede ser ledo por herramientas de este tipo. Este detalle se especifica en el punto siguiente.

5.

6.

7.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

12

requiere contar con un administrador de plataforma ms experimentado y capacitado en esta plataforma. Dado que en la organizacin se estn implantando otras aplicaciones del mismo proveedor que deben proporcionar datos a este almacn, cuenta con programas o ETLs previamente Por tanto la extraccin a estos sistemas se basa simplemente en la activacin y scheduler de estos procesos. No provee facilidad para que los usuarios accedan a esta plataforma a no ser que sea va la aplicacin. Esto permite mayor seguridad en el control de acceso a los datos rescatados, puesto que se debe mantener consistencia en la data almacenada. Es una arquitectura abierta y escalable, por tanto la incorporacin de otros DataMart o la conexin en la implementacin del DataWareHouse Corporativo, no tendr mayores inconvenientes.
c)

informacin para los reportes de gestin dependiendo de los programas de operacin definidos para el o los DataMarts construidos.
Herramientas para construccin de MetaData

Existir cdigo denominado Peopletools a partir de los cuales se construirn los MetaData requeridos para cada anlisis.
d) DataMarts

Se formarn a partir de los MetaData generados. Una vez identificados los DataMart lgicos, slo debern ser graficados en la herramienta, sta los almacenar en base a variables de actualizacin, por ejemplo rango de fechas, lo que permitir mantenerlos actualizados, y por tanto, crear los cubos de anlisis segn la periodicidad deseada por el usuario. La garanta con esta herramienta, es que los cubos de anlisis se forman a partir de un clic de usuario, se genera el archivo multidimensional que finalmente ser tomado por un usuario a partir de una herramienta de grfica de anlisis multidimensional. La herramienta seleccionada para operar en esta ltima actividad se denomina Cognos. La aplicacin se encuentra instalada sobre mquinas Intel corriendo sobre Windows 2000 y base de datos Oracle. El esquema diseado para esta plataforma corresponde al siguiente:

BD Test

Maquina Intel Windows 2000 4 Procesadores Contiene BD sobre Oracle 8i 1

Mquina Intel Windows 2000 4 Procesadores Contiene BD sobre Oracle 8i Web Server (Web Logic) Aplication Server Informtica (ETL) 3

BD Desarrollo

BD Produccin

Maquina Intel Windows 2000 2 Procesadores

Figura 8 : Esquema del DataWareHouse Peoplesoft.

de

Opera el Web server (web Logic) Aplicaion Server Informtica (ETL) Provistos por la Herramienta 2

Arquitectura Propuesta para este Proyecto

Sus principales componentes son:

a) ETL
Figura EPM. 9 : Arquitectura definida para Peoplesoft

El ETL incorporado en la plataforma se denomina Informtica, esta herramienta posee los conectores necesarios para conectarse a plataformas de bases de datos diferentes, como tambin a diferentes esquemas de Datos. Puede operar sobre la misma mquina que la aplicacin de WareHouse o en una mquina adicional.
b) ODS (Operational Data Store)

A la fecha slo se cuenta con la mquina 3, dado el estado en que se encuentra este proyecto. Las dos restantes mquinas estn presupuestadas para compra en el ao 2004. Para esta arquitectura no se defini mquina de contingencia, pues si bien ser una aplicacin crtica, no operar en rgimen 7x24. D. Modelo y Flujo Definido A partir de las definiciones identificadas anteriormente y las caractersticas de la herramienta de trabajo, se muestra en detalle las actividades desarrolladas.

Los datos extrados por el ETL, son almacenados en una base de datos relacional, modelada a partir de la lgica de los datos que formarn el Warehouse. Los programas de ETLs se construyen para que generen los tipos de datos definidos en este ltimo modelo. El ODS ser capaz de almacenar gran cantidad de datos, y procesar la

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

13

El siguiente es el esquema general de la implementacin:

Sistema nuevo Operacional Productos de Vida Generales - Colectivos

DataWareHouse
Sistema Rentas Vitalicias ODS Poliza Transacciones Reserva Productos Planes Ramos <Saldos_Contables> Clientes Coberturas Transacciones_SUM Reserva_SUM

DataMart
Aos SDOS Cts Prods Rmos

ERP-Contable Adems de ser el receptor de la informacin de los anteriores sistemas, pero a nivel de montos contables, recibe todo el detalle de los sistemas de inversiones y los negocios de Corredora de Bolsa y Crditos Hipotecarios. Esto permite contar con la informacin de Inversiones en su totalidad. Archivos Excel Existe un grupo de informacin relevante que debe ser considerado en el anlisis, sin embargo, no se encuentra almacenado en ningn sistema. Son datos que se generan a partir de frmulas de clculo de la informacin almacenada en los sistemas operacionales y modelos de presupuesto que mantiene la compaa.
b) ODS

Sistema Siniestros AFP

Sistema ERP - Contable

Real
Archivos Excel

2003-01 2003-02 2003-03

Proceso de Carga Proceso de Emisin

Figura 10 : Esquema de Operacin de Software EPM de Peoplesoft.

D.1. Descripcin de los elementos que conforman el modelo

a) Sistemas Externos

Correspondern a los sistemas desde los cuales se extraer la informacin a analizar. Los ETLs de extraccin de datos, se han construido para acceder a ellos y rescatar datos, como los que se identifican a continuacin: Nuevo Sistema Operacional Corresponde a la plataforma que administra los negocios de Seguros de Vida y Generales. Almacena la informacin desde que ingresa una nueva propuesta a la compaa, la recepcin de los pagos mensuales del cliente, los pagos de comisiones a la fuerza de venta, los siniestros de una pliza, el clculo a los reaseguradores, entre otros. Por tanto, gran parte de la informacin de anlisis de ste, se encontrar almacenada en l. Rentas Vitalicias Opera en forma similar a los sistemas de Seguros de Vida y Generales, pero administrando la informacin de Rentas Vitalicias. Sin embargo, se conecta con el anterior en lo referente a Recaudacin y Pago de Comisiones. Siniestros AFP En la compaa se administran algunas plizas de AFP, que corresponden a los Seguros de Invalidez y Sobrevivencia, estos servicios son contratados por una AFP para grupos de afiliados a ella. En estos negocios la compaa de seguros mantiene cubierto al afiliado a la AFP de riesgos de invalidez parcial, total y pensiones de viudez, para el caso de muertes. Este sistema contiene el detalle de esta informacin. Esta informacin no influye en el margen del negocio, pero se deben considerar los montos de prdida en caso de siniestralidad total.

Es una capa intermedia en el DataWareHouse, la cual contiene el resultado de las extracciones de datos desde los sistemas orgenes, trasformada al tipo de datos del modelo definido, pero aun no ha sido cargada al modelo relacional central de este esquema. En este caso los ODS fueron definidos como archivos ASCII de llegada, que contiene la lgica de la carga de datos al modelo central, con la codificacin de este ltimo.
c) Modelo Relacional

Corresponde al modelo sobre el cual sern construidos los reportes y el modelo de anlisis para el cubo. Dado que este proyecto tiene lineamientos de construccin de un DataMart y no un DataWareHouse, al momento de definir este modelo relacional se pens en un modelo consistente para la lgica de anlisis que se desea responder. Sin embargo, puede ser ampliado creando tablas adicionales y relacionndolas, hasta llegar a convertirse en un modelo de DataWareHouse Corporativo. Est basado entonces en un desarrollo incremental del DataWareHouse que desarrolla y genera un subconjunto del DataWareHouse total. La implementacin incremental (segn algunos autores) es una aproximacin pragmtica para construir WareHouse a nivel empresarial, en forma evolutiva.
d) Diseo de Reportes

A partir del levantamiento de reportes que actualmente se construyen y utilizando las bondades de la herramienta utilizada, se defini un esquema de rbol de reportes, donde se categorizaron cada uno de ellos, llegando a construir solo 37 que finalmente dan respuesta a las inquietudes del usuario.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

14

e)

DataMart y Cubo de Anlisis

Puesto que el desarrollo consider la construccin de un slo cubo de anlisis, ste se dise sobre las preguntas que el usuario defini como crticas de responder. Basndose en ellas se construyeron las dimensiones y se model en la herramienta de trabajo. Esta ltima se encarg de construir el archivo de salida, que finalmente podr ser revisado a partir de una herramienta multidimensional. D.2. Modelos de Datos Definido

Vendedores, contendr a todos los vendedores que se relacionan con la pliza, clasificndolos en contratados por la compaa, agentes libres y corredores. Estos correspondern al canal por el cual se efectu la venta. Tablas paramtricas que detallan el negocio (Ramo, Producto, Plan, cobertura). Transacciones, contendr la definicin de todas las transacciones que se desea medir en el modelo. De esta manera cualquier transaccin no incorporada al momento de la partida con el sistema, podr ser incluida a futuro definindola en esta entidad y creando los procesos de ETLs necesarios para extraer la informacin. Transacciones por Pliza, contendr el detalle de movimientos por pliza asociados a cada transaccin. En algunas transacciones puede existir un conjunto reducido de informacin (slo se afectan algunas plizas), en otros casos, la transaccin podr estar asociada a todo el conjunto de plizas vigentes. Saldos contables y Plan, contendr la informacin extrada desde el Sistema Contable a partir de los estados de resultados mensuales. Esta informacin debe cuadrar con lo extrado desde los sistemas operacionales. Se encontrar adems el detalle de lo planificado (o presupuestado) para determinados negocios en el ao, lo cual servir en los anlisis para contrastar lo real v/s lo planificado. Reservas, si bien la informacin de las reservas es considerada una transaccin ms, existe informacin adicional a medir sobre ella, por tanto, fue considerada como una entidad adicional. Se entiende que la informacin necesaria para cargar en el modelo ser la asociada a las transacciones. En el Anexo 1, se muestra un extracto de las definidas efectuadas en el proyecto. Existen un total de 90 transacciones definidas a la fecha, para cada una de ellas se deber definir la lgica de carga. Esto pues algunas de las transacciones llevan incorporada lgica al momento de la extraccin para llegar a la definicin dada en este modelo. D.3. Periodicidad de carga de las transacciones al modelo Los procedimientos de carga consistirn en procesos programados usando para ello la herramienta lNFORMATICA de Power Mart, esta herramienta corresponde a un ETL que permite definir los procesos de extraccin de datos y la calendarizacin de la ejecucin de los mismos.

El modelo definido para este DataMart Financiero, se centr en la entidad que cruza todos los sistemas operacionales y sobre la cual se desea llegar a identificar su comportamiento durante un perodo de tiempo, la Pliza. Sobre esta entidad giran todos los conceptos del negocio, pues ella representa una relacin entre la compaa y un cliente, o un grupo de asegurados.

Asegurado Permanencia en el tiempo

Cliente

Recaudacin

Coberturas

Pliza

Comisiones

Capital Asegurado

Siniestros

Reaseguro

Reserva

Figura 11 : Transacciones a medir sobre una pliza.

A partir del anterior esquema, se tuvo como resultado el siguiente modelo de EntidadRelacin.
TR AN S A C C IO N E S

C LIE N T ES P O LIZ A

TR AN S AC C IO N ES _ x_P O L IZ A

TR AN S AC C IO N ES _S U M

R ES E R V A

R E S ER V A _ SU M

V EN D ED O R E S _ BR K

RAM O P R O D U C TO P L AN C O B ER TU R AS

S U C U R S AL SA LD O S C O N T AB LE S y P LA N IN VE R S IO N E S G AS TO S F IJO S A JU S T E S C O N T A B LE S

O F IC IN A

A G E N C IA S
A RB O L

S A LD O S P LA N

O P E R A C IO N E S P LA N

R E S ER V A S P L AN

SA LD O S C O N T AB LE S

O P E R A C IO N E S R E AL

R ES E R V AS R EA L

Figura 12 : Modelo Entidad-Relacin asociado al DataMart Financiero

La lgica del modelo se interpreta como sigue: Pliza, se tendrn todas las plizas vigentes en la compaa para el perodo analizado. Cada iteracin nueva de carga de datos, modificar algn cambio en los valores de las plizas ya existentes e insertar las plizas nuevas. Clientes, contendr los clientes (contratantes, asegurados o beneficiarios) asociados a una pliza.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

15

Existen dos tipos de procesos: Proceso que se ejecutarn una vez por ao. Proceso que se ejecutarn al menos una vez por mes.
a) Procesos anuales

Los procesos anuales corresponden a la carga de las tablas que soportan el presupuesto de la compaa. Esta informacin ser cargada en forma anual desde planillas Excel (con formato definido) que llenan las reas usuarias de la compaa. Estas sern tomadas por un proceso automtico (ETL) encargado de subirlo al modelo de anlisis.
b) Procesos mensuales

En sntesis los rboles empleados en este esquema mostrarn el detalle mximo al cual se puede expandir un informe, y sus elementos dictarn la jerarqua y agrupacin que el listado nVision presente. Los valores relatados en el informe, slo emitirn los valores relatados en cada hoja; por ejemplo si se trata de un rbol de cuentas contables, entonces es de esperar que en las hojas se encuentren solo valores de cuentas contables. Para aquellos reportes que mezclan conceptos, esto es por que en un prrafo se listan saldos de cuentas contables y en otros saldos de productosramos, entonces ser necesario a lo menos dos rboles que detallen cada prrafo.
b) rboles de Cubos

Los proceso mensuales corresponden a la informacin necesaria para generar mensualmente los informes y reportes al directorio (Transacciones del modelo). Esta informacin ser obtenida usando la herramienta ETL INFORMATICA y haciendo uso de las definiciones estndares de MetaDatos que provee la herramienta en uso, tomando la informacin desde los datos operacionales. D.4. Uso de rboles en el acceso a los datos, definicin de reportes y generacin de cubos Una de las garantas de la herramienta de anlisis usada, es que provee estructuras de rboles a travs de los cuales es posible definir algunas estructuras jerrquicas o generacin de informacin a partir de niveles de dependencia. Por ello se han definido como parte de este modelo dos estructuras de rboles sobre las cuales se ha implementado la lgica de los reportes y definiciones de cubo.
a) rboles de Informes

Cada cubo se compone de una tabla de hechos ms un set de tablas de dimensin. Las tablas de dimensin definen los ejes coordenados por los cuales ser factible analizar los datos almacenados en la tabla de hechos. La tabla de hechos es nica por cada DataMart que se defina, mientras que las dimensiones en cada DataMart pueden superar las cuatro(4). Cada una de estas definiciones de ejes coordenados, estn asociadas a la tabla de hechos a travs de su campo llave. En los modelos DataMarts convencionales, cada dimensin es una tabla del tipo maestro. No obstante, en la herramienta utilizada cada dimensin puede ser tratada como un rbol. Esto en ocasiones, cuando se tiene una jerarqua de dependencia de tablas relacionadas, es una gran ventaja, pues la relacin queda graficada y puede ser directamente empleada en la interpretacin grfica de la data, para este proyecto, se usar PowerPlay de Cognos, como herramienta de visualizacin. En el modelo entidad-relacin propuesto, se tiene relacin de dependencia directas entre Sucursal, Oficina y Agencias. Esta jerarqua puede ser tratada como un rbol, evitndose con ello el mantenimiento directo de las tablas a travs de paneles, y permitiendo adems que el usuario pueda consultar a travs de simples clic, por ejemplo la recaudacin por agencia, oficina o sucursal, siendo esta ltima el nivel ms atmico en el detalle de localidades fsicas. D.5. Cubo de Anlisis

Los informes sern emitidos a travs de nVision generador de informes incorporado en la herramienta de anlisis. Permite generar listados y reportes con niveles de desagregacin variables en dependencia directa con los diagramas jerrquicos de rboles planteados para cada reporte. La gran ventaja de nVision es que los listados son extractos de filas de la base de datos cuyo resultado queda directamente propuesto al usuario en Excel. Los resultados expuestos en esta instancia, ya son operables y factibles de ser sometidos a operaciones aritmticas y eliminaciones de resultados, con funcionalidad Excel y no nVision. Los rboles en principio son usados para la sola especificacin de criterios para el barrido de conceptos, pero tambin pueden portar en sus ramas la inteligencia para conseguir la agrupacin y presentacin deseada en subtotales y totales en el mismo informe.

El objetivo de construccin de un cubo de anlisis es poder explorar en ms detalle la informacin provista en los informes o reportes generados a travs de las estructuras de rboles. El cubo de anlisis deber contemplar de manera bsica, como dimensiones, las mismas coordenadas empleadas en la elaboracin de los informes, esto es: Ramo, Producto, Plan, Ao, Mes, Empresa o Unidad de Negocio,

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

16

Tipo de Saldo (Real-Presupuesto), Tipo de Transacciones (ING, INGxPRIMA, GTOS, etc.), para contemplar y explorar los siguientes datos: Saldo (Real, Presupuesto), Reserva (Base-Calculada-Financiera-Producto de Inversin). El cubo presentar la informacin agregada y desagregada a voluntad del usuario por las dimensiones especificadas en tiempo de diseo, mientras los datos requeridos estn debidamente cargados para los perodos que se desea explorar.
a) Dimensiones y Datos mnimos para el Cubo de Anlisis

datos, permitir generar anlisis detallados de la compaa y su competencia. Incorporar variables de RRHH, para identificar los mrgenes del negocio, v/s el detalle de las comisiones pagadas a los agentes, y los presupuestos de dotacin para las reas comerciales de la compaa. Incorporar detalle de las ventas por sucursales, esto permitir identificar los productos vendidos segn parte del territorio nacional. Esto ayudar a anlisis de segmentacin por clientes. Lo anterior podr ser modelado llegando a ampliar el modelo actual, pero sin destruir el trabajo efectuado a la fecha. E. Validacin de la Solucin Propuesta La solucin mostrada en el presente documento no ha sido puesta en produccin, pues el 80% de los ETLs a construir debern provenir desde: El nuevo sistema operacional El nuevo sistema contable Consoderando las planificaciones iniciales, que indicaban que ambos sistemas estaran en produccin a comienzos del segundo semestre, este proyecto de implante de DataMart financiero debiese haber comenzado su operacin en rgimen normal a finales de Septiembre, esto no ocurri. Los atrasos han provenido principalmente de funciones no terminadas en los sistemas indicados anteriormente. Al no contar con la informacin y modelo de datos estable en el origen, no ha sido posible construir todos los ETLs necesarios para la operacin de este DataMart. Segn lo planificado, este proyecto deber estar en operacin dos meses despus de la puesta en explotacin del nuevo Sistema Operacional. Pese a que son arriesgadas estas fechas pues no estarn del todo estable las fuentes de datos que proveern informacin, no es posible colocarlo en otro momento, una vez cambiado el Sistema Operacional se deber seguir respondiendo a las inquietudes de los Directores, indicando que pueden existir algunas variaciones por los problemas de estabilidad de la plataforma. Sin embargo, es un riesgo que se debe correr, pues no se tendr otra fuente de informacin a la cual recurrir. Pese a todo este escenario, ha sido posible efectuar pruebas de operacin del modelo, revisando algunas transacciones que se activan desde los sistemas: Rentas Vitalicias Siniestros AFP Planillas Excel

Las dimensiones de un cubo son las coordenadas o unidades mediante las cuales los datos pueden ser explorados en el contexto fijado. Las dimensiones que contempla el anlisis son: Dimensin Ramo Producto Plan Cdigo Transaccin Tipo de Saldo Ao Mes Descripcin Cdigo de Ramo Cdigo de Producto Cdigo de Plan de Cdigo de Transaccin Real/Plan Ao de proceso Mes de Proceso Tipo Tabla Tabla Tabla rbol rbol Ao Mes

Figura 13 : Dimensiones identificadas para el cubo a construir.

Los datos o columnas de monto analizados con estas dimensiones son: Datos Monto Descripcin Importe almacenado por cada transaccin de pliza Reserva Importe de reserva almacenado por cada transaccin de reservas (trans_de_reserva)
Figura 14 : Datos contemplados en el cubo a construir.

D.6.

Incorporacin de Futuros DataMart

Pensando un modelo evolutivo de DataMart y de acuerdo al modelo de datos definido, ser posible (dada la simpleza de ste) incorporar nuevos grupos de datos para crear nuevos anlisis. A la fecha, se tiene identificados la necesidad de crear cubos que permitan: Revisar informacin de la Superintendencia de Valores y Seguros (SVS) a partir de un informe trimestral generado con la informacin de rentabilidad de todo el mercado de seguros. El incorporar esta fuente de

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

17

Tomando algunos supuestos bases, se ha logrado la construccin de los respectivos ETLs y se han efectuado las cargas de informacin requeridas para 3 meses de trabajo, operando sin problemas la extraccin y carga del modelo, como tambin la generacin de algunos reportes a partir de la informacin cargada. La siguiente tabla, muestra cantidades de registros cargados mensualmente.

este proyecto, la organizacin se encontraba modificando por completo su plataforma operacional y de back-office, por tanto, no contaba con una base de datos slida, sobre la cual identificar la data necesaria a extraer. Pese a la variables antes mencionada, la experiencia con este proyecto, desde el punto de vista del desarrollo del modelo 7 se considera exitosa, dado que de forma fcil se identificaron las variables a medir y las entidades principales a considerar el modelo de datos a implementar para el DataWareHouse o repositorio de datos central. Se consider como entidad todos los elementos relevantes de medir del negocio, y el resultado es el modelo de datos presentado en la Figura 12. Lo anterior ocurri debido a que el conocimiento de lo que se deseaba medir, puesto que al momento del implante, se generan los reportes hacia las distintas reas gerenciales y Directorio, la diferencia est en que el trabajo desarrollado para llegar a ellos (sin la implementacin de este proyecto), es completamente manual. El modelo construido fue validado por los usuarios responsables participantes del proyecto. Quiz lo ms destacable del modelo es la generacin del concepto transaccin, puesto que permite considerar a todas las variables del negocio que se desea medir, como tambin, presenta facilidades en la incorporacin de nuevos conceptos a futuro. En este ltimo caso el trabajo corresponder a crear la descripcin en la respectiva tabla de transaccin y construir el ETL (extractor-transformador de datos), capaz de rescatar la data asociada a esa transaccin (o definicin). Por tanto, cualquier crecimiento en variables a medir, no involucrar modificar el modelo de datos desarrollado. Los entes participantes de este proyecto correspondieron a los usuarios (definiciones a medir), proveedor encargado del implante (conocimiento en la herramienta tecnolgica usada y en la creacin de modelos de gestin) e informtica (a travs de un jefe de proyecto). Si bien la tarea de los usuarios y proveedores fue importante en lo referente a conocimiento del negocio de los primeros, y conocimiento tecnolgico de los segundos, el aporte del jefe de proyectos estuvo orientado al conocimiento de la plataforma operacional y de los cambios en que esta se encontraba, adems estuvo en la identificacin de los datos que se relacionaban con cada definicin de transaccin del negocio, y la fuente proveedora de ellos. De esta manera se pudo identificar cuales sistemas provean datos estables y podan ser considerados en forma inmediata en la construccin de los ETLs (construccin de ETLs desde Sistema de Rentas Vitalicias), y cuales aun no podan ser tomados en cuenta (resto de la plataforma operacional que se encuentra sufriendo cambio). Adems fue
7 Debido a que a la fecha (Octubre 2003) el proyecto aun no entra en operacin, slo se referencia la generacin del modelamiento como exitosa.

Figura 15 : Totales de registros cargados a la fecha, para un mes de proceso.

Sin embargo, la prueba total se llevar a cabo cuando sea posible efectuar la carga de todas las transacciones al modelo. Se estima el procesamiento mensual de este DataMart sobre un universo de 3.000.000 de registros. En ese momento se podr medir el tiempo de respuesta y la performance sobre el modelo diseado. Adems ser posible revisar el resultado del cubo definido.
IV. CONCLUSIONES

A nivel organizacional, el concepto de Business Intelligence est tomando cada vez mayor impulso. Las empresas requieren contrastar informacin de las distintas reas de negocios que manejan y que este contraste apoye la toma de decisiones respecto de innovar en nuevas reas de negocio, incorporar nuevos servicios en la organizacin, conocer el crecimiento de la organizacin a corto mediano, largo plazo; todo lo anterior basado en la informacin real que se mueve al interior de la organizacin y las condiciones del mercado que se tengan. En este sentido, la organizacin sobre la cual est referido el caso antes presentado, deseosa de mostrar los resultados del negocio a todas las reas de toma de decisiones (niveles gerenciales, reas comerciales y de inversin, directorio de la compaa), decidi apoyar la construccin de un DataMart Financiero. Sin embargo, no tom en cuenta algunas condiciones mnimas y necesarias para la implementacin de este almacn de datos, entre ellas el considerar poco relevante que al momento de tomar la decisin de llevar a cabo

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

18

clave en la integracin entre los administradores de plataforma tecnolgica, implantadores, usuarios, reas externas involucradas, permitiendo la conexin y cohesin en las actividades asociadas a cada uno de ellos. Es decir, ocup un rol de conocimiento de la organizacin a travs de los datos almacenados, administrador de los recursos provenientes de cada participante en el proyecto y controlador de las actividades que se estaban desarrollando. Como resultado, se logr llegar a tiempo con las actividades definidas en el alcance del proyecto (para esta primera parte). Si bien las actividades desarrolladas permitieron modelar y definir un modelo de DataMart para controlar los informes del negocio en un cierto periodo, el momento de llevar a cabo este proyecto no fue analizado en detalle. La organizacin tom la decisin de efectuar cambios tecnolgicos muy grandes, los cuales fueron llevados en forma simultanea. Esto deriv que se cruzaron proyectos, pues algunos de ellos involucraban a la organizacin en forma transversal y otros involucraban a reas especificas, llegando a tener mismo grupo de usuarios participando en 2 a 3 proyectos, una Gerencia de Informtica sobrecargada de actividades, y la organizacin llena de proveedores externos. Muchos de los proyectos en carpeta para el ao 2003, terminaron alargando sus plazos de implementacin, pues en algunos casos (como el presentado), se toparon con falta de definiciones provenientes de otras fuentes que an no se encontraban estables. En el caso presentado, el proyecto fue dejado en espera (se termin modelamiento y falta la construccin de las extracciones de datos), la se espera retomar las actividades una vez terminada la implantacin de toda la plataforma operacional. Una vez que esta termine su desarrollo 8 , se continuar con las extracciones de datos, pruebas de poblamiento, performance y generacin de cubo, asociado al DataMart presentado. Si se compara este caso, con las definiciones tericas asociadas tanto a la administracin de proyectos, como a la construccin de DataMart, es posible concluir que muchas veces quines est a cargo de definir los alcances de proyectos informticos a desarrollar en una organizacin, no toman en cuenta las actividades que pueden estar ocurriendo en sta, o no han determinado la capacidad mxima de actividades posibles de soportar, y efectan evaluaciones demasiado optimistas, que finalmente llevarn a: atrasos en los proyectos respecto de los plazos definidos, generacin de stress colectivo que redundar en disminucin de la productividad de los equipos de trabajo y aumentos en los costos en los proyectos implementados.

Pese a esto ltimo, la organizacin est comenzando a analizar la proyeccin optimista del ao 2003 y definiendo una estrategia ms conservadora para el ao 2004. Entre los objetivos principales est el terminar al primer trimestre del 2004, todos los proyectos que hayan comenzado en el 2003 y que no pudieron concluir. Adems se est revisando la plataforma que se encontrar definida en su totalidad, y sobre la cual se levantarn proyectos que apoyen el anlisis de informacin de otras reas, entre ellas reas comerciales (estudio de segmentos de clientes) y reas de estudio (nuevas definiciones y lineamientos presupuestarios); siguiendo la lnea de gestin, como la aplicada en este caso.
REFERENCIAS

[BLECHAR] Blechar, Michel J, How to Manage Your Metadata, www.gartner.com, 2003. (Bibliografa) [CWOLFF] Wolf, Carmen, Implementado un DataWareHouse, http://www.inf.udec.cl/revista/edicion5/cwolff. htm, 2002. [GASCON] De la Herrn, Manuel, CastellarBus, Vicent, Como Disear Grandes Variables en Bases de Datos Multidimensionales, http://www.redcientifica.com/doc/doc2001041 90004.html, 2001 [JOAQ] Martn-Albo, Joaquina Coral Calero, DataWareHouse, Almacenes de Datos, 2002 [PEOPLESOFT] (Bibliografa) www.peoplesoft.com

[PSDATA] Morris, Henry y Vesset, Dan, Peoplesofts Enterprice Warehouse, www.idc.com , 2002 (Bibliografa)

Ser puesta en produccin en Enero del 2004.

MARIA CRISTINA VELIZ BELLO

> Creacin de un DataWareHouse Financiero y su Apoyo a la Gestin de la Compaa <

18

Anexo I : Ejemplo de Transacciones Definidas para Operar sobre el DataMart Financiero

MARIA CRISTINA VELIZ BELLO