PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO

FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA

SOLUCIÓN DE INTELIGENCIA DE
NEGOCIOS PARA UNA PYME

JUAN PABLO SOTO OLIVARES

INFORME FINAL DEL PROYECTO PARA

OPTAR AL TÍTULO PROFESIONAL DE
INGENIERO CIVIL EN INFORMÁTICA

MAYO DE 2011
PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA

SOLUCIÓN DE INTELIGENCIA DE
NEGOCIOS PARA UNA PYME

JUAN PABLO SOTO OLIVARES

Profesor Guía: Broderick Crawford Labrín.

Profesor Correferente: Guillermo Cabrera Guerrero.

Carrera: Ingeniería Civil en Informática.

MAYO DE 2011

2
 A Dios, a mis padres, hermanos,
familia y amigos por su apoyo
incondicional…
Índice de Contenidos
Índice de Contenidos..................................................................................................i
Glosario de Términos ............................................................................................... iv
Lista de Abreviaturas ................................................................................................ v
Índice de Ilustraciones ............................................................................................. vi
Abstract ..................................................................................................................vii
Resumen .................................................................................................................vii
1 Introducción ..................................................................................................... 8
1.1 Descripción y Observaciones previas del proyecto .................................... 8
1.2 La Empresa ............................................................................................... 8
1.3.- Problemática ................................................................................................... 9
2 Objetivos del Proyecto ................................................................................... 10
2.1 Objetivo General ..................................................................................... 10
2.2 Actividades del Proyecto ......................................................................... 10
3 Plan de Trabajo .............................................................................................. 11
4 Estado del Arte ............................................................................................... 12
4.1 Aspectos Generales de la Inteligencia de Negocios .................................. 12
4.1.1 Un poco de Historia ..................................................................................... 12
4.1.2 Beneficios .................................................................................................... 12
4.2 Datawarehouses y Datamarts ................................................................... 13
4.2.1 Características de los Datawarehouses ......................................................... 13
4.2.2 Ventajas de los Datawarehouses .................................................................. 14
4.2.3 Desventajas de los Datawarehouses ............................................................. 16
4.2.4 Modelos de Data Warehouses ...................................................................... 16
4.3 ETL (Extraction, Transformation and Load ............................................. 18
4.3.1 Importancia de los ETL ............................................................................... 18
4.4 OLAP (On-Line Analytical Processing) .................................................. 19
4.4.1 Cubos OLAP ............................................................................................... 19
4.4.2 Tipos de OLAP ............................................................................................ 20
4.5 Tendencias .............................................................................................. 20
5 Elementos de Análisis Empresarial ................................................................. 21
5.1 Misión y Visión....................................................................................... 21
5.1.1 Misión ......................................................................................................... 21
5.1.2 Visión .......................................................................................................... 21
5.2 Análisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas).... 21
5.2.1 Variables de Análisis ................................................................................... 23
5.2.2 La Matriz FODA ......................................................................................... 24
5.2.3 Estrategias ................................................................................................... 24
i
6 Análisis de la empresa .................................................................................... 26
6.1 Misión y Visión....................................................................................... 26
6.1.1 Misión ......................................................................................................... 26
6.1.2 Visión .......................................................................................................... 26
6.2 Análisis FODA........................................................................................ 26
6.2.1 Fortalezas .................................................................................................... 29
6.2.2 Debilidades .................................................................................................. 29
6.2.3 Oportunidades ............................................................................................. 30
6.2.4 Amenazas .................................................................................................... 30
6.2.5 Estrategia ..................................................................................................... 30
7 Metodología ................................................................................................... 31
7.1 Kimball e Inmon ..................................................................................... 31
7.1.1 Kimball (Bottom Up) ................................................................................... 31
7.1.2 Inmon (Top Down) ...................................................................................... 33
7.2 La Metodología de Larissa Moss ............................................................. 34
7.2.1 Justificación................................................................................................. 36
7.2.2 Planeación ................................................................................................... 36
7.2.3 Análisis del negocio ..................................................................................... 36
7.2.4 Diseño ......................................................................................................... 37
7.2.5 Construcción................................................................................................ 38
7.2.6 Despliegue ................................................................................................... 39
8 Desarrollo del Problema ................................................................................. 40
8.1 Justificación ............................................................................................ 41
8.1.1 Estudio de caso de negocio .......................................................................... 41
8.2 Planeación ............................................................................................... 43
8.2.1 Evaluación de la infraestructura técnica de la empresa ................................. 43
8.2.2 Planeación del proyecto ............................................................................... 44
8.3 Análisis del Negocio ............................................................................... 45
8.3.1 Definición de Requerimientos del Proyecto ................................................. 45
8.4 Diseño ..................................................................................................... 45
8.4.1 Diseño de la base de datos (Kimball) ........................................................... 45
8.5 Construcción ........................................................................................... 47
8.5.1 Diseño del ETL............................................................................................ 47
8.5.2 Desarrollo de la aplicación ........................................................................... 52
9 Herramientas .................................................................................................. 63
9.1 Pentaho ................................................................................................... 63
9.2 Jaspersoft ................................................................................................ 64
10 Propuesta Metodológica ................................................................................. 66
10.1 Formalización de los pasos: Formulación de Neil Salkind ....................... 66
10.1.1 Formulación del problema ....................................................................... 67
10.1.2 Identificación de Variables ...................................................................... 67

ii
 10.1.3 Formulación de la Hipótesis de Investigación .......................................... 68
10.1.4 Recopilación de la información ............................................................... 68
10.1.5 Prueba, trabajo, reconsideración y confirmación o refutación .................. 71
11 Conclusiones .................................................................................................. 72
11.1 Implementación en AOSA....................................................................... 72
12 Referencias..................................................................................................... 74

iii
Glosario de Términos
PYME Según el ministerio de economía de Chile,
empresa que vende entre 2.400 y 100.000 UFs
anuales o que tiene entre 10 y 199 empleados.

ETL Herramienta que permite extraer, transformar y

cargar datos en diferentes fuentes.

OLAP Conjunto de tecnologías y metodologías que

permiten el uso de bases de datos
multidimensionales con fines analíticos y
predictivos.

Cubo OLAP Modelo lógico de una base de datos

multidimensional, construible mediante
herramientas OLAP.

MDX Expresiones multidimensionales. Lenguaje de

consulta para bases de datos OLAP.

Pentaho Suite de herramientas de código abierto de

inteligencia de negocios.

Kettle Herramienta ETL dentro de la suite Pentaho.

iv
Lista de Abreviaturas
BI Business Intelligence.
ETL Extract, Transform and Load.
OLAP On-Line Analytical Processing.

TI Tecnologías de la Información
XML Extensible Markup Language
MDX Multidimensional Expressions

v
Índice de Ilustraciones
Figura n° 1: Diagrama Organizacional Alirio Olivares S.A. .................................... 9
Figura n° 2: Ejemplo de modelo estrella ............................................................... 17
Figura n° 3: Ejemplo de modelo copo de nieve ..................................................... 17
Figura n° 4: Evolución del proceso de carga de datos............................................ 18
Figura nº 5: Poblamiento y utilización de datos del datawarehouse ....................... 19
Figura nº6: Dimensiones del análisis FODA ......................................................... 22
Figura nº 7: Matriz FODA genérica ...................................................................... 24
Figura nº 8: Data warehouse según Kimball .......................................................... 32
Figura nº 9: Data warehouse según Inmon ............................................................ 33
Figura nº10: La metodología de Larissa Moss ....................................................... 35
Figura nº 11: Relación uno a uno de data mart y data warehouse........................... 38
Figura nº12: Metodología de Moss adaptada ......................................................... 40
Figura nº13: Diagrama del Data Warehouse .......................................................... 47
Figura nº14: Modelo de llenado tabla Cliente ........................................................ 49
Figura nº15: Función trim sobre campos seleccionados......................................... 49
Figura nº16: Modelo de llenado tabla Vendedor.................................................... 50
Figura nº17: Muestra de archivo fuente de fechas ................................................. 50
Figura nº18: Modelo de llenado tabla Fecha.......................................................... 51
Figura nº19: Modelo de llenado tabla Producto ..................................................... 51
Figura nº20: Modelo de llenado tabla Metrica ....................................................... 52
Figura nº21: Dimensión “Métrica” ........................................................................ 53
Figura nº 22: Dimensión “Producto” ..................................................................... 54
Figura nº 23: Dimensión “Cliente”........................................................................ 54
Figura nº 24: Dimensión “Vendedor”.................................................................... 54
Figura nº 25: Dimensión “Fecha”.......................................................................... 55
Figura nº 26: Grilla de Reporte 1 .......................................................................... 59
Figura nº 27: Gráfico de Reporte 1........................................................................ 59
Figura nº 28: Grilla de Reporte 2 .......................................................................... 60
Figura nº 29: Gráfico de Reporte 2........................................................................ 60
Figura nº 30: Grilla de Reporte 3 .......................................................................... 61
Figura nº 31: Gráfico de Reporte 3........................................................................ 61
Figura nº 32: Sistema BI Alirio Olivares S.A. ....................................................... 62
Figura n° 33: Clasificación PYMEs por ventas anuales ......................................... 68
Figura n° 34: Clasificación PYMEs por número de empleados ............................. 69

vi
Abstract
Strategic management support tools have been historically hard to acquire, being
reserved mostly for big enterprises. Nowadays there are great performance and low cost
(and even open source) alternatives to these tools. This allow an approachment between
business intelligence and smaller enterprises, letting them to include analysis tools as
dynamic dashboards, specially oriented to their business. The feasibility of a small or
medium enterprise business intelligence project it's about to be proved.

Resumen
Las herramientas de apoyo a la gestión estratégica han sido históricamente de difícil
adquisición, estando reservadas en su mayoría para grandes empresas. En la actualidad
existen alternativas de estas herramientas de bajo costo e incluso open source, de muy buen
desempeño. Esto permite hacer un acercamiento de la inteligencia de negocios a empresas
más pequeñas, permitiéndoles incluir herramientas de análisis como dashboards dinámicos,
especialmente orientados a su negocio. Está por probarse la factibilidad de un proyecto de
inteligencia de negocios en una PYME.

vii
1 Introducción
1.1 Descripción y Observaciones previas del proyecto
La motivación principal de este proyecto es investigar y experimentar hasta qué
punto podemos llevar tecnologías que históricamente han sido muy caras, a empresas de
limitados recursos. La directriz principal de este trabajo es, a su vez, demostrar que es
posible la implementación de un sistema de apoyo a la gestión en una PYME, en específico
un sistema de inteligencia de negocios.
El proyecto será realizado sobre una PYME de la región: Alirio Olivares S.A., una
empresa de compra – venta de artículos médicos, ubicada en Viña del Mar.
Este proyecto conjugará la investigación de las tecnologías necesarias para la
implantación de un sistema de apoyo a la gestión, como también la búsqueda de
metodologías que permitan un diseño correcto y eficiente. Además, se analizará a la
empresa en cuestión, con el fin de obtener un conocimiento de la situación inicial y estar al
tanto de posibles dificultades que puedan tenerse en el proceso, en cualquiera de sus etapas.
Debido a lo anterior, serán tomadas las precauciones que sean necesarias para evitar
un impacto cultural que atente contra las expectativas del proyecto.
Este informe expone las tecnologías que son necesarias para la implementación de
un sistema de inteligencia de negocios, tomando en cuenta cada uno de sus componentes.

1.2 La Empresa
Alirio Olivares S.A. compra y vende artículos médicos de toda clase, con excepción
de medicamentos. Vende desde parches y agujas hasta vaporizadores, camillas y sillas de
rueda. Sus compras no funcionan en base a importaciones, debido a que son una empresa
muy pequeña para traer grandes cargamentos, por lo que compran a intermediarios dentro
del país. Esto último hace que sus precios no sean los más convenientes.

Está conformada de 8 empleados:

 2 administradoras (socias y dueñas)

 1 ayudante administrativo (chofer de reserva)

 1 vendedor externo

 1 vendedor interno

 1 encargado de bodega

8
Introducción

 1 chofer

 1 peoneta

Su estructura organizacional está explicada por el siguiente diagrama:

Figura n° 1: Diagrama Organizacional Alirio Olivares S.A.

1.3.- Problemática
Durante años, Alirio Olivares S.A. se ha ganado la confianza y la fidelidad de sus
clientes. La mayoría de las ventas que realiza en el mes corresponde a clientes frecuentes.
Extrañamente, esta fidelidad se ha mantenido en el tiempo a pesar de que los precios
ofrecidos por la empresa no son los más convenientes del mercado.

Lo que explica lo anterior es su gran elemento diferenciador: el servicio de

despacho. Alirio Olivares ofrece despacho gratuito e inmediato todos los días hábiles, lo
que permite acudir a ellos en el momento que se necesite y no sólo para compras
programadas.
Sin embargo, debido a la crisis económica que aqueja al mundo hoy en día y a la
arremetida agresiva de los grandes del rubro, es muy difícil que el negocio crezca. Las
decisiones estratégicas se hacen cada vez más críticas y no se cuenta con las herramientas
indicadas para apoyar tales procesos. A lo anterior se le suma el alto costo de las
herramientas de apoyo a la gestión estratégica y su implementación.
No obstante, hoy en día existen alternativas gratuitas a las inalcanzables
herramientas conocidas y, además, grandes desarrolladores de herramientas de apoyo a la
gestión han lanzado suites de bajo costo para empresas pequeñas, acercando aún más una
solución de este tipo a una empresa como Alirio Olivares S.A.

9
2 Objetivos del Proyecto
2.1 Objetivo General

El objetivo de este proyecto es analizar, diseñar e implementar una solución de

inteligencia de negocios para una pequeña empresa de venta de artículos médicos.

2.2 Actividades del Proyecto

 Investigar y analizar los diferentes elementos de la Inteligencia de Negocios

 Recopilar información de la PYME en cuestión, su misión y visión y sus objetivos

corporativos

 Realizar análisis empresarial, cadena de valor y FODA

 Analizar la situación organizacional actual de la pyme en cuestión con los

resultados obtenidos en los análisis previos

 Modelar e implementar un datawarehouse

 Modelar e implementar un ETL

 Modelar e implementar un cubo multidimensional

 Implementar herramientas de análisis de inteligencia de negocio

10
3 Plan de Trabajo

 Investigación Tecnologías de Inteligencia de Negocios

 Recopilación y análisis de información relativa a situación actual de la pyme en

cuestión

 Análisis FODA

 Análisis y definición de situación actual de la empresa (problemática)

 Investigación, análisis y elección de metodología

 Investigación de diferentes proveedores de herramientas de inteligencia de negocios

 Análisis y diseño datawarehouse

 Análisis y diseño ETL

 Análisis y diseño cubo OLAP

 Elección de proveedor (o proveedores) de herramientas de inteligencia de negocios

 Construcción datawarehouse

 Construcción ETL

 Llenado datawarehouse

 Implementación herramientas de análisis

 Efectuar análisis

 Evaluación de la entrega

 Conclusiones con el cliente

11
Análisis

4 Estado del Arte

4.1 Aspectos Generales de la Inteligencia de Negocios
Inteligencia de Negocios es el proceso de conversión de datos en conocimiento para
alguna organización, aunque el término también incluye las herramientas y tecnologías
necesarias para lograr tal objetivo.

La inteligencia de Negocios comprende desde las tecnologías de almacenes de

datos (Data Warehousing) hasta las herramientas utilizadas para generación de reportes y
análisis, o sea, la creación de conocimiento corporativo.
Pero, ¿Qué ventajas trae manejar este nuevo conocimiento creado, antes no
poseído? Al implementar una solución de inteligencia de negocios, nuestro objetivo
primordial debiese ser el perseguir el liderazgo financiero, por lo que cabe preguntarse:
¿qué escenario o nueva visión serían estas herramientas capaces de entregarle a la
organización para ayudarle a alcanzar tal liderazgo?

4.1.1 Un poco de Historia

Los primeros modelos para el análisis de negocios fueron hechos con planillas de
cálculo. Aunque estas herramientas siguen usándose ampliamente hoy en día, este era el
método único en los años 80. Luego, hicieron su aparición los sistemas EIS, prometiendo
dejar al alcance de la mano toda la información clave para los ejecutivos, pero con el
problema de necesitar mucho trabajo manual para convertir y cargar los datos desde las
fuentes de datos.
Ya en los años 90, con la masificación del uso de SQL y la aparición del Data
Warehousing y de los ETL (extracción, transformación y carga), se cimentó la aparición de
la inteligencia de negocios. Con el correr de los años, en consecuencia, los sistemas de
apoyo a la toma de decisiones han evolucionado de un ambiente estático a la inteligencia de
negocios como la conocemos ahora.

4.1.2 Beneficios
Las ventajas de implementar una solución de inteligencia de negocios son muy
variadas y radican en la motivación que se tuvo para ponerla en marcha. Sin embargo, el
beneficio directo que se obtiene (o debería obtenerse) tras su implementación es la
agilización de la toma de decisiones.

12
Análisis

El éxito de la implementación de una solución de inteligencia de negocios depende

de los análisis previos, de la disposición de la entidad sobre la cual se implementa la
solución (permeabilidad tecnológica), y de la destreza de los desarrolladores y sus
contrapartes (usuarios).
Una de las grandes ventajas que una solución de esta naturaleza presenta es la
posibilidad de encontrar anomalías, fallos o incluso actividades fraudulentas dentro de la
organización.

4.2 Datawarehouses y Datamarts

Son repositorios de información de clientes, pudiendo ser esta de carácter
demográfico, de interacciones o transacciones. No están limitados al aspecto comercial,
aunque este es el uso más típico. Aunque son bases de datos como lo es también una base
de datos relacional, poseen una serie de características que los hacen ser diferentes.
Los Datamarts son más específicos en su contenido de información, mientras que
los Data Warehouses pueden llegar a contener datos de todos los departamentos de una
gran compañía, relacionando muchas veces áreas completamente ajenas una de otra.
Estos repositorios son el corazón de un sistema de inteligencia de negocios. De ellos
se extraerá la información necesaria para generar el conocimiento buscado. Su diseño está
basado en satisfacer a los analistas [Wolff, 02].

4.2.1 Características de los Datawarehouses

Los Data Warehouses (o almacenes de datos) combinan datos de todo tipo de fuentes,
son orientados al negocio, integrados, con variable tiempo, y manejan datos no volátiles,
con el fin de asistir el proceso de toma de decisiones [Walton y Cline, 00].

4.2.1.1 Orientados al Negocio

El diseño e implementación de un datawarehouse se hace en base a las necesidades
concretas de la organización. Esto quiere decir que un datawarehouse deja de lado toda
aquella información que no será utilizada en el proceso de toma de decisiones. Un
datawarehouse almacena información que servirá para hacer consultas acerca de la
organización; no tiene el fin de soportar los procesos operativos cotidianos que se realizan
en ella, por lo que maneja entidades de alto nivel. Esta característica supone la necesidad de
mantener la información desnormalizada (con redundancia de datos) y dimensionada, con
el fin de evitar recorrer la base de datos completa y así disminuir los tiempos de respuesta.

13
Análisis

4.2.1.2 Integrados
Los datawarehouses deben integrar todos los datos de diferentes fuentes, tanto
internas como externas, de manera tal de establecer una convención de nombres, unidades
de medidas, codificaciones, etc. El componente encargado de esta integración es el ETL. El
ETL (Extracción, transformación y Carga) será explicado más adelante.

4.2.1.3 Variante en el Tiempo

Una consulta en un datawarehouse no es instantánea (a diferencia de una consulta
en un ambiente operacional, en la que se espera instantaneidad), lo cual es parte de su
naturaleza. Sin embargo, los datos en un datawarehouse mantienen un sello de tiempo. Esto
posibilita el manejo de versiones de información dentro del mismo sistema, siendo un
factor positivo (y fundamental) en pos del manejo de información histórica, aspecto
esencial para el desarrollo de pronósticos y el estudio de tendencias y patrones.

4.2.1.4 No Volátil
Los datos en un datawarehouse son estables, a diferencia de un sistema operacional
en el que son constantemente cambiados (eliminaciones, modificaciones e inserciones).
Cuando los datos son consolidados en la base de datos con su sello de tiempo, permanecen
constantes con sus características de carga.

4.2.2 Ventajas de los Datawarehouses

 Apoya la toma de decisiones convirtiendo datos orientados a aplicaciones en

información orientada al negocio

 Integra fuentes de datos de diferentes orígenes, posibilitando unir elementos

empresariales que eran antes independientes y no relacionables

 Posibilita el análisis de diferentes áreas de trabajo

 Aumenta la capacidad de reacción ante cambios del mercado

 Aumenta competitividad

 Permite dejar de producir elementos no necesarios de ser utilizados o producto de

aplicaciones mal diseñadas

14
Análisis

 Mejora los tiempos y calidad de la información, proporcionando completitud,

correctitud, consistencia y accesibilidad.

 Aumento en eficiencia en encargados de la toma de decisiones

 Permite el acceso en línea a la información

 Permite acceso multiusuario a la información

 Permite mostrar información con herramientas de presentación familiares a la

mayoría de los usuarios, como lo son las hojas de cálculo, procesadores de texto,
software de análisis de datos, etc.

 Fuente de datos única

 Definiciones Consistentes

 Relaciones bien documentadas

 Tiempos de corte de servicios coordinados

Esto es muy importante debido a las tendencias y necesidades actuales, encontrándose

entre las más importantes:

 Sistemas centralizados e integrados

 Usuarios no estáticos (escalables)

 Prioridad de la seguridad

 Conexión en tiempo real

 Aumento de la criticidad de la disponibilidad de los sistemas (24/7)

 Inclusión de fuentes de datos externas

15
Análisis

4.2.3 Desventajas de los Datawarehouses

 Requiere de una inversión importante; se necesitan, en la mayoría de los casos,
muchos recursos para implementarlos.

 Resistencia al cambio en usuarios no experimentados

 Resultados positivos visualizables en el mediano a largo plazo, por lo que puede

producir desmotivación

 Información de alta criticidad visible a usuarios: se genera una nueva

responsabilidad (usuario del datawarehouse manejará datos personales de clientes)

 Incremento continuo de los requerimientos del usuario (que, según sea el caso,
puede verse como una ventaja)

 Subestimación de recursos necesarios para captura, carga y almacenamiento de

datos

 Subestimación de de esfuerzo necesario para su diseño y creación

 Subestimación de sus capacidades

4.2.4 Modelos de Data Warehouses

4.2.4.1 Modelo Estrella
El modelo estrella contiene una tabla de hechos y una serie de dimensiones en
profundidad simple, es decir, sin relaciones con otras tablas más allá de la misma
dimensión. Tiene como ventaja mayor velocidad de procesamiento, al prescindir de
operaciones “join” para relacionar a las demás tablas. Su desventaja es el almacenamiento
por la desnormalización, pero esto es poco crítico.

16
Análisis

Figura n° 2: Ejemplo de modelo estrella

4.2.4.2 Modelo Copo de Nieve

El modelo copo de nieve mantiene relación de sus dimensiones con otras tablas, con
el fin de clarificar lógicamente las relaciones jerárquicas. Su gran desventaja es el
performance, dado los numerosos “joins” necesarios para las consultas. Su ventaja es el
espacio en disco, dada la normalización de datos.

Figura n° 3: Ejemplo de modelo copo de nieve

17
Análisis

4.3 ETL (Extraction, Transformation and Load: Extracción,

Transformación y Carga)
Es la aplicación encargada de automatizar el llenado de datos del datawarehouse.

La extracción de datos se hace de fuentes externas, pudiendo ser estas desde

archivos de texto plano, pasando por planillas Excel, hasta otras bases de datos, por lo
general de información a nivel transaccional, como lo sería una base de datos relacional.
La transformación de los datos tiene como única función hacer calzar los mismos
según las necesidades operacionales del datawarehouse.
La carga corresponde al proceso final, donde los datos, ya transformados, son
ingresados al repositorio de la solución BI.

4.3.1 Importancia de los ETL

Es un gran y conocido problema el hecho de que diferentes desarrolladores de
software no tienen buena compatibilidad entre ellos. La unidad de intercambio de datos más
sencilla y frecuente es el archivo de texto, pero la carga manual de estos puede ser
imposible en casos que su cuantía exceda ciertos niveles.
Un ETL posibilita obtener agilidad en la generación del conocimiento deseado,
puesto que debe ser definido una sola vez, para luego ser ejecutado de manera automática,
entregando dinamismo para etapas posteriores.

Figura n° 4: Evolución del proceso de carga de datos

18
Análisis

De un punto de vista más gráfico, el correcto uso e implementación de un ETL

posibilita la comunicación ideal entre los datos operacionales hacia las herramientas de
inteligencia de negocios, utilizando un datawarehouse o datamart como único paso
intermedio: destino de la información histórica y fuente de conocimiento BI.

Figura nº 5: Poblamiento y utilización de datos del datawarehouse

4.4 OLAP (On-Line Analytical Processing)

OLAP es una categoría de tecnología de software. Se basa en el uso de bases de
datos multidimensionales para proveer a analistas, administradores y ejecutivos una visión
rápida, consistente e interactiva de una amplia variedad de información. Se diferencia al
uso exclusivo de un datawarehouse en que provee acceso rápido a información estratégica
para su análisis posterior [Forsman, 97].
El acrónimo OLAP sugiere diferentes explicaciones dependiendo del área específica
al que este se refiere. Podemos, en consecuencia, hablar de: conceptos OLAP, lenguajes
OLAP, capas de producto OLAP y de productos OLAP completos [Thomsen, 02].

4.4.1 Cubos OLAP

Se le llama cubo al mecanismo de organización y sumarización de datos dentro de
una estructura multidimensional. La estructura de un cubo es diseñada de acuerdo a las
necesidades del negocio en particular. El cubo OLAP puede ser basado en una
representación lógica de una base de datos, como puede estar pareado 100% con la misma.
Dicha dualidad se ve representada y explicada en los tipos de OLAP, encontrándose entre
los más comunes ROLAP y MOLAP. En el primero la representación del cubo es un
reordenamiento de datos lógico y en el segundo es directa con una base de datos física.

19
Análisis

4.4.2 Tipos de OLAP

4.4.2.1 ROLAP (Relational On-Line Analytical Processing)
Consiste en tecnología OLAP construida sobre una base de datos relacional,
generalmente un datawarehouse. Las consultas se hacen directamente sobre la base de datos
y los problemas de performance se solucionan mediante el uso de índices [Kotler y Ketler,
06].
Un cubo ROLAP se basa en el modelo del datawarehouse y es de tipo lógico, lo que
quiere decir que es una representación multidimensional de la base de datos con una
motivación específica del negocio.
En un sistema ROLAP se evitan las redundancias de datos, al mantener la totalidad
de la información en el repositorio físico de origen, y hacer los modelos del negocio de
manera lógica [Kotler, Armstrong, Cámara, y Cruz, 04].

4.4.2.2 MOLAP (Multidimensional On-Line Analytical Processing)

Consiste en tecnología OLAP que utiliza una base de datos multidimensional para
realizar los análisis. A diferencia del ROLAP, sí utiliza un repositorio físico, conllevando a
la replicación casi total de los datos (dependiendo de las necesidades del negocio).
Esta estrategia evita el uso de consultas SQL para efectuar el análisis. La
navegación de los datos es más natural, al permitirse drill downs y roll ups: aumento y
disminución de detalle de información de manera instantánea, navegando por las jerarquías
del cubo [Piedrabuena, 05].

4.5 Tendencias
La popularidad de la tecnología de inteligencia de negocios en los últimos años la
ha llevado a posicionarse firmemente entre empresas de cada vez más cantidad de tamaños.
Esto significa que la accesibilidad a esta es cada vez mayor para empresas con menor poder
adquisitivo. De la mano de la aparición de herramientas de código abierto, como Pentaho,
también han hecho su entrada soluciones de bajo costo de grandes empresas como Oracle,
como su producto Oracle BI Standard Edition One, que cuenta con base de datos, ETL y
herramientas de análisis por un precio bajo.

20
Análisis

5 Elementos de Análisis Empresarial

Para proporcionar una solución que sea beneficiosa, es necesario conocer en
profundidad la realidad de la empresa. Para esto, no solo basta con conocer en las
características de la empresa en particular, sino también el comportamiento del entorno y la
influencia que tiene sobre ella.

5.1 Misión y Visión

Es imprescindible conocer a la empresa desde afuera, como también es muy
importante estudiar cómo la ven sus dueños, gerentes, administradores e incluso operarios.
La misión y la visión de la empresa servirán para ser alineados con los análisis que serán
desarrollados sobre la misma y poder determinar estrategias. Buenas misiones y visiones
buscan sueños casi imposibles de ser realizados. Este estado empresarial ideal y
virtualmente inalcanzable que se presenta más que como un objetivo como una filosofía, es
precisamente el más apropiado [Llombart, 08].

5.1.1 Misión
Es un elemento fundamental para la planificación estratégica, puesto que de ella se
obtienen los objetivos organizacionales [Piedrabuena, 05]. Por consiguiente, es materia de
este proyecto, ya que las herramientas de inteligencia de negocios son un apoyo a la toma
de decisiones, lo que está estrechamente relacionado con los objetivos de la empresa.
Una versión más radical de lo que es la misión de una empresa consiste en que esta
contesta a la pregunta de por qué existe la empresa [Diez de Castro, 01].

5.1.2 Visión
La visión define hacia dónde va la empresa en el largo plazo y orienta las decisiones
estratégicas y de competitividad [Fleitman, 99]. Una característica que tiene la visión es la
de no centrarse única y exclusivamente en el presente de la organización, sino más bien en
las posibles situaciones que se podrían generar con el llegar de nuevas tecnologías, desafíos
productivos, nuevas competencias, etc. [Thomson, 01].

5.2 Análisis FODA

El análisis FODA es una herramienta muy útil de apoyo a la planeación estratégica.
Proporciona información fundamental para la toma de acciones ya sean correctivas
(eliminación o modificación de elementos) o de adición de elementos faltantes o
potencialmente útiles.

21
Análisis

El análisis FODA tiene la ventaja de ser muy simple y fácil de implementar, lo que
hace de esta herramienta un acercamiento muy rápido y eficaz para empresas de pequeño
tamaño al análisis empresarial [Maturana, 02].

FODA es un acrónimo que significa fortalezas, oportunidades, debilidades y

amenazas. El análisis FODA es una metodología que estudia la situación competitiva de
una empresa en su mercado. Estudia tanto sus características internas como externas
[Kotler y Ketler, 06].

Figura nº6: Dimensiones del análisis FODA

El análisis FODA considera diferentes factores o dimensiones. Estos son los

factores económicos, políticos, sociales y culturales. Cada uno de esos aspectos influirá de
diferente manera, dependiendo de la ubicación geográfica e incluso temporal de la
organización. Las dimensiones del FODA son explicadas en la figura nº 5.
En consecuencia, por lo anterior, tenemos que un análisis FODA tiene relación
exclusiva con el tiempo en el que fue confeccionado, es decir, un análisis realizado en el

22
Análisis

año 2005 no arrojará los mismos resultados que uno del 2009 de la misma empresa
[Instituto Politécnico Nacional, 02].

5.2.1 Variables de Análisis

5.2.1.1 Variables Internas

5.2.1.1.1 Fortalezas
Son capacidades que tiene la empresa que potencian una posible diferenciación
positiva sobre los demás competidores. Son recursos controlados directamente por la
empresa, habilidades o cualidades en general.

5.2.1.1.2 Debilidades
Son factores internos que gatillan una posición desfavorable frente a los
competidores. Son las carencias de habilidades y cualidades de la empresa.

5.2.1.2 Variables Externas

5.2.1.2.1 Oportunidades
Son todos aquellos aspectos del entorno que resultan positivos y que, de alguna
manera, permiten a la empresa beneficiarse de ellos. Son los aspectos externos a la empresa
que proporcionan elementos de diferenciación con respecto a la competencia.

5.2.1.2.2 Amenazas
Son todas las situaciones externas a la empresa que pueden poner en riesgo la
capacidad competitiva de la misma. Pueden ser tan fuertes como para llegar a poner en
duda la permanencia de la organización. Son variables muy poderosas que difícilmente
pueden ser evadidas del todo, sin embargo, sus efectos han de ser minimizados luego de ser
identificadas.
La identificación de las variables internas y externas puede ser asistidas con el
reconocimiento de las actividades primarias y de apoyo según la teoría de la cadena de
valor [Hax y Majluf, 04].

23
Análisis

5.2.2 La Matriz FODA

Esta es una matriz simple de 2 x 2 celdas en la que se listan por orden de
importancia cada uno de los aspectos internos y externos, positivos y negativos de la
organización. Un ejemplo de matriz FODA genérico es mostrado a continuación.

Figura nº 7: Matriz FODA genérica

5.2.3 Estrategias
Dados los resultados del análisis en la matriz FODA, es necesario adoptar una
iniciativa que permita hacer frente (o tomar ventaja) de la situación que se enfrenta. De la
misma matriz FODA se desprenden 4 estrategias [Marquez, 99].

5.2.3.1 Estrategia DA (Mini - Mini)

Consiste en minimizar las debilidades y las amenazas. En el caso que una empresa
se enfrente a una mayoría de debilidades y amenazas sería una situación más que
preocupante, en la que la organización tendría que preocuparse básicamente por no
desaparecer. En la mayoría de los casos, esta estrategia debería tratar de evitarse.

5.2.3.2 Estrategia DO (Mini – Maxi)

Consiste en minimizar las debilidades y maximizar las oportunidades. Podría darse
el caso en el que el ambiente ofrezca oportunidades que la organización es incapaz de
aprovechar debido a carencias internas en particular. Por consiguiente, esta estrategia
sugiere proponer los cambios internos necesarios para hacer frente a este
desaprovechamiento de posibilidades. Cabe destacar que el resultado de un análisis DO
podría arrojar el no aprovechar la oportunidad.

24
Análisis

5.2.3.3 Estrategia FA (Maxi – Mini)

Consiste en maximizar las fortalezas y minimizar las amenazas. Se busca potenciar
aquellas fortalezas que pueden que anulan o al menos apaciguan los efectos de ciertas
amenazas. Es muy importante aclarar que una empresa fuerte no necesita una búsqueda
extensa de amenazas; éstas deben tratarse a medida que son identificadas.

5.2.3.4 Estrategia FO (Maxi – Maxi)

Consiste en maximizar las fortalezas y maximizar las oportunidades. Es la situación
ideal en la que cualquier empresa buscará encontrarse. En este caso es posible hacer uso y
potenciar las fortalezas para hacer mejor frente de las oportunidades existentes. Es posible
también, en caso que se esté en una situación de éxito y estabilidad, intentar transformar las
debilidades en fortalezas, como también sortear las amenazas para enfocarse en las
oportunidades.

25
Análisis

6 Análisis de la empresa
6.1 Misión y Visión
Estudiar la misión y visión de la empresa ayuda a entender de mejor manera sus
motivaciones y anhelos. Esto deberá alinearse con los resultados del análisis FODA y con
la estrategia a seguir.

6.1.1 Misión
“Nuestra misión es satisfacer las necesidades de nuestros clientes del mercado de
insumos médicos con integridad, ofreciendo productos y servicios de la mejor calidad y
variedad a un precio justo. Agregaremos valor a estos productos ofreciendo un excelente
servicio de despacho y poniendo a su disposición los más de 40 años de experiencia que
nos avalan.”

6.1.2 Visión
“Nuestra visión es liderar el mercado de venta y distribución de insumos médicos a
lo largo de la V Región, con el mejor equipo de trabajo y tecnología disponible para
satisfacer las necesidades de nuestros clientes, especialmente en el área de la salud pública
y privada, industria y la seguridad.”

6.2 Análisis FODA

Para el reconocimiento de las fortalezas, debilidades, oportunidades y amenazas, se
identificarán las actividades primarias y secundarias presentes en la organización.

 Actividades Primarias

o Logística de Entrada: Recepción de productos ordenada y controlada.

Gestión de stocks manual. Programación del arribo de productos
dependiente directamente de la orden de las dueñas.

o Operaciones: Sistema de re – embalaje y creación de packs promocionales

amoldado a necesidades del cliente.

o Logística de Salida: Sistema de despacho inmediato. Sala de preparación de

despachos para agilizar los mismos.

26
Análisis

o Comercialización y ventas: Excelente relación de la empresa con sus

clientes. Canales exclusivos en base a confianza y fidelidad de los clientes.

o Servicio de post – venta: Contacto con el cliente para posibles reembolsos.

 Actividades de apoyo

o Adquisiciones: Constante búsqueda de proveedores más convenientes.

o Desarrollo de la tecnología: Conocimiento de los productos transados.

Constante innovación de acuerdo a actualidad tecnológica.

o Gestión de recursos humanos: Fomento de la confianza y motivación a sus

empleados con incentivos y ofrecimiento de participación. Relación cercana
entre empleados y dueñas.

o Infraestructura gerencial: Gestión gerencial suficiente. Gestión financiera y

de ventas deficiente.

Con el fin de analizar la influencia del entorno sectorial y el macro entorno sobre la
empresa, es que realizamos un análisis de 5 fuerzas de Porter:

 Amenaza de entrada de nuevos competidores

o Bajas barreras de entrada

o Economías de escala amenaza constante; grandes empresas del rubro

manejan precios muy convenientes

o Existe gran valor de marca en la quinta región, siendo una empresa conocida
y solicitada por su gran prestación de servicios adicionales a la mera venta

o El coste de cambio es bajo, por lo que significa una amenaza de entrada de

nuevos competidores

o Requerimiento de capital relativamente bajo, siendo esto una amenaza de

entrada de nuevos competidores

27
Análisis

o Ventaja absoluta de coste no efectiva, por lo que es una amenaza

o Existe una ventaja en la curva de aprendizaje, dada la cantidad de años en el

rubro.

o El incumplimiento es castigado ampliamente en este sector, puesto que son

bienes que no pueden demorar en ser obtenidos (primera necesidad). Al ser
una empresa ordenada y cumplidora, se entiende esto como una oportunidad

o Las mejoras en tecnologías no son factor en este negocio, por lo que no

representan una amenaza, pero tampoco una oportunidad

 Poder de negociación de los proveedores

o Esto no representa una amenaza, dado que existen numerosas opciones de

compra para artículos médicos. No son artículos altamente específicos y las
vías de compra van desde la compra a importadores hasta la importación
directa, en caso de grandes volúmenes para ciertos artículos.

 Poder de negociación de los compradores

o En este punto se considera que los compradores sí tienen buen poder de

negociación, pero sólo hasta cierto nivel, puesto que el elemento
diferenciador de la empresa (su excelente servicio de despacho) hace que
este atributo mengüe considerablemente.

 Amenaza de ingreso de productos sustitutos

o No existe propensión por parte del consumidor a sustituir, puesto que son
elementos de primera necesidad y no se puede escatimar en ellos.

o El coste de cambio del comprador es bajo, dado que existen otras empresas
de compra y venta de artículos médicos que venden productos similares. Sin
embargo, si se toman en cuenta los servicios adicionales de post venta que
entrega la empresa, este costo aumento en cierto sentido.

28
Análisis

 Intensidad de la rivalidad de los competidores

o Existen diversos competidores, numerosas pequeñas empresas dedicadas a

lo mismo y unos cuantos grandes del rubro.

o Los costos fijos de la actividad son bajos, por lo que la competencia se hace
más dura según ese respecto.

o La empresa en cuestión goza de mejor posicionamiento que las demás

pequeñas empresas del rubro en la zona, pero las grandes la superan. El
posicionamiento en cuentas pequeñas es liderado por la empresa en cuestión,
dado su sistema de servicio de despacho inmediato, servicio único en su
categoría.

A partir de la identificación de las actividades primarias y de apoyo se reconocen los

siguientes elementos del FODA:

6.2.1 Fortalezas
 Buena relación con proveedores

 Confianza ya ganada de clientes importantes

 Excelente servicio de despacho

 Buena salud de estados contables

 Equipo de trabajo comprometido

6.2.2 Debilidades
 Poca variedad de productos

 Baja capacidad de bodegaje

 Precios Altos

29
Análisis

6.2.3 Oportunidades
 Cambio monetario favorable

 Buena reputación potencial fuente de nuevos clientes

 Baja de precios en importaciones por crisis mundial

 Recesión disminuye probabilidad de nuevos competidores

6.2.4 Amenazas
 Crisis cohíbe expansión de los negocios

 Importaciones tienen precios excesivos en cantidades pequeñas

 Grandes del rubro con mayor poder de manejo de precios

6.2.5 Estrategia
Analizando sólo los factores internos, podemos determinar que la empresa posee
grandes fortalezas, las que claramente han sido fundamentales para la supervivencia en un
mercado tan turbulento como en el de la venta de artículos médicos. De todas ellas, el muy
buen servicio de despacho ha sido un gran elemento de diferenciación. Con respecto a las
debilidades, son elementos que la empresa ha sabido manejar. Aunque sería muy positivo
mejorarlos, es más conveniente enfocar la estrategia en las fortalezas.
Debido a la crisis económica y a la inestabilidad política e incluso social que existe en
gran parte del mundo, son las amenazas las que adquieren una connotación diferente. Si
bien es cierto existe una cantidad importante de oportunidades, las amenazas son mucho
más críticas en este caso (atentan contra la permanencia de la empresa).
La fuerza e importancia que adquieren las amenazas en este caso podrían suponer una
estrategia de supervivencia, pero considerando que Alirio Olivares S.A. es una empresa
fuerte internamente y que, durante años, ha permanecido vigente gracias a esa virtud, es
que se descarta una medida tan extrema. Por lo anterior es que se propone una estrategia
defensiva que haga frente a las peligrosas amenazas, potenciando las fortalezas que puedan
coparlas, es decir, estrategia FA (Maxi – Mini).

Un análisis mayor de la estrategia a seguir escapa al alcance de este proyecto. No

obstante, han sido trazadas importantes directrices sobre las cuales debiese concentrarse la
funcionalidad de las herramientas de inteligencia de negocios que se desean implementar.

30
Análisis

7 Metodología
La utilización de una metodología de trabajo es lo primordial para asegurar que las
distintas etapas del proyecto se alineen entre ellas con el fin de conseguir el objetivo
principal. Usar una metodología en proyectos en los que no se tiene experiencia previa se
hace aún más necesario, como medida cautelar a posibles problemas. Dicho de otro modo,
trabajar al amparo de la madurez de una metodología sólida proporciona seguridad y
consistencia en el desarrollo de las distintas tareas involucradas en el proyecto.

La metodología debe ser lo suficientemente flexible como para hacer posible la

realización de un proyecto de esta naturaleza en una empresa pequeña. Esto quiere decir
que debe ser posible hacerle modificaciones a la metodología escogida, tomando en cuenta
que la magnitud de un proyecto BI en una PYME será bastante pequeño en comparación a
empresas grandes.
Las metodologías existentes son, en su mayoría, para desarrollar proyectos TI
genéricos. Sin embargo, existe una cuyo eje fundamental son los proyectos de inteligencia
de negocios: la metodología de Larissa Moss. Moss considera todas las etapas necesarias en
un proyecto BI, incluso más de las necesarias en un proyecto más reducido como lo es éste.
Sin embargo, Moss identifica y clarifica cada una de las etapas de su metodología, haciendo
fácil la elección de los pasos que no son necesarios de ser utilizados.

7.1 Kimball e Inmon

Kimball e Inmon apuntan a la creación de los componentes de un proyecto BI más
que a su integración con la organización. Esto puede ser muy nocivo en un proyecto en el
que no se tiene mucha experiencia y en el que se necesita un hilo conductor de principio a
fin. A continuación analizaremos a grandes rasgos las metodologías de Kimball e Inmon.

7.1.1 Kimball (Bottom Up)

La propuesta de Kimball consiste en generar un data warehouse a partir de la unión
de 2 o más data marts. Para eso, es necesario identificar las diferentes unidades de negocio
que serán parte de la organización y generar un data mart de cada una de ellas. Para
Kimball, el data warehouse de la organización es simplemente la unión de cada uno de los
data marts formulados (Kimball, 2002). El siguiente diagrama explica la visión bottom up
de construcción de data warehouse propuesta por Kimball:

31
Análisis

Figura nº 8: Data warehouse según Kimball

Este enfoque es muy simple de entender y de poner en práctica. La identificación de

las unidades de negocio puede llegar a ser casi trivial. Es a la hora de unir los data marts
que la complejidad aumenta. Darle un sentido transversal a un grupo de data marts puede
ser una tarea compleja y delicada, en donde el principal cuidado debe ser no perder el foco
del proyecto general.
Sin embargo, en el caso de este proyecto, existe sólo una unidad de negocio
identificable, dado que es una empresa pequeña. Esto simplifica mucho el problema,
quedando el data warehouse constituido por un solo data mart.
Kimball propone 4 pasos para la construcción de un data mart. Estos pasos son los
siguientes:

1.- Seleccionar el proceso de negocio para modelar:

En este paso debe fijarse el negocio que será modelado por el data mart. Posibles
negocios a modelar pueden ser ventas, inventario o proveedores.

2.- Declarar la granularidad del proceso de negocio:

Esto es especificar la información que provee cada hecho de la tabla de hechos.
Kimball propone tener especial cuidado en este punto, ya que una mala decisión en esta
etapa del proyecto puede llevar a un problema muy costoso de ser solucionado en el futuro.
Kimball propone no escatimar en la elección de la granularidad de los datos y especificar la
mayor cantidad de detalle disponible, a no ser que se esté completamente seguro.

32
Análisis

3.- Escoger las dimensiones que apliquen a cada fila de la tabla de hechos:
La elección de las dimensiones se obtienen de responder la pregunta: “¿Cómo se
pueden describir los datos que resultan del proceso de negocio?”. Dicho de otro modo, las
dimensiones son descriptores de cada una de las filas de la tabla de hechos.

4.- Identificar los hechos numéricos que poblarán cada una de las filas de la
tabla de hechos:
Los hechos se desprenden de la pregunta: “¿qué queremos medir? “. La elección de
cada hecho debe tener estrecha relación con la elección de la granularidad (paso 2).

7.1.2 Inmon (Top Down)

La propuesta de Inmon consiste en modelar un data warehouse general y transversal
a toda la organización y, luego, desagregarlo en 2 o más data marts [Inmon, 96]. La visión
top – down de Inmon implica la creación de data marts a partir de una idea macro, por lo
que no debe perderse el foco general. Los procedimientos necesarios para la división de un
data mart son complejos y lejos de la trivialidad.

Figura nº 9: Data warehouse según Inmon

La visión más corporativa y amplia de Inmon la hace una buena opción para
proyectos de gran magnitud, pero no es una opción simple de implementar. Los procesos
necesarios para desagregar un data warehouse en distintas unidades base o data marts son
complejos.

33
Análisis

7.2 La Metodología de Larissa Moss

La metodología de Moss propone una serie de pasos para la creación de la solución
BI, desde la justificación del proyecto hasta la implementación del ETL y data warehouse
[Moss, 03]. Los pasos identificados.

Como se explicaba, la metodología de Moss considera cada una de las etapas del
ciclo BI, pero además ofrece la posibilidad de dejar de lado ciertos pasos de la metodología,
advirtiendo oportunamente los riesgos que implica omitir cada uno de los pasos. Sin
embargo, en un proyecto pequeño existen varios de estos riesgos que no aplican de la
misma manera que un proyecto grande, como también hay riesgos que pueden acrecentarse.
Es por esto último que una adecuación de la metodología a la realidad del presente proyecto
se convierte en una acción obligada.
Las evidencias previamente mostradas ratifican a Moss como la metodología idónea
para este proyecto. No obstante, como también ya se estableció, serán realizadas ciertas
modificaciones en ella para que calce con la realidad de este proyecto.
Las etapas y flujo de la metodología de Moss están ilustrados en la siguiente figura:

34
Análisis

Figura nº10: La metodología de Larissa Moss

A continuación, se describirán estas etapas, en función de su posible aplicación en

este proyecto:
35
Análisis

7.2.1 Justificación
Paso 1: Estudio de caso de negocio
En este paso deben presentársele al cliente las razones por las cuales debe ser
implementado el proyecto. Dicho de otro modo, se refiere al momento en que el cliente es
convencido con buenas y claras razones para poner en marcha el proyecto.
Este paso cobra vital importancia al tratarse de la instancia propicia para explicar el
por qué de un proyecto BI en una PYME. Esto es muy importante si va de la mano con
justificación del proyecto con el cliente, ya que él será el primero que deberá entender y
creer que incursionar en el proyecto será beneficioso para su empresa.

7.2.2 Planeación
Paso 2: Evaluación de la infraestructura de la empresa
En este paso se describe la infraestructura técnica y no técnica propia de la empresa
que formará parte de la infraestructura del proyecto, o que de alguna manera se conectará a
él. Además, es necesario especificar qué componentes serán tomados desde los ya
existentes y cuáles son necesarios de ser incorporados.
La especificación de la infraestructura técnica será muy útil para el diseño del ETL
y para mayor claridad y transparencia en la etapa de implementación. Sin embargo, Alirio
Olivares S.A. cuenta con apenas un sistema transaccional de facturación simple y no
existen repositorios de metadata o modelos lógicos que pudiesen ser importados o
reciclados. Por esto último, este paso se reducirá a la evaluación de la infraestructura
técnica de la empresa.

Paso 3: Planeación del proyecto

En este paso se define el plan a seguir del proyecto. Un plan adecuado considera
qué se construirá, cuándo se hará, cuánto costará y quién lo hará. Aunque las 2 últimas
interrogantes de las 4 mencionadas no son de vital consideración en este proyecto, sí lo son
las 2 primeras.

7.2.3 Análisis del negocio

Paso 4: Definición de los requerimientos del proyecto
Los requerimientos del proyecto tienen directa relación con el proceso de negocio.
En términos simples, los requerimientos se traducen en lo que se quiere saber de modelar
determinado proceso de negocio. Una buena captura de requerimientos del proyecto se
traducirá en un buen diseño de los distintos elementos de la solución de inteligencia de
negocios.

36
Análisis

Paso 5: Análisis de datos

El análisis de datos se refiere a cómo se tratan los mismos dentro del proyecto, su
análisis estructural (cómo se ordenan) y de pureza (limpieza de datos). Para analizar los
datos en su estructura, Moss propone dos métodos bastante parecidos a los de Kimball e
Inmon. Estos son los enfoques bottom up y top down respectivamente. Como ya se dijo
anteriormente, una PYME cuenta con solo una unidad de negocio, por lo que la elección de
cualquiera de estos dos enfoques puede omitirse.
No obstante, será necesario tener cuidado con la limpieza de los datos. Esto es,
elegir correctamente los datos que apoyan los requerimientos de negocio del proyecto.

Paso 6: Creación de un prototipo de la aplicación

La creación de un prototipo de una aplicación simple puede reemplazarse con la
exhibición de una aplicación de ejemplo de la suite escogida. Pentaho cuenta con una
aplicación de ejemplo en su página Web y puede navegarse de manera gratuita.

Paso 7: Análisis del repositorio de metadata

En este paso se definen dos tipos de metadata: la metadata de negocio y la metadata
técnica. La metadata de negocio se refiere al manejo de perfiles de usuario y roles en el
sistema. La metadata técnica se refiere a los nombres que describirán la información en el
sistema mismo (bases de datos, cubos).
Con respecto a la metadata de negocio es totalmente prescindible en este proyecto,
dado que será utilizado por a lo más dos personas (dos socias).

Con respecto al repositorio de metadata técnica, es bastante prescindible

considerando la magnitud del proyecto.
En conclusión, se prescindirá de este paso.

7.2.4 Diseño
Paso 8: Diseño de la base de datos
Moss propone un diseño de base de datos orientado a los requerimientos de grandes
proyectos, que consideren la desagregación top down o integración bottom up. Sin
embargo, existiendo una única unidad de negocio como parte del sistema, se evidencia la
conveniencia de utilizar un enfoque que ataque en detalle la creación de un data mart.
Por lo anterior, se usará el enfoque de Kimball para el diseño de la base de datos,
por su simpleza y por estar enfocado principalmente al desarrollo de cada data mart por
separado (que sería la totalidad del presente proyecto). Con esto, se prescinde del paso
posterior de integración de data marts, considerando lo generado como la única unidad de
base de datos física del proyecto.

37
Análisis

Figura nº 11: Relación uno a uno de data mart y data warehouse

Paso 9: Diseño del ETL

Moss propone un diseño detallado del ETL, para cada una de sus capas: extracción,
transformación y carga. Aunque el tamaño del ETL de este proyecto será bastante pequeño
y simple, es necesario especificar el flujo que tendrán los datos desde la fuente hasta la capa
de análisis. Esto permitirá establecer más fácilmente las políticas de manejo de datos una
vez puesto en marcha el sistema.

Paso 10: Diseño del repositorio de metadata

El diseño del repositorio de metadata no será implementado, dado que no se
realizará el análisis. Tampoco lo será el desarrollo del repositorio de metadata.

7.2.5 Construcción
Paso 11: Desarrollo del ETL
Este paso contempla la construcción del ETL, como también el desarrollo del plan
de pruebas respectivo para analizar la integridad de los datos cargados en el data
warehouse.

Paso 12: Desarrollo de la aplicación

Este paso cosiste en el desarrollo de las aplicaciones BI propiamente tal, como
cubos OLAP, reportes, dashboards, etc. La creación de estas aplicaciones debe estar en
directa relación con los requerimientos establecidos en las etapas anteriores. Se considera
tanto el diseño como la creación y prueba de las aplicaciones.

Moss propone la utilización de 4 ambientes para cada una de las etapas del
desarrollo de aplicaciones de inteligencia de negocios. Estos son:

 Ambiente de prototipado: Donde se prueba la tecnología en términos genéricos. Son

solidificados los requerimientos del proyecto.
38
Análisis

 Ambiente de desarrollo: Donde las aplicaciones son creadas y probadas por los
desarrolladores.

 Ambiente de QA (aseguramiento de calidad): Donde los scripts y programas son

probados antes que sea aprobado el paso a ambiente de producción.

 Ambiente de producción: Donde las aplicaciones serán ejecutadas después que sea
puesto en marcha el sistema.

El número de ambientes puede reducirse si el tamaño del proyecto así lo sugiere.

Para este proyecto, serán considerados dos ambientes: el de desarrollo y el de producción,
quedando las pruebas como parte del ambiente de desarrollo.
Paso 13: Data mining
En este paso se define y especifican las actividades de data mining. En cualquier
caso, data mining no es alcance de este proyecto, por lo que podemos a priori establecer
que no será utilizada esta parte de la metodología.

Paso 14: Desarrollo del repositorio de metadata

Este paso no será considerado, como tampoco lo serán los pasos 7 y 10.

7.2.6 Despliegue
Paso 15: Implementación
Este paso consiste en el despliegue de la solución en el ambiente de producción.
Considera entre sus actividades:

 Manejo de la seguridad

 Respaldos y recuperación

 Monitoreo de utilización de recursos

 Manejo del crecimiento

Paso 16: Evaluación de la entrega

En este paso, se propone una serie de guías y esquemas para evaluar la versión
desplegada. Consiste en la realización de revisiones y comparaciones con el fin de evaluar
los diferentes ámbitos del sistema, como tiempo de entrega, presupuesto, satisfacción del
cliente, alcance, entre otros.

39
8 Desarrollo del Problema
El sistema será desarrollado de la mano de la metodología de Larissa Moss,
utilizando la metodología de Kimball para el diseño del data warehouse. Las etapas de la
metodología de Moss seleccionadas para este proyecto quedan ilustradas en la siguiente
figura:

Figura nº12: Metodología de Moss adaptada

40
Diseño

8.1 Justificación

8.1.1 Estudio de caso de negocio

Las soluciones BI ofrecen ventajas competitivas con respecto a la manera en que es
posible analizar la historia para tomar mejores decisiones en el futuro. Esto es a grueso
modo, pero el cuadro es muy diferente si comparamos empresas de gran tamaño con
PYMES. Una empresa grande, o mejor dicho, un holding o grupo económico, tendrá que
necesariamente incorporar tecnologías de análisis de datos si su intención es no verse
sobrepasado por competidores más preparados para el cambio. En el caso de las empresas
pequeñas el escenario es bastante diferente, donde la incorporación de tecnologías
innovadoras es considerada una decisión arriesgada.

Pero, ¿qué argumento podría darse para la implementación de una solución BI en

una PYME?
Ya es sabido que una solución de inteligencia de negocios bien implementada
otorga una ventaja competitiva y, en el caso de una PYME, esa ventaja sería aún mayor,
considerando que muy pocas empresas de similar tamaño tomarían una decisión parecida.
Esto sigue siendo un argumento débil, pero es, al menos, un buen indicio.
Al incurrir en cualquier inversión, es necesario tener conocimiento del negocio en el
que se está entrando: deben manejarse muy claramente los objetivos del negocio, contar
con un análisis del mismo, hacer un análisis de los costos y los beneficios que se obtendrían
y saber a los riesgos a los que se está expuesto.

Conductores de Negocio
Los conductores de negocio corresponden a la motivación por la cual se incurrirá en
el proyecto. Alirio Olivares S.A. es una empresa pequeña que se ha mantenido en el tiempo
muy sólidamente gracias a una gran relación con su clientela. Sin embargo, lleva años sin
experimentar un crecimiento significativo. Esta congelamiento del negocio se debe a que el
manejo “por olfato” de una empresa tiene un límite relacionado con el tamaño de esta. Esto
quiere decir que mientras más crece la empresa, más difícil es visualizar la información que
la historia de la misma presenta y, por ende, más complicado se hace el tomar decisiones a
partir de ellas.
Por consiguiente, el conductor de negocio en una pyme se traduce en algo tan obvio
como esencial: mejorar la gestión de la empresa. Para una PYME esto puede ser un antes y
un después, especialmente para aquellas que se encuentran en una posición privilegiada con
respecto a sus competidores directos.

Análisis del Negocio

Alirio Olivares S.A. es una empresa estancada que no ha sabido aprovechar su
potencial y sus ya probadas fórmulas de relación con clientes. Sin embargo, cuenta con un
elemento clave: una base de datos que guarda información histórica desde el año 2003. Esto
es básicamente toda la materia prima necesaria para el desarrollo del proyecto BI.

41
Diseño

A partir de esos datos históricos, es posible generar los modelos que darán origen a
al data warehouse y luego a los cubos y reportes para el tan ansiado análisis.

Análisis Costo Beneficio

En términos generales, la consultoría es un trabajo disciplinado altamente
especializado, muchas veces inalcanzable para organizaciones más pequeñas. En la mayoría
de los países desarrollados, los consultores gozan de sueldos suculentos y contar con sus
servicios muchas veces es sinónimo de tener finanzas más que sólidas. Y es que la
diferenciación que ofrece una consultoría bien hecha es bastante potente y, muchas veces,
un aspecto decidor en la obtención de ventajas competitivas.
En el caso de nuestro país, la brecha entre empresas que pueden y no pueden contar
con mano de obra especializada de este tipo no es tanto más amplia que en los países
desarrollados, debido a que la mano de obra en general es peor pagada que en países como
EEUU y la mayoría de los países europeos.
Tomando en consideración que existen suites de soluciones BI open source, los
costos de implementar este tipo de soluciones recaen casi netamente en el servicio prestado
y equipamiento.

Estudio de Riesgos
Algunos riesgos o aspectos que deben ser tomados en cuenta son:

 Inestabilidad de requerimientos: Incluso en las grandes empresas se da el caso que

los requerimientos no están del todo claros en este tipo de proyectos. Es muy común
que cuando el cliente comience a interiorizarse con la tecnología empiecen a surgir
nuevas inquietudes. Esto se traduce en una amenaza a los tiempos y metas
establecidas del proyecto. Para esto, es necesario que el grupo consultor lleve
enérgica y sólidamente el proyecto. Un modo de hacerlo es siendo más protagonista
en la toma de requerimientos, haciendo uso de la experiencia para sugerir caminos
apropiados. El otro modo es proponer al cliente que todas esas ideas que vayan
surgiendo se plasmen en un proyecto posterior.

 Políticas: Las políticas amenazan a la implementación del proyecto no sólo con

trabas y dificultades de uso, sino también con dejar de lado por completo el sistema.
El costumbrismo y falta de destrezas TI en una organización puede pasar la cuenta
en proyectos en los que se desean cambiar hábitos por otros completamente
diferentes. El grupo consultor deberá desarrollar estrategias integradoras, en las que
se haga partícipe a cada personaje involucrado en el sistema. Para eso, es muy

42
Diseño

necesario mostrar resultados efectivos para todos los niveles de participación, tanto
para la alta gerencia como para los operativos, con el fin de asegurar el compromiso
general con el proyecto.

 Motivación: Es muy importante que el interés por el proyecto no se quede en el

inicio. Para esto, es indispensable que el grupo consultor mantenga incluido al
cliente en todo el proceso.

8.2 Planeación

8.2.1 Evaluación de la infraestructura técnica de la empresa

La inversión necesaria para el proyecto puede disminuirse significativamente si se
identifican elementos existentes en la organización que pudieran reutilizarse. La sola
existencia del recurso no significa necesariamente que se pueda tener disponibilidad
completa de él, por eso es necesario tener una idea de las cuotas de uso asociadas.

Hardware
Alirio Olivares S.A. cuenta con 3 computadores de escritorio, cada uno con las
siguientes características:
- Procesador Intel Pentium 4 1.6 Ghz

- 1 Gb RAM

- 120 Gb Disco Duro

El servidor de la base de datos transaccional es un computador de características

bastante limitadas:
- Procesador Intel MMX 233 Mhz

- 256 Mb RAM

- 80 Gb Disco Duro

Se estima que los computadores de escritorio son suficiente como para ser empleados
como clientes del sistema (capa de análisis). En lo que respecta al servidor, claramente se
requerirá una inversión adicional.

43
Diseño

Red
La empresa cuenta con una LAN con conexión a Internet. Dado que sólo tienen una
dependencia física, toda la empresa está conectada. Esta red puede ser utilizada por el
sistema BI sin mayores complicaciones, conectando el servidor del proyecto al router.

Middleware
De middleware es poco lo que se puede decir. El único Middleware existente es el
driver de la base de datos, pero para efectos del proyecto esto no será utilizado, por lo que
se omitirá.

Sistemas de Bases de Datos

La empresa tiene implementado un sistema de base de datos en Novel. Las
relaciones de las tablas no se hacen mediante lenguaje SQL, sino por manejo de archivos.
Esto dificulta la eventual conexión directa entre los dos sistemas. Sin embargo, las tablas
son exportables fácilmente, por lo que serán un muy buen canal de información mediante el
uso de un ETL.

Herramientas de Análisis
Actualmente la empresa no cuenta con ninguna herramienta de análisis.

8.2.2 Planeación del proyecto

Definición del proyecto
Lo que se persigue con la implementación de un sistema BI es, en términos
generales, obtener un beneficio económico, ya sea por el aumento de ingresos o
disminución de costos. En el caso de Alirio Olivares S.A., la meta es apoyar las decisiones
de negocios en el corto plazo y que eso se traduzca en una mejora notable en la gestión de
la empresa.
Sin embargo, es complicado determinar un objetivo financiero o comercial en
términos porcentuales. Dado que este es un trabajo mayormente de investigación, podemos
decir que el objetivo es demostrar que la implementación de un sistema BI en una pyme
proporcionará ventajas notorias de gestión empresarial y que, de la mano de lo anterior,
conllevará a beneficios monetarios sustentables importantes.

Plan de proyecto
El plan del proyecto está listado completamente en la primera parte de este informe,
en el capítulo “Actividades”.

44
Diseño

8.3 Análisis del Negocio

8.3.1 Definición de Requerimientos del Proyecto

Alirio Olivares es una empresa pequeña que se ha mantenido en el mercado con
gran astucia. Es una empresa ordenada en sus gastos, de finanzas claras y muy alerta. Sin
embargo, poco se sabe sobre cuál es la mejor decisión en cuanto a negocios. En primera
instancia, esto sugiere que se apoye la gestión de las ventas.

Conversaciones con el cliente acerca de las potencialidades de la inteligencia de

negocios llevaron a los requerimientos en esa dirección: la gestión de ventas.
En términos concretos, el cliente requiere:

 Analizar los comportamientos de las ventas de productos en todos los años de los
que se tiene registro histórico.

 Comparar el desempeño de los vendedores con respecto a los distintos productos.

 Comparar el desempeño de los vendedores con respecto al giro de los clientes.

 Analizar tendencias de ventas de los productos en diferentes momentos del año.

 Analizar los comportamientos históricos de los clientes.

 Efectuar rankings de clientes, en cuanto a volúmenes de compras.

Esto se traduce en la creación de un cubo OLAP de ventas.

8.4 Diseño

8.4.1 Diseño de la base de datos (Kimball)

La base de datos será diseñada según la metodología de Kimball, como fue
establecido previamente en este informe. Kimball propone 4 etapas en la creación de un
data warehouse, las cuales en este caso serán alineadas con la metodología de Larissa Moss.

Selección del proceso de negocio a modelar

Este paso está cubierto por la metodología de Moss. Esto se refiere a la gestión de
ventas. De todas maneras no está de más recalcar que el data warehouse debe ser construido
pensando en la posterior construcción del cubo OLAP que soportará esta tarea.

45
Diseño

Declaración de Granularidad
La granularidad de la base de datos define qué representa cada hecho de la tabla de
hechos. En el caso de este data warehouse, el detalle que contendrá será a nivel de
transacción. El hecho de elegir granularidad lo más detallada posible aumentará la
versatilidad a la hora de diseñar el cubo OLAP. Además, rediseñar un data warehouse una
vez implementada la capa de análisis conlleva a la necesidad de rehacer también el ETL.

Elección de las Dimensiones

La elección de las dimensiones está sujeta a los requerimientos de negocio que se
hicieron previamente. Las dimensiones deben apoyar la capacidad de análisis de ventas y
clientes. Esto supone de manera inmediata que deben incluirse las dimensiones “Producto”
y “Cliente”. Indispensable es, naturalmente, la inclusión de la dimensión “Fecha”, que
permitirá analizar la historia de los datos. Además del análisis de clientes, el usuario
manifestó su deseo de analizar a sus vendedores, por lo que se incluirá también la
dimensión “Vendedor”.

Identificación de Hechos
La elección de los hechos va de la mano de la elección de la granularidad. Los hechos
deben tener relación entre ellos y deben coexistir de manera lógica en cada registro de la
tabla de hechos. Esto quiere decir que deben describir el mismo proceso de negocio. La
elección de hechos es el último paso en el diseño del data warehouse, porque la tarea se
simplifica al conocer de qué manera describirán las dimensiones a la tabla de hechos.
Además, teniendo claridad del proceso de negocio que se quiere apoyar es posible
comprobar la relación de cada hecho con los requerimientos de manera directa. Los hechos
escogidos son los siguientes:

 Número Factura: Mayor nivel de granularidad transaccional posible.

 Venta: Valor en pesos de la transacción.

 Monto: Precio unitario del producto

 Cantidad: Cantidad de producto vendida en la transacción.

 Descuento: Descuento al cliente por transacción.

 Comisión: Comisión del vendedor por transacción.

46
Diseño

El modelo del data warehouse queda como muestra la siguiente figura:

Figura nº13: Diagrama del Data Warehouse

8.5 Construcción

8.5.1 Diseño del ETL

El ETL de la solución es bastante sencillo en cuanto a su estructura, pero no por eso
debe descuidarse un asunto muy importante: la integridad de los datos. La limpieza de la
información es un proceso que debe definirse en la capa del ETL.

Básicamente consta de la lectura de archivos .dbf y la reorganización de la

información contenida en ellos en las tablas del data warehouse.
Con respecto a los procesos de llenado de datos, existen 3 etapas:

 Carga inicial: Corresponde a la carga de datos una vez puesto en marcha el proyecto
hecha por el desarrollador.

47
Diseño

 Carga Histórica: Es una extensión de la carga inicial, pero contempla los cambios
que puedan haberse manifestado durante el tiempo de desarrollo. Esta carga es
hecha por el desarrollador.

 Carga Incremental: Corresponde a la carga de datos que se realiza una vez puesto en
marcha el proyecto. Debe definirse una periodicidad. Esta carga es realizada por el
usuario.

La ejecución del ETL será realizada por el usuario una vez que el proyecto esté en
producción. Para esto, es necesario definir una secuencia de carga de datos, en la que se
defina la periodicidad de extracciones de la base de datos transaccional y de lectura de los
archivos .dbf para el llenado del data warehouse. Esto forma parte de las políticas internas
de implementación, por lo que será incluido en las etapas finales.

Herramienta
La herramienta con la que se construyó el ETL es Spoon, el ETL de la Suite de BI
Pentaho. Con esta herramienta es posible realizar desde transformaciones simples (como
lectura de una fuente de datos y escritura de los datos en otra fuente de manera directa)
hasta transformaciones complejas (con joins entre distintos elementos, multiples fuentes de
datos, filtrado de valores, validación por valores de campos, control de flujo de datos, entre
otros).
Las cargas de las tablas se realizan mediante la ejecución del modelo del ETL,
representado de manera gráfica con pasos y flujos.

8.5.1.1 Carga de tablas con Spoon

La carga del data mart se realizó completamente con Spoon de Pentaho. Esta carga
corresponde a la carga histórica inicial del sistema, por lo que considera datos históricos
desde el 2003 a la fecha.
Como especificación, los orígenes de datos (extracciones de archivos .DBF de la base
de datos transaccional de la empresa) deberán situarse en una carpeta a definir, y ser
reemplazados cada vez que se realice una nueva ejecución del ETL. Con esto se logra que
el ETL no tenga que ser modificado cada vez que cambie la ruta del origen de datos o los
nombres de los archivos que forman el mismo.

Llenado de dimensión Cliente

Como primer paso, se lee el archivo que contiene la información de los clientes. Luego,
se seleccionan los valores a utilizar en la carga del data mart. Como los valores pueden
venir con espacios al final, se hace un trim a cada uno de los campos seleccionado en el
paso anterior. Para esto, se agrega un paso de javascript aplicando trim a todos los campos.
Como interesa analizar las transacciones realizadas exitosamente, se deben dejar de
lado todas aquellas transacciones nulas que no aportan valor al modelo. Para eso, se filtran

48
Diseño

las filas que tengan un código de cliente vacío (o nulo) y se envían a un paso que no haga
nada; si el campo tiene algún valor, entonces se pasa la información al último paso que se
encargará de hacer la inserción en la tabla Cliente del Data Mart, manejando las
credenciales e información de conexión respectiva de la base de datos en Mysql.

Figura nº14: Modelo de llenado tabla Cliente

Figura nº15: Función trim (borrado de espacios sobrantes) sobre campos seleccionados

Llenado de dimensión Vendedor

El proceso lee la tabla de origen de empleados, selecciona los valores que serán
utilizados en el data mart, filtra filas vacías para luego llenar la tabla Vendedor del data
mart en Mysql.

49
Diseño

Figura nº16: Modelo de llenado tabla Vendedor

Llenado de dimensión Fecha

La carga de la dimensión fecha se hace a partir de un archivo creado y no uno extraído
de la base de datos del cliente. El archivo contiene los campos necesarios para formar la
dimensión de la base de datos Mysql, según lo requieran los registros de las transacciones
de la base de datos de origen.

Figura nº17: Muestra de archivo fuente de fechas

Una vez creado el archivo fuente, sólo debe leerse su contenido, seleccionar los campos
y llenarlos en la tabla Fecha de la base de datos Mysql.
50
Diseño

Figura nº18: Modelo de llenado tabla Fecha

Llenado de dimensión Producto

La carga de la dimensión Producto se lleva a cabo leyendo el archivo de inventario de la
extracción del transaccional. Se seleccionan los valores y se eliminan los espacios sobrantes
con la función javascript trim. Luego, se cargan los campos en la tabla Producto de la base
de datos Mysql.

Figura nº19: Modelo de llenado tabla Producto

Llenado de la tabla de hechos

Para llenar la tabla de hechos es necesario hacerlo a partir de dos tablas de origen: la
tabla de ventas (información general por factura) y la tabla de detalle de ventas (detalle de
factura). En esas dos tablas se maneja toda la información necesaria para llenar la tabla de
hechos.
Para poder hacer una selección más natural de campos sobre dos tablas diferentes, se
debe hacer un merge join en el proceso ETL. Para esto, se ordenan ambos origenes de datos
por número de factura y luego se realiza un FULL OUTER JOIN sobre las mismas. Se
ordenan las tablas para garantizar que el resultado del join sea el correcto.
Una vez realizado el join, se seleccionan los valores que serán utilizados en el llenado
de la tabla en Mysql. Luego, por razones de consistencia con la clave primaria, se filtran las
filas que contengan valores vacíos en la fecha y en el codigo de producto.
Posterior a todo, se realiza la inserción de las filas en la tabla Metrica de la base de
datos Mysql

51
Diseño

Figura nº20: Modelo de llenado tabla Metrica

8.5.2 Desarrollo de la aplicación

Data Mart
Para la construcción del Data Mart fue utilizado el motor de base de datos Mysql,
por ser de libre uso y además estar 100% soportado por las herramientas de inteligencia de
negocios a utilizar (Suite Pentaho). la construcción de las tablas fue realizado a mano,
según lo definido en el diseño del data mart.

Cubo
La creación del cubo deberá apoyar las potencialidades de análisis requeridas.
Básicamente, se incorporarán dos elementos fuertes del análisis OLAP: jerarquías y
miembros compartidos.

Jerarquías
Las jerarquías permiten modelar dependencias padre hijo a partir de una misma
dimensión del data warehouse. Esto evita incorporar manualmente relaciones inter tablas a
base de “joins”, reduciendo la complejidad lógica.

52
Diseño

El manejo de jerarquías ofrece una funcionalidad analítica muy poderosa. Ofrece

ventajas como:

 Consolidación: Permite consolidar valores en un miembro común, otorgando menor

granularidad de análisis para los casos que lo amerite.

 Orden: Permite darle un orden lógico a las dimensiones.

Miembros Compartidos
Los miembros compartidos corresponden a miembros que son replicados en alguna
parte de la misma dimensión a la que pertenecen, ofreciendo otra perspectiva de análisis de
la misma información. Del punto de vista estructurado, son punteros a miembros que
replican toda la información que describen.
Un ejemplo de miembro compartido puede apreciarse en la dimensión cliente. Los
clientes son agrupados por su giro, pero también es necesario analizarlos por su ciudad de
origen. Sin embargo, el miembro “cliente” bajo ambas jerarquías es el mismo, debiendo
uno depender del otro.
Las dimensiones del cubo son las siguientes:

Figura nº21: Dimensión “Métrica”

53
Diseño

Figura nº 22: Dimensión “Producto”

Figura nº 23: Dimensión “Cliente”

Figura nº 24: Dimensión “Vendedor”

54
Diseño

Figura nº 25: Dimensión “Fecha”

8.5.2.1 Creación del Cubo con Mondrian

La creación del cubo es realizada con Mondrian, un servidor OLAP escrito en Java
de la suite BI de Pentaho. La generación del cubo se realiza con una herramienta gráfica
llamada Aggregation Designer, la que facilita el mapeo de las dimensiones del cubo, como
también la generación de la estructura jerárquica del mismo.

Un cubo está determinado por estructuras XML, las que son definidas en un
comienzo por el Aggregation Designer.
Las consultas sobre los cubos se realizan en lenguaje MDX (Expresiones multi
dimensionales).
El esquema del cubo de Ventas de esta solución es el siguiente:
<Schema name="AOSA">
<Cube name="Ventas" cache="true" enabled="true">
<Table name="metrica" alias="">

</Table>
<Dimension type="StandardDimension" foreignKey="Fecha_Key"
name="Tiempo">
<Hierarchy name="Por A&#241;o" hasAll="true" allMemberName="Por
A&#241;o - Todos" primaryKey="fecha_key" primaryKeyTable="fecha">
<Table name="fecha" alias="">
</Table>

55
Diseño

<Level name="A&#241;o" table="fecha" column="Anio" type="String"

uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
<Level name="Mes" table="fecha" column="Mes" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
<Level name="Dia" table="fecha" column="Dia" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="Codigo_Producto"
name="Producto">
<Hierarchy name="Por Familia" hasAll="true" allMemberName="Por Familias"
primaryKey="Codigo_Producto" primaryKeyTable="producto">

<Table name="producto" alias="">

</Table>
<Level name="Familia" table="producto" column="Familia" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>

<Level name="Producto" table="producto" column="Descripcion_Producto"

type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>

</Dimension>
<Dimension type="StandardDimension" foreignKey="Codigo_Cliente"
name="Cliente">
<Hierarchy name="Por Giro" hasAll="true" allMemberName="Por Giro -
Todos" primaryKey="Codigo_Cliente" primaryKeyTable="cliente">
<Table name="cliente" alias="">
</Table>

56
Diseño

<Level name="Giro" table="cliente" column="Giro" nameColumn="Giro"

type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
<Level name="Cliente" table="cliente" column="Nombre_Cliente"
type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
<Hierarchy name="Clientes" hasAll="true" allMemberName="Clientes -
Todos" primaryKey="Codigo_Cliente" primaryKeyTable="cliente">
<Table name="cliente">
</Table>
<Level name="Cliente" table="cliente" column="Nombre_Cliente"
type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="Codigo_Tipo_Pago"
name="Tipo_Pago">
<Hierarchy name="Tipo_Pago" hasAll="true" allMemberName="Tipo_Pago -
Todos" primaryKey="Codigo_Tipo_Pago" primaryKeyTable="tipo_pago">

<Table name="tipo_pago" alias="">

</Table>
<Level name="Tipo_Pago" table="tipo_pago" column="Tipo_Pago"
type="String" uniqueMembers="false" levelType="Regular">

</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="Codigo_Vendedor"
name="Vendedor">
<Hierarchy name="Vendedores" hasAll="true" allMemberName="Vendedores -
Todos" primaryKey="Codigo_Vendedor" primaryKeyTable="vendedor">

57
Diseño

<Table name="vendedor" alias="">

</Table>
<Level name="Vendedor" table="vendedor" column="Nombre_Vendedor"
type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>

</Hierarchy>
</Dimension>
<Measure name="Venta" column="Venta" datatype="Numeric"
aggregator="sum" visible="true">

</Measure>
<Measure name="Monto" column="Monto" datatype="Numeric"
aggregator="sum" visible="true">
</Measure>

<Measure name="Cantidad" column="Cantidad" datatype="Numeric"

aggregator="count" visible="true">
</Measure>
</Cube>
</Schema>

El esquema del cubo define jerarquías y niveles de consolidación anidando los tags
del xml. De esta forma, la estructura del cubo se hace más natural de leer y entender.

8.5.2.2 Creación de Reportes

Los reportes son el entregable principal que está orientado al usuario final. La idea
es plasmar el modelo construido en elementos visuales y esquemas bien ordenados que
entreguen una respuesta a una pregunta de negocio. A continuación se presentarán reportes
que son parte de esta solución:

58
Diseño

Reporte 1: Mejores clientes del 2008

Figura nº 26: Grilla de Reporte 1

Figura nº 27: Gráfico de Reporte 1

Este reporte muestra a los mejores clientes del año 2008 ordenados de manera
descendente, según ventas

59
Diseño

Reporte 2: Vendedor vs Tipo de Pago

Figura nº 28: Grilla de Reporte 2

Figura nº 29: Gráfico de Reporte 2

Este reporte grafica qué vendedores son los que tienen más ventas según el criterio
de tipo de venta.

60
Diseño

Reporte 3: Familia de Productos x Meses 2008

Figura nº 30: Grilla de Reporte 3

Figura nº 31: Gráfico de Reporte 3

Este reporte grafica en qué parte del año fue más vendida una cierta familia de
productos. Además, ilustra qué familia de productos fue más vendida el año 2008 en su
total.

61
Diseño

El sistema BI queda representado por la siguiente figura:

Figura nº 32: Sistema BI Alirio Olivares S.A.

62
9 Herramientas
9.1 Pentaho
La Suite Open Source de Pentaho, provee un completo espectro de funcionalidades de
Business Intelligence, incluyendo reportes, análisis, tableros de control, minería de datos,
integración de datos y una plataforma de BI que la han convertido en la suite de código abierto
más popular del mundo. Los productos Pentaho son utilizados por organizaciones líderes tales
como MySQL, Motorola, Terra Industries, DivX entre otras [Pentaho, 09].
Pentaho Corporation es el patrocinador principal y líder del proyecto Pentaho BI. El
proyecto Pentaho BI es una iniciativa en curso de la comunidad Open Source que provee a las
organizaciones de las mejores soluciones de su clase para sus necesidades de inteligencia de
negocios. Al aprovechar la riqueza de las tecnologías de código abierto y las contribuciones de la
comunidad de desarrollo de código abierto, Pentaho es capaz de innovar mucho más rápido que
los proveedores comerciales. Como resultado, Pentaho ofrece una alternativa de código abierto
que supera a las soluciones de Business Intelligence propietarias en muchas áreas como
arquitectura, soporte de estándares, funcionalidad y simplicidad de implantación. En otras
palabras, no se espera que la gente la adopte sólo porque es de código abierto sino porque es
superior.

El proyecto Pentaho BI abarca las siguientes grandes áreas de aplicaciones:

 Reportes

 Análisis

 Tableros de control

 Minería de datos

 Plataforma de Business Intelligence

Pentaho es el patrocinador y dueño de otros proyectos de código abierto. Estos proyectos

proveen componentes y funcionalidades integradas con la plataforma de BI de Pentaho. Estos
son:

 Mondrian - Servidor OLAP de código abierto.

 Pentaho Reporting Engine - Motor de reportes de código abierto.

 Kettle - Integración de datos (ETL) de código abierto.

63
Diseño

 Pentaho - Suite BI de código abierto.

 Weka - Minería de datos de código abierto.

9.2 Jaspersoft
La Suite de Business Intelligence Jaspersoft es un completo conjunto de herramientas
Open Source desarrolladas por Jaspersoft que provee de reportes sólidos, servidores de reporte,
análisis de datos e integración de los mismos para empresas que necesiten realizar decisiones
rápidas y mejores sobre su negocio [Jaspersoft, 09].
La visión principal de Jaspersoft BI Suite es cubrir todo tipos de empresas, ya sean
grandes o pequeñas, y que pueda ser integrado tanto con otras soluciones Open Source como con
soluciones propietarias. Esta Suite nace de la necesidad de complementar uno de los productos
estrella de la compañía llamado JasperReports, el cual es una librería de reportes desarrollada en
Java, y que ha tenido una amplia aceptación debido a que esta puede ser integrada en complejas
aplicaciones de reportes existentes hoy en día.
La Suite está orientada para que sea utilizada por usuarios esporádicos hasta analistas de
negocio y ejecutivos.
Jaspersoft BI Suite está compuesto por varios productos, estos son:

 JasperReports: es una librería de reporte hecha en Java. Su poder, desempeño y

accesibilidad ha hecho que sea uno de los productos de reporte más usado en el mundo,
extendiéndose a través de este hacia otras compañías que lo redistribuyen en variadas
aplicaciones Open Source y comerciales.

 JasperServer: es un servidor de reportes interactivo que permite entregar información

crítica en tiempo real o en tareas programadas en una amplia variedad de formatos de
salida. JasperServer es el núcleo de la plataforma BI de la Suite Jaspersoft y provee de
servicios como seguridad, repositorios, interfaces de usuario y programación de tareas.

 iReport: es un diseñador de reportes gráficos para JasperReports y JasperServer, que

simplifica el proceso de acceso a las fuentes de datos, definición y diseño de la capa de
presentación de los reportes y la compilación de los mismos.

 JasperAnalysis: es un servidor ROLAP y una aplicación de usuario final. Permite que

estos exploren tendencias, patrones, anomalías y correlaciones de los datos. La aplicación
permite que usuarios no técnicos puedan interactuar con los cubos de datos.

64
Diseño

 JasperETL: es una herramienta ETL intuitiva, flexible y poderosa. El usuario puede

gráficamente diseñar, programar y ejecutar movimientos de datos y transformaciones para
proyectos de inteligencia de negocios.

Los productos de la Suite al ser desarrollados puramente en Java pueden ser integrados con
otros sistemas o bien pueden ser utilizados cada uno por separado.

65
Diseño

10 Propuesta Metodológica
La metodología que se utiliza para este proyecto corresponde a un derivado de la
metodología de Larissa Moss, además de la incorporación de Kimball para la creación del Data
Warehouse. Sin embargo, si se pensara en masificar este tipo de soluciones para la pequeña y
mediana empresa, el trabajo de adaptar una metodología a cada caso en particular se haría
demasiado tedioso, además de no garantizar una correcta aplicación de cada método.
No existe una metodología que albergue las excepciones y condiciones naturales de una
empresa chilena pequeña o mediana, lo que se traduce en una complejización del análisis y
diseño de un proyecto sobre este nicho, haciendo el desarrollo en masa virtualmente
impracticable.
Una metodología es un conjunto de procedimientos conectados mediante principios
lógicos. Una serie de pasos conectados arbitrariamente no es una metodología, son sólo un
conjunto de pasos. Para proponer una metodología es necesario un procedimiento consistente que
explique las decisiones de diseño. Es por esto que se optó por generar esta propuesta a través del
método científico, específicamente la formulación de método empírico-analítico de Neil Salkind.
El objetivo es generar una propuesta metodológica que permita realizar proyectos de
inteligencia de negocios para pequeñas y medianas empresas de Chile (V Región).

Lo que se presentará a continuación son los pasos a seguir para la generación de una
propuesta metodológica.

10.1 Formalización de los pasos: Formulación de Neil Salkind

Los pasos para formular la metodología son los siguientes:

 Formulación del problema.

 Identificación de variables.

 Formulación de hipótesis de investigación.

 Recopilación de la información.

 Prueba de la Hipótesis.

66
Diseño

 Trabajo con la hipótesis.

 Reconsideración de la teoría.

 Confirmación o refutación.

10.1.1 Formulación del problema

La problemática es, como fue señalado más arriba, la ausencia de una metodología que
albergue las necesidades de una pequeña y mediana empresa de Chile para el desarrollo de un
proyecto de inteligencia de negocios.
Para generar una metodología enfocada a un nicho en particular, primero es necesario
entender las características del mismo. Una vez hecho esto, se debe contrastar esa descripción
con la considerada en las demás metodologías, por ejemplo, Larissa Moss.

10.1.2 Identificación de Variables

Las variables que se utlilizan en este desarrollo son las siguientes:

 Tecnología

 Educación empleadores

 Empleo a Nivel Nacional

 Trabajadores

 Idioma

 Exportaciones

 Certificación

67
Diseño

10.1.3 Formulación de la Hipótesis de Investigación

Un proyecto llevado a cabo con la nueva metodología deberá cumplir en plazos y calidad
esperada.
Los parámetros esperados deben medirse con respecto al retorno de la inversion, por lo que
no pueden ser analizados hasta una vez concluído un proyecto.
La creación de la metodología se hará en base a la de Larissa Moss, aplicándose variaciones
en la medida que lo recopilado por el estudio de mercado lo amerite.

10.1.4 Recopilación de la información

10.1.4.1 Análisis de mercado

Un nicho de mercado es parte de un segmento más grande del mismo. Las empresas que
serán consideradas en esta metodología corresponden a un sector productivo y de servicios del
país (dejando de lado el potencial internacional). En Chile, el nicho de la “Mediana Empresa”
posee necesidades o deseos específicos y parecidos.
El nicho de la mediana empresa presenta una “buena predisposición” por adquirir un
producto o servicio que satisfaga sus expectativas y, en el caso de las empresas u organizaciones,
tienen la capacidad de tomar decisiones de compra. Lo más atractivo a observar, si se quiere
focalizar esfuerzos organizacionales sobre competencias técnicas, es que existe la capacidad
económica que les permite incurrir en los gastos necesarios para obtener la satisfacción de su
necesidad o deseo. Incluso, están dispuestos a pagar un monto adicional por valor agregado.
En Chile el Ministerio de Economía define a las MIPYMES según las ventas anuales en UF
según el siguiente esquema:

Tipo de empresa Ventas anuales en U.F.

Microempresa hasta 2.400

Pequeña Empresa 2.400-25.000

Mediana Empresa 25.000-100.000

Figura n° 33: Clasificación PYMEs por ventas anuales

68
Diseño

Además, se clasifica a las empresas por su número de empleados:

Tipo de empresa Empleados

Microempresa hasta 9

Pequeña Empresa 10-49

Mediana Empresa 50-199

Figura n° 34: Clasificación PYMEs por número de empleados

10.1.4.2 Información de las variables

 Tecnologías

Un 70.4% de las pequeñas empresas y un 92.5% de las medianas cuenta con acceso a
Internet. En el caso de los sectores económicos, un 86% de las empresas de servicios financieros
tiene acceso a esta herramienta, mientras que sólo un 53.8% de las empresas del sector comercio
tienen acceso a Internet.

Por otra parte, mientras un 59.9% de las medianas empresas tiene página web, sólo un
26.0% de las pequeñas posee un sitio en Internet. En tanto, un 44.9% de las empresas del sector
de servicios financieros tiene página web.

 Educación empleadores

Casi un 70% de los socios o gerentes generales de las empresas medianas tienen educación
universitaria o de postgrado, y un 50% de los socios o gerentes generales de las pequeñas
empresas tienen ese nivel educacional.

69
Diseño

 Empleo a Nivel Nacional

Las pequeñas y medianas empresas son responsables de más de 90% del empleo en Chile.

 Trabajadores

Durante 2005, las pequeñas y medianas empresas contrataron más obreros calificados que
cualquier otro tipo de trabajador. En el caso de las medianas empresas, los empleados
administrativos fueron el segundo tipo de trabajador más requerido.
Tanto en las pequeñas como en las medianas empresas, la gran mayoría de los trabajadores
(más del 40%) son obreros, y en ambos casos el porcentaje de ejecutivos no supera el 20%.

 Idioma

Entre un 7,5% y un 10% del personal de pequeñas y medianas empresas habla inglés en
algún nivel. Sin embargo, sólo entre un 0% y un 4% de los trabajadores considera que sabe hablar
inglés en un nivel medio o avanzado.
Por otra parte, la mayor proporción de trabajadores que habla inglés trabaja en el sector de
servicios financieros y profesionales, y la menor proporción en el sector industrial.

 Exportaciones

Sólo un 8% de las pequeñas empresas ha realizado exportaciones y sólo un 2% son

operaciones de comercio exterior regulares. Por su parte, un 17% de las medianas empresas
exporta, y menos de un 7% lo hace regularmente. Respecto a los sectores, las pymes industriales
son las que más exportan (17.6%).

 Certificación

Un 9% de las empresas pequeñas y un 24% de las medianas, cuentan o está en trámite para
adquirir algún tipo de certificación de proceso o calidad [CORFO, INE, 10].

70
Diseño

10.1.5 Prueba, trabajo, reconsideración y confirmación o refutación

Los 4 últimos puntos deben desarrollarse considerando el desarrollo de un proyecto

completo con la nueva metodología. La confirmación o refutación de la teoría se relaciona
directamente con la necesidad de iterar en el proceso o no. Un proyecto que no cumpla con los
resultados esperados en cuanto a plazos y resultados visibles en el ROI indicará que debe
reestructurarse la metología propuesta y repetir el proceso.

71
Diseño

11 Conclusiones
En el presente informe, se han expuesto las tecnologías necesarias para implementar
herramientas de análisis de gestión. Con respecto a esto, se evidencia una gran cantidad de
variantes de implementación, gracias a la versatilidad de las herramientas. Las distintas
herramientas disponibles en el mercado utilizan diferentes tipos de tecnología OLAP, lo que hizo
más fácil la elección de las herramientas, centrándose esta en la Suite de Pentaho, con el fin de
evitar coordinar y conectar módulos de diferentes propietarios.
Se cumple el objetivo de este informe en términos de generar un acercamiento positivo
entre la realidad de una PYME y el complejo mundo de la inteligencia de negocios. El análisis
empresarial efectuado arrojó elementos interesantes y desafíos importantes aunque abordables,
con respecto a la solución de problemas mediante el uso de herramientas BI. Eso más el apoyo
que dio el gran interés por parte de la contraparte en la empresa en cuestión, hizo de este un
proyecto muy dinámico.
Se hizo un análisis de los requerimientos del proyecto y se formuló una solución de la
mano de la metodología de Larissa Moss, con el apoyo de la metodología de construcción de data
warehouse de Ralph Kimball. Se hizo el diseño y construcción del data warehouse y se construyó
el cubo OLAP que se implementó como solución BI a la problemática de negocio: mejorar la
gestión de las ventas.
En otros términos, se logró un avance significativo en el acercamiento de una solución BI
a una PYME. Se logró demostrar que una metodología BI integral puede ser acoplada a los
requerimientos de una pequeña empresa sin mayores problemas. Se demostró también la
potencialidad analítica que presenta una empresa pequeña teniendo historia transaccional entre
sus activos.

El ETL fue construido de manera exitosa. Tras bastantes complicaciones debido a poca
uniformidad en los datos de origen, fue posible ejecutar con éxito cada uno de los modelos que
terminaron en el llenado del data mart.
Un proyecto BI es aplicable 100% a una PYME si se tienen correctas nociones de los
alcances de un eventual proyecto. Una capa de presentación amigable y orientada al negocio
mantiene alejado al usuario final de complicadas actividades como la programación o las
consultas a bases de datos. Esto hace que, sin importar cuál sea la naturaleza del negocio, el
usuario final pueda centrarse sólo en el análisis y no perder tiempo en prepararlo.

11.1 Implementación en AOSA

El primer acercamiento a Alirio Olivares S.A. consistió en una explicación sencilla de lo
que es la inteligencia de negocios. La presentación generó interés de inmediato en la dueña de la
empresa, generándose una dinámica de preguntas y respuestas al final de la misma, dónde se
evidenció el deseo por parte del cliente de entender cuáles eran realmente sus posibilidades y cuál
72
Diseño

era el potencial de estas tecnologías que podían ser capitalizados de manera efectiva por una
pequeña empresa.
La inteligencia de negocios basa su terminología en conceptos sencillos, haciendo fácil una
primera inmersión en los temas relacionados a ella. Esto ayudó a centrar la conversación con
Alirio Olivares S.A. en las problemáticas de negocio y no en tratar de explicar cosas complejas.
A su vez, esta fue la razón del gran interés presentado por la dueña de Alirio Olivares S.A. en la
conversación inicial.
El trabajo realizado fue en gran parte hecho en la oficina de AOSA, por lo que se tuvo
mucha cercanía con el cliente. Esto permitió tener instancias de validación en la etapa de
levantamiento, como también en la implementación. Además, se generaron instancias de trabajo
grupal para la definición de reportes.
Los entregables del proyecto comenzaron bastante antes de la finalización del mismo, lo
que mantuvo constantemente el interés de los usuarios. Además, los informes y reportes no
permanecieron de manera exclusiva en la gerencia de la empresa, quedando disponible en
algunos casos para vendedores y administrativos, mostrando la información de manera clara y
entendible, lo que posibilitó una participación más profunda en el negocio por parte de muchos
de los miembros de la empresa.

Esto último tuvo un efecto positivo en la forma en que la empresa entiende su misión y la
manera en que la operativiza. A medida que los empleados fueron siendo incluidos en los análisis
e interpretaciones de la información presentada,se percibió un mayor compromiso con la
empresa. Además, el entender las metas y objetivos de manera gráfica y participativa permite que
los caminos recorridos para lograrlos sean comprendidos y puestos en marcha en función de
lograr un resultado positivo para la empresa y no resulten en realizar tareas sólo por hacerlas.
Por último, el trabajo realizado no sólo tuvo un efecto en la implementación misma, sino
que también representó una experiencia de aprendizaje interno para los usuarios tanto gerenciales
como no gerenciales, lo que sin duda cimienta el camino para la adopción de nuevas
implementaciones.

73
Diseño

12 Referencias
[Wolff, C. G., 2002]. La Tecnología Datawarehousing (pág 2). Concepción, Chile
[Walton, S. & Cline, A., 2000]. Data Warehouses/Data Marts (pág 1). Carolla
Development
[Forsman, S., 1997]. OLAP Council Whitepaper (pág 1). Olap Council
[Thomsen, E., 2002]. OLAP Solutions: Building Multidimensional Information Systems,
Second Edition (pág 5). New York: Wiley
[Kotler, P. & Ketler, K., 2006]. Marketing Management, 12th Edition (pág 44-52). United
States.
[Kotler, P. & Armstrong, G. & Cámara, D. & Cruz, I., 2004]. Marketing, 10th Edition (pág
43).
[Piedrabuena, F., 2005]. Relevamiento: Diseño Físico de Sistemas OLAP (pág 3 - 4).
Montevideo: PEDECIBA Informática
[Llombart, O. A., 2008] BI: Inteligencia Aplicada al Negocio (pág 17). España
[Diez de Castro, E. P., 2001]. Administración y Dirección (pág 244).
[Fleitman, J., 1999]. Negocios Exitosos. McGraw-Hill
[Thomson, A., 2001]. Administración Estratégica Conceptos y Casos 11ª Edición (pág 4).
México: McGraw-Hill
[Maturana, C., 2002]. Análisis FODA: un instrumento de aplicación práctica para las
MYPYMES (pág 5). Managua: Universidad Americana U.A.M.
[Instituto Politécnico Nacional, 2002]. Metodología para el Análisis FODA (pág 8).
Dirección de planeación y organización
[Hax, A. & Majluf, N., 2004]. Estrategias para el liderazgo competitivo. Santiago: Granica
[Marquez, F., 1999]. Autonomías y Análisis FODA. Ecuador.
[Kimball, R., 2002]. The DataWarehouse Toolkit. Wiley

[Inmon, W. H., 1996]. Building the DataWarehouse (2nd). Wiley

[Moss, L., 2003]. Business Intelligence Roadmap. Addison Wesley.
[Pentaho , 2009]. Open Source Business Intelligence . www.pentaho.com
[Jaspersoft , 2009]. The Most Widely Used BI. www.jaspersoft.com

74