Business intelligence para Pymes

Business Intelligence para
PYMES
Autor/es: Manuel Alejandro González Yanes
Rebeca Mora Anca
Director/a: Virginia Gutiérrez Rodríguez
Fecha: 12 de Julio de 2011

2 Chapter I
D./Dña. Virginia Gutiérrez Rodríguez Profesora de la Escuela Técnica Superior de Ingeniería
Informática, y adscrito al Departamento de Estadística, Investigación Operativa y Computación
de la Universidad de La Laguna.
CERTIFICA: Que la presente memoria titulada Business Intelligence para PYMES, ha sido
realizada bajo mi dirección por el/los alumno/s D. Manuel Alejandro González Yanes y Dña
Rebeca Mora Anca, y constituye su Proyecto Fin de Carrera de Ingeniería Informática por la
Universidad de La Laguna.
Y para que así conste, en cumplimiento de la legislación vigente y a los efectos que haya lugar,
firmo el presente certificado en La Laguna, a 12 de Julio de 2011
Fdo: D./Dña. Virginia Gutiérrez Rodríguez
2

Resumen
Se denomina inteligencia empresarial, inteligencia de negocios o BI (del inglés Business
Intelligence) al conjunto de estrategias y herramientas enfocadas a la administración y
creación de conocimiento mediante el análisis de datos existentes en una organización o
empresa.
La Business Intelligence actúa como un factor estratégico para una empresa u organización,
generando una potencial ventaja competitiva, que no es otra que proporcionar información
privilegiada para responder a los problemas de negocio: entrada a nuevos mercados,
promociones u ofertas de productos, control financiero, optimización de costes, planificación de
la producción, análisis de perfiles de clientes, rentabilidad de un producto concreto, etc...
Las herramientas de inteligencia abarcan la comprensión del funcionamiento actual de la
empresa como la anticipación de acontecimientos futuros, con el objetivo de ofrecer
conocimientos para respaldar las decisiones empresariales. Las herramientas de Business
Intelligence se basan en la utilización de un Sistema de Información de Inteligencia que se
forma con distintos datos extraídos de producción, con información relacionada con la empresa
o sus ámbitos y con datos económicos.
Las herramientas de Business Intelligence ofrecen a las personas que toman las decisiones
utilidades que facilitan ese proceso como:
 Cuadros de Mando para medir la evolución de los Indicadores clave del negocio cómo
controlar las ventas o la situación económica.
 Informes dinámicos con los que buscar causas o tendencias de forma sencilla y que
permiten analizar clientes, proveedores, producción, etc. en profundidad.
El problema a abordar consiste en integrar SAP BO con una solución de Business Intelligence
de forma que proporcione a las Pymes informes gráficos y cuadros de mandos interactivos que
ofrezca una mayor versatilidad, control de los ingresos, los márgenes y la liquidez.
3

4 Chapter I
Agradecimientos
A nuestro profesor de la Universidad de La Laguna, Marcos Colebrook, el cual nos animó a
desarrollar este proyecto tan satisfactorio a nivel personal y profesional.
A nuestra directora de proyecto de la Universidad de La Laguna, Virginia Gutiérrez Rodríguez,
la cual trabajó con nosotros a lo largo de todo el proyecto siempre ayudando, aconsejando y
orientándonos en todo momento.
A las personas que forman ITOP Management Consulting, y en especial a Teresa Pestana y
Miguel Fernández, por el apoyo y las horas que han dedicado con nosotros a este proyecto.
Dedicar este proyecto a nuestra familia y amigos por el apoyo y los ánimos prestados en todo
momento incondicionalmente.
Gracias a profesores como José Luis Roda que nos dio grandes consejos y nos proporcionó las
infraestructuras con las que realizar el proyecto, Daniel González que nos descubrió el mundo
del PMBOK e ITIL para poder crear los indicadores, Roberto Dorta que nos ayudó a entender la
ISO9001.
4

6 Chapter I
Al término de esta etapa de nuestras vida. Queremos expresar todo nuestro agradecimiento a
quienes con su ayuda, apoyo y comprensión, nos alentaron a lograr esta hermosa realidad…
nuestra formación profesional.Tabla de contenidos
Resumen..........................................................................................................2
Agradecimientos.............................................................................................4
Lista de figuras ..............................................................................................7
Lista de Tablas................................................................................................8
Parte I.Introducción y fundamentos básicos...................................................8
Capítulo 1.Fundamentos Business Intelligence.........................................9
1.1Introducción................................................................................................................9
1.2¿Qué es BI?................................................................................................................9
1.2.1Proceso BI......................................................................................................10
1.2.2Arquitectura de una solución BI......................................................................10
1.3¿Qué es un Data Warehouse?.................................................................................10
1.3.1Arquitectura de una solución BI con Data Warehouse...................................11
Capítulo 2.ITOP Management Consulting..................................................20
2.1La empresa...............................................................................................................20
2.2Filosofía....................................................................................................................20
2.3Alianzas....................................................................................................................20
Capítulo 3.Descripción del problema e integración de soluciones
tecnológicas ..........................................................................................21
3.1Introducción..............................................................................................................21
3.2Análisis funcional y elección.....................................................................................21
3.2.1Análisis Inicial.................................................................................................21
3.2.2Conclusión .....................................................................................................23
3.3 Descripción del problema........................................................................................24
Parte II.Cuerpo principal. Descripción del trabajo........................................25
Capítulo 1.Descripción de la metodología para resolver el problema...26
1.1Metodología de desarrollo........................................................................................26
1.1.1Metodología SCRUM.....................................................................................27
Capítulo 2.Metodología de Implementación de una solución BI.............33
2.1.1Metodologías para construir un Data Warehouse..........................................33
6

2.1.2Metodología propia para la Construcción de un Data Warehouse con base en
HEFESTO....................................................................................................34
Capítulo 3.Análisis de los resultados.........................................................71
3.1Resultados................................................................................................................71
Parte III.Conclusiones, Final............................................................................73
Capítulo 1.Conclusiones y posibles ampliaciones...................................74
Parte IV.Bibliografía..........................................................................................76
Parte V.1. Kniberg, Henrick. . http://www.proyectalis.com/wp-
content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf. [En
línea] 09 de 06 de 2011. .............................................................................76
Parte VI.2. Dario, Bernabeu R. Investigación y Sistematización de
HEFESTO: Metodología propia para la Construcción de un Data
Warehouse. [En línea] 09 de 06 de 2011. ................................................76
Parte VII.3. Commerce, Office of Government. ITIL Gestión de Servicios TI.
[En línea] 05 de 01 de 2011. http://itil.osiatis.es......................................76
Parte VIII.4. Alexander, Michael. Crystal Xcelsius for Dummies. 2007........76
Parte IX.5. Berndtsson, M., Hansson, J., Olsson, B., Lundell, B. A Guide for
Students in Computer Science and Information Systems, Springer.
2008..............................................................................................................76
Parte X.6. Stephen Few. Information Dashboard Design, The Effective
Visual Communication of Data. s.l. : O'Reilly, 2006...............................76
Parte XI.7. Doug Harts, Jim Dugan, Tricia Wilcox Almas. Microsoft SQL
Server 2008 R2 Analytics & Data Visualization. s.l. : Mac Graw Hill,
2008..............................................................................................................76
Parte XII.8. Ramos, Salvador. Microsoft Business Intelligence vea el cubo
medio lleno. s.l. : SolidQ Press, 2011.......................................................76
7

8 Chapter I
Parte XIII.9. Sivakumar Harinath, Matt Carroll, Sethu Meenakshisundaram,
Robert Zare, Denny Guang-Yeu Lee. Professional Microsoft SQL
Server Analysis Services 2008 with MDX. s.l. : Wiley Publishing, Inc.,
2009..............................................................................................................76
Parte XIV.10. Xavier Hacking, David Lai. SAP BusinessObjects
Dashboards 4.0 Cookbook. s.l. : Packt Publishing, 2011......................76
Parte XV.11. Roland Bouman, Jos van Dongen. Pentaho Solutions -
Business Intelligence and Data Warehousing with Pentaho and
MySQL. s.l. : WILEY....................................................................................76
Parte XVI.12. Roldán, María Carina. Pentaho 3.2 Data Integration,
Beginner's Guide. s.l. : Packt Publishing, 2010......................................76
Parte XVII.13. Erik Veerman, Jessica M. Moss, Brian Knight, Brian Knight.
Microsoft® SQL Server® 2008 Integration Services Problem–Design–
Solution. s.l. : Wiley Publishing, Inc, 2010...............................................76
Parte XVIII.14. Nanda, Ashwani. Microsoft SQL Server 2008 Integration
Servicies. s.l. : Mac Graw Hill, 2010..........................................................76
Parte XIX.15. Haselden, Kirk. Microsoft® SQL Server 2008 Integration
Services. s.l. : UNLEASHED, 2009............................................................76
Parte XX.16. Anónimo. The Official Introduction to the ITIL Service
Lifecycle. s.l. : Published by TSO (The Stationery Office).....................76
Parte XXI.17. Commerce, Office of Government. ITIL Serivce Transition.
s.l. : Published by TSO (The Stationery Office)......................................76
Parte XXII.18. —. ITIL Continual Service Improvement. s.l. : Office
Government Comerce, 2009......................................................................76
Parte XXIII.19. —. ITIL Service Design. s.l. : Published by TSO (The
Stationery Office)........................................................................................76
8

Parte XXIV.20. —. ITIL Service Operation. s.l. : Published by TSO (The
Stationery Office)........................................................................................76
Parte XXV.21. ZELAZNY, GENE. Say it whit Charts. s.l. : McGraw-Hill, 2001.
......................................................................................................................76
Parte XXVI.22. PARMENTER, DAVID. Key Performance Indicators,
Developing, Implementing, and Using Winning KPIs. s.l. : John Wiley &
Sons, Inc., 2010...........................................................................................76
Parte XXVII.23. John Wiley & Sons, Inc., Hoboken, New Jersey. Business
Dashboards. s.l. : John Wiley & Sons, Inc., 2009...................................76
Parte XXVIII.24. Withee, Ken. Microsoft Business Intelligence for
Dummies. s.l. : Wiley Publishing, Inc, 2010.............................................76
Parte XXIX.25. Lynn Langit, Kevin S. Goff, Davide Mauri, Sahil Malik, and
John Welch. Smart Business Intelligence Solutions with Microsoft
SQL Server2008. s.l. : Microsoft Press, 2009..........................................76
Parte XXX.26. SQL SERVER INTEGRATION SERVICES 2008
LABORATORIOS . s.l. : INTERMEZZO BUSINESS INTELLIGENCE ,
2010..............................................................................................................76
Parte XXXI.27. Inmon, W. H. Building the Data Warehouse. s.l. : Design &
Composition, 2010......................................................................................76
Parte XXXII.28. Viera, Robert. Professional Microsft SQL Server 2008
Programming. s.l. : Wiley Publishing, I nc, 2009....................................76
Parte XXXIII.29. Ross MistRy, Stacia MisneR. Introduciong Microsoft SQL
Server 2008 R2. s.l. : Microsoft Press, 2010............................................77
Parte XXXIV.30. Philo Janus, Philo Janus. Pro SQL Server 2008 Analysis
Services. s.l. : Apress, 2010......................................................................77
9

10 Chapter I
Parte XXXV.31. Rainardi, Vincent. Building a Data Warehouse with
Examples in SQL Server. s.l. : Apress, 2010...........................................77
Parte XXXVI.32. Scott Cameron, Hitachi Consulting. SQL Server 2008
Analysis Services. s.l. : Vincent Rainardi, 2009......................................77
Parte XXXVII.33. Chris Webb, Alberto Ferrari and Marco Russo. Expert
Cube Development with Microsoft SQL Server 2008 Analysis Services.
s.l. : Marco Russo, 2009.............................................................................77
Parte XXXVIII.34. Langit, Guy Fouché and Lynn. Foundations of SQL
Server 2008 R2 Business Intelligence. s.l. : Apress, 2009.....................77
Parte XXXIX.35. Kimball, Joy Mundy and Marren Thornthwaite with Ralph.
The Microsft Data Warehouse Toolkit whit SQL Server. s.l. : Kimball
Group, 2011.................................................................................................77
Parte XL.36. Anónimo. Scrum. Definición de Scrum. [En línea] 23 de 06 de
2011. http://es.wikipedia.org/wiki/Scrum.................................................77
Parte XLI.37. Institute, Project Management. PMBOK. ................................77
Glosario de términos....................................................................................78
Índice de siglas.............................................................................................82
Apéndices......................................................................................................84
10

12 Chapter I
Lista de Tablas
Parte I. Introducción y fundamentos básicos
12

Capítulo 1. Fundamentos Business
Intelligence
Resumen:
Introducción a mundo del Business Intelligence
Introducción Data Warehouse y conceptos relacionados
1.1 Introducción
En la actualidad, la gran mayoría de las organizaciones cuenta con un Sistema de
Información1
(SI) que soporta gran parte de las actividades diarias propias del sector de
negocios en donde se esté desempeñando. Este sistema puede ser sencillo o robusto,
todo depende de las exigencias del negocio. Con el transcurso del tiempo, estas
aplicaciones llegan a tener la historia de la organización: los datos almacenados en las
bases de datos pueden ser utilizados para argumentar la decisión que se quiera tomar.
Un estudio realizado en Europa por Information Builders Ibéric mostró el costo que
tiene la falta de Sistemas de Información Orientados para la Toma de Decisiones2
o
Decision Support Systems (DSS) en las organizaciones. Según estos datos, el
empleado europeo medio pierde una media de 67 minutos diariamente buscando
información de la compañía, lo que equivale a un 15,9% de su jornada laboral. Para
una organización de 1.000 empleados que gane unos 50.000 euros al día equivaldría a
7,95 millones de euros al año de salario perdido, debido todo ello a la búsqueda de
información orientada a la toma de decisiones.
El poder competitivo que puede tener una empresa se basa en la calidad y cantidad de
información que sea capaz de usar en la toma de decisiones. Mediante la
implementación de Inteligencia de Negocios o Business Intelligence (BI) se
proporcionan las herramientas necesarias para aprovechar los datos almacenados en
las bases de datos de los Sistemas Transaccionales3
para utilizar la información como
respaldo a las decisiones, reduciendo el efecto negativo que puede traer consigo una
mala determinación. Precisamente, Business Intelligence permite que el proceso de
toma de decisiones esté fundamentado sobre un amplio conocimiento de sí mismo y
del entorno, minimizando de esta manera el riesgo y la incertidumbre.
1 Un Sistema de Información es un conjunto de elementos orientados al tratamiento y administración de datos e
información, organizados y listos para su posterior uso, generados para cubrir una necesidad u objetivo.
2 DSS es un sistema informático utilizado para servir de apoyo, más que automatizar, el proceso de toma de
decisiones.
3 Es un tipo de Sistema de Información diseñado para recolectar, almacenar, modificar y recuperar todo tipo de
información que es generada por las transacciones en una organización.
13

14 Chapter I
1.2 ¿Qué es BI?
“BI es el conjunto de estrategias y tecnologías que nos van a ayudar a convertir los
datos en información de calidad y dicha información en conocimiento que nos permita
una toma de decisiones más acertada y nos ayude así a mejorar nuestra
competitividad”4
Business Intelligence hace hincapié en los procesos de recolectar y utilizar
efectivamente la información con el fin de mejorar la forma de operar de una
organización, brindando a sus usuarios, el acceso a la información clave que necesitan
para llevar a cabo sus tareas habituales y, en concreto, para poder tomar decisiones
oportunas basadas en datos correctos y certeros —algo peor que no tener información
disponible es tener mucha información y no saber qué hacer con ella. Los datos
almacenados en nuestros sistemas no valen nada si no somos capaces de comprender
su significado, de elaborarlos y transformarlos en información de calidad, que sea
capaz de responder a las preguntas de los usuarios de diferentes áreas de negocios —
ventas, marketing, finanzas, inventarios, entre otras—, como:
¿Cuál es el estado de salud de mi empresa?
¿Cuál es el nivel de satisfacción de mis clientes? ¿Y el de mis empleados?
¿Cuál es la línea de productos más rentables? ¿Es la misma que el año anterior?
¿Cuál es el segmento de clientes al que deberíamos dirigir un nuevo producto?
¿Qué departamentos son los más productivos?
Al contar con la información exacta y en tiempo real, es posible, además de lo anterior,
identificar y corregir situaciones antes de que se conviertan en problemas potenciales o
pérdidas de control de la empresa, pudiendo conseguir nuevas oportunidades o
readaptarse frente a la ocurrencia de sucesos inesperados. A todo ello, a partir de
ahora se denominará solución BI.
¿Quién necesita soluciones de Business Intelligence?
Para ello nos planteamos las siguientes cuestiones:
¿Pasa más tiempo recolectando y preparando información que analizándola?
¿En ocasiones le frustra el no poder encontrar información que usted está seguro que
existe dentro de la empresa?
¿Pasa mucho tiempo tratando de hacer que los informes en Excel luzcan bien?
¿No sabe qué hacer con tanta información que tiene disponible en la empresa?
¿Quiere saber qué productos fueron los más rentables durante un periodo
determinado?
¿Ha perdido oportunidades de negocio por recibir información retrasada?
¿Trabaja horas extras el fin de mes para procesar documentos e informes?
¿No sabe con certeza si su gente está alcanzando los objetivos planeados?
4 Microsoft Business Intelligence: Vea el cubo medio lleno (http://www.solidq.com/sqj/books/Pages/Microsoft-Business-
Intelligence-vea-el-cubo-medio-lleno.aspx)
14

¿No tiene idea de por qué sus clientes le devuelven mercancía?
Estas son las soluciones de BI más reconocidas actualmente en el mercado.
Un caso de éxito de solución BI fue un estudio de la cadena de supermercados Wal-
Mart5
, donde decidieron iniciar un proyecto de Basket Analysis6
utilizando la
información recogida de las ventas. Descubrieron una correlación estadísticamente
significativa entre la compra de pañales y cerveza. Profundizando en el estudio, vieron
que los compradores de cerveza y pañales eran varones de entre 25 y 35 años que
solían comprar estos productos conjuntamente los viernes por la tarde. La cadena de
supermercado tomo la decisión de colocar las cervezas cerca de los pañales, con la
intención de que los padres que compraban pañales y que no solían comprar cerveza,
se acordasen que faltaba cerveza en casa. Los resultados fueron espectaculares
aumentando un 15% las ventas de cervezas con pañales.
La Inteligencia de Negocios tiene sus raíces en los Sistemas de Información Ejecutiva
7
o Executive Information Systems (EIS) y en los DSS, pero ha evolucionado y se ha
transformado en todo un conjunto de tecnologías capaces de satisfacer a una gran
gama de usuarios, junto a sus necesidades especíﬁcas, en cuanto al análisis de la
información.
1.2.1 Proceso BI
El proceso BI se describe en cinco fases, las cuales se explican teniendo como
referencia la Figura 1, gráfico que sintetiza todo el proceso.
Figura 1: Fases de un proceso BI
5 Wal-Mart es una empresa multinacional de origen estadounidense, el minorista más grande del mundo; y por sus
ventas y número de empleados, la mayor compañía del mundo. Su concepto de negocio es la tienda de autoservicio de
bajo precio y alto volumen.
6 Las técnicas de basket analysis del mercado permiten analizar los productos que integran la bolsa de la compra y las
relaciones existentes entre ellos. En este nivel de detalle, la información es muy útil y proporciona a los usuarios de
negocio visibilidad directa sobre la bolsa de la compra de cada cliente.
7 Los Sistema de Información Ejecutiva son una herramienta de Business Intelligence, orientada a usuarios de nivel
gerencial, que permite monitorizar el estado de las variables de un área o unidad de la empresa a partir de información
interna y externa a la misma.
15

16 Chapter I
 FASE 1: Dirigir y planear. Fase inicial donde se deberán recoger los
requerimientos de información de los diferentes usuarios así como entender
sus necesidades de información.
 FASE 2: Recolección de información. Se estudiaran las diferentes fuentes de
información de la empresa para recolectar aquellos datos que darán
respuestas a las necesidades planteadas en la fase anterior
 FASE 3: Procesamiento de datos. En esta fase es donde de integran y cargan
los datos en crudo en un formato utilizable para el análisis. Esta actividad
puede realizarse mediante la creación de una nueva base de datos, agregando
datos a una base de datos ya existente o bien consolidando la información.
 FASE 4: Difusión. Finalmente los usuarios a través de una serie de
herramientas podrán explorar los datos de manera sencilla e intuitiva.
1.2.2 Arquitectura de una solución BI
Una solución Business Intelligence parte de los sistemas de origen de una organización
—bases de datos, ERPs, ficheros de texto, entre otros—, sobre los que suele ser
necesario aplicar una transformación estructural para optimizar su proceso analítico.
Para ello se realiza una fase de extracción, transformación y carga (ETL) de datos,
donde se depuran y homogeneizan Esta etapa suele apoyarse en un almacén
intermedio —Operational Data Store— (ODS) que actúa como pasarela entre los
sistemas fuente y los sistemas destino —generalmente un Data Warehouse—, y cuyo
principal objetivo consiste en evitar la saturación de los servidores funcionales de la
organización.
La información resultante, ya unificada, depurada y consolidada, se almacena en un
Data Warehouse (DW) corporativo, que puede servir como base para la construcción
de distintos Datamarts departamentales. Estos Datamarts se caracterizan por poseer la
estructura óptima para el análisis de los datos del área de la organización, ya sea
mediante Bases de Datos Transaccionales (OLTP) o mediante Bases de datos
analíticas (OLAP).
1.3 ¿Qué es un Data Warehouse?
Supóngase que una compañía quiere analizar aquellos países y gama de productos en
los que las ventas vayan excepcionalmente bien. La compañía dispone de una base de
datos transaccional sobre la que operan todas las aplicaciones de la empresa:
producción, venta, facturación, proveedores etc. Lógicamente, de cada venta se
registra la fecha, la cantidad, el comprador y el país de este. Con toda esta información
histórica nos podemos preguntar:
¿Es esta información suficiente para realizar el análisis planteado?
La respuesta hay que buscarla fuera de la base de datos, en el contexto donde se
motiva el análisis. La incorporación de un producto depende de las ventas por
habitantes. Si no tenemos en cuenta la población de cada país, la repuesta al análisis
16

estará sesgada. También puede ocurrir que, dependiendo de la gama del producto, nos
interese información externa verdaderamente específica, como por ejemplo, las horas
de sol anuales de cada país, siendo información valiosa para una compañía de
cosmética: es más difícil vender bronceador en Lituania que en Canarias. Pero este
hecho, que nos parece tan lógico, sólo podrá ser descubierto por herramientas de
Minería de Datos8
, si se incorpora información climática de cada país. Con lo cual, cada
organización deberá recoger diferente información que le pueda ser útil para la tarea de
análisis y extracción de conocimiento y en definitiva para la toma de decisiones.
Un Data Warehouse es una base de datos corporativa en la que se integra información
depurada de las diversas fuentes inmersas en la organización o externas a ella, como
se muestra en la Figura 2. Dicha información debe ser homogénea y fiable, se
almacena de forma que permita su análisis desde muy diversas perspectivas, y a su
vez de tiempos de respuestas óptimos.
Figura 2: En un Data Warehouse se integra información de diversas fuentes.
Una de las deﬁniciones más famosas sobre DW, es la de William Harvey Inmon9
, que
expone:
“Un Data Warehouse es una colección de datos orientada al negocio, integrada,
variante en el tiempo y no volátil para el soporte del proceso de toma de decisiones de
la gerencia”.
donde en la Tabla 1 se aprecia en profundidad cada una de las características más
detalladas.
8La Minería de Datos consiste en la extracción no trivial de información que reside de manera implícita en los datos.
Dicha información era previamente desconocida y podrá resultar útil para algún proceso. En otras palabras, la Minería
de Datos prepara, sondea y explora los datos para sacar la información oculta en ellos.
9 William Harvey Inmon es reconocido por muchos como “ el padre del Data Warehouse”
17

18 Chapter I
Tabla 1: Características de un Data Warehouse
Orientado a temas
Los datos están organizados por temas para facilitar el entendimiento
por parte de los usuarios, de forma que todos los datos relativos a un
mismo elemento de la vida real queden unidos entre sí. Por ejemplo,
todos los datos de un cliente pueden estar consolidados en una misma
tabla, todos los datos de los productos en otra y así sucesivamente.
Integrado
La integración implica que todos los datos de diversas fuentes que son
producidos por distintos departamentos, secciones y aplicaciones, tanto
internos como externos, deben ser consolidados en una instancia antes
de ser agregados al Data Warehouse, y deben, por lo tanto, ser
analizados para asegurar su calidad y limpieza, entre otras cosas.
Algunas de las inconsistencias más comunes que nos solemos
encontrar son: en nomenclatura, unidades, formato de fechas,..
Histórico (variante
en el tiempo)
Los datos, que pueden ir variando en el tiempo, deben quedar reflejados
de forma que al ser consultados reflejen estos cambios y no se altere la
realidad que había en el momento que se almacenaron, evitando así la
problemática que ocurre en los sistemas operacionales, que reflejan
solamente el estado de la actividad de negocio presente.
No volátil
Una vez almacenada la información en el Data Warehouse debe ser de
solo lectura, nunca se modifica ni se elimina, debe ser permanente para
futuras consultas.
1.3.1 Arquitectura de una solución BI con Data Warehouse
En este punto —teniendo en cuenta que ya se han detallado claramente las
características generales del Data Warehouse— se deﬁne y describe todos los
componentes que intervienen en su arquitectura o ambiente.
A través de la Figura 3 se explicita la estructura del Data Warehouse.
Figura 3: Estructura de un Data Warehouse
La forma de operar de una solución BI a través de un DW se resume de la siguiente
manera:
1. Los datos son extraídos desde aplicaciones, bases de datos, archivos, etc.
Esta información generalmente reside en diferentes tipos de sistemas,
orígenes y arquitecturas y tienen formatos muy variados.
2. Los datos son integrados, transformados y limpiados, para luego ser cargados
en el Data Warehouse.
18

3. Principalmente, la información del Data Warehouse se estructura en cubos
multidimensionales, ya que estos preparan la información para responder a
consultas dinámicas con un buen rendimiento. Pero también pueden utilizarse
otros tipos de estructuras de datos para representar la información del Data
Warehouse, como por ejemplo Business Models10
.
4. Los usuarios acceden a los cubos multidimensionales, Business Models (u otro
tipo de estructura de datos) del Data Warehouse utilizando diversas
herramientas de consulta, exploración, análisis, generación de informes, entre
otras.
A continuación se detalla cada uno de los componentes de la arquitectura del Data
Warehouse, teniendo como referencia la Figura 3, resaltando el tema en concreto que
se vaya tratando.
I.1.3.1.1 OLTP Online Transaction Processing
Figura 4:Online Transaction Procesing
Los sistemas OLTP están diseñados para gestionar un gran número de peticiones
concurrentes sobre sus bases de datos. Están enfocados a que cada operación —
transacción— trabaje con pequeñas cantidades de filas, y a ofrecer una respuesta
rápida. Habitualmente utilizan Sistemas de Bases de Datos Relacionales (SGBDR)
para gestionar los datos y suelen estar altamente normalizados.
OLTP representa toda aquella información transaccional que genera la empresa en su
día a día, además de fuentes externas que puede llegar a disponer.
I.1.3.1.2 Load Manager
Figura 5: Load Manager
10 Business Models describe los fundamentos de cómo una organización crea, entrega y captan valores (económicos,
sociales, u otras formas de valor).
19

20 Chapter I
En un Data Warehouse se cargan y unifican periódicamente información procedente de
múltiples fuentes, esto implica que deben existir una serie de procesos que leen los
datos de las diferentes fuentes, los transforman, los adaptan al modelo que se haya
definido, los depuran y limpian para luego introducirlos en el Data Warehouse. Esto es
lo que se conoce como procesos ETL —Procesos de Extracción, Transformación y
Carga o Load.
Figura 6: Proceso ETL
A continuación se detalla cada una de estas etapas, donde se expone cuál es el
proceso que llevan a cabo los ETL y se enumera cuáles son sus principales tareas.
 Extracción.- Consiste en extraer los datos desde los sistemas de origen. La
mayoría de los proyectos de almacenamiento de información fusionan datos
provenientes de diferentes sistemas de origen, donde cada sistema puede usar
una organización diferente de los datos o formatos distintos. La extracción los
convierte a un formato preparado para iniciar el proceso de transformación.
Una vez que los datos son seleccionados y extraídos, se guardan en un
almacenamiento intermedio, lo cual permite manipular los datos sin interrumpir
ni paralizar los OLTP ni el Data Warehouse.
 Transformación: En estos procesos es preciso asegurar que los datos sean
válidos, íntegros y útiles, lo que suele incluir realizar cálculos y generar nuevos
valores. Los datos deben ser depurados para eliminar inconsistencias,
discrepancias y duplicidades. Los casos más comunes en los que se debe
realizar una transformación son los mostrados en la Tabla 2 .
Tabla 2: Casos más comunes de transformaciones ETL
Codificación
Al integrar varias fuentes de datos puede existir más de una
forma de codificar un atributo en común. Ejemplo: En el campo
sexo algunos diseñadores definen su valor como “M” y “F” otros
“Mujer” y “Hombre”. Se debe escoger una forma común para
decodificar los atributos.
Medida de atributos
Los tipos de unidades de medidas utilizados para representar los
atributos de una entidad varían considerablemente entre sí, a
través de los diferentes OLTP. Por ejemplo, al registrar la longitud
de un producto determinado, las unidades de medidas pueden
ser explicitadas en centímetros, metros, pulgadas, etc. Se
deberán estandarizar las unidades de medidas de los atributos,
para que todas las fuentes de datos expresen sus valores de
igual manera.
Convenciones de
nombramiento
Usualmente, un mismo atributo es nombrado de diversas
maneras en los diferentes OLTP. Por ejemplo, al referirse al
nombre del proveedor, puede hacerse como “nombre”,
“razón_social”, “proveedor”. Aquí, se debe utilizar la convención
de nombramiento que para los usuarios sea más comprensible
Fuentes múltiples
Un mismo elemento puede derivarse desde varias fuentes. En
este caso, se debe elegir aquella fuente que se considere más
ﬁable y apropiada.
20

Tabla 2: Casos más comunes de transformaciones ETL
Limpieza de datos
Su objetivo principal es el de realizar distintos tipos de acciones
contra el mayor número de datos erróneos, inconsistentes,
irrelevantes o datos faltantes o Missing Values. Las acciones
más comunes son: ignorarlos, eliminar la columna, filtrar la
columna, reemplazar valor o filtrar fila errónea
 Carga.- Esta función se encarga, por un lado de realizar las tareas
relacionadas con:
o Carga Inicial (Initial Load). Es el proceso de incorporar los datos al
Data Warehouse
o Actualización o mantenimiento periódico. Antes de realizar una nueva
actualización, es necesario identificar si se han producido cambios en
las fuentes originales de los datos recogidos, desde la fecha del último
mantenimiento, a fin de no atentar contra la consistencia del Data
Warehouse.
I.1.3.1.3 Data Warehouse Manager
Figura 7: Data Warehouse Manager
Si bien existen diversas estructuras de datos, a través de las cuales se puede
representar los datos del DW, solamente se entrará en detalle en los cubos
multidimensionales, por considerarse que esta estructura de datos es una de las más
utilizadas.
Un cubo multidimensional o hipercubo, representa o convierte los datos planos que se
encuentran en filas y columnas, en una matriz de N dimensiones.
Los datos se organizan en “hechos”, que tienen unos atributos o medidas que pueden
verse en mayor o menor detalle según ciertas “dimensiones”. Por ejemplo, una cadena
de supermercado puede tener como hechos las ventas. Cada venta tiene unas
medidas: importe, cantidad, número de clientes, etc., y se pueden detallar o agregar
varias dimensiones: tiempo de la venta, producto de la venta, lugar de la venta etc. Es
esclarecedor comprobar que las medidas responden generalmente a la pregunta
“cuánto”, mientras que las dimensiones responderán al “cuanto”,”que”,”donde”, etc.
El modelo dimensional es una adaptación del modelo relacional, con el fin de
optimizarlo para dar una rápida respuesta a las consultas realizadas por los usuarios.
Aunque a nivel físico, una vez implementado en un Sistema Gestor de Bases de Datos
21

22 Chapter I
Relacionales, lo que allí se encuentra son tablas y relaciones entre ellas, a nivel
conceptual conocer que existen dos tipos de tablas en un modelo dimensional:
 Tablas de dimensiones.- Definen como están los datos organizados
lógicamente y proveen el medio para analizar el contexto del negocio
 Tablas de hechos.- Son datos instantáneos en el tiempo, que son filtrados,
agrupados y explorados a través de condiciones definidas en las tablas de
dimensiones.
Las bases de datos multidimensionales implican tres variantes posibles de modelado,
que permiten realizar consultas orientadas a la toma de decisiones, representados en
los siguientes esquemas:
 Esquema en estrellas
 Esquema en copo de nieve
 Esquema constelación
Estos esquemas pueden ser implementados de diversas maneras que,
independientemente al tipo de arquitectura, requieren que toda la estructura de datos
este desnormalizada o semi desnormalizada, para evitar desarrollar uniones complejas
de acceso a la información, con el fin de agilizar la ejecución de consultas. Los
diferentes tipos de implementación son: relacional, multidimensional e híbrido
A continuación se entra en detalle en los diferentes tipos de tablas —dimensiones y
hechos— indicadas anteriormente, así como las características de un cubo
multidimensional y los diferentes esquemas de modelado de un DW.
Tablas de dimensiones
Las tablas de dimensiones definen como están los datos organizados lógicamente y
proveen el medio para analizar el contexto del negocio. Contienen datos cualitativos.
En la Figura 8 podemos ver varias tablas dimensión con sus correspondientes
atributos.
Figura 8: Tablas de Dimensiones
A veces estos atributos están organizados en jerarquías para describir niveles de
agrupamiento específicos explícitos o implícitos) y, por tanto, las diferentes
granularidades o niveles de detalle en la visión de los datos. Las jerarquías forman
distintos niveles, relacionados entre sí, y son utilizados para realizar operaciones
de agrupamiento. Por ejemplo la jerarquía correspondiente a la dimensión tiempo
podría estar formada por los atributos Año, Mes y Día. Los diferentes tipos de
22

jerarquías que se pueden establecer para describir niveles de agrupamiento
específicos se pueden observar en la Figura 9 y se describen en la Tabla 3.
Figura 9: Esquema de organización jerárquica de las dimensiones
Tabla 3: Organización jerárquica de las dimensiones
Dimensiones
degeneradas
Este término hace referencia a un campo que será utilizado como criterio de análisis y
que es almacenado en la tabla de hechos.
Esto sucede cuando un campo que se utiliza como criterio de análisis posee el mismo
nivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no se
pueden realizar agrupaciones o sumarizaciones a través de este campo, como por
ejemplo "números de orden", "números de ticket", "números de transacción", etc.
Atributos no
dimensión
Los niveles de la jerarquía también pueden tener atributos descriptivos, donde no son
utilizados para formar niveles de jerarquía, sino para describir detalles en los mismos,
como por ejemplo, el número de teléfono, la dirección de correo electrónico, etc.
Jerárquicas
Describen diferentes niveles de agrupamiento específicos —explícitos o implícitos— y,
por lo tanto, las diferentes granularidades o niveles de detalle en la visión de los datos,
como por ejemplo la jerarquía formada por Año, Trimestre, Mes y Día
En las tablas dimensiones, habitualmente no es posible utilizar la clave de negocio —
business key— como clave principal —primary key— e incluso, en el caso que sea
posible, no es aconsejable por temas de rendimiento, ya que desde este punto de vista
es recomendable utilizar número enteros de pocos bytes. Si en un sistema
transaccional tenemos, por ejemplo, una clave principal con dominio char(10), siempre
será más óptimo utilizar un tipo de datos numérico de menos byte como clave principal
en las tablas dimensiones. Se sustituirán las habituales clave de negocio por claves
subrogadas —subrogate key— las cuales serán de tipo numérico y habitualmente
autoincremental. Esta clave no tiene sentido a nivel de negocio, pero la necesitamos
para identificar de forma única cada una de las filas.
Un concepto importante dentro de este apartado son las dimensiones lentamente
cambiantes o Slowly Changing Dimensions (SCD). Son dimensiones en las cuales sus
datos tienden a modificarse a través del tiempo, ya sea de forma ocasional o constante,
o implique a un solo registro o a la tabla completa. Cuando ocurren estos cambios, se
puede optar por seguir alguna de estas dos grandes opciones:
 Registrar el historial de cambios.
 Reemplazar los valores que sean necesarios.
23

24 Chapter I
Inicialmente Ralph Kimball11
planteó tres estrategias a seguir cuando se tratan las SCD:
tipo 1, tipo 2 y tipo 3, pero, a través de los años, la comunidad de personas que se
encargaba de modelar bases de datos profundizó las definiciones iniciales e incluyó
varios tipos SCD más, como tipo 4 y tipo 6. A continuación se detalla cada tipo de
estrategia SCD:
SCD Tipo 1: Sobreescribir.
SCD Tipo 2: Añadir fila.
SCD Tipo 3: Añadir columna.
SCD Tipo 4: Tabla de Historia separada.
SCD Tipo 6: Híbrido.
De acuerdo a la naturaleza del cambio se debe seleccionar qué Tipo SCD se utilizará y,
en algunos casos, resultará conveniente combinar varias técnicas.
Tablas de Hechos
Las tablas de hechos representan un proceso de negocio, como por ejemplo, las
ventas, las compras, los pagos entre otras. Estas tablas son utilizadas por los analistas
de negocio para apoyar el proceso de toma de decisiones. Contienen datos
cuantitativos.
Los hechos son datos instantáneos en el tiempo, que son filtrados, agrupados y
explorados a través de condiciones definidas en las tablas de dimensiones. El registro
de hecho posee una clave primaria que está compuesta por las claves primarias de las
tablas de dimensiones relacionadas a este.
Figura 10: Tabla de hecho “Ventas”
En la Figura 10 se aprecia la tabla de hechos “VENTAS” ubicada en el centro y
conectada a ella, mediante sus claves primarias, se encuentran las tablas de
dimensiones “CLIENTES”, “PRODUCTOS” y “FECHAS”. Es por ello que la clave
primaria de la tabla de hechos es la combinación de las claves primarias de sus
dimensiones. Los hechos en este caso son “ImporteTotal” y “Utilidad”.
11 Ralph Kimball reconocido como uno de los padres del concepto de Datawarehouse, se ha dedicado desde hace ya
más de 10 años al desarrollo de su metodología para que este concepto sea bien aplicado en las organizaciones y se
asegure la calidad en el desarrollo de estos proyectos.
24

Es importante a la hora de diseñar una tabla de hechos, tener en cuenta el nivel de
granularidad que va a tener, es decir, el nivel de detalle más atómico que vamos a
encontrar de los datos: no es lo mismo tener una fila por cada venta, que una fila donde
se indiquen las ventas del día para cada artículo y tienda.
Existen dos tipos de hechos:
 Hechos básicos.- Se encuentran representados por un campo de una tabla de
hechos. Los campos “precio” y “cantidad” de la Figura 11 son hechos básicos.
 Hechos derivado.-: Se forman al combinar uno o más hechos con alguna
operación matemática o lógica y que también residen en una tabla de hechos.
El campo “total” de la Figura 11 es un hecho derivado, ya que se conforma de
la siguiente manera: total = precio * cantidad.
Figura 11: Hechos Básicos y Derivados
Otro concepto importante a tener en cuenta es la agregación, proceso por el cual se
resumen los datos a partir de las filas de detalle de máxima granularidad.
Cubo Multidimensional
Como se ha comentado, si bien existen diversas estructuras de datos, a través de las
cuales se puede representar los datos del DW, solamente se entrará en detalle en los
cubos multidimensionales.
Los objetos más importantes que se pueden incluir en un cubo multidimensional son
los siguientes:
 Indicadores.- Sumarizaciones que se efectúan sobre algún hecho o
expresiones pertenecientes a una tabla de hechos.
 Atributos de dimensión.- Campos o criterios de análisis, pertenecientes a tablas
de dimensiones.
 Jerarquías de dimensiones.- Representa una relación lógica entre dos o más
atributos.
Se puede observar, que el resultado del análisis está dado por los cruces matriciales de
acuerdo a los valores de las dimensiones seleccionadas.
Más especíﬁcamente, para acceder a los datos del Data Warehouse, se pueden
ejecutar consultas sobre algún cubo multidimensional previamente deﬁnido. Dicho cubo
debe incluir, entre otros objetos, indicadores, atributos y jerarquías basados en los
campos de las tablas de dimensiones y de hechos que se deseen analizar. De esta
manera, las consultas se responden con un alto rendimiento, minimizando al máximo el
25

26 Chapter I
tiempo que hubiese incurrido en realizar dicha consulta sobre una base de datos
transaccional.
Como ejemplo, en la Figura 12 se representa un cubo tridimensional donde las
dimensiones producto, lugar y tiempo se han agregado por artículo, ciudad y trimestre.
La representación de un hecho corresponde a una casilla de dicho cubo, el valor de la
casilla es la medida observada, importe de ventas, concretamente el hecho que se
observa en dicha figura muestra que “el primer trimestre de 2004 la empresa vendió en
Valencia por un importe de 22.00 euros el producto Androbio 33cl”
Figura 12: Ejemplo cubo multidimensional
Resaltar que un cubo no es más que una base de datos multidimensional, en la cual el
almacenamiento físico de los datos se realiza en un vector multidimensional.
Indicadores de rendimiento clave o KPI
Los indicadores de rendimiento clave (KPI) son métricas financieras o no, utilizadas
para cuantificar objetivos que reflejan el rendimiento de una organización,
recogiéndose generalmente en su plan estratégico. Estos indicadores son utilizados en
BI para asistir o ayudar, al estado actual de un negocio, a prescribir una línea de acción
futura. Los indicadores de rendimiento son frecuentemente utilizados para "valorar"
actividades complicadas de medir como los beneficios de desarrollos líderes, eficiencia
de empleados, servicio o satisfacción de un cliente.
Los KPIs deberían preferiblemente cumplir los siguientes criterios esenciales (SMART):
eSpecificos (Specific)
Medibles (Measurable)
Alcanzables (Achievable)
Realista (Realistic)
a Tiempo (Timely)
Atributos
Los atributos constituyen los criterios que se utilizan para analizar los indicadores
dentro de un cubo multidimensional. Los mismos se basan, en su gran mayoría, en los
campos de las tablas de dimensiones y/o expresiones. Dentro de un cubo
multidimensional, los atributos son los ejes del mismo.
26

Jerarquías
Como se comentó en el apartado Data Warehouse Manager de tablas de dimensión,
una jerarquía representa una relación lógica entre dos o más atributos pertenecientes a
un cubo multidimensional. Pueden existir varias en un mismo cubo.
La principal ventaja de manejar jerarquías, reside en poder analizar los datos desde su
nivel más general al más detallado y viceversa, al desplazarse por los diferentes
niveles.
Figura 13: Jerarquía fecha
Esquemas de modelado de un Data Warehouse
Los tipos de esquemas de modelado de un Data Warehouse son los siguientes:
 Esquema en estrella.- Consta de una tabla de hechos central y de varias tablas
de dimensiones relacionadas a esta por sus claves. Este modelo debe estar
totalmente desnormalizado. En la Figura 14 se puede apreciar un esquema en
estrella.
Figura 14: Esquema en estrella
 Esquema en copo de nieve.- Es una estructura algo más compleja que el
esquema en estrella. Se da cuando alguna de las dimensiones se implementa
con más de una tabla de datos y/o estas se organizan en jerarquías de
dimensiones. La Figura 15 muestra un ejemplo de esquema en copo de nieve.
27

28 Chapter I
Figura 15: Esquema en copo de nieve
 Esquema constelación.- Está compuesto por una serie de esquemas en
estrellas, tal como se puede apreciar en Figura 16 No es necesario que las
diferentes tablas de hechos compartan las mismas dimensiones.
Figura 16: Esquema en constelación
En la Tabla 4 se puede observar un resumen comparativo de ambos esquema.
Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse
Modelo Ventajas Inconvenientes
Estrella
La desnormalización permite obviar
uniones —Join— entre las tablas
cuando se realizan consultas,
procurando así un mejor tiempo de
respuesta y una mayor sencillez con
respecto a su utilización
Más simple de interpretar
Optimiza los tiempos de respuesta
ante las consultas
La desnormalización con la que cuenta
genera un cierto grado de redundancia
Necesidad de mayor espacio de
almacenamiento
Menos robusto para la carga
Es el más lento de construir
Copo de
nieve
Posibilidad de segregar los datos de
las tablas de dimensiones y proveer un
esquema que sustente los
requerimientos de diseño.
Muy ﬂexible y puede implementarse
después de que se haya desarrollado
un esquema en estrella.
Hace una mejor utilización del espacio.
Puede desarrollar clases de jerarquías
fuera de las tablas de dimensiones,
que permiten realizar análisis de lo
general a lo detallado y viceversa.
Si se poseen múltiples tablas de
dimensiones, cada una de ellas con
varias jerarquías, se creará un número
de tablas bastante considerable, que
pueden llegar al punto de ser
inmanejables
Al existir muchas uniones y relaciones
entre tablas, el desempeño puede verse
reducido
La existencia de las diferentes jerarquías
de dimensiones debe estar bien
fundamentada, ya que de otro modo las
consultas demorarán más tiempo en
28

Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse
devolver los resultados, debido a que se
deben realizar las uniones entre las
tablas.
Constelació
n
Permite tener más de una tabla de
hechos, por lo cual se podrán analizar
más aspectos claves del negocio con
un mínimo esfuerzo adicional de
diseño.
Contribuye a la reutilización de las
tablas de dimensiones, ya que una
misma tabla de dimensión puede
utilizarse para varias tablas de hechos.
No es soportado por todas las
herramientas de consulta y análisis
Data Warehouse vs OLTP
Debido a que, ya se han explicado y caracterizado los distintos tipos de esquemas del
DW, se procederá a exponer las razones de su utilización, como también las causas de
por qué no se emplean simplemente las estructuras de las bases de datos
tradicionales. Esta comparación se puede ver en la Tabla 5.
Tabla 5: OTLP VS Data Warehouse
OLTP Data Warehouse
Objetivo
Soportar actividades
transaccionales
Consultar y analizar información
estratégica y táctica
Tiempo de datos Operacionales Para la toma de decisiones
Modelo de datos Normalizado Desnormalizado
Consulta SQL SQL más extensiones
Datos consultados 60-90 días 5-10 años
Tipos de consultas Repetitivas, predefinidas No previsibles, dinámicas
Nivel de almacenamiento Nivel de detalle
Nivel de detalle y diferentes niveles
de sumarización
Acciones disponibles Alta, baja, modificación y consulta Carga y consulta
Número de transacciones Elevado Medio o bajo
Tamaño Pequeño-Mediano Grande
Tiempo de respuesta Pequeño Variable
Orientación Orientado a las aplicaciones Orientado al negocio
Sello de tiempo
La clave puede o no tener un
elemento de tiempo
La clave tiene un elemento de
tiempo
Estructura Generalmente estable
Generalmente varía de acuerdo a
su propia evolución y utilización
29

30 Chapter I
Implementación de un Data Warehouse
Los distintos tipos de implementación de un Data Warehouse son los siguientes:
1. Implementación ROLAP (Procesamiento Analítico Online Relacional).- Se trata de
sistemas y herramientas OLAP (Online Analytic Processing) construidos sobre una
base de datos relacional. Típicamente, los datos son detallados, evitando las
agregaciones, y las tablas se encuentran normalizadas. Los esquemas más
comunes sobre los que se trabaja son estrella o copo de nieve, aunque es posible
trabajar sobre cualquier base de datos relacional. La arquitectura está compuesta
por un servidor de banco de datos relacional y el motor OLAP se encuentra en un
servidor dedicado. La principal ventaja de esta arquitectura es que permite el
análisis de una enorme cantidad de datos.
2. Implementación MOLAP (Multidimensional Online Analytical Processing o
'Procesamiento Analítico Multidimensional en línea'). Se trata de una alternativa a
la tecnología ROLAP (OLAP-Relacional). Aunque ambos tipos de herramientas
están diseñadas para realizar análisis de datos a través de un modelo de datos
multidimensional, MOLAP se diferencia significativamente en que requiere un
preprocesamiento y almacenamiento de la información contenida en el cubo OLAP.
MOLAP almacena estos datos en una matriz de almacenamiento multidimensional
optimizada, más que en una base de datos relacional (o en un ROLAP). Para
optimizar los tiempos de respuesta, el resumen de la información es usualmente
calculado por adelantado. Estos valores precalculados o agregaciones son la base
de las ganancias de desempeño de este sistema. Algunos sistemas utilizan
técnicas de compresión de datos para disminuir el espacio de almacenamiento en
disco debido a los valores precalculados.
3. Implementación HOLAP (Hybrid Online Analytical Process o Procesamiento
Analítico en línea Híbrido). Es una combinación de ROLAP y MOLAP. HOLAP
permite almacenar una parte de los datos como en un sistema MOLAP y el resto
como en uno ROLAP. El grado de control que el operador de la aplicación tiene
sobre este particionamiento varía de unos productos a otros.
I.1.3.1.4 Query Manager
Figura 17: Query Manager
Este componente realiza las operaciones necesarias para soportar los procesos de
gestión y ejecución de consultas relacionales y de consultas propias de análisis de
30

datos, es decir, Query Manager recibe las consultas de los usuarios, las aplica a la
estructura de datos correspondiente —cubo multidimensional, Business Models, etc..—
y devuelve los resultados obtenidos.
Cabe aclarar que una consulta a un DW, generalmente consiste en la obtención de
indicadores a partir de los datos —hechos— de una tabla de hechos, restringidas por
las propiedades o condiciones de los atributos que hayan sido creados.
El procesamiento analítico en línea OLAP, es la componente más poderosa de un Data
Warehouse, ya que es el motor de consultas especializadas del Data Warehouse. Las
herramientas OLAP, son una tecnología de software para análisis en línea,
administración y ejecución de consultas, que permiten inferir información del
comportamiento del negocio.
Su principal objetivo es el de brindar rápidas respuestas a complejas preguntas, para
interpretar la situación del negocio y tomar decisiones. Cabe destacar que lo que es
realmente interesante en OLAP, no es la ejecución de simples consultas tradicionales,
sino la posibilidad de utilizar operadores, como se muestran en la Tabla 6, que permitan
profundizar en la información.
Tabla 6: Operaciones definidas dentro de un Data Warehouse
Drill-down
Permite apreciar los datos en un mayor detalle, bajando por una jerarquía
definida en un cubo. Esto brinda la posibilidad de introducir un nuevo nivel o
criterio de agregación en el análisis, disgregando los grupos actuales
Drill-up
Permite apreciar los datos en menor nivel de detalle, subiendo por una jerarquía
definida en un cubo. Esto brinda la posibilidad de quitar un nivel o criterio de
agregación en el análisis, agregando los grupos actuales.
Drill-acros
Funciona de forma similar a drill-down, con la diferencia que drill-across no se
realiza sobre una jerarquía, sino que su forma es ir de lo general a lo específico,
agregando un atributo a la consulta como nuevo criterio de análisis.
Roll-across
Funciona de forma similar a drill-up, con la diferencia que roll-across no se hace
sobre una jerarquía, sino que su forma de ir de lo específico a lo general es
quitar un atributo de la consulta, eliminando de esta manera un criterio de
análisis.
Drill-through
Permite apreciar los datos en su máximo nivel de detalle. Esto brinda la
posibilidad de analizar cuáles son los datos relacionados al valor de un
Indicador, que se ha sumarizado dentro del cubo multidimensional.
I.1.3.1.5 Herramienta de consulta y análisis
31

32 Chapter I
Figura 18: Herramienta de consulta y análisis
Las Herramienta de Consulta y Análisis son sistemas que permiten a los usuarios
realizar la exploración de datos del Data Warehouse, constituyendo la unión entre el
Data Warehouse y los usuarios.
A través de una interfaz gráfica y una serie de pasos, los usuarios generan consultas
que son enviadas desde la Herramienta de Consulta y Análisis al Data Warehouse,
devolviendo los resultados obtenidos a la herramienta que se los solicitó. Luego estos
resultados son expuestos antes los usuarios en formatos que le sean familiares.
Algunas de las interfaces a través de las cuales podemos representar los resultados de
las consultas pueden ser:
 Cuadros de mando12
 Informes estáticos13
 Informes dinámicos
I.1.3.1.5.1 Usuarios
Figura 19: Usuarios
Los usuarios que posee el Data Warehouse son aquellos que se encargan de tomar
decisiones y de planiﬁcar las actividades del negocio, es por ello que se hace tanto
énfasis en la integración, limpieza de datos, etc, para poder conseguir que la
información posea toda la calidad posible.
Es a través de las herramientas de consulta y análisis, que los usuarios exploran los
datos en busca de respuestas para poder tomar decisiones proactivas. La diferencia
entre un usuario OLTP y otro Data Warehouse se ven reflejadas en la Tabla 7.
12 Los cuadros de mandos se pueden entender como una colección de informes, consultas y análisis
interactivos que hacen referencia a un tema en particular y que están relacionados entre sí.
13 La elección de uno u otro tipo de informe dependerá fundamentalmente del uso que se pretenda dar a
dichos informes.
32

Tabla 7: Usuarios OLTP vs usuarios Data Warehouse
Usuarios OLTP Usuarios Data Warehouse
Acceso concurrente Muchos Pocos
Tipo de consultas Predefinidas
Complejas, no predecibles y no
anticipadas
Registros consultados Pocos Muchos
Tiempo de respuesta Crítico No crítico
Acciones permitidas
Agregar, modificar,
eliminar y consultar
Consultar
I.1.3.1.6 Conceptos complementarios: Datamarts
Un Datamarts (DM) es una versión especial del Data Warehouse. Son subconjuntos de
datos con el propósito de ayudar a que un área específica dentro del negocio pueda
tomar mejores decisiones. Los datos existentes en este contexto pueden ser
agrupados, explorados y propagados de múltiples formas para que diversos grupos de
usuarios realicen la explotación de los mismos de la forma más conveniente según sus
necesidades.
En síntesis, se puede decir que los Datamarts son pequeños Data Warehouse
centrados en un tema o un área de negocio específico dentro de una organización.
Por ejemplo la información de personal de una empresa —empleados, departamento,
proyectos— es difícilmente integrable en un mismo modelo de estrella de ventas.
Incluso en ámbitos más relacionados de una organización, ventas y producción no
resulta fácil. La solución está en que para cada subámbito de la organización se va a
construir una estructura en estrella. Por tanto, el Data Warehouse estará formado por
muchas estrellas, cada una de estas estrellas es un Datamarts. Lógicamente cada
Datamart tendrá unas medidas y dimensiones propias y diferentes de los demás, la
única dimensión que suele aparecer en todos los Datamarts es la dimensión tiempo, ya
que el Data Warehouse representa información histórica.
Figura 20: Datamarts
33

34 Chapter I
Capítulo 2. ITOP Management
Consulting
Resumen:
ITOP MC es una empresa de consultaría de Negocios y Gestión Empresarial con la que se
ha colaborado en la consecución de este proyecto. En términos BI, la empresa ITOP
desempeña el papel de Product Owner.
2.1 La empresa
ITOP Management Consulting (ITOP MC) es una empresa experta en Consultoría de
Negocios y Gestión Empresarial, especializada en Tecnologías de la Información, que
ofrece sus servicios de gestión global a las PYMEs, colaborando con una red sólida de
partners y con compañías punteras pertenecientes al sector informático y empresarial.
ITOP Management Consulting nace en el año 2006 como una iniciativa de varios
socios con más de 10 años de experiencia en el mundo de la Consultoría de
Tecnologías de la Información. El objetivo principal de la creación de esta consultora es
ofrecer a la empresa canaria un servicio local de calidad en este terreno de la
consultoría cuya demanda y dependencia de empresas de la península es muy
grande y ofrecer una oportunidad al consultor que, habiendo desarrollado su carrera
fuera de las islas, quiera volver a ellas pero con el condicionante de encontrar una
empresa en la que pueda seguir evolucionando de forma profesional, y en unas
condiciones similares a las empresas en las que ha estado trabajando.
La experiencia de los socios actuales se ha desarrollado en empresas de gran prestigio
y experiencia dentro del sector de la consultoría a nivel nacional e internacional tales
como: CSC, Indra, Unisys, Realtech, SAP, etc.
Alguno de los clientes con los que se ha trabajado en diferentes proyectos han sido:
Repsol, Telefónica, Bayer, GlaxoWellcome, ICEX, Turespaña y un largo etcétera.
2.2 Filosofía
La integración horizontal que pretende ITOP con todos sus clientes hace que éstos
evolucionen hacia el concepto de socios-clientes. La empresa es consciente de que
tiene mucho que aportar en el crecimiento de sus clientes, al igual que ellos les facilitan
la energía necesaria para seguir creciendo e invirtiendo en ideas. La filosofía de la
empresa queda reflejada en el nombre ITOP —Información, Tecnología, Organización,
Procesos.
34

2.3 Alianzas
Las principales alianzas y áreas de experiencia del equipo de ITOP MC son:
• HP
• Microsoft
• SAP
 SAP Business One
 SAP R/3
35

36 Chapter I
Capítulo 3. Descripción del problema e
integración de soluciones tecnológicas
Resumen:
En este capítulo se describe el estudio realizado a lo largo del proyecto para la elección de
las tecnologías por las que se iban a apostar para la construcción de una solución BI.
3.1 Introducción
Sap Business One (Sap BO) es una única aplicación de gestión empresarial integrada
integra todas las funciones empresariales básicas necesarias en cualquier empresa
(incluye gestión financiera, ventas, gestión de atención al cliente, e-commerce, gestión
de inventarios y operaciones).
El problema a abordar consiste en integrar SAP BO con una solución BI, de forma que
proporcione a las Pymes informes gráficos y cuadros de mando interactivos que
ofrezcan una mayor versatilidad, control de los ingresos, los márgenes y la liquidez.
Con esta aplicación de BI, se ofrece funcionalidades para la gestión del conocimiento
que ayudan a las empresas a poner en contacto a "aquellos que saben" con "aquellos
que necesitan saber".
3.2 Análisis funcional y elección
En este capítulo se describe el estudio realizado a lo largo del proyecto para la elección
de las tecnologías por las que se iban a apostar para la construcción de una solución
BI.
3.2.1 Análisis Inicial
La evolución del Business Intelligence (BI) durante los últimos 10 años ha sido muy
interesante, sobre todo en la manera en cómo se han simplificado el desarrollo e
implantación de proyectos de este tipo, gracias a las tecnologías que han sabido
adaptarse a las necesidades de los usuarios, tanto de perfil desarrollador como
usuarios finales.
En el año 1998 el esfuerzo era realmente muy grande para poder plasmar en un
informe las necesidades del usuario final, con el fin de que pudiera realizar un
monitoreo y análisis de la información. En aquel momento las herramientas eran algo
primitivas, en cuanto a la presentación de los datos y al desarrollo de las mismas,
36

teniendo muchas restricciones de formatos en los que se podía mostrar la información.
En consecuencia, se tenían que implementar desarrollos adicionales con el objetivo de
complementar las herramientas de BI existentes. El escenario típico era el desarrollo
en Visual Basic; con este lenguaje se creaba una aplicación de presentación enfocada
a un ambiente más ejecutivo, amigable, permitiéndoles a los usuarios finales de la
herramienta de BI realizar un análisis con el ya famoso término "Drill Down", que en
aquellos tiempos era lo último en tecnología14
.
Con el tiempo la historia fue cambiando y ahora existen innumerables tecnologías para
llevar a cabo una solución BI, tanto con herramientas propietarias como con
OpenSource, cuyas dos vertientes también fueron analizadas en este proyecto.
I.3.2.1.1 Análisis de una solución BI con Software privativo.
Por la parte del Software privativo se encontró que existían muchas empresas
dedicadas a desarrollar software que facilita el desarrollo de una solución BI. Para
conocer cuáles de ellas eran las líderes se procedió al estudio del cuadrante de
Gartner del año 2010. Gartner es una empresa consultora, la cual realiza y publica una
serie de análisis, de las más fiables referencias, para conocer el estado y nivel de
madurez de los proveedores de BI más influyentes de la actualidad. En la Figura 21
muestra el análisis de Gartner del 2010:
 En el eje X “completeness of visión” se representa el conocimiento de los
proveedores indicando cómo se puede aprovechar el momento actual del
mercado para generar valor, tanto para sus clientes como para ellos mismos.
 En el eje Y “ability to execute” trata de querer medir la habilidad de los
proveedores para ejecutar con éxito su visión del mercado.
14 The Datawarehouse Toolkit de Ralph Kimball
37

38 Chapter I
Figura 21: Cuadrante de Gartner BI 2010
Estos dos baremos dividen al cuadrante en cuatro sectores en donde se clasifican los
proveedores estudiados.
 Leaders: Esta categoría, en principio, es la mejor. Situarse aquí significa haber
puntuado alto en los dos ejes de medidas, por lo que se puede esperar de
estos proveedores una solución de productos amplia, completa y madura, que
evoluciona según demanda el mercado. Por otra parte también nos sugiere
que el proveedor goza de buena salud como empresa y que dispone de
medios suficientes para implantar con éxito su solución en variados escenarios.
 Visionaries: En esta categoría entrarían aquellos proveedores con una buena
puntuación en “completeness of visión” pero peor puntuación en “ability to
execute”. Por lo tanto aquí estarán las empresas con una fuerte y acertada
visión del mercado actual en Business Intelligence. Sin embargo, a pesar de
sus buenas ideas, aún puede que no tengan la capacidad para llevar
implantaciones, bien sea por su tamaño o por otras circunstancias.
 Challengers: Este es el caso contrario al de los Visionaries. Se trata de
proveedores bien posicionados y que ofrecen altas posibilidades de éxito a la
hora de implantar su solución. No obstante, suelen ofrecer poca variedad de
productos, o directamente centrarse en un único aspecto de lo que demanda el
mercado. También puede ocurrir que se trate de un déficit en su canal de
ventas o presencia geográfica.
 Niche Players: La última categoría en principio es la más desfavorable. Son
proveedores que no llegan a puntuar lo suficiente en ninguna categoría como
para alcanzar uno de los otros cuadrantes. No obstante, no significa que por
ello sus soluciones no tengan calidad. Por otra parte, la falta de puntuación en
“completeness of visión” nos da una idea de que estos proveedores no están
38

evolucionando sus soluciones suficientemente rápido y de alguna manera
están perdiendo parte de la perspectiva.
Una vez visto que representan las diferentes áreas del cuadrante de Gartner, se
analiza como Oracle y Microsoft, consolidadas en el año 2010 como las empresas
líderes en producto BI, son las mejores por lo cual se decide apostar por Microsoft
como una opción muy interesante para desarrollar este proyecto —destacar además
que la empresa ITOP MC ya poseía una serie de licencias por lo que no habría que
realizar una nueva inversión a priori.
Para poder implantar una solución BI usando tecnologías de Microsoft es necesario los
requerimientos que se muestran en la Tabla 8, resumidos en la Figura 22.
Tabla 8: Requerimientos tecnológicos básicos para una solución BI con Microsoft
Requerimientos de Software ¿Qué solución necesitamos? ¿Qué nos aporta?
Sistema Operativo Windows 2008 R2 64bits
Conexiones remotas, trabajo
concurrente y Sistema Operativo
Windows convencional
Servidor de Integración de
datos
SQL Server 2008 R2 Integration
Services (SSIS)
Servidor para realizar y planificar el
proceso de Extracción,
Transformación y Carga de los
datos de origen
Servidor de Base de datos
Analista o OLAP
SQL Server 2008 R2 Analisys
Servicies (SSAS)
Análisis y optimización de los datos
almacenados en el DW
Sistema gestor de base de
datos SQL Server 2008 R2 64bits
Gestión y creación de almacén de
datos
Servidor de Informes
SQL Server 2008 R2 Reporting
Services (SSRS)
Representación de informes
alimentados desde un Cubo OLAP
Cuadros de mando
Crystal Xcelsius 2008 (No
pertenece a Microsoft pero está
totalmente integrada, con
cualquier producto de esa
empresa)
Cuadros de mando dinámicos
basados en Flash, exportables a
Excel, PDF, etc.
SharePoint Foundation 2010 +
Performance Point
Diseñador de cuadro de mando
integrables en los portales Web
corporativos Share Point
Silverlight 4.0
Cuadros de mando dinámicos y con
conexión directa al cubo OLAP
Microsoft Office Excel 2007 +
Power Pivot
Tablas y cuadros de mando
dinámicos con conexión directa a los
cubos OLAP
39

40 Chapter I
Figura 22: Solución tecnológica propuesta para una solución BI usando herramientas Microsoft
Se realizó además una comparación de las características que nos aporta cada una de
las herramientas de presentación y cuadros de mando, indicada en la Tabla 9. Con
respecto a la parte de Sistema Gestor de Bases de Datos y Sistema Operativo se parte
del punto que los clientes, a los que se les quieres implantar la solución BI, ya tienen
disponibles el software necesario derivado de la contratación ERP SAP BO, así como
el deseo por parte de ITOP MC de la importancia del uso de Share Point para tener
acceso, tanto externo como interno, a sus cuadros de mando por parte de sus clientes
desde cualquier parte y dispositivo.
Tabla 9: Tabla comparativa del Software de representación
SSRS
Crystal
Xcelsius
Performance
Point
Silverlight
Microsoft
Excel
Publicación
SharePoint
Características
interactivas
Programables
(SDK)
Interfaz Amigable
Integración con
SAP
Publicables en
Web
40

Tabla 9: Tabla comparativa del Software de representación
SSRS
Crystal
Xcelsius
Performance
Point
Silverlight
Microsoft
Excel
Facilidad de uso
Costo de licencia
aceptable
Valoración final
En mayor o menor medida las cuatro herramientas se ajustan a las necesidades por
tanto se escogieron dos y el resto quedaron estudiadas para futuros proyectos:
 Generación de informes: SSRS y Microsoft Excel
 Creación de cuadros de mando: Microsoft Excel y Cristal Xcelsius
I.3.2.1.2 Análisis de una solución BI con Open Source.
En cuanto al estudio que se realizó por la vertiente del Open Source se escogió la
solución BI mejor valorada: Pentaho.
La plataforma Open Source Pentaho Business Intelligence cubre muy amplias
necesidades de Análisis de los Datos y de presentación de información empresarial.
Las soluciones de Pentaho están escritas en Java y tienen un ambiente de
implementación también basado en IDE Eclipse. Eso hace de Pentaho una solución
muy flexible para cubrir una amplia gama de necesidades empresariales —tanto las
típicas como las sofisticadas y especificas al negocio.
La Figura 23 muestra un esquema de la estructura de Pentaho.
Figura 23: Estructura de la solución de Pentaho
Los módulos de la plataforma Pentaho BI son:
41

42 Chapter I
 Reporting.- Módulo de informes que ofrece la solución adecuada a las
necesidades de los usuarios. Pentaho Reporting es una solución basada en el
proyecto JFreeReport y permite generar informes ágil y de gran capacidad.
Pentaho Reporting permite la distribución de los resultados del análisis en
múltiples formatos —todos los informes incluyen la opción de imprimir o
exportar a formato PDF, XLS, HTML y texto—, además de admitir
programación de tareas y ejecución automática de informes con una
determinada periodicidad.
 Análisis.- Pentaho Análisis suministra a los usuarios un sistema avanzado de
análisis de información, con uso de las tablas dinámicas —pivot tables,
crosstabs—, generadas por Mondrian y JPivot. El usuario puede navegar por
los datos, ajustando la visión de los mismos, los filtros de visualización,
añadiendo o quitando los campos de agregación. Los datos pueden ser
representados en una forma de SVG o Flash, los dashboards widgets, o
también integrados con los sistemas de Minería de Datos y los portales web o
portlets. Además, con Microsoft Excel Analysis Services, se puede analizar los
datos dinámicos en Microsoft Excel —usando la conexión a OLAP server
Mondrian.
 Portal de BI: En este portal web se publica toda la información recolectada en
los procesos de análisis.
 Dashboards.- Todos los componentes del módulo Pentaho Reporting y
Pentaho Análisis pueden formar parte de un Dashboard. En Pentaho
Dashboards es muy fácil incorporar una gran variedad en tipos de gráficos,
tablas y velocímetros —Dashboard widgets— e integrarlos con los Portlets
JSP, en donde podrá visualizar informes, gráficos y análisis OLAP. Así como
una librería de código abierto integrada en el Portal de BI que nos proporciona
Pentaho denominada CDF (Community Dashboard Framework).
 Data Mining.- Minería de datos se realiza con una herramienta WeKa.
 Integración de Datos.- Se realiza con una herramienta Kettle ETL (Pentaho
Data Integration) que permite implementar los procesos ETL. Últimamente
Pentaho lanzó una nueva versión PDI 3.0, que marcó un gran paso adelante
en OSBI ETL y que hizo Pentaho Data Integration una alternativa interesante
para las herramientas comerciales.
3.2.2 Conclusión
Una vez estudiada la vertiente del software privativo y Open Source se procedió a
comparar y decidir por cual se va optar para desarrollar el proyecto. Resaltar que
ambas herramientas fueron instaladas y testeadas antes de su selección. Para más
detalle mirar la Tabla 10.
42

Tabla 10: Tabla comparativa Pentaho vs Microsoft
Pentaho Microsoft
Documentación
Integración con otras herramientas Sólo especificas
Posibilidad de añadir funcionalidades
Integrables con SharePoint
Facilidad para implementar cuadros de
mando
con el uso de
herramientas externas
Coste de Licencias
Curva de aprendizaje
Multiplataforma. Múltiple sistema de
BBDD
Valoración final
Finalmente se decidió decantarse por la solución propuesta por Microsoft debido a los
siguientes motivos:
 Documentación más homogénea, sólida y abundante.
 Mayor bibliografía que Pentaho, quizás porque esta última utiliza herramientas
muy heterogéneas entre sí, no siguen un mismo patrón de desarrollo, están en
constante cambios y son desarrolladas por diferentes organizaciones15
.
 Menor curva de aprendizaje.
 Mayor facilidad de desarrollo.
 La versión libre de Pentaho tiene elementos muy básicos que conlleva un
esfuerzo adicional de instalación y configuración adicional
 ITOP MC, así como sus clientes, ya poseían la licencia de Microsoft SQL
Server 2008 Standard y se quería aprovechar esta opción.
3.3 Descripción del problema
Finalmente, después de haber decidido cuál era la tecnología que se iba a usar para
implementar la solución BI con el fin de integrarla con SAP BO, se procede a definir el
problema al que en este trabajo se le da solución.
15 A fecha 07 de julio de 2011 en la búsqueda realiza de bibliografía sobre Pentaho fue escaso encontrar libros que
realmente entren en profundidad en cómo llevar a cabo un desarrollo completo de BI con Pentaho, ya que lo normal fue
encontrar bibliografía centrada en las herramientas de ETL y de Reporting.
43

44 Chapter I
Se quiere implantar una solución Business Intelligence en SAP BO de manera que el
cliente que posea esta aplicación pueda explotar y visualizar los datos, de tal forma que
sea una herramienta que recoja periódicamente los datos claves de su empresa,
convirtiéndose en un mecanismo para la ayuda en la toma de decisiones empresariales
y/o económicas acertadas que permitan mejorar su competitividad.
Se elaboran una serie de indicadores de estudios centrándose en unas áreas de
negocio específicas, concretamente en gestión de ventas, gestión financiera, gestión
de proyectos y gestión de incidencias. A continuación se valoraran cuáles son las
dimensiones y sus jerarquías por las cuales se analiza dichos indicadores, para acto
seguido elaborar los diferentes cubos.
Por último se implementa los cuadros de mandos e informes necesarios que le permite
al usuario final visualizar, medir y tomar decisiones con respecto a su empresa.
44

Parte II. Cuerpo principal. Descripción del
trabajo
45

46 Chapter I
Capítulo 1. Descripción de la
metodología para resolver el problema
Resumen:
Desarrollo ágil de Software
Metodología de desarrollo Scrum
Planificación del proyecto
1.1 Metodología de desarrollo
Una metodología de desarrollo de software se refiere a un framework16
que se usa para
estructurar, planear y controlar el proceso de desarrollo en Sistemas de Información. El
objetivo es mejorar la productividad en el desarrollo y la calidad del producto software.
¿Qué tipo de metodología se podría utilizar?
Se entiende por metodología ágil de desarrollo de software a una colección de valores,
principios y prácticas para modelar software que pueden ser aplicados de manera
simple y ligera. La filosofía de las metodologías ágiles se basa en dar mayor valor al
individuo, a la colaboración con el cliente y al desarrollo incremental del software con
iteraciones muy cortas.
En este proyecto se ha apostado por una metodología ágil de desarrollo de software,
intentando evitar los tortuosos y burocráticos caminos de las metodologías
tradicionales, debido a que presentan los siguientes problemas a la hora de abordar
proyectos, como se muestra en la Tabla 11.
Tabla 11: Desventajas de las metodologías de desarrollo tradicionales
Existen unas costosas fases previas de especificación de requisitos, análisis y
diseño
La corrección de errores durante el desarrollo será costosa, es decir, se pierde
flexibilidad ante los cambios
El proceso de desarrollo está encorsetado por documentos firmados
El desarrollo es más lento y entender un sistema complejo en su globalidad
16 Un framework que se usa para estructurar, planear y controlar el proceso de desarrollo en Sistemas de Información
asistir al proceso de desarrollo de software.
46

implica mayor dificultad
Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con
requisitos poco definidos y/o cambiantes o cuando se exige reducir drásticamente los
tiempos de desarrollo pero manteniendo una alta calidad. Además, se aplican bien en
equipos pequeños que resuelven problemas concretos, lo que no está reñido con su
aplicación en el desarrollo de grandes sistemas, ya que una correcta modularización de
los mismos es fundamental para su exitosa implantación. Dividir el trabajo en módulos
abordables minimiza los fallos y el coste, con lo cual las metodologías ágiles presentan
diversas ventajas, entre las que podemos destacar las indicadas en la Tabla 12.
Tabla 12: Ventajas de la metodologías de desarrollo ágiles
Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo
Entrega continua y en plazos breves de software funcional
Trabajo conjunto entre el cliente y el equipo de desarrollo
Importancia de la simplicidad, eliminado el trabajo innecesario
Atención continua a la excelencia técnica y al buen diseño
Mejora continua de los procesos y el equipo de desarrollo
En este proyecto se ha querido aportar más dinamismo y adaptabilidad frente a los
cambios, por lo que se ha decidido hacer uso de una metodóloga ágil, apostando,
dentro del abanico de posibilidades, por la metodología Scrum debido a que permite
maximizar la realimentación sobre el desarrollo —pudiendo corregir problemas y
mitigar riesgos de forma temprana—, a su creciente uso en los equipos de desarrollo
software a nivel internacional, así como otras ventajas que se adaptaban de forma
eficiente con la naturaleza del problema abordado, como se detallará a continuación.
1.1.1 Metodología SCRUM
Scrum es una metodología para la gestión y desarrollo de software basada en un
proceso iterativo e incremental utilizado, comúnmente, en entornos basados en el
desarrollo ágil de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se
emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y
flexibilidad —situaciones frecuentes en el desarrollo de determinados sistemas de
software.
47

48 Chapter I
Scrum es un modelo de referencia que define un conjunto de tareas —que se engloban
en trabajos— y roles, pudiéndose tomar como punto de partida para definir el proceso
de desarrollo que se ejecutará durante un proyecto software. A continuación en la Error:
No se encuentra la fuente de referencia se presenta una ilustración donde se puede
apreciar los elementos que lo integran —roles, artefactos, eventos— así como sus
conexiones.
Scrum estructura el desarrollo en ciclos de trabajo llamados Sprints, siendo de duración
fija —entre 1 y 4 semanas— y terminando en una fecha específica,
independientemente de haberse finalizado, o no, el trabajo. Cada Sprint se va
sucediendo uno detrás de otro. Dentro de Scrum se diferencian los siguientes roles
principales, presentes en los Sprints:
48

 ScrumMaster es la persona que vela por el cumplimiento de las normas de
Scrum. Trabaja de forma similar a un director de proyecto, llevando a cabo la
gestión del Sprint, con seguimientos diario del Scrum Daily Meeting —
representa una reunión de avance diaria de no más de 15 minutos, cuyo
propósito es vigilar las tareas realizadas, los recursos necesarios y los
obstáculos que se presentan— en busca del objetivo fijado.
 Dueño del producto (Product Owner) representa a los clientes externos o
internos
 Equipo de desarrolladores (Team) es el grupo de personas encargadas de
implementar los requisitos del cliente, así como de elegir las tareas que se
comprometen hacer en cada Sprint.
Al comienzo de cada Sprint, un equipo Team selecciona las tareas del Product
Backlog17
o pila del producto —se trata de una lista, previamente priorizada por el
Product Owner—, y se comprometen a terminarlas al final del Sprint. Las tareas
elegidas por el Team serán introducidas en el Sprint Backlog18
o pila del Sprint. Todos
los días el equipo Team realiza un Scrum Daily Meeting, actualizando unas gráficas
orientativas que permiten hacer un seguimiento, de forma rápida y sencilla, de las
tareas que faltan para alcanzar su objetivo. Al final del Sprint, el Team hace una
revisión del mismo con los interesados en el proyecto, enseñándoles lo construido: se
obtienen comentarios y observaciones que pueden incorporar al siguiente Sprint.
Scrum pone énfasis en productos que funcionen al final del Sprint, es decir, que
realmente estén “hechos”19
—en el caso de software significa estar integrado,
completamente probado y potencialmente para entregar.
Un tema importante en Scrum es “inspeccionar y adaptar” (1). El desarrollo
inevitablemente implica aprender e innovar, haciendo hincapié en tiempos no muy
extensos de desarrollo y centrándose en analizar el producto resultante midiendo la
eficacia obtenida, ajustando el objetivo del producto iterativamente o en continuo
feedback.
II.1.1.1.1 Scrum en el proyecto
Dada la naturaleza y la magnitud del proyecto, se optó por aplicar esta metodología
modificándola para se ajustara a las necesidades puntuales de la solución BI aportada
en este documento.
17 El Product Backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos
los requerimientos, funcionalidades deseables, etc. priorizadas. Contiene estimaciones a grosso modo, tanto del valor
para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al Product Owner a ajustar la línea
temporal y la prioridad de las diferentes tareas.
18 El Sprint Backlog es un documento detallado donde se incluye la lista de tareas o elementos que el equipo va a
implementar durante el siguiente Sprint. Estas tareas son extraídas del Product Backlog por el Team, teniendo en
cuenta cuáles de ellas son más prioritarias.
19 Scrum y XP desde las Trincheras. Henrick Kniberg (1)
49

50 Chapter I
En primer lugar, los roles de los participantes no estaban bien definidos ya que se trata
de un Proyecto Final de Carrera en colaboración con la empresa ITOP MC y esta
desempeñaba el tanto el papel de Product Owner como el de Scrum Master.
Por otro lado no se consideró mantener reuniones diarias para el seguimiento de los
Sprint, ya que no serían efectivas puesto que no existirían cambios sustanciales que se
pudieran comentar para su valoración. En su lugar se mantuvieron, siempre que fue
posible, reuniones semanales.
II.1.1.1.2 Planificación de la solución BI
A continuación, en la Tabla 13, se muestra el Product Backlog tal y como se describe
en la metodología Scrum. Se especificaron en una columna las funcionalidades y al
lado las correspondiente estimación del tiempo que se dedicará para completar cada
ítem. Decir que, aunque tendrían que diferenciarse entre requisitos básicos, prioritarios
o no, todos los requisitos son prioritarios ya que en si son una secuencia de pasos para
construir una solución BI.
50

Tabla 13: Product Backlog de la solución BI
Ítem Descripción Estimación
1 Estado del arte 30 días
2 Búsqueda de una metodología 15 días
3 Estudio de las herramientas de desarrollo 15 días
4 Análisis de requerimientos
4.1 Identificar Preguntas 15 días
4.2 Identificar Indicadores y Perspectivas 30 días
4.3 Modelo Conceptual 7 días
5 Análisis de los OLTP
5.1 Conformar indicadores 30 días
5.2 Establecer correspondencias 7 días
5.3 Nivel de granularidad 7 días
5.4 Modelo conceptual ampliado 7 días
6 Modelo lógico del Data Warehouse
6.1 Tipo de modelo lógico del Data Warehouse 7 días
6.2 Tablas de dimensiones 15 días
6.3 Tablas de hechos 15 días
6.4 Uniones 15 días
7 Integración de datos
7.1 Carga inicial 15 días
7.2 Actualización 15 días
8 Implementación de ETL con el SSIS 15 días
9 Implementación de cubos OLAP con el SSAS 15 días
10 Representación 15 días
A partir del Product Backlog se ha elaborado el Sprint Backlog. Esta lista de tareas
permitirá organizar el trabajo del Team para optimizar el uso de los recursos
disponibles, obtener resultados en plazos de tiempo breves y controlar la ejecución de
cada punto para detectar “cuellos de botellas” y, en consecuencia, darles solución.
La estrategia que se ha seguido para definir los distintos Sprints ha sido tomar cada
ítem del Product Backlog como una etapa a completar. Cada una de estas etapas
contendrá tantos Sprints como tareas contenga la etapa, de manera que cada sprint
51

52 Chapter I
tenga como objetivo el desarrollo de una tarea. Como limitación a estos Sprints, se ha
impuesto que cada uno tenga como mínimo 6 días de ciclo de vida y, como máximo 7.
52

54 Chapter I
Tabla 14: Sprint Backlog de la solución BI
Backlog Sprint Descripción
Duración
Estimación Real
1
Estudio del estado del arte
1,2,3,4,5 Estado del arte 30 días 30 días
6 Documentación 3 días 3 días
2
Desarrollo de una metodología
7, 8 Búsqueda de una metodología 15 días 15 días
3
Herramientas de desarrollo
10, 11
Estudio de las herramientas de
desarrollo
15 días 15 días
13 Pruebas 7 días 7 días
4
Análisis de requerimientos
14, 15 Identificar Preguntas 7 días 10 días
16,17,18,19,2
0
Identificar Indicadores y Perspectivas 7 días 10 días
21 Modelo Conceptual 7 días 7 días
5
Análisis de los OLTP
24,25,26,27,2
8
Conformar indicadores 7 días 15 días
29 Establecer correspondencias 7 días 15 días
30 Nivel de granularidad 7 días 15 días
31 Modelo conceptual ampliado 7 días 7 días
Modelo lógico del Data Warehouse
Tipo de modelo lógico del Data
54

En la Tabla 14 se puede observar el tiempo estimado para cada tarea, de forma que se
cumpla con el requisito temporal impuesto para los Sprints y, en la última columna de la
derecha, el tiempo real dedicado a cada una de ellas. Se observa que en varios casos
el tiempo empleado ha sido mayor que el estimado, circunstancia que viene explicada
por el hecho de que, dichas tareas, presentaban una mayor complejidad de la
esperada, eran novedosas pues se acometían por primera vez, hubo cambios de
tecnologías y necesidad de nuevos equipos de trabajo debido a que los que existían no
soportaban la tecnología elegida, además no se parte de un caso ideal o teórico sino
que se trataba de explotar datos reales donde no se disponía, entre otros problemas,
de una base de datos totalmente depurada (o purificada).
II.1.1.1.3 Planificación temporal
Este proyecto viene delimitado temporalmente por la necesidad de no exceder las 150
horas de dedicación, equivalentes a los 15 créditos asignados a esta asignatura.
Respetar este límite es una tarea difícil, ya que siempre se dedican más horas en la
parte de desarrollo para intentar cumplir los objetivos fijados, sin contar con el tiempo
dedicado a las reuniones, a la formación o a incidencias tecnológicas.
Para la representación de las tareas y su asignación temporal, se ha seleccionado el
Diagrama de Gantt. Su objetivo es mostrar el tiempo de dedicación previsto para
diferentes tareas o actividades a lo largo de un tiempo total determinado. El diagrama
de Gantt de este proyecto se puede ver reflejado en la Figura 24.
55

56 Chapter I
Figura 24: Diagrama de Gantt
56

Capítulo 2. Metodología de
Implementación de una solución BI
Resumen:
Metodología para construir de un Data Warehouse
Metodología propia para la construcción de un Data Warehouse
Como se mencionó en el Capítulo Fundamentos Business Intelligence, se denomina
Business Intelligence al conjunto de estrategias y herramientas enfocadas a la
administración y creación de conocimiento mediante el análisis de datos existentes en
una organización o empresa. Abarca la comprensión del funcionamiento actual de la
empresa, bien como la anticipación de acontecimientos futuros, con el objetivo de
ofrecer conocimientos para respaldar las decisiones empresariales. En Figura 25 se
representa el esquema de una solución BI, teniendo en cuenta que los componentes
básicos son: OLTP, herramientas ETL —Extracción, Transformación y Carga—, Data
Warehouse, Query Manager y las herramientas de consultas y análisis como los
cuadros de mandos o generados de informes.
Figura 25: Componentes principales de una solución BI
Una vez entendido en qué consiste una solución BI, se puede observar que uno de los
pilares es el Data Warehouse ya que contiene los datos que vamos a analizar, por eso
es importante como se diseña e implementa.
La construcción e implementación de un Data Warehouse puede adaptarse muy bien a
cualquier ciclo de vida de desarrollo de software, con la salvedad de que para algunas
fases las acciones que se han de realizar, en particular, serán diferentes. Lo que se
57

58 Chapter I
debe tener muy en cuenta, es no entrar en la utilización de metodologías que requieran
fases extensas de reunión de requerimientos y análisis, fases de desarrollo monolítica
que conlleve demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es
entregar una primera implementación que satisfaga una parte de las necesidades, para
demostrar las ventajas del Data Warehouse y motivar a los usuarios.
La metodología elegida para el diseño del Data Warehouse se ha elaborado a partir de
una metodología base existente, la cual se ha ampliado y adaptando a nuestro
problema. La ampliación ha consistido en la adición de algunos aspectos claves en el
diseño de un Data Warehouse y una metodología de implementación para una solución
de Business Intelligence. La metodología base de la que se parte fue propuesta por el
Ingeniero Argentino Bernabeu Ricardo “Investigación y Sistematización de Conceptos -
HEFESTO: Metodología propia para la Construcción de un Data Warehouse ”20
(2).
2.1.1 Metodologías para construir un Data Warehouse
En un principio se realizó una búsqueda con el fin de encontrar una metodología que
se adaptara lo mejor posible a nuestro problema. Se encontraron dos metodologías
interesantes: por un lado Hefesto, anteriormente nombrada, y por otro lado la
desarrollada por SAS, llamada The SAS Rapid Data Warehouse Methodology
(SRDWM). Dicha metodología es iterativa y desarrolla incrementalmente un proyecto
Data Warehouse dividiéndolo en cinco fases:
1. Definición de los objetivos
2. Definición de los requerimientos de información
3. Diseño y modelización
4. Implementación
5. Revisión
La razón por la que se desestimó el uso de la metodología SRDWM es debido a la
sencillez y eficacia con la que está elaborada la metodología Hefesto. Hefesto explica
de forma muy intuitiva los pasos que hay que tomar en cada momento, así como por
qué debemos tomarlos, acompañada siempre con ejemplos y comparaciones. Se toma
como punto de referencia para todas aquellas personas que estén dando sus primeros
pasos en el mundo del Data Warehousing y quizás en ese sentido SRDWM no
aportaba esa sencillez, resultando incluso más dificultoso. Otra ventaja es que encaja
perfectamente con la metodología Scrum frente a SRDWM, que al ser una metodología
iterativa incremental, tendría mayor dificultad de adaptarse a una metodología de
desarrollo ágil. En la Tabla 15 se muestra las principales características de Hefesto.
Tabla 15: Características principales en la metodología Hefesto
Los objetivos y resultados esperados en cada fase se distinguen fácilmente y son sencillos de
comprender
20 A partir de ahora utilizaremos Hefesto para referirnos a ella.
58

Tabla 15: Características principales en la metodología Hefesto
Se basa en los requerimientos de los usuarios, por lo cual su estructura es capaz de adaptarse
con facilidad y rapidez ante los cambios en el negocio
Cuando se culmina con una fase, los resultados obtenidos se convierten en el punto de partida
para llevar a cabo el paso siguiente
Utiliza modelos conceptuales y lógicos, los cuales son sencillos de interpretar y analizar
Se aplica tanto para Data Warehouse como para Data Mart
Es independiente del tipo de ciclo de vida que se emplee para contener la metodología
Es independiente de las herramientas que se utilicen para su implementación
Es independiente de las estructuras físicas que contengan el DW y de su respectiva distribución
Reduce la resistencia al cambio, ya que involucra a los usuarios finales en cada etapa para que
tome decisiones respecto al comportamiento y funciones del Data Warehouse
Durante el estudio de la metodología Hefesto nos dimos cuenta que habría que
adaptarla hacia una situación real de Data Warehouse más compleja, pero esto no
supuso ningún problema gracias a la flexibilidad que ofrece.
2.1.2 Metodología propia para la Construcción de un Data Warehouse
con base en HEFESTO
La metodología Hefesto sigue las fases de construcción mostradas en la Figura 27.
Figura 26: Metodología propia de Hefesto para la construcción de un Data Warehouse
Las adaptaciones llevadas a cabo en la metodología propia de Hefesto, ha consistido en crear
una nueva sección dedicada a la implementación, ya que no lo tiene en cuenta por ser
independiente de las herramientas que se utilicen para su implementación. Además las fases
de análisis e integración también sufrieron modificaciones en diversos apartados.
Figura 27: Metodología propia para la construcción de un Data Warehouse
En la Figura 27 se muestra la metodología propia con base en Hefesto, donde se puede
apreciar en color rojo las adiciones o reestructuraciones de las fases. A continuación se van
analizando las fases resaltando los cambios realizados en cada una de ellas.
II.2.1.2.1 Fase 1: Análisis de Requerimientos
59

Business intelligence para Pymes

Business intelligence para Pymes

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (13)

Similar a Business intelligence para Pymes

Similar a Business intelligence para Pymes (20)

Último

Último (20)

Business intelligence para Pymes