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.

I.

Estructura Organizacional

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

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 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

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.

La organizacin tiene cobertura a nivel

nacional con una amplia red de sucursales y
oficinas en las ciudades ms importantes del

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:

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

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.

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

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.

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.

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

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.

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

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.

La consolidacin de los presupuestos para

obtener el presupuesto del holding, tambin es
efectuada en forma manual. Las planillas
3

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.

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.

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.

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.

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

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

Plan
Simple
Doble

Dotal
Vida

Incluye oncolgico
No incluye oncolgico

Opcin Mayor
Rentas
Vitalicias
Vehculo

Simple
Garantizada

Sobrevivencia
FullCar

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.

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

C. Detalle del Problema

Fecha del mes en que se

ejecuta

Clculo de Reserva Matemtica

1er da del nuevo mes

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:

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

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 4 : Calendario de Procesos Operacionales.

Algunos problemas que ocurren a partir de los

cierres operacionales:

Siniestros
Generacin de los
cargos del mes

Gastos mdicos

Prestamos y Rescates

Recuperos y Salvatajes

Gastos Judiciales

Cobranza

Administracin de
Rentas Vitalicias

Propuestas y Plizas
Del mes

Beneficios
y Siniestros
Previsionales

Siniestros

Gerencia
Tcnica
Departamento de
Informacin
Financiera

Colectivos

Suscripcin

Reservas
Reaseguros

Administracin de
Seguros Colectivos

Contabilidad
Inversiones

Comisiones
Pago de Comisiones

Crditos Hipotecarios
Pago de
Remuneraciones
Gastos del Mes

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.

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.

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

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.

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.

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)

RRHH

Orientado a apoyar funciones

de Recursos Humanos a partir
del manejo de competencias
de los empleados.

CRM

Orientado a apoyar las labores

de Call Center y manejo de
segmentacin de clientes.

EPM

Provee un DataWareHouse,
herramientas de generacin de
DataMart y anlisis de
informacin
multidimensional, reportes y
herramientas ETL

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

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.

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]:

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.
5

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 <

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:

Paquetes de
Aplicaciones

ACCESO AL
WAREHOUSE

BD
Produccin

Extraccin
De Datos

GENERACIN DEL
WAREHOUSE

Transformacin
De Datos

Data Warehouse

Querys y
Reportes

Anlisis
Multidimensional

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.

Data Mart
Aplicaciones de
Anlisis

ADMINISTRACIN
DEL WAREHOUSE

Figura
5 : Pasos en la construccin de un
DataWareHouse

B.2.

10

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.

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

Saliente

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.

MARIA CRISTINA VELIZ BELLO

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

2.

3.

4.

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.

5.

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.

6.

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.

7.

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

11

los reportes y se prob la generacin del

cubo de anlisis6.
El cuadro siguiente resume los tiempos
involucrados en estas actividades.
Actividades

Marzo
Abril
Mayo
Junio
Julio
Agosto Septiembre
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

Identificar equipoparticipante
Identificar actualesreportes
Detallar fuentesactualesdeentregade
informacin
Homologar sistemasoperacionalesactuales
y nuevos
Anlisisdelaherramientasobrelacual se
efectuarlaimplementacin
Definicindelastransacciones adesarrollar
Creacindeformatosdeextraccindedatos
oETL's
Procesodetrasformacinde
datos,construccindereportesy cubode
anlisis
Pruebasdeusuario
Validacindel modelo

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.

MARIA CRISTINA VELIZ BELLO

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

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.

12

informacin para los reportes de gestin

dependiendo de los programas de operacin
definidos para el o los DataMarts
construidos.
c)

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

Mquina Intel
Windows 2000
4 Procesadores

Maquina Intel
Windows 2000
4 Procesadores

BD
Produccin

BD
Desarrollo

Contiene BD sobre
Oracle 8i

Contiene BD sobre
Oracle 8i

Web Server (Web Logic)

Aplication Server
Informtica (ETL)

3
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

Arquitectura Propuesta para este Proyecto

Sus principales componentes son:

a)

ETL

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)

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

Figura
EPM.

9 : Arquitectura

definida para Peoplesoft

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.

MARIA CRISTINA VELIZ BELLO

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

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.

El siguiente es el esquema general de la

implementacin:
Sistema nuevo
Operacional
Productos de
Vida Generales
- Colectivos

DataWareHouse
Sistema
Rentas Vitalicias
ODS

Sistema
Siniestros AFP

Poliza
Transacciones
Reserva
Productos
Planes
Ramos
<Saldos_Contables>
Clientes
Coberturas
Transacciones_SUM
Reserva_SUM

DataMart
Aos

Rmos
SDOS
Prods

Cts

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.

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)

13

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.

b)

ODS

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 <

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

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

Recaudacin

Pliza

Coberturas

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

TR AN S AC C IO N ES _S U M

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

C LIE N T ES
P O LIZ A

R ES E R V A

R E S ER V A _ SU M

RAM O

V EN D ED O R E S _ BR K

P R O D U C TO

C O B ER TU R AS

P L AN

S U C U R S AL

IN VE R S IO N E S
G AS TO S F IJO S

A G E N C IA S

A JU S T E S C O N T A B LE 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

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

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.

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.

O F IC IN A

SA LD O S C O N T AB LE S y P LA N

SA LD O S C O N T AB LE S

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.

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.

Cliente

Permanencia
en el
tiempo

14

R E S ER V A S P L AN

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.

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.

MARIA CRISTINA VELIZ BELLO

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

15

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.

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)

b)

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

Procesos mensuales

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

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.

rboles de Cubos

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

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 <

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

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

16

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

MARIA CRISTINA VELIZ BELLO

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

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.

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

17

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.

MARIA CRISTINA VELIZ BELLO

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

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.

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)

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.

18

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 <

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

MARIA CRISTINA VELIZ BELLO

18