BUSINESS INTELLIGENCE

Junio 2013



Agradecemos a nuestras familias el
apoyo incondicional que nos brindan
para alcanzar nuestros objetivos.

INDICE

RESUMEN .................................................................................................................................................6
SUMMARY ................................................................................................................................................7
INTRODUCCION ........................................................................................................................................8
ANTECEDENTES ........................................................................................................................................9
HISTORIA DE LA INTELIGENCIA DE NEGOCIOS .....................................................................................9
FECHAS SIGNIFICATIVAS EN EL DESARROLLO DEL BUSINESS INTELLIGENCE .................................... 10
DATOS, INFORMACIN, CONOCIMIENTO ......................................................................................... 11
Datos ............................................................................................................................................ 11
Informacin .................................................................................................................................. 12
Conocimiento .............................................................................................................................. 12
BUSINESS INTELLIGENCE ....................................................................................................................... 14
QUE ES EL BUSINESS INTELLIGENCE .................................................................................................. 14
Qu aporta una solucin de Business Intelligence? ............................................................. 15
DATAWAREHOUSE ......................................................................................................................... 17
DEFINICIONES. ............................................................................................................................. 17
LOS DATAMARS ........................................................................................................................... 19
LOS CUBOS DE INFORMACION ............................................................................................... 19
ELEMENTOS DE UN DATAWAREHOUSE .............................................................................. 20
Metadatos ................................................................................................................................... 20
Funciones ETL .............................................................................................................................. 21
Middleware ................................................................................................................................. 23
DISEO DE UN DATAWAREHOUSE ....................................................................................... 24
DATAWAREHOUSE ESPACIAL ................................................................................................ 25
CONDICIONES IMPORTANTES PARA CREAR UN DATAWAREHOUSE ................................................ 26
Cmo saber si su empresa necesita una solucin BI? ...................................................... 29
DATAMART ........................................................................................................................................ 31
DEFINICION .................................................................................................................................... 31
DEPENDENCIA DE UN DATAMART......................................................................................... 31
CONCEPTOS ERRONEOS SOBRE LOS DATAMART ......................................................... 32
TIPOS DE DATAMART ........................................................................................................................ 33
Datamart OLAP ........................................................................................................................... 33
Datamart OLTP ........................................................................................................................... 33
VENTAJAS DE LOS DATAMART .............................................................................................. 34
BASES DE DATOS OLTP Y OLAP ............................................................................................ 34
OLTP - On-Line Transactional Processing ............................................................................. 34
OLAP - On-Line Analytical Processing ................................................................................... 34
LOS CUBOS DE INFORMACION ................................................................................................... 36
PERSISTENCIA MOLAP, ROLAP, HOLAP ............................................................................................. 36
Sistemas MOLAP ....................................................................................................................... 37
Sistemas ROLAP ........................................................................................................................ 38
Sistemas MOLAP ....................................................................................................................... 39
CUADRO DE MANDO INTEGRAL ................................................................................................. 40
PERSPECTIVAS ................................................................................................................................... 41
Perspectiva financiera................................................................................................................ 41
Perspectiva del cliente ............................................................................................................... 41
Perspectiva de procesos ........................................................................................................... 42
Perspectiva del desarrollo de las personas y el aprendizaje ............................................... 43
CARACTERISTICAS DEL CUADRO DE MANDO .................................................................................... 44
Elaboracin y contenido del cuadro de mando ...................................................................... 45
Elaboracin del Cuadro de Mando ................................................................................................ 46
PROYECTOS EN INTELIGENCIA DE NEGOCIOS ..................................................................... 49
POR QUE FALLAN LOS PROYECTOS DE INTELIGENCIA DE NEGOCIOS ................... 49
CONCLUSIONES ..................................................................................................................................... 51
Referencias bibliogrficas ................................................................................................................. 53
Referencias electrnicas ................................................................................................................... 53
ANEXOS ................................................................................................................................................. 55
ANEXO N 1. EFECTO DE IMPLEMENTAR BI ...................................................................................... 55
ANEXO N 2. Arquitectura de Datawarehouse. ................................................................................ 56
ANEXO N 3. Cubo de Informacion ................................................................................................... 57
ANEXO N 4. Datos-Informacion-Conocimiento ................................................................................... 58




6
RESUMEN

Se denomina inteligencia empresarial, inteligencia de negocios o BI (del ingls
business intelligence) al conjunto de estrategias y herramientas enfocadas a la
administracin y creacin de conocimiento mediante el anlisis de datos existentes
en una organizacin o empresa.
Business Intelligence persigue incrementar el rendimiento de la empresa o la
competitividad del negocio, a travs de la organizacin inteligente de sus datos
histricos (transacciones u operaciones diarias), usualmente residiendo en Data
Warehouse corporativos o Data Marts departamentales.
El concepto de BI no es nuevo, desde que la idea fue introducida a mediados de los
aos 60, no ha dejado de evolucionar a soluciones ms efectivas y adaptadas al
nuevo entorno tecnolgico imperante.
Entre las principales razones que justifican una inversin en BI se pueden sealar:
Visibilidad de lo que est pasando en el negocio
Informes / reportes centralizados
Anlisis de tendencias y prediccin del futuro
Toma de decisiones efectivas sobre productos que funcionan y lo que no
funcionan
Centraliza datos dispersos
Valida sistemas transaccionales

El xito de BI no depende solamente del diseo de la aplicacin. Tampoco depende
nicamente del resultado de las consultas y de la generacin de informes. Depende
de una cadena de aplicaciones y tecnologas que trabajan juntas desde la capa de
datos para crear una versin comprobable y verificable de la realidad.







7
SUMMARY

It's called business intelligence, business intelligence or BI (business intelligence
English) the set of strategies and tools focused on knowledge creation and
management through the analysis of existing data in an organization or company.
Business Intelligence aims to increase the performance of the company or business
competitiveness through intelligent organization historical data (transactions or daily
operations), usually residing in Data Warehouse Data Marts corporate or
departmental.
The BI concept is not new, since the idea was introduced in the mid-60s, has
continued to evolve effective solutions adapted to the new technological environment
prevailing.
Among the main reasons for investing in BI can be noted:
visibility of what's happening in business
Reports / centralized reporting
Analysis of trends and "prediction" of the future
Making effective decisions about products that work and what does not work
centralizes disparate data
"Validates" transactional systems

BI's success depends not only on application design. Nor only depend on the
outcome of the consultation and reporting. It depends on a chain of applications and
technologies working together from the data layer to create a testable and verifiable
version of reality.




8
INTRODUCCION


La presente monografa tiene como finalidad el entender el impacto de las
tecnologas propias de la inteligencia de negocios y su aplicacin en las empresas.
El xito de una empresa depende en gran medida de una rpida y eficiente toma de
decisiones, sin embargo las aplicaciones y sistemas de bases de datos tradicionales
no tienen el potencial suficiente para extraer el conocimiento necesario para dicha
toma de decisiones. La Inteligencia de Negocios (Business Intelligence) combina un
conjunto de tcnicas y herramientas que.posibilitan el almacenamiento, recuperacin
y anlisis de los datos de forma rpida y flexible con el fin de apoyar a directivos y
usuarios en la toma de decisiones.
La presente monografa tiene como finalidad el comprender concepto de Inteligencia
de Negocios como estrategia empresarial que persigue incrementar el rendimiento
de la empresa o la competitividad del negocio, a travs de la organizacin inteligente
de sus datos histricos (transacciones u operaciones diarias), usualmente residiendo
en Data Warehouse corporativos o Data Marts departamentales.









9
ANTECEDENTES

HISTORIA DE LA INTELIGENCIA DE NEGOCIOS
La mayora de los expertos consideran que la investigacin moderna en este campo
nace a raz de la Segunda Guerra Mundial donde se conformaron equipos
multidisciplinares para que abordaran con una visin integral una amplia diversidad
de problemas estratgicos, logsticos y tcticos que enfrentaban las fuerzas
armadas.
Sin embargo existen evidencias que certifican que ya a principios del siglo XX la
revolucin de la administracin cientfica, iniciada por Frederic W. Taylor, sent las
bases para el uso de mtodos cuantitativos en la toma de decisiones.
La inteligencia de negocios es un tema que se viene tratando desde los aos 50,
cuando Hans Peter Luhn cientfico de IBM, escribi un artculo donde hablaba de un
sistema dedicado a la Inteligencia de Negocios , entonces pensar en que BI es algo
nuevo no tiene sentido. Vamos a realizar un recuento de los principales hecho y
descubrimientos que permitieron llegar al punto donde nos encontramos hoy en da
para utilizar la informacin para los negocios.
El concepto de BI no es nuevo, desde que la idea fue introducida a mediados de los
aos 60, no ha dejado de evolucionar a soluciones ms efectivas y adaptadas al
nuevo entorno tecnolgico imperante. Con el precio del hardware en franco
descenso, procesadores ms potentes, la hegemona de Internet-Web y software de
gestin ms eficientes, el concepto de inteligencia de negocio (BI) se coloca al
alcance de muchas organizaciones modernas quienes estn interesadas en
maximizar sus inversiones en el rea informtica.
El DSS (Decision Support Systems) fue el origen de todo, luego aparecieron
conceptos similares tales como los EIS (Executive Information Suystems), hasta
llegar al estado del arte actual, los BIs y BI-Web.
Antes del ao 1969, se trabajaba con la informacin guardada en archivadores,
existan cuartos repletos de carpetas con diversos tipos de datos, en ocasiones la
informacin no tena sentido, o era fcilmente modificable o desapareca porque s.
Al tener ese escenario el manejo de la informacin era realmente complejo. En la
dcada del sesenta con la aparicin del computador, tambin surgieron las bases de
datos, creadas por el Edgar Frank Codd, lo cual cambio el paradigma de trabajar con



10
la informacin, cambio el concepto de guardar la informacin en carpetas y se pas
a guardar la informacin en el computador.
Con la invencin de Codd, a principios de la dcada del 70 varias empresas (SAP,
JD Edwards, Siebel, PeopleSoft) empezaron a crear aplicaciones empresariales y
sacar provecho de las bases de datos que algunas empresas empezaron a utilizar,
pero estas primeras aplicaciones tenan el grave problema de que no tenan un
acceso rpido y fcil a los datos contenidos en las bases de datos.
En los aos 80, por primera vez aparece el termino Datawarehouse desarrollado por
Ralph Kimball y Bill Inmon y los primeros sistemas (SAP) que podan generar
reportes para el usuario, pero segua siendo algo difcil de utilizar por parte de los
usuarios finales y surgi un nuevo problema, potentes sistemas de bases de datos
sin aplicativos que permitieran una fcil explotacin de las mismas.


FECHAS SIGNIFICATIVAS EN EL DESARROLLO DEL BUSINESS
INTELLIGENCE

1969: Creacin del concepto de base de datos (Codd)
1970s: Desarrollo de las primeras bases de datos y las primeras aplicaciones
empresariales (SAP, JD Edwards, Siebel, PeopleSoft). Estas aplicaciones
permitieron realizar data entry en los sistemas, aumentando la informacin
disponible, pero no fueron capaces de ofrecer un acceso rpido y fcil a dicha
informacin.
1980s: Creacin del concepto Datawarehouse (Ralph Kimball, Bill Inmon), y
aparicin de los primeros sistemas de reporting. A pesar de todo, segua siendo
complicado y funcionalmente pobre. Existan relativamente potentes sistemas de
bases de datos pero no haba aplicaciones que facilitasen su explotacin.
1989: Introduccin del trmino Business Intelligence (Howard Dresner).Ejem.
1990s: Business Intelligence 1.0. Proliferacin de mltiples aplicaciones BI. Estos
proveedores resultaban caros, pero facilitaron el acceso a la informacin, y en



11
cierto modo agravaron el problema que pretendan resolver (Haba an ms
versiones de la verdad!)
2000s: Business Intelligence 2.0. Consolidacin de las aplicaciones BI en unas
pocas plataformas Business Intelligence (Oracle, SAP, IBM, Microsoft). A parte
de la informacin estructurada, se empieza a considerar otro tipo de informacin
y documentos no estructurados.

DATOS, INFORMACIN, CONOCIMIENTO
En qu se diferencia el conocimiento de los datos y de la informacin? En una
conversacin informal, los tres trminos suelen utilizarse indistintamente y esto
puede llevar a una interpretacin libre del concepto de conocimiento. Quizs la forma
ms sencilla de diferenciar los trminos sea pensar que los datos estn localizados
en el mundo y el conocimiento est localizado en agentes de cualquier tipo
(personas, empresas, mquinas...), mientras que la informacin adopta un papel
mediador entre ambos.
Los conceptos que se muestran a continuacin se basan en las definiciones de
Davenport y Prusak (1999).

Datos
Los datos son la mnima unidad semntica, y se corresponden con elementos
primarios de informacin que por s solos son irrelevantes como apoyo a la toma de
decisiones. Tambin se pueden ver como un conjunto discreto de valores, que no
dicen nada sobre el porqu de las cosas y no son orientativos para la accin.
Un nmero telefnico o un nombre de una persona, por ejemplo, son datos que, sin
un propsito, una utilidad o un contexto no sirven como base para apoyar la toma de
una decisin. Los datos pueden ser una coleccin de hechos almacenados en algn
lugar fsico como un papel, un dispositivo electrnico (CD, DVD, disco duro...), o la
mente de una persona. En este sentido las tecnologas de la informacin han
aportado mucho a recopilacin de datos.



12
Como cabe suponer, los datos pueden provenir de fuentes externas o internas a la
organizacin, pudiendo ser de carcter objetivo o subjetivo, o de tipo cualitativo o
cuantitativo, etc.

Informacin
La informacin se puede definir como un conjunto de datos procesados y que tienen
un significado (relevancia, propsito y contexto), y que por lo tanto son de utilidad
para quin debe tomar decisiones, al disminuir su incertidumbre. Los datos se
pueden transforman en informacin aadindoles valor:
Contextualizando: se sabe en qu contexto y para qu propsito se generaron.
Categorizando: se conocen las unidades de medida que ayudan a interpretarlos.
Calculando: los datos pueden haber sido procesados matemtica o
estadsticamente.
Corrigiendo: se han eliminado errores e inconsistencias de los datos.
Condensando: los datos se han podido resumir de forma ms concisa
(agregacin).
Por tanto, la informacin es la comunicacin de conocimientos o inteligencia, y es
capaz de cambiar la forma en que el receptor percibe algo, impactando sobre sus
juicios de valor y sus comportamientos.

Informacin = Datos + Contexto (aadir valor) + Utilidad (disminuir la incertidumbre)

Conocimiento
El conocimiento es una mezcla de experiencia, valores, informacin y know-how que
sirve como marco para la incorporacin de nuevas experiencias e informacin, y es
til para la accin. Se origina y aplica en la mente de los conocedores. En las
organizaciones con frecuencia no slo se encuentra dentro de documentos o
almacenes de datos, sino que tambin est en rutinas organizativas, procesos,
prcticas, y normas.



13
El conocimiento se deriva de la informacin, as como la informacin se deriva de los
datos. Para que la informacin se convierta en conocimiento es necesario realizar
acciones como:
Comparacin con otros elementos.
Prediccin de consecuencias.
Bsqueda de conexiones.
Conversacin con otros portadores de conocimiento.





14
BUSINESS INTELLIGENCE

QUE ES EL BUSINESS INTELLIGENCE
Se denomina inteligencia empresarial, inteligencia de negocios o BI (del ingls
business intelligence) al conjunto de estrategias y herramientas enfocadas a la
administracin y creacin de conocimiento mediante el anlisis de datos existentes
en una organizacin o empresa.
Este trmino no tiene nada que ver con el ndice de inteligencia medio de las
personas que trabajan en un determinado negocio. De hecho, (BI) tiene que ver con
los datos y aplicaciones de un negocio para entenderse mejor.
Semejante a la inteligencia militar, que procura entender al enemigo, la inteligencia
de negocio versa sobre todo alrededor de s mismo.
Especficamente, los sistemas de la inteligencia de negocio se basan en crear
modelos informticos de negocio de modo que pueda funcionar ms eficientemente.
El almacenamiento de los datos est en la base de los procesos de la inteligencia de
negocio. En el mundo de ETL, la inteligencia de negocio se refiere generalmente al
espacio entero de los sistemas de la base de datos, del software, del anlisis, y de la
evaluacin del usuario que pretende entender y evaluar un negocio.
Hay generalmente unos o ms usos analticos del software (por ejemplo, Business
Objects, Cognos, o Microstrategy ).
Los sistemas del BI se diferencian de sistemas operacionales en que estn
optimizados para preguntar y divulgar sobre datos.
Esto significa tpicamente que, en un Datawarehouse, los datos estn
desnormalizados para apoyar preguntas de alto rendimiento, mientras que los
sistemas operacionales generalmente se normalizan completamente para apoyar
integridad de referencia y para insertar datos continuamente.
Los procesos de ETL que cargan sistemas del BI tienen que traducir del sistema
operacional normalizado a desnormalizado.
Y, tpicamente, tienen fallos severos de funcionamiento debido a que no deben
degradar el funcionamiento de los sistemas operacionales, y no deben prohibir el
acceso al almacn.



15
Por eso surge el Business Intelligence, basado en nuevas estructuras de anlisis,
bsicamente multidimensional, en contraste con el relacional.

Qu aporta una solucin de Business Intelligence?
Cualquier persona con cierto grado de responsabilidad en su empresa es
conocedora de la ingente cantidad de datos con los que cuenta su compaa. Estos
datos, relevantes para el buen funcionamiento de la misma, son manejados,
manipulados y traspasados de un compaero a otro, de unos departamentos a otros,
a travs de cientos de Excels, PDF o Words que cada uno de nosotros apilamos en
nuestros PCs de forma local y que compartimos mediante email que se pierden en el
olvido.
Gran parte de nuestro tiempo lo perdemos enfrentndonos a un maremgnum de
datos que hemos de localizar, unir y verificar.
Hoy en da, tanto las multinacionales como las PYMES, cuentan en el mercado con
soluciones de Business Intelligence que ayudan a resolver este problema, y facilitan
el acceso a la informacin y por tanto a la toma de decisiones. Veamos algunos de
los beneficios que aportan estas soluciones de Business Intelligence:
Facilita la recogida y validacin diaria de la informacin: Todos los das el sistema
carga los datos que cada departamento haya generado.
Posibilita el control y comunicacin interdepartamental: La informacin agregada
diariamente es traducida a lenguaje de negocio y se hace visible y accesible a
todos los miembros de la organizacin. Obviamente cada usuario tendr acceso
y visibilidad nicamente a la informacin que necesita.
Ofrece informacin en tiempo real sobre el estado de la empresa: lo que nos
permite tomar decisiones acertadas y en base a la realidad presente de la
compaa.
Permite realizar simulaciones What if, pudiendo dar respuesta a preguntas
como: Qu necesitar si consigo ms clientes? Qu ocurrir si pierdo a mi
mejor cliente? Esto nos permitir adelantarnos a las posibles necesidades o
problemticas que el mercado nos plantee y nos facilitar la adopcin de
respuestas ms agiles, rpidas y acertadas. As, nos ahorramos sorpresas de
ltima hora.



16
Facilita la toma de decisiones: dispondrs en todo momento de informacin
actualizada.
Mejora de la calidad del dato al eliminar o reducir el tratamiento manualm de la
informacin. No dependemos del factor humano para la recogida de la
informacin, que se realiza de manera automtica.
Permite valorar si la estrategia empresarial es la adecuada e introducir los
cambios necesarios en funcin de los resultados: al disponer de informacin
fiable, los cambios o necesidades del mercado sern afrontados y gestionados
diariamente, lo que permite dar una respuesta rpida y altamente competitiva.
Ahorro de costes.
Unin interdepartamental: toda la empresa ir en la misma direccin, hablar
el mismo lenguaje y dispondr de la misma informacin.





17
DATAWAREHOUSE

En el contexto de la informtica, un almacn de datos (del ingls data warehouse) es
una coleccin de datos orientada a un determinado mbito (empresa, organizacin,
etc.), integrado, no voltil y variable en el tiempo, que ayuda a la toma de decisiones
en la entidad en la que se utiliza. Se trata, sobre todo, de un expediente completo de
una organizacin, ms all de la informacin transaccional y operacional,
almacenado en una base de datos diseada para favorecer el anlisis y la
divulgacin eficiente de datos (especialmente OLAP, procesamiento analtico en
lnea). El almacenamiento de los datos no debe usarse con datos de uso actual. Los
almacenes de datos contienen a menudo grandes cantidades de informacin que se
subdividen a veces en unidades lgicas ms pequeas dependiendo del subsistema
de la entidad del que procedan o para el que sea necesario.
Los avances en las Tecnologas de Informacin, ofrecen herramientas de gran
capacidad que se han desarrollado como aplicaciones de soporte para la toma de
decisiones, en diversos niveles de las organizaciones, generando conocimiento,
base para la Inteligencia del Negocio. La gestin del Conocimiento, desarrolla las
competencias centrales en las organizaciones.

DEFINICIONES.
El Datawarehouse presenta diferentes definiciones de las cuales algunas de las ms
importantes son:
Bill Inmon fue uno de los primeros autores en escribir sobre el tema de los
almacenes de datos, define un data warehouse (almacn de datos) en trminos de
las caractersticas del repositorio de datos:
Orientado a temas.- Los datos en la base de datos estn organizados de manera
que todos los elementos de datos relativos al mismo evento u objeto del mundo
real queden unidos entre s.
Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo
quedan registrados para que los informes que se puedan generar reflejen esas
variaciones.



18
No voltil.- La informacin no se modifica ni se elimina, una vez almacenado un
dato, ste se convierte en informacin de slo lectura, y se mantiene para futuras
consultas.
Integrado.- La base de datos contiene los datos de todos los sistemas
operacionales de la organizacin, y dichos datos deben ser consistentes.
Inmon defiende una metodologa descendente (top-down) a la hora de disear un
almacn de datos, ya que de esta forma se considerarn mejor todos los datos
corporativos. En esta metodologa los Data marts se crearn despus de haber
terminado el data warehouse completo de la organizacin.
Ralph Kimball es otro conocido autor en el tema de los data warehouse, define un
almacn de datos como: "una copia de las transacciones de datos especficamente
estructurada para la consulta y el anlisis". Tambin fue Kimball quien determin que
un data warehouse no era ms que: "la unin de todos los Data marts de una
entidad". Defiende por tanto una metodologa ascendente (bottom-up) a la hora de
disear un almacn de datos.
Las definiciones anteriores se centran en los datos en s mismos. Sin embargo, los
medios para obtener esos datos, para extraerlos, transformarlos y cargarlos, las
tcnicas para analizarlos y generar informacin, as como las diferentes formas para
realizar la gestin de datos son componentes esenciales de un almacn de datos.
Muchas referencias a un almacn de datos utilizan esta definicin ms amplia. Por lo
tanto, en esta definicin se incluyen herramientas para extraer, transformar y cargar
datos, herramientas para el anlisis (inteligencia empresarial) y herramientas para
gestionar y recuperar los metadatos.

FUNCION DE UN DATAWAREHOUSE
En un almacn de datos lo que se quiere es contener datos que son necesarios o
tiles para una organizacin, es decir, que se utiliza como un repositorio de datos
para posteriormente transformarlos en informacin til para el usuario. Un almacn
de datos debe entregar la informacin correcta a la gente indicada en el momento
ptimo y en el formato adecuado. El almacn de datos da respuesta a las
necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones
(DSS), Sistemas de informacin ejecutiva (EIS) o herramientas para hacer consultas



19
o informes. Los usuarios finales pueden hacer fcilmente consultas sobre sus
almacenes de datos sin tocar o afectar la operacin del sistema.
En el funcionamiento de un almacn de datos son muy importantes las siguientes
ideas:
Integracin de los datos provenientes de bases de datos distribuidas por las
diferentes unidades de la organizacin y que con frecuencia tendrn
diferentes estructuras (fuentes heterogneas). Se debe facilitar una
descripcin global y un anlisis comprensivo de toda la organizacin en el
almacn de datos.
Separacin de los datos usados en operaciones diarias de los datos usados
en el almacn de datos para los propsitos de divulgacin, de ayuda en la
toma de decisiones, para el anlisis y para operaciones de control. Ambos
tipos de datos no deben coincidir en la misma base de datos, ya que
obedecen a objetivos muy distintos y podran entorpecerse entre s.
Peridicamente, se importan datos al almacn de datos de los distintos sistemas de
planeamiento de recursos de la entidad (ERP) y de otros sistemas de software
relacionados con el negocio para la transformacin posterior. Es prctica comn
normalizar los datos antes de combinarlos en el almacn de datos mediante
herramientas de extraccin, transformacin y carga (ETL). Estas herramientas leen
los datos primarios (a menudo bases de datos OLTP de un negocio), realizan el
proceso de transformacin al almacn de datos (filtracin, adaptacin, cambios de
formato, etc.) y escriben en el almacn.

LOS DATAMARS
Los Data marts son subconjuntos de datos de un data warehouse para reas
especficas.
Entre las caractersticas de un data mart destacan:
Usuarios limitados.
rea especfica.
Tiene un propsito especfico.
Tiene una funcin de apoyo.

LOS CUBOS DE INFORMACION



20
Los cubos de informacin o cubos OLAP funcionan como los cubos de
rompecabezas en los juegos, en el juego se trata de armar los colores y en el data
warehouse se trata de organizar los datos por tablas o relaciones; los primeros (el
juego) tienen 3 dimensiones, los cubos OLAP tienen un nmero indefinido de
dimensiones, razn por la cual tambin reciben el nombre de hipercubos. Un cubo
OLAP contendr datos de una determinada variable que se desea analizar,
proporcionando una vista lgica de los datos provistos por el sistema de informacin
hacia el data warehouse, esta vista estar dispuesta segn unas dimensiones y
podr contener informacin calculada. El anlisis de los datos est basado en las
dimensiones del hipercubo, por lo tanto, se trata de un anlisis multidimensional.
A la informacin de un cubo puede acceder el ejecutivo mediante "tablas dinmicas"
en una hoja de clculo o a travs de programas personalizados. Las tablas
dinmicas le permiten manipular las vistas (cruces, filtrados, organizacin, totales)
de la informacin con mucha facilidad. Las diferentes operaciones que se pueden
realizar con cubos de informacin se producen con mucha rapidez. Llevando estos
conceptos a un data warehouse, ste es una coleccin de datos que est formada
por dimensiones y variables, entendiendo como dimensiones a aquellos
elementos que participan en el anlisis y variables a los valores que se desean
analizar.

ELEMENTOS DE UN DATAWAREHOUSE

Metadatos
Uno de los componentes ms importantes de la arquitectura de un almacn de datos
son los metadatos. Se define comnmente como "datos acerca de los datos", en el
sentido de que se trata de datos que describen cul es la estructura de los datos que
se van a almacenar y cmo se relacionan.
El metadato documenta, entre otras cosas, qu tablas existen en una base de datos,
qu columnas posee cada una de las tablas y qu tipo de datos se pueden
almacenar. Los datos son de inters para el usuario final, el metadato es de inters
para los programas que tienen que manejar estos datos. Sin embargo, el rol que
cumple el metadato en un entorno de almacn de datos es muy diferente al rol que
cumple en los ambientes operacionales. En el mbito de los data warehouse el



21
metadato juega un papel fundamental, su funcin consiste en recoger todas las
definiciones de la organizacin y el concepto de los datos en el almacn de datos,
debe contener toda la informacin concerniente a:
Tablas
Columnas de tablas
Relaciones entre tablas
Jerarquas y Dimensiones de datos
Entidades y Relaciones

Funciones ETL
Los procesos de extraccin, transformacin y carga (ETL) son importantes ya que
son la forma en que los datos se guardan en un almacn de datos (o en cualquier
base de datos). Implican las siguientes operaciones:
Extraccin. Accin de obtener la informacin deseada a partir de los datos
almacenados en fuentes externas.
La primera parte del proceso ETL consiste en extraer los datos desde los sistemas
de origen. La mayora de los proyectos de almacenamiento de datos fusionan datos
provenientes de diferentes sistemas de origen. Cada sistema separado puede usar
una organizacin diferente de los datos o formatos distintos. Los formatos de las
fuentes normalmente se encuentran en bases de datos relacionales o ficheros
planos, pero pueden incluir bases de datos no relacionales u otras estructuras
diferentes. La extraccin convierte los datos a un formato preparado para iniciar el
proceso de transformacin.
Una parte intrnseca del proceso de extraccin es la de analizar los datos extrados,
de lo que resulta un chequeo que verifica si los datos cumplen la pauta o estructura
que se esperaba. De no ser as los datos son rechazados.
Un requerimiento importante que se debe exigir a la tarea de extraccin es que sta
cause un impacto mnimo en el sistema origen. Si los datos a extraer son muchos, el
sistema de origen se podra ralentizar e incluso colapsar, provocando que ste no
pueda utilizarse con normalidad para su uso cotidiano. Por esta razn, en sistemas
grandes las operaciones de extraccin suelen programarse en horarios o das donde
este impacto sea nulo o mnimo.




22
Transformacin. Cualquier operacin realizada sobre los datos para que puedan
ser cargados en el data warehouse o se puedan migrar de ste a otra base de datos.
La fase de transformacin aplica una serie de reglas de negocio o funciones sobre
los datos extrados para convertirlos en datos que sern cargados. Algunas fuentes
de datos requerirn alguna pequea manipulacin de los datos. No obstante en
otros casos pueden ser necesarias aplicar algunas de las siguientes
transformaciones:
Seleccionar slo ciertas columnas para su carga (por ejemplo, que las columnas
con valores nulos no se carguen).
Traducir cdigos (por ejemplo, si la fuente almacena una "H" para Hombre y "M"
para Mujer pero el destino tiene que guardar "1" para Hombre y "2" para Mujer).
Codificar valores libres (por ejemplo, convertir "Hombre" en "H" o "Sr" en "1").
Obtener nuevos valores calculados (por ejemplo, total_venta = cantidad * precio).
Unir datos de mltiples fuentes (por ejemplo, bsquedas, combinaciones, etc.).
Calcular totales de mltiples filas de datos (por ejemplo, ventas totales de cada
regin).
Generacin de campos clave en el destino.
Transponer o pivotar (girando mltiples columnas en filas o viceversa).
Dividir una columna en varias (por ejemplo, columna "Nombre: Garca Lpez,
Miguel ngel"; pasar a dos columnas "Nombre: Miguel ngel", "Apellido1: Garca"
y "Apellido2: Lpez").
La aplicacin de cualquier forma, simple o compleja, de validacin de datos, y la
consiguiente aplicacin de la accin que en cada caso se requiera:
o Datos OK: Entregar datos a la siguiente etapa (Carga).
o Datos errneos: Ejecutar polticas de tratamiento de excepciones (por
ejemplo, rechazar el registro completo, dar al campo errneo un valor nulo
o un valor centinela).

Carga. Consiste en almacenar los datos en la base de datos final, por ejemplo el
almacn de datos objetivo normal.
La fase de carga es el momento en el cual los datos de la fase anterior
(transformacin) son cargados en el sistema de destino. Dependiendo de los
requerimientos de la organizacin, este proceso puede abarcar una amplia variedad



23
de acciones diferentes. En algunas bases de datos se sobrescribe la informacin
antigua con nuevos datos. Los data warehouse mantienen un historial de los
registros de manera que se pueda hacer una auditora de los mismos y disponer de
un rastro de toda la historia de un valor a lo largo del tiempo.
Existen dos formas bsicas de desarrollar el proceso de carga:
Acumulacin simple: La acumulacin simple es la ms sencilla y comn, y
consiste en realizar un resumen de todas las transacciones comprendidas en
el perodo de tiempo seleccionado y transportar el resultado como una nica
transaccin hacia el data warehouse, almacenando un valor calculado que
consistir tpicamente en un sumatorio o un promedio de la magnitud
considerada.
Rolling: El proceso de Rolling por su parte, se aplica en los casos en que se
opta por mantener varios niveles de granularidad (jerarquas). Para ello se
almacena informacin resumida a distintos niveles, correspondientes a
distintas agrupaciones de la unidad de tiempo o diferentes niveles jerrquicos
en alguna o varias de las dimensiones de la magnitud almacenada (por
ejemplo, totales diarios, totales semanales, totales mensuales, etc.).
La fase de carga interacta directamente con la base de datos de destino. Al realizar
esta operacin se aplicarn todas las restricciones y triggers (disparadores) que se
hayan definido en sta (por ejemplo, valores nicos, integridad referencial, campos
obligatorios, rangos de valores). Estas restricciones y triggers (si estn bien
definidos) contribuyen a que se garantice la calidad de los datos en el proceso ETL,
y deben ser tomados en cuenta.

Middleware
Middleware es un trmino genrico que se utiliza para referirse a todo tipo de
software de conectividad que ofrece servicios u operaciones que hacen posible el
funcionamiento de aplicaciones distribuidas sobre plataformas heterogneas. Estos
servicios funcionan como una capa de abstraccin de software distribuida, que se
sita entre las capas de aplicaciones y las capas inferiores (sistema operativo y red).
El middleware puede verse como una capa API, que sirve como base a los
programadores para que puedan desarrollar aplicaciones que trabajen en diferentes
entornos sin preocuparse de los protocolos de red y comunicaciones en que se



24
ejecutarn. De esta manera se ofrece una mejor relacin costo/rendimiento que pasa
por el desarrollo de aplicaciones ms complejas, en menos tiempo.
La funcin del middleware en el contexto de los data warehouse es la de asegurar la
conectividad entre todos los componentes de la arquitectura de un almacn de
datos.



DISEO DE UN DATAWAREHOUSE
Para construir un Data Warehouse se necesitan herramientas para ayudar a la
migracin y a la transformacin de los datos hacia el almacn. Una vez construido,
se requieren medios para manejar grandes volmenes de informacin. Se disea su
arquitectura dependiendo de la estructura interna de los datos del almacn y
especialmente del tipo de consultas a realizar. Con este criterio los datos deben ser
repartidos entre numerosos data marts. Para abordar un proyecto de data
warehouse es necesario hacer un estudio de algunos temas generales de la
organizacin o empresa, los cuales se describen a continuacin:
Situacin actual de partida.- Cualquier solucin propuesta de data warehouse
debe estar muy orientada por las necesidades del negocio y debe ser compatible
con la arquitectura tcnica existente y planeada de la compaa.
Tipo y caractersticas del negocio.- Es indispensable tener el conocimiento exacto
sobre el tipo de negocios de la organizacin y el soporte que representa la
informacin dentro de todo su proceso de toma de decisiones.
Entorno tcnico.- Se debe incluir tanto el aspecto del hardware (mainframes,
servidores, redes,...) as como aplicaciones y herramientas. Se dar nfasis a los
Sistemas de soporte a decisiones (DSS), si existen en la actualidad, cmo
operan, etc.
Expectativas de los usuarios.- Un proyecto de data warehouse no es nicamente
un proyecto tecnolgico, es una forma de vida de las organizaciones y como tal,
tiene que contar con el apoyo de todos los usuarios y su convencimiento sobre su
bondad.
Etapas de desarrollo.- Con el conocimiento previo, ya se entra en el desarrollo de
un modelo conceptual para la construccin del data warehouse.



25
Prototipo.- Un prototipo es un esfuerzo designado a simular tanto como sea
posible el producto final que ser entregado a los usuarios.
Piloto.- El piloto de un data warehouse es el primero, o cada uno de los primeros
resultados generados de forma iterativa que se harn para llegar a la
construccin del producto final deseado.
Prueba del concepto tecnolgico.- Es un paso opcional que se puede necesitar
para determinar si la arquitectura especificada del data warehouse funcionar
finalmente como se espera.

DATAWAREHOUSE ESPACIAL
Almacn de datos espacial es una coleccin de datos orientados al tema,
integrados, no voltiles, variantes en el tiempo y que aaden la geografa de los
datos, para la toma de decisiones. Sin embargo la componente geogrfica no es un
dato agregado, sino que es una dimensin o variable en la tecnologa de la
informacin, de tal manera que permita modelar todo el negocio como un ente
holstico, y que a travs de herramientas de procesamiento analtico en lnea
(OLAP), no solamente se posea un alto desempeo en consultas multidimensionales
sino que adicionalmente se puedan visualizar espacialmente los resultados.
El almacn de datos espacial forma el corazn de un extensivo Sistema de
Informacin Geogrfica para la toma de decisiones, ste al igual que los SIG,
permiten que un gran nmero de usuarios accedan a informacin integrada, a
diferencia de un simple almacn de datos que est orientado al tema, el Data
warehouse espacial adicionalmente es Geo-Relacional, es decir que en estructuras
relacionales combina e integra los datos espaciales con los datos descriptivos.
Actualmente es geo-objetos, esto es que los elementos geogrficos se manifiestan
como objetos con todas sus propiedades y comportamientos, y que adicionalmente
estn almacenados en una nica base de datos Objeto-Relacional. Los Data
Warehouse Espaciales son aplicaciones basadas en un alto desempeo de las
bases de datos, que utilizan arquitecturas Cliente-Servidor para integrar diversos
datos en tiempo real. Mientras los almacenes de datos trabajan con muchos tipos y
dimensiones de datos, muchos de los cuales no referencian ubicacin espacial, a
pesar de poseerla intrnsecamente, y sabiendo que un 80% de los datos poseen
representacin y ubicacin en el espacio, en los Data warehouse espaciales, la



26
variable geogrfica desempea un papel importante en la base de informacin para
la construccin del anlisis, y de igual manera que para un Data warehouse, la
variable tiempo es imprescindible en los anlisis, para los Data warehouse
espaciales la variable geogrfica debe ser almacenada directamente en ella.


CONDICIONES IMPORTANTES PARA CREAR UN DATAWAREHOUSE
Cuando se planifica la construccin de un data warehouse, o para la implantacin de
un proyecto Business Intelligence, sera sin duda el principio muy importante a
aplicar el DRY de no repetirse.
Dont repeat yourself, o simplemente DRY, es un principio que defiende la
necesidad de reducir o eliminar todo tipo de duplicidades. Este principio, aplicado a
la ingeniera del software, fue formulado por Andrew Hunt y David Thomas en The
Pragmatic Programmer
El principio DRY debe ser valorado en todas y cada una de las decisiones que
tomamos durante el ciclo de vida de un proyecto de software (y de datawarehousing
en particular). Hemos de evitar las duplicidades en la extraccin de la informacin,
en el tratamiento de estos datos, en el modelo de datos, en la arquitectura de la
solucin, en los patrones que seguimos, en las herramientas de explotacin, en los
informes que realizamos y en la estructura de cada uno de ellos, en la
documentacin En todo. Cada vez que nos ponemos la gorra de programadores
y hemos de disear algo o tomar una decisin tcnica (o no), debemos
preguntarnos, Y qu opinara DRY de esto?
Por supuesto, y muy lamentablemente, a veces son inevitables las duplicidades. De
hecho, paradjicamente, un data warehouse es la duplicacin de datos que ya
tenamos en otro lugar. Tambin las herramientas o los lenguajes de programacin
(el SQL, por ejemplo) a veces nos obligan a repetir cosas. Es muy triste y a veces lo
hacemos, pero no sin antes preguntarnos: De verdad es imprescindible? Est
justificada esta duplicidad que estoy a punto de introducir? Las ventajas que nos
aporta la duplicidad cubre los importantes costes de mantenimiento que tiene toda
reiteracin? No es posible automatizarlo? Es posible realizarlo de otro modo? No
hagas nada sin pasarlo por el filtro DRY.



27
Lo contrario de DRY es WET (Write Everything Twice), y tiene unas implicaciones
nefastas: La ms leve de ellas es que se tarda el doble de tiempo en escribirlo, y la
ms grave es que tendrs la lgica de tu aplicacin y procesos, y los datos de tu DW
diseminados en distintos lugares de tu arquitectura. Una implantacin WET tiene
unos costes de mantenimiento y una deuda tcnica muy elevados. Cuando se
recurre al cmodo Copiar y pegar, aunque pueda parecer que es fcil y rpido, se
est asumiendo una deuda (deuda tcnica) que repercutir en intereses
(sobrecoste) a lo largo de tooooda la vida del proyecto.
Los datos, indudablemente, parece que los estamos repitiendo en distintos sitios.
Los datos que ya tenamos en los sistemas de origen los duplicamos temporalmente
en la staging, los volvemos a duplicar en un modelo normalizado y finalmente los
duplicamos en el modelo dimensional que ser accedido por la capa de
presentacin. S, es una duplicacin dolorosa, y costosa como todas las
duplicaciones. Como toda duplicacin, debe justificarse, y en este caso se valora
que los usos que se hacen en cada una de las reas son distintos y claramente
diferenciados:
El data warehouse, en contraposicin al sistema operacional de origen, tiene un
enfoque analtico y cubre unos requerimientos que el operacional no alcanza
(facilidad de uso, tiempo de respuesta, visin histrica). Es decir, aunque los datos
sean los mismos, el DW y el operacional son cosas distintas.
El rea de staging es una duplicidad evidente. Son los mismos datos que el sistema
de origen. Es necesario justificarlo: Es temporal, es fcil duplicarlo, y evita que los
procesos de carga del DWH (que pueden llegar a ser largos) afecten negativamente
al operacional.
El modelo normalizado es el modelo de datos DRY por excelencia. En un modelo
3NF, cada dato est una y solo una vez. Si hemos aceptado que necesitamos un
DWH, y queremos una nica fuente de la verdad, y somos buenos discpulos de
DRY, hemos de defender a capa y espada el modelo normalizado, con la ayuda de
Codd.
El modelo dimensional es un mal necesario. En el estado actual de la tcnica, y con
el volumen de informacin que gestionan las empresas, el modelo normalizado no
cubre los requerimientos que justifican la existencia del DWH (facilidad de uso y
tiempos de respuesta, fundamentalmente). En el mejor de los mundos posibles, las



28
rbitas de los planetas seran circunferencias perfectas, no habra terremotos en
Lisboa, y todas las consultas seran instantneas. En el nuestro, no, y por eso es
necesario hacer caso a Kimball y mantener un modelo dimensional. Otras
consideraciones ayudan a justificar esta best practice: El modelo dimensional ser el
nico que ser accedido por las herramientas de explotacin. En este sentido, es
muy distinto al modelo normalizado. Adems, crear un modelo dimensional a partir
de un modelo normalizado es una tarea casi trivial que se justifica fcilmente.
En la arquitectura propuesta, los cubos son opcionales. De entrada, por DRY,
evitaremos esta duplicidad. Pero no somos dogmticos en este aspecto, los cubos
estn muy bien y muchas veces cumplen una funcin. Lo nico que digo es que
debe justificarse convenientemente su necesidad.
En los procesos de aprovisionamiento (ETL), tambin es necesario reflexionar si
seguimos o no el principio DRY. En este caso, es fcil ver que los tres procesos de
carga propuestos son ortogonales y distintos. Cumplen funciones distintas y siguen
estrategias distintas. En esta ETL no estamos duplicando nada:
Extraccin: Al extraer los datos desde la fuente hasta la staging, estamos
movindolos a una base de datos distinta, tal vez en otra tecnologa o en otra
ubicacin fsica. El nico punto que se accede a las fuentes es aqu. Si se
requiere cambiar el proceso o la estrategia de extraccin, solo se debe modificar
este cdigo. Es DRY.
Transformacin: El proceso desde la staging al modelo normalizado es
probablemente el ms complejo. En este punto, y solo en este punto,
conformamos las dimensiones, integramos las distintas fuentes, limpiamos o
seleccionamos los datos, guardamos la historia de las SCD, etc. Es muy DRY.
Carga del modelo dimensional: En el proceso final, cargamos las tablas que
sern accedidas por la capa de presentacin. Para minimizar el trabajo, y para
optimizar el rendimiento, cargamos solo la informacin que razonablemente
necesitar el usuario. Las estrategias de carga que seguiremos sern muy
distintas a las anteriores (no nos hemos de preocupar de crear la historia de las
SCD, podemos usar estrategias de recarga completas, no hemos de controlar la
calidad del dato de origen, etc.).





29
Cmo saber si su empresa necesita una solucin BI?
Recuerde que el objetivo del Business Intelligence es colocar todos los datos al
alcance de toda la empresa, proporcionando las herramientas para extraerlos de las
aplicaciones, conferirles un formato estndar, y posteriormente almacenarlos en un
repositorio optimizado para una entrega de la informacin rpida y resumida que
haga posible un anlisis muy detallado.
Para realizar un diagnstico instantneo de su empresa, slo tiene que responder al
siguiente cuestionario:

Est seguro de qu productos y clientes son los ms importantes para su
empresa?
S No N/a
Tiene problemas para crear una visin clara de toda su organizacin?
S No N/a
Sabe si est perdiendo cuota de mercado con respecto a su competencia?
S No N/a
Ha perdido oportunidades de negocio por recibir informacin atrasada?
S No N/a
Dedica horas extras a analizar documentos e informes?
S No N/a
Tiene informes de varios sistemas operacionales que no concuerdan?
S No N/a
Dispone de alguna ventaja competitiva clara con respecto a las dems empresas
de su sector?
S No N/a
Sabe con certeza si su gente est alcanzando los objetivos planificados?
S No N/a

Si al menos la mitad de las respuestas han sido afirmativas, su empresa puede
encontrar importantes beneficios al implantar un sistema de Business Intelligence.



30
En caso contrario, puede consultar aqu los motivos por los que quiz llegue a
interesarle en un futuro.








31
DATAMART

DEFINICION
Un Data mart es una versin especial de almacn de datos (data warehouse). Son
subconjuntos de datos con el propsito de ayudar a que un rea especfica dentro
del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto
pueden ser agrupados, explorados y propagados de mltiples formas para que
diversos grupos de usuarios realicen la explotacin de los mismos de la forma ms
conveniente segn sus necesidades.
El Data mart es un sistema orientado a la consulta, en el que se producen procesos
batch de carga de datos (altas) con una frecuencia baja y conocida. Es consultado
mediante herramientas OLAP (On line Analytical Processing - Procesamiento
Analtico en Lnea) que ofrecen una visin multidimensional de la informacin. Sobre
estas bases de datos se pueden construir EIS (Executive Information Systems,
Sistemas de Informacin para Directivos) y DSS (Decision Support Systems,
Sistemas de Ayuda a la toma de Decisiones). Por otra parte, se conoce como Data
Mining al proceso no trivial de anlisis de grandes cantidades de datos con el
objetivo de extraer informacin til, por ejemplo para realizar clasificaciones o
predicciones.
En sntesis, se puede decir que los data marts son pequeos data warehouse
centrados en un tema o un rea de negocio especfico dentro de una organizacin.

DEPENDENCIA DE UN DATAMART
Segn la tendencia marcada por Inmon sobre los data warehouse, un data mart
dependiente es un subconjunto lgico (vista) o un subconjunto fsico (extracto) de un
almacn de datos ms grande, que se ha aislado por alguna de las siguientes
razones:
Se necesita para un esquema o modelo de datos espacial (por ejemplo, para
reestructurar los datos para alguna herramienta OLAP).
Prestaciones: Para descargar el data mart a un ordenador independiente para
mejorar la eficiencia o para obviar las necesidades de gestionar todo el volumen
del data warehouse centralizado.



32
Seguridad: Para separar un subconjunto de datos de forma selectiva a los que
queremos permitir o restringir el acceso.
Conveniencia: la de poder pasar por alto las autorizaciones y requerimientos
necesarios para poder incorporar una nueva aplicacin en el Data Warehouse
principal de la Empresa.
Demostracin sobre el terreno: para demostrar la viabilidad y el potencial de una
aplicacin antes de migrarla al Data Warehouse de la Empresa.
Poltica: Razones internas de la organizacin para hacer esta divisin o
separacin de los datos del almacn de datos, por ejemplo:
o Cuando se decide una estrategia para las TI (Tecnologas de la
informacin) en situaciones en las que un grupo de usuarios tiene ms
influencia, para determinar si se financia dicha estrategia o descubrir si
sta no sera buena para el almacn de datos centralizado.
o Estrategia para los consumidores de los datos en situaciones en las que
un equipo de almacn de datos no est en condiciones de crear un
almacn de datos utilizable.
Segn la escuela Inmon de data warehouse, entre las prdidas inherentes al uso de
data marts estn la escalabilidad limitada, la duplicacin de datos, la inconsistencia
de los datos con respecto a otros almacenes de informacin y la incapacidad para
aprovechar las fuentes de datos de la empresa. As y todo estas herramientas son
de gran importancia.

CONCEPTOS ERRONEOS SOBRE LOS DATAMART
Al hablar de los data marts, es inevitable la comparacin con los data warehouse y al
final se acaba diciendo (o entendiendo) que son como estos, pero en pequeo, y en
cierto modo esto es as, pero esta idea suele hacer caer en los siguientes errores
sobre la implementacin y funcionamiento de los data marts:
Son ms simples de implementar que un Data Warehouse: FALSO, la
implementacin es muy similar, ya que debe proporcionar las mismas
funcionalidades.
Son pequeos conjuntos de datos y, en consecuencia, tienen menor necesidad
de recursos: FALSO, una aplicacin corriendo sobre un data mart necesita los
mismos recursos que si corriera sobre un data warehouse.



33
Las consultas son ms rpidas, dado el menor volumen de datos: FALSO, el
menor volumen de datos se debe a que no se tienen todos los datos de toda la
empresa, pero s se tienen todos los datos de un determinado sector de la
empresa, por lo que una consulta sobre dicho sector tarda lo mismo si se hace
sobre el data mart que si se hace sobre el data warehouse.
En algunos casos aade tiempo al proceso de actualizacin: FALSO, actualizar el
data mart desde el data warehouse cuesta menos (ya que los formatos de los
datos son o suelen ser idnticos) que actualizar el data warehouse desde sus
fuentes de datos primarias, donde es necesario realizar operaciones de
transformacin (ver ETL).

TIPOS DE DATAMART

Datamart OLAP
Se basan en los populares cubos OLAP, que se construyen agregando, segn los
requisitos de cada rea o departamento, las dimensiones y los indicadores
necesarios de cada cubo relacional. El modo de creacin, explotacin y
mantenimiento de los cubos OLAP es muy heterogneo, en funcin de la
herramienta final que se utilice.

Datamart OLTP
Pueden basarse en un simple extracto del datawarehouse, no obstante, lo comn es
introducir mejoras en su rendimiento (las agregaciones y los filtrados suelen ser las
operaciones ms usuales) aprovechando las caractersticas particulares de cada
rea de la empresa. Las estructuras ms comunes en este sentido son las tablas
report, que vienen a ser fact-tables reducidas (que agregan las dimensiones
oportunas), y las vistas materializadas, que se construyen con la misma estructura
que las anteriores, pero con el objetivo de explotar la reescritura de queries (aunque
slo es posibles en algunos SGBD avanzados, como Oracle).





34
VENTAJAS DE LOS DATAMART

Poco volumen de datos
Mayor rapidez de consulta
Consultas SQL y/o MDX sencillas
Validacin directa de la informacin
Facilidad para la historizacin de los datos


BASES DE DATOS OLTP Y OLAP

OLTP - On-Line Transactional Processing
Los sistemas OLTP son bases de datos orientadas al procesamiento de
transacciones. Una transaccin genera un proceso atmico (que debe ser validado
con un commit, o invalidado con un rollback), y que puede involucrar operaciones de
insercin, modificacin y borrado de datos. El proceso transaccional es tpico de las
bases de datos operacionales.
El acceso a los datos est optimizado para tareas frecuentes de lectura y
escritura. (Por ejemplo, la enorme cantidad de transacciones que tienen que
soportar las BD de bancos o hipermercados diariamente).
Los datos se estructuran segn el nivel aplicacin (programa de gestin a
medida, ERP o CRM implantado, sistema de informacin departamental...).
Los formatos de los datos no son necesariamente uniformes en los diferentes
departamentos (es comn la falta de compatibilidad y la existencia de islas de
datos).
El historial de datos suele limitarse a los datos actuales o recientes.

OLAP - On-Line Analytical Processing
Los sistemas OLAP son bases de datos orientadas al procesamiento analtico. Este
anlisis suele implicar, generalmente, la lectura de grandes cantidades de datos
para llegar a extraer algn tipo de informacin til: tendencias de ventas, patrones



35
de comportamiento de los consumidores, elaboracin de informes complejos etc.
Este sistema es tpico de los datamarts.
El acceso a los datos suele ser de slo lectura. La accin ms comn es la
consulta, con muy pocas inserciones, actualizaciones o eliminaciones.
Los datos se estructuran segn las reas de negocio, y los formatos de los datos
estn integrados de manera uniforme en toda la organizacin.
El historial de datos es a largo plazo, normalmente de dos a cinco aos.
Las bases de datos OLAP se suelen alimentar de informacin procedente de los
sistemas operacionales existentes, mediante un proceso de extraccin,
transformacin y carga (ETL).






36
LOS CUBOS DE INFORMACION

Un cubo OLAP, OnLine Analytical Processing o procesamiento Analtico en Lnea,
trmino acuado por Edgar Frank Codd de EF Codd & Associates, encargado por
Arbor Software (en la actualidad Hyperion Solutions), es una base de datos
multidimensional, en la cual el almacenamiento fsico de los datos se realiza en un
vector multidimensional. Los cubos OLAP se pueden considerar como una
ampliacin de las dos dimensiones de una hoja de clculo.
A menudo se pensaba que todo lo que los usuarios pueden querer de un sistema de
informacin se podra hacer de una base de datos relacional. No obstante Codd fue
uno de los precursores de las bases de datos relacionales, por lo que sus opiniones
fueron y son respetadas.

PERSISTENCIA MOLAP, ROLAP, HOLAP
Los cubos, las dimensiones y las jerarquas son la esencia de la navegacin
multidimensional del OLAP. Al describir y representar la informacin en esta forma,
los usuarios pueden navegar intuitivamente en un conjunto complejo de datos. Sin
embargo, el solo describir el modelo de datos en una forma ms intuitiva, hace muy
poco para ayudar a entregar la informacin al usuario ms rpidamente.
Un principio clave del OLAP es que los usuarios deberan obtener tiempos de
respuesta consistentes para cada vista de datos que requieran. Dado que la
informacin se colecta en el nivel de detalle solamente, el resumen de la informacin
es usualmente calculado por adelantado. Estos valores precalculados son la base de
las ganancias de desempeo del OLAP.
En los primeros das de la tecnologa OLAP, la mayora de las compaas asuma
que la nica solucin para una aplicacin OLAP era un modelo de almacenamiento
no relacional. Despus, otras compaas descubrieron que a travs del uso de
estructuras de base de datos (esquemas de estrella y de copo de nieve), ndices y el
almacenamiento de agregados, se podran utilizar sistemas de administracin de
bases de datos relacionales (RDBMS) para el OLAP.
Estos vendedores llamaron a esta tecnologa OLAP relacional (ROLAP). Las
primeras compaas adoptaron entonces el trmino OLAP multidimensional
(MOLAP), estos conceptos, MOLAP y ROLAP, se explican con ms detalle en los



37
siguientes prrafos. Las implementaciones MOLAP normalmente se desempean
mejor que la tecnologa ROLAP, pero tienen problemas de escalabilidad. Por otro
lado, las implementaciones ROLAP son ms escalables y son frecuentemente
atractivas a los clientes debido a que aprovechan las inversiones en tecnologas de
bases de datos relacionales preexistentes.

Sistemas MOLAP
La arquitectura MOLAP usa unas bases de datos multidimensionales para
proporcionar el anlisis, su principal premisa es que el OLAP est mejor implantado
almacenando los datos multidimensionalmente. Por el contrario, la arquitectura
ROLAP cree que las capacidades OLAP estn perfectamente implantadas sobre
bases de datos relacionales Un sistema MOLAP usa una base de datos propietaria
multidimensional, en la que la informacin se almacena multidimensionalmente, para
ser visualizada en varias dimensiones de anlisis.
El sistema MOLAP utiliza una arquitectura de dos niveles: la bases de datos
multidimensionales y el motor analtico. La base de datos multidimensional es la
encargada del manejo, acceso y obtencin del dato.
El nivel de aplicacin es el responsable de la ejecucin de los requerimientos OLAP.
El nivel de presentacin se integra con el de aplicacin y proporciona un interfaz a
travs del cual los usuarios finales visualizan los anlisis OLAP. Una arquitectura
cliente/servidor permite a varios usuarios acceder a la misma base de datos
multidimensional.
La informacin procedente de los sistemas operacionales, se carga en el sistema
MOLAP, mediante una serie de rutinas por lotes. Una vez cargado el dato elemental
en la Base de Datos multidimensional (MDDB), se realizan una serie de clculos por
lotes, para calcular los datos agregados, a travs de las dimensiones de negocio,
rellenando la estructura MDDB.
Tras rellenar esta estructura, se generan unos ndices y algoritmos de tablas hash
para mejorar los tiempos de accesos a las consultas. Una vez que el proceso de
compilacin se ha acabado, la MDDB est lista para su uso. Los usuarios solicitan
informes a travs de la interfase, y la lgica de aplicacin de la MDDB obtiene el
dato.



38
La arquitectura MOLAP requiere unos clculos intensivos de compilacin. Lee de
datos precompilados, y tiene capacidades limitadas de crear agregaciones
dinmicamente o de hallar ratios que no se hayan precalculados y almacenados
previamente.

Sistemas ROLAP
La arquitectura ROLAP, accede a los datos almacenados en un datawarehouse para
proporcionar los anlisis OLAP. La premisa de los sistemas ROLAP es que las
capacidades OLAP se soportan mejor contra las bases de datos relacionales.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos
relacional maneja los requerimientos de almacenamiento de datos, y el motor
ROLAP proporciona la funcionalidad analtica. El nivel de base de datos usa bases
de datos relacionales para el manejo, acceso y obtencin del dato. El nivel de
aplicacin es el motor que ejecuta las consultas multidimensionales de los usuarios.
El motor ROLAP se integra con niveles de presentacin, a travs de los cules los
usuarios realizan los anlisis OLAP. Despus de que el modelo de datos para el
datawarehouse se ha definido, los datos se cargan desde el sistema operacional. Se
ejecutan rutinas de bases de datos para agregar el dato, si as es requerido por el
modelo de datos. Se crean entonces los ndices para optimizar los tiempos de
acceso a las consultas.
Los usuarios finales ejecutan sus anlisis multidimensionales, a travs del motor
ROLAP, que transforma dinmicamente sus consultas a consultas SQL. Se ejecutan
estas consultas SQL en las bases de datos relacionales, y sus resultados se
relacionan mediante tablas cruzadas y conjuntos multidimensionales para devolver
los resultados a los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos estn
disponibles, o de generar dinmicamente los resultados desde los datos elementales
si es preciso. Esta arquitectura accede directamente a los datos del datawarehouse,
y soporta tcnicas de optimizacin de accesos para acelerar las consultas. Estas
optimizaciones son, entre otras, particionado de los datos a nivel de aplicacin,
soporte a la desnormalizacin y joins mltiples.




39
Sistemas MOLAP
Un desarrollo un poco ms reciente ha sido la solucin OLAP hbrida (HOLAP), la
cual combina las arquitecturas ROLAP y MOLAP para brindar una solucin con las
mejores caractersticas de ambas: desempeo superior y gran escalabilidad. Un tipo
de HOLAP mantiene los registros de detalle (los volmenes ms grandes) en la base
de datos relacional, mientras que mantiene las agregaciones en un almacn MOLAP
separado.







40
CUADRO DE MANDO INTEGRAL

El concepto de Cuadro de Mando Integral CMI (Balanced Scorecard BSC) fue
presentado en el nmero de enero/febrero de 1992 de la revista Harvard Business
Review, con base en un trabajo realizado para una empresa de semiconductores.
Sus autores, Robert Kaplan y David Norton, plantean que el CMI es un sistema de
administracin o sistema administrativo (management system), que va ms all de la
perspectiva financiera con la que los gerentes acostumbran evaluar la marcha de
una empresa.
Es un mtodo para medir las actividades de una compaa en trminos de su visin
y estrategia. Proporciona a los gerentes una mirada global del desempeo del
negocio.
Es una herramienta de administracin de empresas que muestra continuamente
cundo una compaa y sus empleados alcanzan los resultados definidos por el plan
estratgico. Tambin es una herramienta que ayuda a la compaa a expresar los
objetivos e iniciativas necesarias para cumplir con la estrategia.
El CMI sugiere que veamos a la organizacin desde cuatro perspectivas, cada una
de las cuales debe responder a una pregunta determinada:
Desarrollo y Aprendizaje (Learning and Growth): Podemos continuar mejorando
y creando valor?
Interna del Negocio (Internal Business): En qu debemos sobresalir?
Del cliente (Customer): Cmo nos ven los clientes?
Financiera (Financial): Cmo nos vemos a los ojos de los accionistas?
El CMI es por lo tanto un sistema de gestin estratgica de la empresa, que consiste
en:
Formular una estrategia consistente y transparente.
Comunicar la estrategia a travs de la organizacin.
Coordinar los objetivos de las diversas unidades organizacionales.
Conectar los objetivos con la planificacin financiera y presupuestaria.
Identificar y coordinar las iniciativas estratgicas.
Medir de un modo sistemtico la realizacin, proponiendo acciones correctivas
oportunas.




41
PERSPECTIVAS

Perspectiva financiera
En general, los indicadores financieros estn basados en la contabilidad de la
compaa, y muestran el pasado de la misma. El motivo se debe a que la
contabilidad no es inmediata (al emitir un proveedor una factura, la misma no se
contabiliza automticamente), sino que deben efectuarse cierres que aseguren la
compilacin y consistencia de la informacin. Debido a estas demoras, algunos
autores sostienen que dirigir una compaa prestando atencin solamente a
indicadores financieros es como conducir a 100 km/h mirando por el espejo
retrovisor.
Esta perspectiva abarca el rea de las necesidades de los accionistas. Esta parte del
BSC se enfoca a los requerimientos de crear valor para el accionista como: las
ganancias, rendimiento econmico, desarrollo de la compaa y rentabilidad de la
misma.
Valor Econmico Agregado (EVA), Retorno sobre Capital Empleado (ROCE),
Margen de Operacin, Ingresos, Rotacin de Activos son algunos indicadores de
esta perspectiva.
Algunos indicadores frecuentemente utilizados son:
ndice de liquidez.
ndice de endeudamiento.
Metodologa DuPont.
ndice de rendimiento del capital invertido (en la mayora de los casos).

Perspectiva del cliente
Para lograr el desempeo financiero que una empresa desea, es fundamental que
posea clientes leales y satisfechos, con ese objetivo en esta perspectiva se miden
las relaciones con los clientes y las expectativas que los mismos tienen sobre los
negocios. Adems, en esta perspectiva se toman en cuenta los principales
elementos que generan valor para los clientes integrndolos en una propuesta de



42
valor, para poder as centrarse en los procesos que para ellos son ms importantes y
que ms los satisfacen.
La Perspectiva de Clientes, como su nombre lo dice est enfocada a la parte ms
importante de una empresa, sus clientes; sin consumidores no existe ningn tipo de
mercado. Por consiguiente, se debern cubrir las necesidades de los compradores
entre las que se encuentran los precios, la calidad del producto o servicio, tiempo,
funcin, imagen y relacin. Cabe mencionar que todas las perspectivas estn unidas
entre s, esto significa que para cubrir las expectativas de los accionistas tambin se
debe cubrir las de los consumidores para que compren y se genere una ganancia.
Algunos indicadores de esta perspectiva son: Satisfaccin de clientes, desviaciones
en acuerdos de servicio, reclamos resueltos del total de reclamos, incorporacin y
retencin de clientes.
El conocimiento de los clientes y de los procesos que ms valor generan es muy
importante para lograr que el panorama financiero sea prspero. Sin el estudio de
las peculiaridades del mercado al que est enfocada la empresa no podr existir un
desarrollo sostenible en la perspectiva financiera, ya que en gran medida el xito
financiero proviene del aumento de las ventas, situacin que es el efecto de clientes
que repiten sus compras porque prefieren los productos que la empresa desarrolla
teniendo en cuenta sus preferencias.
Una buena manera de medir o saber la perspectiva del cliente es diseando
protocolos bsicos de atencin y utilizar la metodologa de cliente incgnito para la
relacin del personal en contacto con el cliente (PEC).

Perspectiva de procesos
Analiza la adecuacin de los procesos internos de la empresa de cara a la obtencin
de la satisfaccin del cliente y logro de altos niveles de rendimiento financiero. Para
alcanzar este objetivo se propone un anlisis de los procesos internos desde una
perspectiva de negocio y una predeterminacin de los procesos clave a travs de la
cadena de valor.
Se distinguen cuatro tipos de procesos:



43
Procesos de operaciones: Desarrollados a travs de los anlisis de calidad y
reingeniera. Los indicadores son los relativos a costos, calidad, tiempos o
flexibilidad de los procesos.
Procesos de gestin de clientes. Indicadores: Seleccin de clientes, captacin
de clientes, retencin y crecimiento de clientes.
Procesos de innovacin (difcil de medir). Ejemplo de indicadores: % de
productos nuevos, % productos patentados, introduccin de nuevos productos
en relacin a la competencia.
Procesos relacionados con el Medio Ambiente y la Comunidad: Indicadores
tpicos de Gestin Ambiental, Seguridad e Higiene y Responsabilidad Social
Corporativa.

Perspectiva del desarrollo de las personas y el aprendizaje
El modelo plantea los valores de este bloque como el conjunto de guas del resto de
las perspectivas. Estos indicadores constituyen el conjunto de activos que dotan a la
organizacin de la habilidad para mejorar y aprender. Se critica la visin de la
contabilidad tradicional, que considera la formacin como un gasto, no como una
inversin.
La perspectiva del aprendizaje y mejora es la menos desarrollada, debido al escaso
avance de las empresas en este punto. De cualquier forma, la aportacin del modelo
es relevante, ya que deja un camino perfectamente apuntado y estructura esta
perspectiva. Clasifica los activos relativos al aprendizaje y mejora en:
Capacidad y competencia de las personas (gestin de los empleados). Incluye
indicadores de satisfaccin de los empleados, productividad, necesidad de
formacin, entre otros.
Sistemas de informacin (sistemas que proveen informacin til para el trabajo).
Indicadores: bases de datos estratgicos, software propio, las patentes y
copyrights (marcas registradas) entre otras.
Cultura-clima-motivacin para el aprendizaje y la accin. Indicadores: iniciativa de
las personas y equipos, la capacidad de trabajar en equipo, el alineamiento con
la visin de la empresa, entre otros.



44
Esta perspectiva se basa en la utilizacin de activos intangibles, lo que en toda
compaa no es siempre la lgica de negocios. En algunas compaas los recursos
tangibles son preponderantes en vez de los intangibles, por lo que no se trata de
copiar e imitar tratando de encajar este modelo en todas las empresas. Pueden
existir ms o menos perspectivas del BSC (Cuadro de Mando Integral).

CARACTERISTICAS DEL CUADRO DE MANDO
En la actualidad -debido a las turbulencias del entorno empresarial, influenciado en
la mayora de los casos por una gran presin competitiva, as como por un auge de
la tecnologa- es cuando comienza a tener una amplia trascendencia.
El concepto de cuadro de mando deriva del concepto denominado "tableau de bord"
en Francia, que traducido de manera literal, vendra a significar algo como tablero de
mandos o cuadro de instrumentos.
A partir de los aos 80, es cuando el Cuadro de Mando pasa a ser, adems de un
concepto prctico, una idea acadmica, ya que hasta entonces el entorno
empresarial no sufra grandes variaciones, la tendencia del mismo era estable, las
decisiones que se tomaban carecan de un alto nivel de riesgo.
Para entonces, los principios bsicos sobre los que se sostena el Cuadro de Mando
ya estaban estructurados, es decir, se fijaban unos fines en la entidad, cada uno de
stos eran llevados a cabo mediante la definicin de unas variables clave, y el
control era realizado a travs de indicadores.
Bsicamente, y de manera resumida, podemos destacar tres caractersticas
fundamentales de los cuadros de mando:
La naturaleza de las informaciones recogidas en l, dando cierto privilegio a
las secciones operativas (ventas, etc.) para poder informar a las secciones de
carcter financiero, siendo stas ltimas el producto resultante de las dems.
La rapidez de ascenso de la informacin entre los distintos niveles de
responsabilidad.
La seleccin de los indicadores necesarios para la toma de decisiones, sobre
todo en el menor nmero posible.
En definitiva, lo importante es establecer un sistema de seales en forma de Cuadro
de Mando que nos indique la variacin de las magnitudes verdaderamente
importantes que debemos vigilar para someter a control la gestin.



45

Elaboracin y contenido del cuadro de mando
Los responsables de cada uno de los cuadros de mando de los diferentes
departamentos han de tener en cuenta una serie de aspectos comunes en cuanto a
su elaboracin. Entre dichos aspectos cabra destacar los siguientes:
Los cuadros de mando han de presentar slo aquella informacin que resulte
ser imprescindible, de una forma sencilla y por supuesto, sinptica y
resumida.
El carcter de estructura piramidal entre los cuadros de mando, ha de tenerse
presente en todo momento, ya que esto permite la conciliacin de dos puntos
bsicos: uno, que cada vez ms se agreguen los indicadores hasta llegar a
los ms resumidos y dos, que a cada responsable se le asignen slo aquellos
indicadores relativos a su gestin y a sus objetivos.
Se debe destacar lo verdaderamente relevante, ofreciendo un mayor nfasis
en cuanto a las informaciones ms significativas.
No se puede olvidar la importancia que tienen tanto los grficos, tablas y/o
cuadros de datos, etc., ya que son verdaderos nexos de apoyo de toda la
informacin que se resume en los Cuadros de Mando.
La uniformidad en cuanto a la forma de elaborar estas herramientas es
importante, ya que esto permitir una verdadera normalizacin de los
informes con los que la empresa trabaja, as como facilitar las tareas de
contrastacin de resultados entre los distintos departamentos o reas.
De alguna manera, lo que se incorpore en esta herramienta, ser aquello con lo que
se podr medir la gestin realizada y, por este motivo, es muy importante establecer
en cada caso qu es lo que hay que controlar y cmo hacerlo. En general, el Cuadro
de Mando debe tener cuatro partes bien diferenciadas:
Primero: se deben constatar de forma clara, cules son las variables o
aspectos claves ms importantes a tener en cuenta para la correcta medicin
de la gestin en un rea determinada o en un nivel de responsabilidad
concreto.



46
Segundo: en la que estas variables puedan ser cuantificadas de alguna
manera a travs de los indicadores precisos, y en los perodos de tiempo que
se consideren oportunos.
Tercero: en alusin al control de dichos indicadores, ser necesaria la
comparacin entre lo previsto y lo realizado, extrayendo de algn modo las
diferencias positivas o negativas que se han generado, es decir, las
desviaciones producidas.
Cuarto: es fundamental que con imaginacin y creatividad se consiga que el
modelo de Cuadro de Mando que se proponga en una organizacin ofrezca
soluciones cuando as sea necesario.

Elaboracin del Cuadro de Mando
No deben perderse de vista los objetivos elementales que se pretenden alcanzar
mediante el Cuadro de Mando, ya que sin fines a alcanzar, difcilmente se puede
entender la creacin de ciertos informes. Entre dichos objetivos podemos considerar
que:
Ha de ser un medio informativo destacable. Sobre todo ha de conseguir
eliminar en la medida de lo posible la burocracia informativa en cuanto a los
diferentes informes con los que la empresa puede contar.
Debe ser una herramienta de diagnstico. Se trata de especificar lo que no
funciona correctamente en la empresa, en definitiva ha de comportarse como
un sistema de alerta. En este sentido, tenemos que considerar dos aspectos:
o Se han de poner en evidencia aquellos parmetros que no marchan
como estaba previsto. Esta es la base de la gestin por excepcin, es
decir, el Cuadro de Mando ha de mostrar en primer lugar aquello que
no se ajusta a los lmites absolutos fijados por la empresa y, en
segundo lugar, advertir de aquellos otros elementos que se mueven en
niveles de tolerancia de cierto riesgo.
o Esta herramienta debe de seleccionar tanto la cantidad como la calidad
de la informacin que suministra en funcin de la repercusin sobre los
resultados que vaya a obtener.



47
En relacin a la confrontacin entre realizaciones y previsiones ha de ponerse
de manifiesto su eficacia. El anlisis de las desviaciones es bsico a la hora
de estudiar la trayectoria de la gestin as como en el proceso de toma de
decisiones a corto plazo.
Debe promover el dilogo entre todos. Mediante la exposicin conjunta de los
problemas por parte de los distintos responsables, se puede avanzar mucho
en cuanto a la agilizacin del proceso de toma de decisiones. Es preciso que
se analicen las causas de las desviaciones ms importantes, proporcionar
soluciones y tomar la va de accin ms adecuada.
Ha de ser til a la hora de asignar responsabilidades. Adems la
disponibilidad de informacin adecuada, facilita una comunicacin fluida entre
los distintos niveles directivos y el trabajo en grupo que permite mejorar
resultados.
Ha de ser motivo de cambio y de formacin continuada en cuanto a los
comportamientos de los distintos ejecutivos y/o responsables. Ha de
conseguir la motivacin entre los distintos responsables. Esto ha de ser as,
sobre todo por cuanto esta herramienta ser el reflejo de su propia gestin.
Por ltimo y como objetivo ms importante esta herramienta de gestin debe
facilitar la toma de decisiones. Para ello, el modelo debera en todo momento:
o Facilitar el anlisis de las causas de las desviaciones. Para ello se
precisara de una serie de informaciones de carcter complementario
en continuo apoyo al Cuadro de Mando adems de la que pudiera
aportarle el "Controller", ya que en muchas ocasiones disfruta de cierta
informacin de carcter privilegiado que ni siquiera la Direccin
conoce.
o Proporcionar los medios para solucionar dichos problemas y disponer
de los medios de accin adecuados.
o Saber decidir cmo comportarse. En cierto modo, estaramos haciendo
referencia a un sistema inteligente, a un sistema que se nutre de la
propia trayectoria de la empresa, y que, cada vez mejor, suministra
informacin y un modo de actuar ptimo.
Los principales elementos que pueden hacer que el Cuadro de Mando muestre
notables diferencias con respecto a otras herramientas contables y de gestin son:



48
El carcter de la informacin utilizada.
La relacin entre el Cuadro de Mando y el perfil caracterstico de la persona
destinataria.
La solucin de problemas mediante acciones rpidas.
Informaciones sencillas y poco voluminosas.
En relacin con el tipo de informacin utilizada, el Cuadro de Mando, aparte de
reunir informacin de similares caractersticas que la empleada en las distintas
disciplinas de naturaleza contable, es decir, financiera, debe contener informacin de
carcter no financiero. Ya desde su presentacin como una herramienta til de
gestin, el Cuadro de Mando se destacaba por su total flexibilidad para recoger tal
informacin.
Otro aspecto a destacar, es la relacin mutua que ha de existir entre el Cuadro de
Mando y el perfil de la persona a quien va destinado. Precisamente, las necesidades
de cada directivo, han de marcar la pauta que caracterice y haga idnea a esta
herramienta en cada caso y situacin, sobre todo con respecto al nivel de mayor
responsabilidad de la jerarqua actual de la empresa, debido a que se precisa un
esfuerzo mucho mayor de generalidad y sntesis.
Un rasgo ms del Cuadro de Mando es la solucin de problemas mediante acciones
rpidas. Cuando se incorporan indicadores de carcter cualitativo al Cuadro de
Mando, en cierto modo, stos estn ms cerca de la accin que los propios
indicadores o resultados financieros. Asimismo, estos indicadores nominales nos
dan un avance en cuanto a qu resultados estn por alcanzarse.
El ltimo de los rasgos que diferenciaran al Cuadro de Mando es el hecho de utilizar
informaciones sencillas y poco voluminosas. Las disciplinas y herramientas
contables habituales precisan una mayor dedicacin de tiempo de anlisis y de
realizacin y, al momento de la toma de decisiones siempre necesita de otros
aspectos que en un principio no formaban parte de su marco de accin.
El Cuadro de Mando se orienta hacia la reduccin y sntesis de conceptos, es una
herramienta que junto con el apoyo de las nuevas tecnologas de la informacin y
comunicacin, puede y debe ofrecer una informacin sencilla, resumida y eficaz para
la toma de decisiones.





49
PROYECTOS EN INTELIGENCIA DE NEGOCIOS


POR QUE FALLAN LOS PROYECTOS DE INTELIGENCIA DE NEGOCIOS
A veces nos sorprende que con el desarrollo al que han llegado muchas
herramientas, el uso de metodologas contrastadas y el mayor nivel de conocimiento
de tcnicos y usuarios, se produzcan tantos desastres en la implementacin de
soluciones Business Intelligence, en trminos de exceso de coste sobre el previsto,
no utilizacin por parte de los usuarios, no cumplir con las expectativas, informacin
errnea, etc...
Algunos de los principales fallos:
Muchos Data Warehouses crecen en tamao de forma desproporcionada
porque los tcnicos no consiguen decir 'no' a las 'excesivas' demandas de los
usuarios.
Se prefiere realizar el proyecto con gente de la propia empresa, cuando stos
no tienen ni tiempo, ni conocimientos para poder abarcarlo.
Se fijan unas fechas de entrada en produccin del sistema poco realistas, que
provoca nuevas fechas y ms retrasos.
El presupuesto destinado para el proyecto es escaso en comparacin con el
grado de complejidad que se quiere desarrollar.
La seleccin del software y hardware a veces se realiza siguiendo criterios de
acuerdos generales o compromisos, antes que puramente tcnicos.
Antes del proyecto, no se realizan benchmarks o 'pruebas de concepto' para
determinar la viabilidad.
Los datos de origen no estn limpios. Duplicidades, errores, caracteres
errneos.implican un proceso ETL ms costoso, mayor tamao de la Base de
datos y peor rendimiento.
El sponsor del proyecto no ejerce como tal durante el mismo. No 'baja a la
tierra'.
Mala eleccin de los consultores y excesiva rotacin entre ellos.
Escasa involucracin de los usuarios finales que les lleva a sentir cierta
frustraccin con los resultados obtenidos.
Caer en el error de 'en informtica todo se puede hacer' y empezar con
customizaciones, escribir cdigo fuera de las funcionalidades standard.



50
No alinear el proyecto dentro de una estrategia de negocio.
Existen muchos ms factores que pueden hacer fallar un proyecto Business
Intelligence, pero stos pueden hacer literalmente 'tumbarlo', no conseguir ms
proyectos para los consultores, mala imagen del producto y riesgos internos para el
director de informtica y otros sponsors.




51

CONCLUSIONES

El ciclo de vida del proyecto permite contar con un marco de referencia para
comparar
Se pudo apreciar como la inteligencia de negocios ha venido apalancando la
estrategia de negocio de diversas empresas que lo han implementado como un
medio para la mejor toma de decisiones.
La inteligencia de negocios en las empresas ha apoyado a la toma de decisiones
que han sido vitales he importantes durante toda su trayectoria y que le han dado
excelentes resultados.
La inteligencia de negocios ha facilitado notablemente la interactividad entre los
usuarios y las herramientas de BI, haciendo que cada vez ms sean ms
utilizadas y por ende la empresa logre obtener mayores resultados para su
beneficio propio y de sus clientes y proveedores.
Las soluciones de Inteligencia de Negocios han proporcionado un fcil acceso a
los datos crticos dentro de la empresa necesarios para el anlisis, as como un
medio para integrar los datos corporativos con los procesos de toma de decisin
a nivel estratgico y tctico; tambin ha permitido a la empresa afinar la toma de
decisiones cotidiana, asegurando que cada grupo operativo tenga acceso a la
informacin necesaria para contestar preguntas especficas y distribuir dicha
informacin a todos los niveles de la organizacin.
La BI a permitido alinear las acciones de todos los empleados con las estrategias
y objetivos corporativos para el mejoramiento continuo del desempeo
empresarial.
Igualmente, ha ayudado a visualizar y controlar lo que sucede en cada lnea de
negocio, por la medicin de mtricas e indicadores especficos, haciendo as que
se actu con seguridad en la toma de decisiones soportada en informacin
confiable y real.
Es importante entender que las herramientas de soporte a la toma de decisiones,
son eso, herramientas, y que la seleccin y uso, simplifican muchas operaciones
y procesos en el negocio, pero que los tomadores de decisiones son la piedra
angular. Factores que toma en cuenta, en mayor o menor grado, como son la



52
velocidad de cambio, innovacin de nuevos modelos de negocio, nuevas
estructuras de relaciones entre las empresas, sus clientes y asociados, la
conectividad de personas, organizaciones y pases, y el valor del conocimiento
residente en la empresa; su conocimiento y habilidades y el uso de sistemas
inteligentes para la toma de decisiones, a toda esta integracin se le denomina
Inteligencia del Negocio y es la que genera las ventajas competitivas entre una
empresa y otra.
Como herramientas actualmente existen versiones pagas y de software libre que
han mejorado aumentado cada vez el acceso a ellas de todo tipo de empresas.
En nuestro medio todava es relativamente reciente su uso y eso por lo general
se debe a que muchas organizaciones no cuentan con sistemas transacionales
integrados y con alto nivel de calidad de datos.





53
FUENTES DE INFORMACION

Referencias bibliogrficas

HERNANDEZ ORALLO, Jose y otros. Introduccion a la Mineria de Datos. 1
edicin. PEARSON EDUCACION, Madrid.2004.

NUIZ, Luis. Cuadro de mando integral. Lupa Solutions. 2012.

Referencias electrnicas

Inteligencia de negocios
http://www.buenastareas.com/ensayos/Historia-Inteligencia-De-
Negocios/24192624.html

http://www.businessintelligence.info/definiciones/historia-business-intelligence.html

http://www.monografias.com/trabajos29/sistema-business-intelligence/sistema-
business-intelligence.shtml

http://sigc.wikidot.com/system:introduccion-bi

http://www.itmadrid.com/blog/que-es-inteligencia-de-negocios-business-intelligence/

http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/busint.htm

Datawarehouse
http://es.wikipedia.org/wiki/Almac%C3%A9n_de_datos

http://es.wikipedia.org/wiki/Extract,_transform_and_load

http://es.wikipedia.org/wiki/Data_mart




54
http://sinnexus.es/business_intelligence/datamart.aspx

http://es.wikipedia.org/wiki/Cuadro_de_mando_integral






55
ANEXOS

ANEXO N 1. EFECTO DE IMPLEMENTAR BI







56
ANEXO N 2. Arquitectura de Datawarehouse.









57
ANEXO N 3. Cubo de Informacion
















58
ANEXO N 4. Datos-Informacin-Conocimiento









59
ANEXO N 5. COMANDO DE MANDO INTEGRAL




60