You are on page 1of 21

Unidad 5: Aplicaciones de negocio

Business Intelligence / Data warehouse


Tecnología aplicada a la toma de decisiones o malas decisiones en tecnología?
Autor: Ernesto Chinkes, 2006
Profesor TI – FCE/UBA

1. Introducción

En la denominada “sociedad del conocimiento”, la información ha pasado a ser uno de los activos
más preciados de los que disponen las organizaciones. En muchas instituciones, sobre todo las de
servicios, es el principal activo; inclusive por encima de los de capital, y en las que no lo es,
igualmente tiene una relevancia mayúscula.

Para tomar mejores decisiones es fundamental contar con la información adecuada en el momento
y lugar preciso. Esto no es nuevo, pero el impacto de no disponer de dicha información cada vez
tiene un efecto más nocivo. Esto se debe a que el mundo que nos rodea es cada vez más
complejo, cambia más rápidamente y el resto de los actores con los que se convive cada vez
cuentan con más y mejor información.

Los términos “data warehouse” y “business intelligence” se usan desde hace varios años en la
industria de las Tecnologías de la Información (TI), y enmarcan soluciones tecnológicas que a las
organizaciones pueden proveerles importantes beneficios alineados con mejorar el proceso de
toma de decisiones. Es tecnología aplicada a dar soporte a la toma de decisiones, pero muchas
veces los proyectos para su incorporación terminan reflejando simplemente malas decisiones en
tecnología. En las secciones que siguen se intenta dar algunos lineamientos para que esto último
no ocurra.

2. La información en la toma de decisiones.

En el transcurrir cotidiano de las organizaciones, las personas que trabajan en ellas deben
enfrentarse a decisiones en forma frecuente y recurrente durante el día, ya sean grandes o
pequeños problemas los que deban afrontar y solucionar. Algunas de ellas son decisiones de rutina
o intrascendentes mientras que otras tienen una repercusión significativa en las operaciones de la
organización y pueden incidir inclusive en la supervivencia.

1
Toda acción que se realiza, o deja de hacer, en una organización es fruto de las decisiones que
han tomado las personas que la componen. Por lo tanto, es en función de la calidad de dichas
decisiones el futuro de éxitos o fracasos que le deparará.

Para tomar decisiones las personas pueden basarse en información, así como en muchos otros
aspectos menos racionales como la emoción, la percepción, el prejuicio, la intuición, etc. Gran
parte del esfuerzo del proceso decisorio estará destinado a comprender el futuro, ya que es el
terreno en el que transcurrirán finalmente sus acciones. Es por ello que un gran soporte en este
sentido es la posibilidad de analizar los hechos ocurridos, para construir de esta forma el
escenario futuro apoyándose en las experiencias vividas.

Las decisiones deben tomarse sobre una realidad altamente compleja, en la que confluyen un
enorme número de variables que entran en juego, que a la vez tienen una infinidad de
posibilidades. Por otro lado se puede observar que para muchas de las decisiones que se toman
se dedica muy poco tiempo, y ello implica tener en cuenta solamente lo que se siente y vislumbra
en ese momento, no considerando aspectos del pasado donde la rica historia de la organización
pueden dar un panorama que, de ser analizados, llevarían la decisión a un resultado distinto.

Es interesante mencionar las cuatro etapas del proceso decisorio que describe Herbert A. Simon:
a) inteligencia, b) diseño, c) selección y d) implementación; ya que ello permite comprender la
significatividad que puede tener en su resultado la disponibilidad de herramientas adecuadas por
parte de los decisores.

a) Inteligencia: es en esta etapa donde se detectan los problemas. El proceso de toma de


decisiones comienza con el reconocimiento de la necesidad de tomar una decisión, ya sea por
que se detecta un problema o el deseo de accionar o cambiar algún aspecto.
b) Diseño: es la base de la toma de decisiones y no es más que desplegar las alternativas. El
tomador de la decisión confecciona una lista de las alternativas posibles que se le ocurren
como viables para resolver el problema.
c) Selección: una vez identificadas las alternativas, se evalúa de manera crítica cada una de
ellas. Se comparan distinguiendo sus consecuencias, ventajas y desventajas, y en particular
sus costos1. El tomador de decisiones tiene que elegir una de ellas.
d) Implementación: finalmente se pone en práctica la decisión elegida, se lleva la decisión a la
acción, y es a partir de ese momento, en donde se monitorean sus progresos y resultados
obtenidos.

Los sistemas informáticos en general, y las soluciones de business intelligence en particular, son
herramientas imprescindibles para dar soporte a este proceso.

En la actualidad, en la mayoría de las organizaciones, prácticamente no existe aspecto sobre el


cual haya que tomar decisiones, del que no se estén guardando datos. Existe gran cantidad de
datos que se almacenan como fruto de la gestión diaria de las operaciones de rutina. Sin embargo,

1
El concepto costo no se limita al aspecto monetario, pura y exclusivamente, sino que se lo referencia con un criterio amplio.

2
muchas veces esos datos no están disponibles, accesibles, en el formato y el momento oportuno
para permitir su uso como información que ayude de manera significativa en las decisiones. Es
decir, no se valora y usufructúa el gran potencial de información que existe.

Las soluciones de inteligencia de negocio pueden ser vitales para mejorar el proceso de toma de
decisiones; ya que brindarán información que permita detectar los problemas sobre los cuales
habrá que decidir, desarrollar alternativas, evaluar las posibles consecuencias de las mismas y su
posterior monitoreo cuando se traduzcan en acciones.

En la medida que las decisiones son propias del nivel operativo (por lo general con efectos a corto
plazo, fáciles de revertir y con impacto único) es más fácil que estas sean programadas y que
puedan por lo tanto estar incorporadas en los sistemas de información de nivel operativo (que se
suelen denominar sistemas OLTP). En cambio las de alto nivel (táctico y estratégico) no son
fácilmente programables, y es allí donde es necesario proveerles a los responsables de realizarlas
la mejor infraestructura posible para encararlas.

3. Los problemas de los sistemas operacionales.

Antes de analizar en detalle una solución es conveniente comprender adecuadamente los


problemas que la misma debe solucionar. Cuando ello no es así, lo que se implanta no cubre
necesidades reales, y en lugar de acercar soluciones genera nuevos problemas, a veces inclusive
mayores que los originarios. Es por ello que hace tiempo me ha interesado estudiar y clasificar
estos problemas, que finalmente bauticé con el rótulo de “Los tres problemas del OLTP”.

Si bien existen en las organizaciones distintas estructuras administrativas y procesos de negocio,


es posible generalizar su organización en lo que se denomina la pirámide organizacional. El nivel
operativo es donde se agrupan la mayoría de los trabajadores y donde los procedimientos están
más estructurados y definidos. Los niveles superiores (nivel táctico y estratégico) realizan
actividades más relacionadas con el control y la toma de decisiones.

Los trabajadores del nivel operativo también necesitan información para el control y la toma de
decisiones, pero están más ligados a aspectos puntuales y específicos, como el control si un
cliente está pagando su deuda en forma correcta o la decisión de si debe cobrarle o no un recargo.
En cambio los niveles superiores necesitan información para un control más global y abarcativo y
para decisiones tácticas y estratégicas, como el lanzamiento de nuevos productos y servicios, la
reubicación de recursos, nuevas políticas de motivación del personal, la inversión o eliminación de
una planta de producción, etc.

3
Los sistemas operacionales son sistemas de información que dan soporte a los procesos del nivel
operativo de la estructura organizacional. El nivel operativo es donde se realizan las actividades de
rutina del negocio que permiten su funcionamiento, es donde se atiende y vende, donde se cobra y
paga, donde se produce, donde se liquidan los haberes de los empleados, etc. Cada una de estas
funciones que necesita realizar una organización para cumplir con sus objetivos, se encuentran
apoyadas por sistemas informáticos. A estos se los denomina sistemas transaccionales,
operacionales u OLTP (On Line Transactional Processing).

Estos sistemas necesitan guardar y consultar datos. Las bases de datos que dan soporte a los
sistemas de nivel operativo, se denominan bases de datos OLTP. Estas bases de datos soportan
procesos con las siguientes características:
• Transacciones que actualizan un conjunto de pocos registros. Ejemplo: Las facturas que
un cliente está pagando.
• Transacciones que consultan un conjunto de pocos registros. Ejemplo: El precio de un
producto que está por comprar un cliente.
• Puede existir alto nivel de concurrencia de las transacciones que consultan y actualizan.
Ejemplo: muchos cajeros de una línea de caja, facturando al mismo tiempo.
• Son operaciones de actualización y consultas en línea (“on line”), que deben tener una
respuesta instantánea para no trabar las operaciones de la organización. Ejemplo: el
cobro de un servicio en un banco, que le debe decir al cajero cuanto cobrar, y debe
quedar registrado el pago antes de que el cliente abandone la ventanilla.

Cuando se necesita información para usar en la toma de decisiones tácticas y estratégicas, las
bases de datos OLTP, pueden presentar una serie de deficiencias que no permitan satisfacer las
necesidades que presentan estos niveles de decisión.

Estas deficiencias, como ya se comentó al principio de la sección, las he clasificado mediante “Los
tres problemas del OLTP”.

a) Problema 1: Descentralización de la base de datos.

Los datos que representan la realidad de la organización se encuentran muchas veces dispersos.
Es decir, existen distintas bases de datos (o en algunos casos archivos), que tienen diseños
conceptuales y físicos independientes entre sí, que guardan situaciones parciales no relacionadas
ni integradas.

Esta descentralización de la base de datos dentro de una organización tiene, por lo general, un
origen pluricausal, que se encuentra relacionado con las particularidades que ha asumido el

4
desarrollo y la administración de los sistemas informáticos. En la medida que mayor sea la
complejidad de las instituciones, mayor será la probabilidad de que existan más causas para esta
descentralización de los datos. Es por ejemplo muy común encontrar que el sistema de ventas
actualiza una base de datos, el de abastecimiento otra y el de liquidación de haberes una distinta,
así mismo podría suceder que distintas sucursales de una empresa se manejen con sistemas
independientes que actualicen sus propias bases de datos.

Surgen, entonces, los siguientes problemas:

• Existen diferentes visiones de una misma realidad entre los decisores de la organización.
• Imposibilidad de obtener información integrada que permita comparar, clasificar y
consolidar la información de las distintas áreas, sectores, procesos, unidades, etc., para
analizar a la organización como un todo.

b) Problema 2: Inadecuados tiempos de respuesta.

Existe en las instituciones la necesidad de realizar consultas de grandes porciones de la base de


datos en forma interactiva. Es decir, gran parte de la información que necesitan los niveles tácticos
y estratégicos para la toma de decisiones, es información que se construye a partir del acceso y
procesamiento de importantes volúmenes de datos.

Por ejemplo, si necesitara comparar los 10 productos más vendidos durante el primer semestre de
este año contra los del semestre del año anterior, debería recorrer los datos correspondientes a
todas las ventas de los seis primeros meses del año anterior y del actual, que podrían ser cientos
de miles (o millones) de registros. Pero esta respuesta debería volver en pocos segundos, ya que
posiblemente en base a dicho resultado el usuario necesite realizar otra consulta, como ampliarlo a
20 productos, o comparar sólo el primer trimestre, o desagregar la información por zona geográfica
de venta, etc.

En la medida que las bases tienen grandes cantidades de datos, se hace muy difícil, obtener
adecuados tiempos de respuesta de las bases de datos OLTP para este tipo de consultas. Por otro
lado este tipo de consultas trae un problema adicional, y es que hace más lento al resto de las
operaciones transaccionales que deben realizarse en esa base de datos, ya que los recursos de la
computadora (principalmente procesador y disco) estarán ocupados con dichas consultas que
hacen un uso muy intensivo de estos recursos.

Surgen, entonces, los siguientes problemas:


• Inadecuados tiempos de respuesta para las consultas que se necesitan para la toma de

5
decisiones.
• Se entorpece el nivel de respuesta de los sistemas de nivel operativo, debido al uso
intensivo de los recursos que genera el procesamiento de las consultas para la toma de
decisiones.

c) Exploración amigable para consultas ad-hoc.

Los tomadores de decisiones necesitan alternativas “amigables” de acceso a los datos. Es decir,
que puedan acceder sin necesitar conocimientos profundos sobre el uso de la tecnología, siendo
ésta lo más “transparente” posible.

Esta amigabilidad se ha logrado muchas veces con consultas pre-planeadas (reportes). Estas son
consultas de rutina, que como los usuarios ya previeron que las iban a necesitar fueron
especificadas, diseñadas y programadas en opciones de un software aplicativo de usuario final,
donde el usuario podrá acceder simplemente seleccionando una opción del software, y a lo sumo
ingresando algunos parámetros claramente identificados (como fechas, ordenamiento, etc.).

El inconveniente surge cuando los decisores necesitan realizar consultas ad-hoc en forma
amigable, ya que si bien existen lenguajes para acceder a los datos y realizar consultas ad-hoc,
como es el caso de SQL (Standard Query Language) o QBE (Query By Example), su uso implica el
conocimiento por parte del usuario del lenguaje y de complejos modelos de datos. Estas
capacidades no son acordes con el perfil de los usuarios que necesitan este tipo de información.

El problema, entonces, es:


Los usuarios no cuentan con herramientas para explorar los datos y obtener información
ad-hoc para la toma de decisiones en forma amigable.

Puede que los problemas enunciados se presenten todos juntos, o que sólo se presente uno o dos
de ellos. Inclusive que no exista ninguno. Sólo en el último de los casos no es necesaria una
solución de business intelligence / data warehouse.

Si existen los problemas 1 y 2 (descentralización de la base de datos e inadecuados tiempos de


respuesta) el data warehouse es el que le acerca los principales beneficios. Si existe el problema 3
(no disponer de herramientas para obtener información ad-hoc en forma amigable), entonces debe
explorar las tecnologías encuadradas bajo el paraguas del business intelligence

6
H e rra m ien ta s d e B I
N ive l
D atam ining
E s tra té g ic o
O LA P
IN F O R M A C IO N Tableros
PARA
N iv e l LA TO M A D E
R eportin g...
T á c tic o D E C IS IO N E S

N iv e l V entas D A TA
S ucurs al P rod ucción
O p e ra tiv o
C órdo ba ... W AREHOUSE
V entas
V entas S ucurs al M arketing
C om pras S ucurs al C órdo ba
B s.A s.

4. Conceptos y lineamientos de una solución de DW / BI

4.1. El Data Warehouse

El data warehouse (almacén de datos) es una base de datos concebida y administrada para dar
soporte a la toma de decisiones. En forma sintética se puede decir que, cuando se piensa en un
data warehouse se debe considerar una base de datos que debe poseer datos que representen la
realidad integrada de toda la organización y que en ella se desea optimizar el desempeño de las
consultas que impliquen el procesamiento de un gran número de registros.

Una solución de data warehouse debe dejar como resultado una base de datos integrada, con
datos que permitan responder a las necesidades de información para la toma de decisiones,
principalmente de los niveles tácticos y estratégicos. Si bien por lo general, el motivo principal es
brindar información para los niveles superiores de la organización, eso no quita que se use también
para responder consultas de niveles operativos, como podría ser el caso de vendedores que
accedan para obtener información integrada sobre el historial de ventas de los clientes, y de esta
forma poder focalizar mejor su estrategia de relación con los mismos.

4.2. El Business Intelligence

El business intelligence (inteligencia de negocio) define una solución donde se usan los datos para
la administración inteligente de la organización.

Si bien este concepto puede tratarse como un tema de “management”, que denote la importancia
del uso de la información para guiar una organización, desde el punto de vista de la tecnología es

7
posible enfocarlo para describir las herramientas de exploración y explotación de datos para dar
soporte a la toma de decisiones.

Cuando se analiza a las organizaciones en función de su organigrama se detecta que las


necesidades con respecto a la información no son iguales para todos los niveles jerárquicos, ni
tampoco para las diferentes áreas funcionales. Un gerente general necesita evaluar la situación
global de la compañía mediante la medición de una serie de indicadores definidos como
estratégicos a nivel directivo, para lo que lo ayudará la utilización de unos pocos indicadores
integrales de rápida detección (como pueden ser semáforos, tacómetros, etc.) sobre la “salud” de
la organización. En cambio un analista de producto de una región particular seguramente no
necesite visualizar el desempeño de esos indicadores globales y esté mucho más interesado en
ver la evolución diaria de las ventas de un producto en la región que él tiene a cargo. Asimismo, no
serán las mismas necesidades las que tiene un analista contable que necesitará crear reportes
sobre el balance, con el formato corporativo, para enviar a la casa matriz o para presentar ante
organismos regulatorios, que las que tiene un analista de marketing cuando quiera saber cuáles
son las combinaciones de productos que más adquieren las personas que tienen entre 20 y 30
años y viven en zona norte de la Ciudad de Buenos Aires.

Este amplio espectro de necesidades es el que debe ser abarcado por las herramientas de
business intelligence. Existe entonces una clasificación de diversos tipos o estilos que puede
asumir el acceso a la información mediante el software de business intelligence. Un usuario
particular puede utilizar uno o más de estos tipos, pero seguramente estará más cerca de uno u
otro, de acuerdo a sus funciones y responsabilidades en la institución y a su forma personal de
relacionarse con la información disponible.

Las categorías de business intelligence son:


1. Reportes (Reporting).
2. Análisis multidimensional (exploración OLAP).
3. Tableros de Control / Balance Scorecard.
4. Minería de datos (Data Mining).
5. Distribución pro activa.

Estas herramientas se conciben para tomadores de decisiones que sean autosuficientes a la hora
de obtener la información que necesitan. Si bien algunas herramientas de las categorías
mencionadas no lo necesitan con tanta fuerza, implantar estas herramientas plantea un cambio
cultural difícil para organizaciones donde los decisores prefieren contar con un área que les provea
información, en lugar una infraestructura tecnológica preparada para acceder a ella por su cuenta.

8
Cuando se encara una solución de business intelligence, ella incluye la existencia de una base de
datos (por lo general un data warehouse) y la implantación de una o varias de estas herramientas.

4.3. La arquitectura de la solución

Es importante describir los componentes que integran la arquitectura de una solución de data
warehouse / business intelligence. La que se plantea es un arquitectura bastante particular, que a
criterio de este autor tiene importantes beneficios, pero con esto no se desea expresar que ésta es
la única arquitectura viable, ni tildar de erróneas otras que puedan ser consideradas.

En esta arquitectura se plantean tres grandes áreas o componentes: 1) Fuentes de datos, 2) área
del data warehouse y 3) herramientas de acceso y exploración.

1. Fuentes de Datos: incluye a todos los datos en su lugar de origen (bases de datos o archivos
2
planos) que se extraerán mediante los correspondientes ETL que permitirán incorporar el
contenido del data warehouse. Esta área se compone principalmente de los datos que
almacenan los sistemas operacionales, pero también pueden existir datos externos, así como
datos internos no sistematizados.

Fuentes de datos Área del Data warehouse Herramientas de


acceso y exploración
Sistema Transformación
operacional A
Extracción
Area de trabajo
Análisis
Sistema Multidimensional
operacional B Carga (Load) Datamining
Tablero de
A comando.
Balance scorecard
Data warehouse
Sistema Alertas
detallado u “objetivo”
operacional N Reporting
Etc.
T, L
Datos Externos B
Data warehouse
agregado o “subjetivo”

Datos Internos no Sistematizados

Arquitectura de una solución de Data warehouse /CBusiness Intelligence


Datamart A Datamart B Datamart N

2
ETL (Extract, Transformation, Load) es la forma a que se denominan los procesos de extracción, transformación y carga
que se usan para nutrir a un data warehouse.

9
2. Área del data warehouse: incluye a todos los datos que se integran para brindar información
para la toma de decisiones en forma eficaz y eficiente. Este área puede ser dividida en tres sub
áreas para su mejor análisis:

o Área de trabajo: aquí se realizan las principales transformaciones de datos, que


incluyen su limpieza, combinación, homogeneización de unidades de medida,
equivalencias de códigos, agregaciones de consistencia, etc.

o Data warehouse “objetivo” o detallado: es una base de datos que contiene los datos
integrados de toda la organización, con el mayor nivel de desagregación posible. Es
decir, que es una base de datos que representa la realidad de la organización desde
una mirada puesta en los datos de origen, intentando reproducir con la mayor
objetividad las transacciones como fueron capturadas.

o Data warehouse “subjetivo” o agregado: podrá estar compuesto por una única base de
datos o por múltiples (data marts), o por ambas. Esta o estas bases de datos están
construidas según las necesidades de la información para la toma de decisiones de los
usuarios y de las herramientas de exploración. Se nutre del data warehouse “objetivo”.
El data warehouse subjetivo, a diferencia del “objetivo”, es una representación
integrada de la realidad desde la perspectiva de la exploración de la información que
podrán hacer los tomadores de decisiones (subjetiva).

3. Las herramientas de acceso y exploración de datos: Es el componente que usufructúa los


beneficios de la solución. Es lo que ven los usuarios. Se compone de las distintas herramientas
que se implanten para explorar los datos, permitiendo cubrir diversos criterios y estilos de
análisis de la información: como el análisis multidimensional, datamining, reporting, alertas,
tablero de comando, balance scorecard, etc.

Los datos del data warehouse se obtienen del área de fuentes de datos, a través de procesos
informáticos que se encargan de la extracción de datos.

Todos estos datos por lo general tienen como destino una base de datos (o el área de una base
de datos) que se denominó “Área de trabajo”. Es allí donde se correrán procesos informáticos que
realicen la transformación de datos. Es un área que contendrá datos que todavía no están listos
para ser consultados por los usuarios. Es un espacio de almacenamiento donde se estarán
preparando los datos.

10
Una vez que los datos estén listos se pasarán a los sectores A, B, y/o C (según la figura de página
9) del área del data warehouse. El sector dependerá de la arquitectura que la organización elija. En
caso de existir una arquitectura completa, como la que aquí se plantea, entonces en primer lugar
se correrían procesos de carga que permitan dejar listo el data warehouse objetivo (sector A),
luego a partir de allí cargar el data warehouse subjetivo (sectores B y/o C), realizando
principalmente transformaciones de agregación según los criterios de exploración que se definan
para los usuarios.

En caso de co-existir los sectores B y C, en B se dispondrá de una base de datos integrada,


mientras que en C los datamarts que se corresponden con visiones parciales de la organización y
serán el resultado de particionar B. Su principal objetivo es lograr mejor performance o explotar
una visión parcial con mayor detalle que el que se encuentra en B. En este último caso el contenido
de C se generaría directamente desde A.

También es posible definir una arquitectura donde sólo exista B o C (sin que exista A). Este
esquema es bastante común, y se da cuando los datos en el data warehouse se guardan
directamente en forma agregada bajo los criterios de las dimensiones de explotación.

El ETL

El ETL, que significa Extraction, Transformation and Load (extracción, transformación y carga), es
la forma en que se denomina al conjunto de procesos mediante los cuales se genera y actualiza el
contenido del data warehouse.

Estos procesos deben resolver el mayor problema con el que suele toparse la construcción de un
data warehouse: la homogeneización de los datos provenientes de fuentes diversas.

Estos procesos deben:


• acceder y tomar datos de las distintas fuentes (Extract),
• realizar las transformaciones que sean necesarias para dejar los datos en el formato, con
la codificación, niveles de agregación, de calidad y criterios de integración que se definan
(Transform), y
• actualizar el data warehouse con dichos datos ya transformados (Load)

Los procesos que componen el ETL necesitan ser ejecutados en base a una programación
temporal. Esta debe ser definida en función de las necesidades de actualización que amerite el
data warehouse. La programación incluye periodicidad (cada cuanto tiempo se ejecuta), el horario,

11
y la secuencia. Hay que determinar la secuencia en que se ejecutarán los n proceso que integren
el ETL, ya que de lo contrario correría riesgo la integridad de la base de datos.

El datamart

El datamart (mercado de datos), es el nombre que se le asigna a una base de datos que asume las
características que se definieron para un data warehouse, pero en lugar de representar la realidad
de toda una organización sólo lo hace respecto de un área o función de ella. De esta forma, por
ejemplo, podrán existir datamarts para el área de ventas, de finanzas, para el departamento de
recursos humanos, etc.

Es un concepto que ha tomado bastante relevancia principalmente debido a la complejidad que


implica la implantación de un data warehouse. Es por ello que muchas veces se avanza sobre
proyectos que consideran la implantación de datamarts.

5. Los factores críticos.

En este apartado se explican algunos criterios que deben considerar quienes construyan e
implementen este tipo de soluciones, principalmente en lo referente a consideraciones o enfoques
acerca de su diseño, construcción e implantación.

5.1. Se trata de un desarrollo a medida.

Un primer punto que vale la pena destacar es que una solución de business Intelligence / data
warehouse necesita un proyecto que se desarrolle a la medida de cada organización.

Es necesario diseñarla considerando las necesidades de la información, el tipo de decisiones que


se deben soportar y la realidad de datos que tiene cada institución en particular. Esto no quiere
decir que el software que integre este tipo de soluciones hay que desarrollarlo a medida, ya que
sería poco inteligente no aprovechar la existencia de una variedad de productos de software que
proveen herramientas para soportar estas soluciones. Lo que debe entenderse es que habrá un
conjunto importante de necesidades particulares que implicarán soluciones propias no replicables
de otras experiencias.

Sin lugar a dudas, dentro del proceso de construcción, el desarrollo del data warehouse es el que
más características de individualidad tendrá. No sólo se debe construir una base de datos que
satisfaga las necesidades de información propias de cada institución, sino que también debe
adaptarse a la realidad de los datos existentes.

12
Este segundo punto es el que más diferencia a cada solución del resto, ya que si bien las
necesidades de información en cada organización podrían definirse también como únicas, es muy
probable que una organización pueda beneficiarse en gran medida de imitar determinados modelos
que ya se usaron en otras empresas de su misma industria. Sin embargo la compleja realidad de
los datos existentes en una organización muy difícilmente se repita en otra (sobre todo en la
medida que sean instituciones de mediana o gran envergadura).

5.2. Partir desde la información o desde los datos

Como se expresó en el punto 5.1. para desarrollar una solución de estas características es
necesario considerar tanto las necesidades de información que tiene la organización, así como
entender cabalmente cual es la realidad de las fuentes de datos a partir de las cuales se podrá
nutrir el data warehouse. A partir de ello es posible considerar dos criterios opuestos para guiar el
desarrollo:

a) Partir desde las necesidades: este criterio considera que debe comenzarse por definir
claramente las necesidades de la información (que deberá proveer la solución) y a partir de allí
diseñar el data warehouse deseado.
b) Partir desde las fuentes de datos: éste considera que debe comenzarse por entender que
datos existen y a partir de allí diseñar el data warehouse posible.

Si bien a) sería lo que se impone como más criterioso, alineándose con las buenas prácticas en
sistemas, donde primero es necesario entender la necesidad a satisfacer y recién allí construir la
mejor solución, quienes defienden b) plantean que de nada sirve que los usuarios “fantaseen”
sobre que información les gustaría obtener, si luego no existen los datos necesarios para lograrlo.
Como ambos criterios tienen una verdad a considerar, se plantea como recomendación, una
tercera alternativa:

c) Equilibrio entre necesidades y datos existentes: se plantea comenzar el análisis a partir


de las necesidades de la información, que permitan fijar el alcance que determine la dirección
hacia la cual avanzar. Luego trabajar en un proceso iterativo entre la formalización de los datos
existentes, las necesidades de información y el diseño del data warehouse.

13
Análisis de las
necesidades de Alcance
información

Formalizar datos Necesidades de Diseño del data


existentes información warehouse

5.3. Redundancia.

La redundancia en las bases de datos, no debe ser considerada como una mala palabra que debe
ser eliminada de la faz de la tierra. No sólo trae perjuicios, que son los que por lo general se
mencionan cuando se estudian o pregonan los conceptos referidos a la normalización (con las
formas normales), sino que también puede traer beneficios. Es por ello que es necesario analizar
ventajas contra desventajas y decidir cuál conviene priorizar.

La redundancia es una de las principales herramientas con que se cuenta para acelerar las
consultas y la implementación de controles. El primer aspecto, que es el que interesa
principalmente al data warehouse, tiene como explicación que la redundancia posibilita almacenar
precalculados los resultados totales o parciales de las consultas.

Entre las desventajas de la redundancia, se pueden mencionar, la mayor probabilidad de que


existan inconsistencias y los mayores tiempos de actualización (ya que es ese el momento en que
se realizaría por ejemplo el “precalculo” que se mencionaba en el párrafo anterior).

En las bases de datos OLTP tiene mayor impacto las desventajas de la redundancia que las
ventajas que puede proveer. Es por ello que no es aconsejable su aplicación, salvo en casos muy
controlados y en la medida que sea la mejor entre otras alternativas que se hayan evaluado. En el
caso del data warehouse pasa lo contrario. Es una excelente solución para lograr importantes
mejoras de desempeño en las consultas. Por otra parte por lo general no es un costo significativo
el tiempo extra en la actualización que es necesario pagar por ello.

En el siguiente cuadro se detallan pros y contras de la redundancia en los dos tipos de bases de
datos.

14
Características de la Efecto que causa en las bases de datos.
redundancia en las Base de datos OLTP Data warehouse
bases de datos
a. Acelerar consultas En la mayoría de los sistemas no es un Es un beneficio significativo por
con datos beneficio significativo, debido a que la que el objetivo es realizar consultas a
precalculados mayoría de las consultas, son sobre una grandes porciones de la base de
cantidad de registros pequeña. datos, que en caso de estar
precalculados, permite evitar recorrer
todos los registros desagregados.
b. Demora la Es un perjuicio significativo, ya que en No es un perjuicio significativo, ya
actualización de la mayoría de los sistemas la actualización que en la mayoría de los casos la
los datos, al es en línea, conllevando demoras en la actualización es “batch” y no trae
guardar en forma misma. Por lo que está íntimamente mayores problemas una demora en
redundante datos relacionado con la eficiencia de las dicho proceso.
calculables (datos operaciones (como por ejemplo la línea de
precalculados). caja).
c. Existe mayor Es un perjuicio significativo, ya que No es un perjuicio significativo, dado
probabilidad de existe la posibilidad de que se actualicen que los datos son una copia de otra
generar los datos correspondientes a una base de datos, que contiene a los
inconsistencias. transacción en forma incompleta. originales, y debido a que el proceso
de actualización es más controlado.
No obstante habrá que controlar que
el ETL actualice en forma consistente
todos los datos.
d. Redundancia para Pude ser un beneficio y un perjuicio No es significativo, ya que la
controles. significativo a la vez. Puede ser una actualización está controlada desde
herramienta muy importante para insertar el ETL y se está realizando una copia
controles que mejoren la confiabilidad de de los sistemas transaccionales
los datos almacenados (digito verificador, donde deberían estar dichos
totales de control, registros duplicados en controles.
distintos servidores, etc), pero por el otro
lado tiene los mismos perjuicios que los
vistos en el retraso de la actualización.

Observación: En el punto b es necesario realizar la siguiente salvedad: existen procesos de ETL


donde el volumen de datos y la complejidad de los procesos hacen que los periodos de
inactividad de los sistemas de nivel operativo no alcancen para su ejecución. En estos casos
mayor redundancia puede transformarse en un perjuicio significativo.

5.4. El costo de la integración de datos y el nivel de desagregación.

Como se explicó en forma precedente la construcción de un data warehouse implica diseñar e


implantar una base de datos integrada. Es por ello, que salvo rarísimas excepciones, ello implica
una ardua tarea que permita integrar en una única base, datos que se vienen almacenando (y
seguramente se seguirán almacenando) en forma descentralizada.

Esta actividad de integración tiene dos componentes principales, uno el del diseño y generación de
una base de datos que pueda contemplar las distintas realidades parciales que se deben conjugar,
y el otro el del diseño y desarrollo de los procesos ETL que deberán mapear el contenido de las
fuentes de datos con el data warehouse.

Esta actividad probablemente sea una de las que más tiempo y recursos insuma en la construcción

15
de una solución de este tipo, ya que implica conocer adecuadamente los modelos de cada una de
las fuentes de datos, conocer las necesidades de información para la toma de decisiones, y
comenzar a trabajar en forma conjunta entre el diseño del data warehouse y de los ETL necesarios
para llenarlo con datos homogéneos y de calidad aceptable.

Ya que los cambios en la solución que se implemente serán inevitables, sobre todo por que es
normal que las necesidades de los tomadores de decisiones deban adaptarse constantemente,
tener que encarar este proceso de integración cada vez que haya que implementar modificaciones
conlleva una solución no sustentable en el tiempo.

Por este motivo es que el diseño de la solución debe ser fácilmente adaptable a los cambios y no
estático a las necesidades específicas del momento de su construcción.

En línea con este análisis se planteó en la sección anterior la arquitectura con un data warehouse
desagregado (“objetivo”) que fuera el que tratara por única vez esta problemática, y otro subjetivo
(más orientado al software de business intelligence y el análisis del negocio) que trabajará con las
agregaciones necesarias según las necesidades de información que surjan en cada momento.

Este esquema permite que cuando surjan cambios no haya que trabajar nuevamente, o solo en
forma mínima, con la integración; porque dichos datos ya existirán en el data warehouse objetivo.
Solamente habrá que adaptar el data warehouse subjetivo, que es una tarea más fácil de
implementar.

5.5. Del data warehouse al datamart o a la inversa ?

El uso de datamart en el proceso de construcción, es otro aspecto que divide posturas opuestas.

Una de ellas recomienda construir el data warehouse desde los datamats, por lo tanto pregona que
primero se vayan realizando proyectos de construcción de datamarts que cubran distintas
necesidades parciales de la organización, como sería el caso del datamarts para el departamento
de ventas, de recursos humanos, de compras, de finanzas, de producción, etc. y luego desde estas
soluciones avanzar hacia la construcción del data warehouse que integre estas soluciones.

La otra postura plantea la construcción del data warehouse primero, y recién luego avanzar hacia
los datamarts en la medida que los mismos sean necesarios. Es decir, el camino exactamente
inverso.

Los patrocinadores del segundo camino expresan con razón que encarar una solución bajo la

16
primera postura, conserva el problema de las visiones parciales desintegradas, y hasta las agrava
por que las consolida mediante el datamart. En cambio los que propician lo contrario, plantean
también con razón, que es imposible encarar un data warehouse en forma integral, sobre todo en
organizaciones medianamente complejas, y que por ello la única solución es comenzar con
soluciones más pequeñas como son los datamarts.

Como se desprende del párrafo anterior, ambas posturas tienen causas razonables, y es por ello
que mi recomendación es comenzar con soluciones chicas, como es un datamart, que permita
mostrar un resultado en el mediano plazo y de esta forma conseguir mayor apoyo para la
continuación del proyecto, pero a la hora de continuar sumando otras áreas de la organización, no
hacerlo construyendo otro datamarts, sino integrando las mismas a un único data warehouse.
Luego si es necesario se podrán subdividir datamarts.

5.6. El recupero de la inversión.

Los proyectos de tecnologías de la información (TI) en general, y los de data warehouse / business
intelligence en particular, son inversiones de capital que, como tales, deben competir con otras
inversiones de la organización. Es por ello que es frecuente la solicitud de justificación de un
proyecto de esta naturaleza desde una perspectiva que demuestre por qué usar el dinero en éste,
en lugar de usarlo en otro proyecto de inversión ya sea de TI o no.

Para calcular el recupero de una inversión de capital se suelen utilizar algunos de los métodos más
conocidos, como el ROI, TIR, VAN, etc.

Estos métodos son de utilidad tanto en la fase inicial, para justificar la factibilidad económica de
realizar el proyecto, como luego de su implementación, para evaluar el desempeño de la solución
lograda.

Para usar cualquiera de estos métodos se necesita especificar los flujos de ingresos y egresos del
proyecto que permitirán realizar el calculo numérico que arroje finalmente el resultado.

Obtener el flujo de egresos al finalizar el proyecto no tiene mayores problemas, ya que los costos
son fácilmente calculables (si se registraron adecuadamente). Para obtenerlo al inicio de un
proyecto hará falta una estimación de los mismos, en los que tendrá fundamental importancia la
utilización de determinadas técnicas de estimación así como la experiencia del administrador de
proyectos.

Pero el principal problema para el cálculo del recupero de la inversión está dado en la

17
determinación de los ingresos a los que se arribará como resultado de la implementación de la
solución (que podrán ser ingresos reales o disminución de costos).

Los ingresos que se generen por la implementación de una solución de este tipo dependerán muy
fuertemente del nivel de las decisiones que se tomen al usar la información que les brindará. Es
decir, en gran parte por la capacidad de los decisores que la usen. Es por ello, que será
sumamente difícil estimar los ingresos al inicio del proyecto, pero inclusive igual grado de dificultad
podrá tener su determinación al final del mismo, donde si bien se podrán observar nuevos ingresos
desde su implementación, habrá que determinar cuantos de ellos son asignables a la información
obtenida por los decisores.

No obstante lo dicho, creo que igualmente debe justificarse económicamente un proyecto de esta
naturaleza, dejando claro que la misma estará muy lejos de ser exacta. Es decir, que por un lado
se deben estimar los costos y por otro lado ejemplificar que tipo de decisiones debería permitir esta
solución para lograr los ahorros o ingresos que lo justifiquen.

Para esquematizar los tipos de decisiones conviene dividirlas entre ingresos duros (reducción de
costos, retención de clientes, adquisición de nuevos clientes, aumento de la porción del mercado,
etc.) e ingresos blandos (aumento de la satisfacción del cliente, empleados más satisfechos,
empleados con mayor autonomía, aumento de la imagen organizacional, etc.).

5.7. Que se use la solución: todo un desafío.

Como en tantos otros proyectos de TI, la construcción es relativamente fácil en relación a lo difícil
que puede ser que el producto desarrollado finalmente se use y que le brinde beneficios a la
organización usuaria.

Las soluciones que aquí se plantean, no son la excepción a este comentario, e inclusive tener que
trabajar con los niveles altos de una organización los convierte en proyectos más vulnerables.
Estos usuarios suelen ser más complicados que el resto, dado el poco tiempo que están
dispuestos a destinar, lo poco dispuestos que se encuentran para acatar instrucciones o recibir
capacitación.

Para lograr una buena implementación hay que conseguir que desde el inicio los potenciales
usuarios entiendan y “comprendan” los beneficios que les proveerá la solución. Otro aspecto
relevante es comenzar a pensar en la implementación desde las etapas iniciales de la
construcción. En este sentido se debe generar una relación con los usuarios, durante el desarrollo,
pensando en la implementación. Por ejemplo, considerando sus decisiones de diseño, sus

18
opiniones y haciéndolos sentir en todo momento que el proyecto es suyo.

Los proyectos de data warehouse / business intelligence suelen destinar mucho tiempo para
resolver los aspectos tecnológicos, sin hacer lo propio en las tareas que permitan una adecuada
implementación. Esto se debe a que en muchas ocasiones pareciera que es posible desarrollar la
solución sin la participación de los usuarios, y que, como se dijo antes, muchos usuarios dado su
escaso tiempo prefieren que avancen sin ellos.

Quienes opinan que es posible llegar a un producto sin consensuar demasiado con los usuarios,
tienen razón, pero también deben entender que deberán poner en duda la factibilidad de su
implementación. En la mayoría de los casos, cuando no se involucró a los usuarios desde el
principio, no se dedica el debido tiempo para lograr una comunicación adecuada y fructífera, luego
del desarrollo ya será tarde.

La inexistencia de una adecuada comunicación es la mayor causa de los fracasos, y no la no


resolución de los aspectos técnicos del data warehouse, o de haber elegido la herramienta
informática errada. Posiblemente haya que rever las prioridades a la hora de dedicar tiempos y
recursos.

5.8. La única verdad ?

Se ha planteado al inicio de este trabajo, en “los tres problemas del OLTP”, que los sistemas
operacionales para brindar información para la toma de decisiones muchas veces tienen el
inconveniente de brindar visiones parciales y que, en muchos casos, ofrecen distintas visiones de
una misma realidad, y no es fácil determinar cual es la verdadera. Por ejemplo cuando el Gerente
de marketing dice que el importe vendido en lo que va del año es de $1.000.000, mientras que el
de Finanzas por su parte consigue información de sus sistemas por $1.250.000 y el de Ventas por
$800.000: cuál tiene razón ? cada uno está tomando decisiones para la misma empresa pero
mirando realidades distintas.

Es por ello que se plantea como una solución el data warehouse, que permite integrar en una sola
base de datos una representación integrada de la realidad de la organización. Sobre ella se
trabajará con herramientas de business intelligence que permitan a todos los decisores obtener
exactamente la misma información. Siguiendo con el caso planteado todos verían, por ejemplo,
que las ventas en el año ascendieron a $1.100.000.

No obstante lo dicho, es fundamental que quienes implementen soluciones de data warehouse /


business intelligence reflexionen que con la mera implantación de estas soluciones no

19
necesariamente se resolverá el problema original. Por el contrario podría agravarse, como suele
suceder cuando se piensa que un problema está resuelto sin que sea cierto (ya que se
despreocupa del mismo).

Por más que exista un indicador unificado, y que cualquier persona que consulte el data warehouse
obtenga el importe de $ 1.100.000 para las ventas, lo que puede no estar unificada es la
interpretación que cada decisor hace de dicho indicador. Es decir, cómo se construyó el número
mostrado (por ejemplo si incluye o no impuestos, si descuenta bonificaciones o promociones, si
incluye los productos discontinuados, etc.). Según la compresión que haga el decisor de dicho
indicador es la decisión que finalmente tomará, y esto es lo que realmente importa.

En el ejemplo (importe vendido) es una variable bastante sencilla, mucho peor será en otras de
construcción más ambigua, como sería la rentabilidad, el valor de un cliente, etc. Es por ello que si
se desea mejorar la percepción unificada de la realidad, por parte de los distintos decisores de la
organización, será deseable incorporar explicaciones accesible por los usuarios acerca de su
significado (ello incluye describir como se calculan dichas variables).

6. Conclusión

Mucho se ha dicho y escrito sobre las falencias que existen en las organizaciones, a la hora de
obtener información adecuada para la toma de decisiones, sobre los aportes que pueden hacer en
este sentido las soluciones de business intelligence (y los data warehouse) y sobre las formas que
deben asumir dichas tecnologías. Pero quienes deben encarar estos proyectos, muchas veces, no
comprenden en profundidad los problemas con los que se enfrentan e intentan simplemente
implantar una tecnología, desconociendo temas que exceden dichas fronteras, y ameritan análisis,
estudio y reflexión de una problemática compleja.

Este trabajo, así como la publicación en la que este autor está trabajando, intentan abordar este
camino, a la espera de generar alertas y disparadores para futuros debates, que nos permitan
mejorar las soluciones que las organizaciones necesitan, para que buenas decisiones en
tecnología implique buenas decisiones de negocio.

20
Bibliografía:

• Silberschatz, Korth, Sdarshan. “Fundamentos de Bases de datos”. Quinta Edición. Mc


Graw Hill. Madrid, 2006.
• Thomas M. Connolly, Carolyn E. Begg. “Sistemas de bases de datos”, Cuarta edición.
Pearson Educación. Madrid, 2005.
• Jose Hernández Orallo, M. José Ramírez Quintana, César Ferri Ramírez. “Introducción a la
Minería de Datos”. Pearson Educación. Madrid, 2004.
• Elizabeth Vitt , Michael Luckevich, Stacia Mister. “Business Intelligence, técnicas de
análisis para la toma de decisiones estratégicas”. Mc Graw Hill. 2003
• Ralph Kimball, Margy Ross. “The Data Warehouse Toolkit", Segunda edición. Wiley, EEUU
2002.
• Kenneth C. Laudon, Jane P. Laudon. “Sistemas de Información Gerencial”, Sexta edición.
Pearson Education. Mexico, 2002.
• Robert Kaplan, David Norton. “Cuadro de Mando Integral (The balance scorecard)”.
Gestión 2000. Barcelona, 2002.
• Effy Oz. “Administración de sistemas de información”, Segunda edición. Thomson. 2001.
• Jill Dyché. “E-data” Prentince Hall. Buenos Aires, 2001.
• Jean-Michel Franco, EDS-Institut Prometheus. “El Data Warehouse. El Data Mining”.
Gestión 2000. Barcelona, 1997.
• Harjinder S. Gill, Prakash C. Rao. “Data Warehousing. La integración de información para
lamedor toma de decisiones”. Pretince Hall. México, 1996.
• William H. Inmon. "Building the Data Warehouse". Wiley, EEUU 1992.

ACTIVIDADES

Con sus propias palabras describa los problemas de los sistemas operacionales y
justifique porqué son resueltos con las herramientas de data warehouse y business
intelligence.

Con sus propias palabras describa qué es un data warehouse, datamart y business
intelligence. Cuáles son sus aplicaciones en un entorno de negocios ?

Cómo puede justificar proyectos de data warehouse y business intelligence

21