1

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.

2

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,

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

3

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.

4

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

5

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

6

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

7

INFO R M A CIO N P A RA

LA TO M A D E DE CIS IO NES

C om prasVentas

S ucursa l Bs.As.

V entasSucursal Córdoba

N ivel O perativo

N ive l Táctico

N ive l Estratég ico

M arketing

P roducc iónV entas

Sucursal Córdoba ...

D A TA

W A R E H O U S E

D atam in ingO LAP

Tableros

R eporting...

H erram ientas de B I

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

8

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.

9

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

planos) que se extraerán mediante los correspondientes ETL2 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.

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

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.

Sistema operacional A

Sistema operacional B

Sistema operacional N

Datos Externos

Datos Internos no Sistematizados

Fuentes de datos Área del Data warehouse

Area de trabajo

Data warehouse detallado u “objetivo”

Data warehouse agregado o “subjetivo”

Extracción

Transformación

Datamart A Datamart B Datamart N

Carga (Load)

T, L

Análisis Multidimensional

Datamining Tablero de

comando. Balance scorecard Alertas Reporting Etc.

A

B

C

Herramientas de acceso y exploración

10

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.

11

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,

12

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.

13

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.

14

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.

Análisis de las necesidades de información

Alcance

Formalizar datos existentes

Necesidades de información

Diseño del data warehouse

15

Efecto que causa en las bases de datos. Características de la redundancia en las bases de datos

Base de datos OLTP Data warehouse

a. Acelerar consultas con datos precalculados

En la mayoría de los sistemas no es un beneficio significativo, debido a que la mayoría de las consultas, son sobre una cantidad de registros pequeña.

Es un beneficio significativo por que el objetivo es realizar consultas a grandes porciones de la base de datos, que en caso de estar precalculados, permite evitar recorrer todos los registros desagregados.

b. Demora la actualización de los datos, al guardar en forma redundante datos calculables (datos precalculados).

Es un perjuicio significativo, ya que en la mayoría de los sistemas la actualización es en línea, conllevando demoras en la misma. Por lo que está íntimamente relacionado con la eficiencia de las operaciones (como por ejemplo la línea de caja).

No es un perjuicio significativo, ya que en la mayoría de los casos la actualización es “batch” y no trae mayores problemas una demora en dicho proceso.

c. Existe mayor probabilidad de generar inconsistencias.

Es un perjuicio significativo, ya que existe la posibilidad de que se actualicen los datos correspondientes a una transacción en forma incompleta.

No es un perjuicio significativo, dado que los datos son una copia de otra base de datos, que contiene a los 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 controles.

Pude ser un beneficio y un perjuicio significativo a la vez. Puede ser una herramienta muy importante para insertar controles que mejoren la confiabilidad de los datos almacenados (digito verificador, totales de control, registros duplicados en distintos servidores, etc), pero por el otro lado tiene los mismos perjuicios que los vistos en el retraso de la actualización.

No es significativo, ya que la actualización está controlada desde el ETL y se está realizando una copia de los sistemas transaccionales donde deberían estar dichos controles.

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

16

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

17

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

18

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

19

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

20

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.

21

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