Business Intelligence para

PYMES

Autor/es:

Manuel Alejandro Gonzlez Yanes

Rebeca Mora Anca

Director/a: Virginia Gutirrez Rodrguez

Fecha: 12 de Julio de 2011

Chapter I

D./Da. Virginia Gutirrez Rodrguez Profesora de la Escuela Tcnica Superior de Ingeniera

Informtica, y adscrito al Departamento de Estadstica, Investigacin Operativa y Computacin
de la Universidad de La Laguna.

CERTIFICA: Que la presente memoria titulada Business Intelligence para PYMES, ha sido
realizada bajo mi direccin por el/los alumno/s D. Manuel Alejandro Gonzlez Yanes y Da
Rebeca Mora Anca, y constituye su Proyecto Fin de Carrera de Ingeniera Informtica por la
Universidad de La Laguna.

Y para que as conste, en cumplimiento de la legislacin vigente y a los efectos que haya lugar,
firmo el presente certificado en La Laguna, a 12 de Julio de 2011

Fdo: D./Da. Virginia Gutirrez Rodrguez

Resumen
Se denomina inteligencia empresarial, inteligencia de negocios o BI (del ingls Business
Intelligence) al conjunto de estrategias y herramientas enfocadas a la administracin y
creacin de conocimiento mediante el anlisis de datos existentes en una organizacin o
empresa.
La Business Intelligence acta como un factor estratgico para una empresa u organizacin,
generando una potencial ventaja competitiva, que no es otra que proporcionar informacin
privilegiada para responder a los problemas de negocio: entrada a nuevos mercados,
promociones u ofertas de productos, control financiero, optimizacin de costes, planificacin de
la produccin, anlisis de perfiles de clientes, rentabilidad de un producto concreto, etc...
Las herramientas de inteligencia abarcan la comprensin del funcionamiento actual de la
empresa como la anticipacin de acontecimientos futuros, con el objetivo de ofrecer
conocimientos para respaldar las decisiones empresariales. Las herramientas de Business
Intelligence se basan en la utilizacin de un Sistema de Informacin de Inteligencia que se
forma con distintos datos extrados de produccin, con informacin relacionada con la empresa
o sus mbitos y con datos econmicos.
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 evolucin de los Indicadores clave del negocio cmo
controlar las ventas o la situacin econmica.

Informes dinmicos con los que buscar causas o tendencias de forma sencilla y que
permiten analizar clientes, proveedores, produccin, etc. en profundidad.

El problema a abordar consiste en integrar SAP BO con una solucin de Business Intelligence
de forma que proporcione a las Pymes informes grficos y cuadros de mandos interactivos que
ofrezca una mayor versatilidad, control de los ingresos, los mrgenes y la liquidez.

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 Gutirrez Rodrguez,
la cual trabaj con nosotros a lo largo de todo el proyecto siempre ayudando, aconsejando y
orientndonos en todo momento.
A las personas que forman ITOP Management Consulting, y en especial a Teresa Pestana y
Miguel Fernndez, 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 Gonzlez que nos descubri el mundo
del PMBOK e ITIL para poder crear los indicadores, Roberto Dorta que nos ayud a entender la
ISO9001.

Chapter I

Al trmino de esta etapa de nuestras vida. Queremos expresar todo nuestro agradecimiento a
quienes con su ayuda, apoyo y comprensin, nos alentaron a lograr esta hermosa realidad
nuestra formacin profesional.

Tabla de contenidos

Resumen..........................................................................................................2
Agradecimientos.............................................................................................4
Lista de figuras .............................................................................................. 7
Lista de Tablas................................................................................................8

Parte I.Introduccin y fundamentos bsicos...................................................8

Captulo 1.Fundamentos Business Intelligence......................................... 9
1.1Introduccin................................................................................................................ 9
1.2Qu es BI?................................................................................................................ 9
1.2.1Proceso BI...................................................................................................... 10
1.2.2Arquitectura de una solucin BI...................................................................... 10
1.3Qu es un Data Warehouse?................................................................................. 10
1.3.1Arquitectura de una solucin BI con Data Warehouse ................................... 11

Captulo 2.ITOP Management Consulting..................................................20

2.1La empresa............................................................................................................... 20
2.2Filosofa.................................................................................................................... 20
2.3Alianzas.................................................................................................................... 20

Captulo 3.Descripcin del problema e integracin de soluciones

tecnolgicas .......................................................................................... 21
3.1Introduccin.............................................................................................................. 21
3.2Anlisis funcional y eleccin..................................................................................... 21
3.2.1Anlisis Inicial................................................................................................. 21
3.2.2Conclusin ..................................................................................................... 23
3.3 Descripcin del problema........................................................................................ 24

Parte II.Cuerpo principal. Descripcin del trabajo........................................25

Captulo 1.Descripcin de la metodologa para resolver el problema. . .26
1.1Metodologa de desarrollo........................................................................................ 26
1.1.1Metodologa SCRUM..................................................................................... 27

Captulo 2.Metodologa de Implementacin de una solucin BI.............33

2.1.1Metodologas para construir un Data Warehouse .......................................... 33

2.1.2Metodologa propia para la Construccin de un Data Warehouse con base en

HEFESTO.................................................................................................... 34

Captulo 3.Anlisis de los resultados.........................................................71

3.1Resultados................................................................................................................ 71

Parte III.Conclusiones, Final............................................................................73

Captulo 1.Conclusiones y posibles ampliaciones...................................74

Parte IV.Bibliografa.......................................................................................... 76

Parte
V.1.
Kniberg,
Henrick.
.
http://www.proyectalis.com/wpcontent/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf.
[En
lnea] 09 de 06 de 2011. .............................................................................76

Parte VI.2. Dario, Bernabeu R. Investigacin y Sistematizacin de

HEFESTO: Metodologa propia para la Construccin de un Data
Warehouse. [En lnea] 09 de 06 de 2011. ................................................ 76

Parte VII.3. Commerce, Office of Government. ITIL Gestin de Servicios TI.

[En lnea] 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

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. Roldn, Mara 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 ProblemDesign
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. Annimo. 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

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

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. Annimo. Scrum. Definicin de Scrum. [En lnea] 23 de 06 de

2011. http://es.wikipedia.org/wiki/Scrum................................................. 77

Parte XLI.37. Institute, Project Management. PMBOK. ................................77

Glosario de trminos....................................................................................78
ndice de siglas.............................................................................................82
Apndices......................................................................................................84

10

Lista de figuras

11

12

Chapter I

Lista de Tablas

Parte I. Introduccin y fundamentos bsicos

12

Captulo 1. Fundamentos Business

Intelligence
Resumen:
Introduccin a mundo del Business Intelligence
Introduccin Data Warehouse y conceptos relacionados

1.1

Introduccin
En la actualidad, la gran mayora de las organizaciones cuenta con un Sistema de
Informacin1 (SI) que soporta gran parte de las actividades diarias propias del sector de
negocios en donde se est desempeando. 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 organizacin: los datos almacenados en las
bases de datos pueden ser utilizados para argumentar la decisin que se quiera tomar.
Un estudio realizado en Europa por Information Builders Ibric mostr el costo que
tiene la falta de Sistemas de Informacin Orientados para la Toma de Decisiones 2 o
Decision Support Systems (DSS) en las organizaciones. Segn estos datos, el
empleado europeo medio pierde una media de 67 minutos diariamente buscando
informacin de la compaa, lo que equivale a un 15,9% de su jornada laboral. Para
una organizacin de 1.000 empleados que gane unos 50.000 euros al da equivaldra a
7,95 millones de euros al ao de salario perdido, debido todo ello a la bsqueda de
informacin orientada a la toma de decisiones.
El poder competitivo que puede tener una empresa se basa en la calidad y cantidad de
informacin que sea capaz de usar en la toma de decisiones. Mediante la
implementacin 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 Transaccionales 3 para utilizar la informacin como
respaldo a las decisiones, reduciendo el efecto negativo que puede traer consigo una
mala determinacin. 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 Informacin es un conjunto de elementos orientados al tratamiento y administracin de datos e

informacin, organizados y listos para su posterior uso, generados para cubrir una necesidad u objetivo.

2 DSS es un sistema informtico utilizado para servir de apoyo, ms que automatizar, el proceso de toma de
decisiones.

3 Es un tipo de Sistema de Informacin diseado para recolectar, almacenar, modificar y recuperar todo tipo de
informacin que es generada por las transacciones en una organizacin.

13

14

1.2

Chapter I

Qu es BI?
BI es el conjunto de estrategias y tecnologas que nos van a ayudar a convertir los
datos en informacin de calidad y dicha informacin en conocimiento que nos permita
una toma de decisiones ms acertada y nos ayude as a mejorar nuestra
competitividad4
Business Intelligence hace hincapi en los procesos de recolectar y utilizar
efectivamente la informacin con el fin de mejorar la forma de operar de una
organizacin, brindando a sus usuarios, el acceso a la informacin 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 informacin
disponible es tener mucha informacin 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 informacin 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:
Cul es el estado de salud de mi empresa?
Cul es el nivel de satisfaccin de mis clientes? Y el de mis empleados?
Cul es la lnea de productos ms rentables? Es la misma que el ao anterior?
Cul es el segmento de clientes al que deberamos dirigir un nuevo producto?
Qu departamentos son los ms productivos?
Al contar con la informacin exacta y en tiempo real, es posible, adems de lo anterior,
identificar y corregir situaciones antes de que se conviertan en problemas potenciales o
prdidas 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 solucin BI.
Quin necesita soluciones de Business Intelligence?
Para ello nos planteamos las siguientes cuestiones:
Pasa ms tiempo recolectando y preparando informacin que analizndola?
En ocasiones le frustra el no poder encontrar informacin 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 informacin que tiene disponible en la empresa?
Quiere saber qu productos fueron los ms rentables durante un periodo
determinado?
Ha perdido oportunidades de negocio por recibir informacin 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-BusinessIntelligence-vea-el-cubo-medio-lleno.aspx)

14

No tiene idea de por qu sus clientes le devuelven mercanca?

Estas son las soluciones de BI ms reconocidas actualmente en el mercado.
Un caso de xito de solucin BI fue un estudio de la cadena de supermercados WalMart5, donde decidieron iniciar un proyecto de Basket Analysis 6 utilizando la
informacin recogida de las ventas. Descubrieron una correlacin estadsticamente
significativa entre la compra de paales y cerveza. Profundizando en el estudio, vieron
que los compradores de cerveza y paales eran varones de entre 25 y 35 aos que
solan comprar estos productos conjuntamente los viernes por la tarde. La cadena de
supermercado tomo la decisin de colocar las cervezas cerca de los paales, con la
intencin de que los padres que compraban paales y que no solan comprar cerveza,
se acordasen que faltaba cerveza en casa. Los resultados fueron espectaculares
aumentando un 15% las ventas de cervezas con paales.
La Inteligencia de Negocios tiene sus races en los Sistemas de Informacin Ejecutiva
7
o Executive Information Systems (EIS) y en los DSS, pero ha evolucionado y se ha
transformado en todo un conjunto de tecnologas capaces de satisfacer a una gran
gama de usuarios, junto a sus necesidades especcas, en cuanto al anlisis de la
informacin.

1.2.1

Proceso BI
El proceso BI se describe en cinco fases, las cuales se explican teniendo como
referencia la Figura 1, grfico que sintetiza todo el proceso.

Figura 1: Fases de un proceso BI

5 Wal-Mart es una empresa multinacional de origen estadounidense, el minorista ms grande del mundo; y por sus
ventas y nmero de empleados, la mayor compaa del mundo. Su concepto de negocio es la tienda de autoservicio de
bajo precio y alto volumen.

6 Las tcnicas 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 informacin es muy til y proporciona a los usuarios de
negocio visibilidad directa sobre la bolsa de la compra de cada cliente.

Los Sistema de Informacin 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 informacin
interna y externa a la misma.

15

16

Chapter I

1.2.2

FASE 1: Dirigir y planear. Fase inicial donde se debern recoger los

requerimientos de informacin de los diferentes usuarios as como entender
sus necesidades de informacin.
FASE 2: Recoleccin de informacin. Se estudiaran las diferentes fuentes de
informacin de la empresa para recolectar aquellos datos que darn
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 anlisis. Esta actividad
puede realizarse mediante la creacin de una nueva base de datos, agregando
datos a una base de datos ya existente o bien consolidando la informacin.
FASE 4: Difusin. Finalmente los usuarios a travs de una serie de
herramientas podrn explorar los datos de manera sencilla e intuitiva.

Arquitectura de una solucin BI

Una solucin Business Intelligence parte de los sistemas de origen de una organizacin
bases de datos, ERPs, ficheros de texto, entre otros, sobre los que suele ser
necesario aplicar una transformacin estructural para optimizar su proceso analtico.
Para ello se realiza una fase de extraccin, transformacin y carga (ETL) de datos,
donde se depuran y homogeneizan Esta etapa suele apoyarse en un almacn
intermedio Operational Data Store (ODS) que acta como pasarela entre los
sistemas fuente y los sistemas destino generalmente un Data Warehouse, y cuyo
principal objetivo consiste en evitar la saturacin de los servidores funcionales de la
organizacin.
La informacin resultante, ya unificada, depurada y consolidada, se almacena en un
Data Warehouse (DW) corporativo, que puede servir como base para la construccin
de distintos Datamarts departamentales. Estos Datamarts se caracterizan por poseer la
estructura ptima para el anlisis de los datos del rea de la organizacin, ya sea
mediante Bases de Datos Transaccionales (OLTP) o mediante Bases de datos
analticas (OLAP).

1.3

Qu es un Data Warehouse?
Supngase que una compaa quiere analizar aquellos pases y gama de productos en
los que las ventas vayan excepcionalmente bien. La compaa dispone de una base de
datos transaccional sobre la que operan todas las aplicaciones de la empresa:
produccin, venta, facturacin, proveedores etc. Lgicamente, de cada venta se
registra la fecha, la cantidad, el comprador y el pas de este. Con toda esta informacin
histrica nos podemos preguntar:
Es esta informacin suficiente para realizar el anlisis planteado?
La respuesta hay que buscarla fuera de la base de datos, en el contexto donde se
motiva el anlisis. La incorporacin de un producto depende de las ventas por
habitantes. Si no tenemos en cuenta la poblacin de cada pas, la repuesta al anlisis

16

estar sesgada. Tambin puede ocurrir que, dependiendo de la gama del producto, nos
interese informacin externa verdaderamente especfica, como por ejemplo, las horas
de sol anuales de cada pas, siendo informacin valiosa para una compaa de
cosmtica: es ms difcil vender bronceador en Lituania que en Canarias. Pero este
hecho, que nos parece tan lgico, slo podr ser descubierto por herramientas de
Minera de Datos8, si se incorpora informacin climtica de cada pas. Con lo cual, cada
organizacin deber recoger diferente informacin que le pueda ser til para la tarea de
anlisis y extraccin de conocimiento y en definitiva para la toma de decisiones.
Un Data Warehouse es una base de datos corporativa en la que se integra informacin
depurada de las diversas fuentes inmersas en la organizacin o externas a ella, como
se muestra en la Figura 2. Dicha informacin debe ser homognea y fiable, se
almacena de forma que permita su anlisis desde muy diversas perspectivas, y a su
vez de tiempos de respuestas ptimos.

Figura 2: En un Data Warehouse se integra informacin de diversas fuentes.

Una de las deniciones ms famosas sobre DW, es la de William Harvey Inmon 9, que
expone:
Un Data Warehouse es una coleccin de datos orientada al negocio, integrada,
variante en el tiempo y no voltil 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 caractersticas ms
detalladas.

8La Minera de Datos consiste en la extraccin no trivial de informacin que reside de manera implcita en los datos.
Dicha informacin era previamente desconocida y podr resultar til para algn proceso. En otras palabras, la Minera
de Datos prepara, sondea y explora los datos para sacar la informacin oculta en ellos.

9 William Harvey Inmon es reconocido por muchos como el padre del Data Warehouse

17

18

Chapter I

Tabla 1: Caractersticas de un Data Warehouse

Orientado a temas

Los datos estn 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 integracin 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 ms comunes que nos solemos
encontrar son: en nomenclatura, unidades, formato de fechas,..

Histrico (variante
en el tiempo)

No voltil

1.3.1

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 haba en el momento que se almacenaron, evitando as la
problemtica que ocurre en los sistemas operacionales, que reflejan
solamente el estado de la actividad de negocio presente.
Una vez almacenada la informacin en el Data Warehouse debe ser de
solo lectura, nunca se modifica ni se elimina, debe ser permanente para
futuras consultas.

Arquitectura de una solucin BI con Data Warehouse

En este punto teniendo en cuenta que ya se han detallado claramente las
caractersticas generales del Data Warehouse se dene y describe todos los
componentes que intervienen en su arquitectura o ambiente.
A travs de la Figura 3 se explicita la estructura del Data Warehouse.

Figura 3: Estructura de un Data Warehouse

La forma de operar de una solucin BI a travs de un DW se resume de la siguiente

manera:
1. Los datos son extrados desde aplicaciones, bases de datos, archivos, etc.
Esta informacin generalmente reside en diferentes tipos de sistemas,
orgenes 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 informacin del Data Warehouse se estructura en cubos

multidimensionales, ya que estos preparan la informacin para responder a
consultas dinmicas con un buen rendimiento. Pero tambin pueden utilizarse
otros tipos de estructuras de datos para representar la informacin 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, exploracin, anlisis, generacin de informes, entre
otras.
A continuacin 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 estn diseados para gestionar un gran nmero de peticiones
concurrentes sobre sus bases de datos. Estn enfocados a que cada operacin
transaccin trabaje con pequeas cantidades de filas, y a ofrecer una respuesta
rpida. Habitualmente utilizan Sistemas de Bases de Datos Relacionales (SGBDR)
para gestionar los datos y suelen estar altamente normalizados.
OLTP representa toda aquella informacin transaccional que genera la empresa en su
da a da, adems 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 cmo una organizacin crea, entrega y captan valores (econmicos,
sociales, u otras formas de valor).

19

20

Chapter I

En un Data Warehouse se cargan y unifican peridicamente informacin procedente de

mltiples 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 Extraccin, Transformacin y
Carga o Load.

Figura 6: Proceso ETL

A continuacin se detalla cada una de estas etapas, donde se expone cul es el

proceso que llevan a cabo los ETL y se enumera cules son sus principales tareas.

Extraccin.- Consiste en extraer los datos desde los sistemas de origen. La

mayora de los proyectos de almacenamiento de informacin fusionan datos
provenientes de diferentes sistemas de origen, donde cada sistema puede usar
una organizacin diferente de los datos o formatos distintos. La extraccin los
convierte a un formato preparado para iniciar el proceso de transformacin.
Una vez que los datos son seleccionados y extrados, se guardan en un
almacenamiento intermedio, lo cual permite manipular los datos sin interrumpir
ni paralizar los OLTP ni el Data Warehouse.
Transformacin: En estos procesos es preciso asegurar que los datos sean
vlidos, ntegros y tiles, lo que suele incluir realizar clculos y generar nuevos
valores. Los datos deben ser depurados para eliminar inconsistencias,
discrepancias y duplicidades. Los casos ms comunes en los que se debe
realizar una transformacin son los mostrados en la Tabla 2 .
Tabla 2: Casos ms comunes de transformaciones ETL

Al integrar varias fuentes de datos puede existir ms de una

forma de codificar un atributo en comn. Ejemplo: En el campo
sexo algunos diseadores definen su valor como M y F otros
Codificacin
Mujer y Hombre. Se debe escoger una forma comn para
decodificar los atributos.
Los tipos de unidades de medidas utilizados para representar los
atributos de una entidad varan considerablemente entre s, a
travs de los diferentes OLTP. Por ejemplo, al registrar la longitud
de un producto determinado, las unidades de medidas pueden
Medida de atributos ser explicitadas en centmetros, metros, pulgadas, etc. Se
debern estandarizar las unidades de medidas de los atributos,
para que todas las fuentes de datos expresen sus valores de
igual manera.
Usualmente, un mismo atributo es nombrado de diversas
maneras en los diferentes OLTP. Por ejemplo, al referirse al
Convenciones de
nombre del proveedor, puede hacerse como nombre,
nombramiento
razn_social, proveedor. Aqu, se debe utilizar la convencin
de nombramiento que para los usuarios sea ms comprensible
Un mismo elemento puede derivarse desde varias fuentes. En
este caso, se debe elegir aquella fuente que se considere ms
Fuentes mltiples
able y apropiada.

20

Tabla 2: Casos ms comunes de transformaciones ETL

Limpieza de datos

I.1.3.1.3

Su objetivo principal es el de realizar distintos tipos de acciones

contra el mayor nmero de datos errneos, inconsistentes,
irrelevantes o datos faltantes o Missing Values. Las acciones
ms comunes son: ignorarlos, eliminar la columna, filtrar la
columna, reemplazar valor o filtrar fila errnea

Carga.- Esta funcin 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 Actualizacin o mantenimiento peridico. Antes de realizar una nueva
actualizacin, es necesario identicar si se han producido cambios en
las fuentes originales de los datos recogidos, desde la fecha del ltimo
mantenimiento, a n de no atentar contra la consistencia del Data
Warehouse.

Data Warehouse Manager

Figura 7: Data Warehouse Manager

Si bien existen diversas estructuras de datos, a travs 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 ms
utilizadas.
Un cubo multidimensional o hipercubo, representa o convierte los datos planos que se
encuentran en las 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 segn ciertas dimensiones. Por ejemplo, una cadena
de supermercado puede tener como hechos las ventas. Cada venta tiene unas
medidas: importe, cantidad, nmero 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
cunto, mientras que las dimensiones respondern al cuanto,que,donde, etc.
El modelo dimensional es una adaptacin del modelo relacional, con el fin de
optimizarlo para dar una rpida respuesta a las consultas realizadas por los usuarios.
Aunque a nivel fsico, 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.- Denen como estn los datos organizados
lgicamente y proveen el medio para analizar el contexto del negocio
Tablas de hechos.- Son datos instantneos en el tiempo, que son filtrados,
agrupados y explorados a travs 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 constelacin

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 informacin, con el n de agilizar la ejecucin de consultas. Los
diferentes tipos de implementacin son: relacional, multidimensional e hbrido
A continuacin se entra en detalle en los diferentes tipos de tablas dimensiones y
hechos indicadas anteriormente, as como las caractersticas de un cubo
multidimensional y los diferentes esquemas de modelado de un DW.

Tablas de dimensiones
Las tablas de dimensiones denen como estn los datos organizados lgicamente y
proveen el medio para analizar el contexto del negocio. Contienen datos cualitativos.
En la Figura 8 podemos ver varias tablas dimensin con sus correspondientes
atributos.

Figura 8: Tablas de Dimensiones

A veces estos atributos estn organizados en jerarquas para describir niveles de

agrupamiento especficos explcitos o implcitos) y, por tanto, las diferentes
granularidades o niveles de detalle en la visin de los datos. Las jerarquas forman
distintos niveles, relacionados entre s, y son utilizados para realizar operaciones
de agrupamiento. Por ejemplo la jerarqua correspondiente a la dimensin tiempo
podra estar formada por los atributos Ao, Mes y Da. Los diferentes tipos de

22

jerarquas que se pueden establecer para describir niveles de agrupamiento

especficos se pueden observar en la Figura 9 y se describen en la Tabla 3.

Figura 9: Esquema de organizacin jerrquica de las dimensiones

Tabla 3: Organizacin jerrquica de las dimensiones

Este trmino hace referencia a un campo que ser utilizado como criterio de anlisis y
que es almacenado en la tabla de hechos.
Dimensiones Esto sucede cuando un campo que se utiliza como criterio de anlisis posee el mismo
degeneradas nivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no se
pueden realizar agrupaciones o sumarizaciones a travs de este campo, como por
ejemplo "nmeros de orden", "nmeros de ticket", "nmeros de transaccin", etc.
Atributos no Los niveles de la jerarqua tambin pueden tener atributos descriptivos, donde no son
utilizados para formar niveles de jerarqua, sino para describir detalles en los mismos,
dimensin
como por ejemplo, el nmero de telfono, la direccin de correo electrnico, etc.
Describen diferentes niveles de agrupamiento especficos explcitos o implcitos y,
Jerrquicas por lo tanto, las diferentes granularidades o niveles de detalle en la visin de los datos,
como por ejemplo la jerarqua formada por Ao, Trimestre, Mes y Da

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 nmero enteros de pocos bytes. Si en un sistema
transaccional tenemos, por ejemplo, una clave principal con dominio char(10), siempre
ser ms ptimo utilizar un tipo de datos numrico de menos byte como clave principal
en las tablas dimensiones. Se sustituirn las habituales clave de negocio por claves
subrogadas subrogate key las cuales sern de tipo numrico 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 travs 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 travs de los aos, la comunidad de personas que se
encargaba de modelar bases de datos profundiz las definiciones iniciales e incluy
varios tipos SCD ms, como tipo 4 y tipo 6. A continuacin se detalla cada tipo de
estrategia SCD:
SCD Tipo 1: Sobreescribir.
SCD Tipo 2: Aadir fila.
SCD Tipo 3: Aadir columna.
SCD Tipo 4: Tabla de Historia separada.
SCD Tipo 6: Hbrido.
De acuerdo a la naturaleza del cambio se debe seleccionar qu Tipo SCD se utilizar y,
en algunos casos, resultar conveniente combinar varias tcnicas.

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 instantneos en el tiempo, que son filtrados, agrupados y
explorados a travs 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 combinacin 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
ms de 10 aos al desarrollo de su metodologa 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 disear una tabla de hechos, tener en cuenta el nivel de

granularidad que va a tener, es decir, el nivel de detalle ms atmico 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 da para cada artculo y tienda.
Existen dos tipos de hechos:
Hechos bsicos.- Se encuentran representados por un campo de una tabla de
hechos. Los campos precio y cantidad de la Figura 11 son hechos bsicos.
Hechos derivado.-: Se forman al combinar uno o ms hechos con alguna
operacin matemtica o lgica y que tambin 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 Bsicos y Derivados

Otro concepto importante a tener en cuenta es la agregacin, proceso por el cual se

resumen los datos a partir de las filas de detalle de mxima granularidad.

Cubo Multidimensional
Como se ha comentado, si bien existen diversas estructuras de datos, a travs de las
cuales se puede representar los datos del DW, solamente se entrar en detalle en los
cubos multidimensionales.
Los objetos ms importantes que se pueden incluir en un cubo multidimensional son
los siguientes:

Indicadores.- Sumarizaciones que se efectan sobre algn hecho o

expresiones pertenecientes a una tabla de hechos.
Atributos de dimensin.- Campos o criterios de anlisis, pertenecientes a tablas
de dimensiones.
Jerarquas de dimensiones.- Representa una relacin lgica entre dos o ms
atributos.

Se puede observar, que el resultado del anlisis est dado por los cruces matriciales de
acuerdo a los valores de las dimensiones seleccionadas.
Ms especcamente, para acceder a los datos del Data Warehouse, se pueden
ejecutar consultas sobre algn cubo multidimensional previamente denido. Dicho cubo
debe incluir, entre otros objetos, indicadores, atributos y jerarquas 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 mximo 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 artculo, ciudad y trimestre.
La representacin 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 ms que una base de datos multidimensional, en la cual el

almacenamiento fsico de los datos se realiza en un vector multidimensional.

Indicadores de rendimiento clave o KPI

Los indicadores de rendimiento clave (KPI) son mtricas financieras o no, utilizadas
para cuantificar objetivos que reflejan el rendimiento de una organizacin,
recogindose generalmente en su plan estratgico. Estos indicadores son utilizados en
BI para asistir o ayudar, al estado actual de un negocio, a prescribir una lnea de accin
futura. Los indicadores de rendimiento son frecuentemente utilizados para "valorar"
actividades complicadas de medir como los beneficios de desarrollos lderes, eficiencia
de empleados, servicio o satisfaccin de un cliente.
Los KPIs deberan 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 mayora, en los
campos de las tablas de dimensiones y/o expresiones. Dentro de un cubo
multidimensional, los atributos son los ejes del mismo.

26

Jerarquas
Como se coment en el apartado Data Warehouse Manager de tablas de dimensin,
una jerarqua representa una relacin lgica entre dos o ms atributos pertenecientes a
un cubo multidimensional. Pueden existir varias en un mismo cubo.
La principal ventaja de manejar jerarquas, reside en poder analizar los datos desde su
nivel ms general al ms detallado y viceversa, al desplazarse por los diferentes
niveles.

Figura 13: Jerarqua 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 ms compleja que el

esquema en estrella. Se da cuando alguna de las dimensiones se implementa
con ms de una tabla de datos y/o estas se organizan en jerarquas 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 constelacin.- 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 constelacin

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

Estrella

Copo de
nieve

Ventajas

Inconvenientes

La desnormalizacin 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 utilizacin

La desnormalizacin con la que cuenta

genera un cierto grado de redundancia
Necesidad de
almacenamiento

mayor

espacio

Ms simple de interpretar

Menos robusto para la carga

Optimiza los tiempos de respuesta

ante las consultas

Es el ms lento de construir

Posibilidad de segregar los datos de

las tablas de dimensiones y proveer un
esquema
que
sustente
los
requerimientos de diseo.

de

Si se poseen mltiples tablas de

dimensiones, cada una de ellas con
varias jerarquas, se crear un nmero
de tablas bastante considerable, que
pueden llegar al punto de ser
Muy exible y puede implementarse inmanejables
despus de que se haya desarrollado
un esquema en estrella.
Al existir muchas uniones y relaciones
entre tablas, el desempeo puede verse
Hace una mejor utilizacin del espacio. reducido
Puede desarrollar clases de jerarquas La existencia de las diferentes jerarquas
fuera de las tablas de dimensiones, de dimensiones debe estar bien
que permiten realizar anlisis de lo fundamentada, ya que de otro modo las
general a lo detallado y viceversa.
consultas demorarn ms 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 ms de una tabla de

hechos, por lo cual se podrn analizar
ms aspectos claves del negocio con
un mnimo esfuerzo adicional de
No es soportado por todas las
diseo.
herramientas de consulta y anlisis
Contribuye a la reutilizacin de las
tablas de dimensiones, ya que una
misma tabla de dimensin puede
utilizarse para varias tablas de hechos.

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 utilizacin, como tambin las causas de
por qu no se emplean simplemente las estructuras de las bases de datos
tradicionales. Esta comparacin se puede ver en la Tabla 5.
Tabla 5: OTLP VS Data Warehouse
OLTP

Data Warehouse

Objetivo

Soportar actividades
transaccionales

Consultar y analizar informacin

estratgica y tctica

Tiempo de datos

Operacionales

Para la toma de decisiones

Modelo de datos

Normalizado

Desnormalizado

Consulta

SQL

SQL ms extensiones

Datos consultados

60-90 das

5-10 aos

Tipos de consultas

Repetitivas, predefinidas

No previsibles, dinmicas

Nivel de almacenamiento

Nivel de detalle

Nivel de detalle y diferentes niveles

de sumarizacin

Acciones disponibles

Alta, baja, modificacin y consulta

Carga y consulta

Nmero de transacciones

Elevado

Medio o bajo

Tamao

Pequeo-Mediano

Grande

Tiempo de respuesta

Pequeo

Variable

Orientacin

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 vara de acuerdo a

su propia evolucin y utilizacin

29

30

Chapter I

Implementacin de un Data Warehouse

Los distintos tipos de implementacin de un Data Warehouse son los siguientes:
1. Implementacin ROLAP (Procesamiento Analtico Online Relacional).- Se trata de
sistemas y herramientas OLAP (Online Analytic Processing) construidos sobre una
base de datos relacional. Tpicamente, los datos son detallados, evitando las
agregaciones, y las tablas se encuentran normalizadas. Los esquemas ms
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
anlisis de una enorme cantidad de datos.
2.

Implementacin MOLAP (Multidimensional Online Analytical Processing o

'Procesamiento Analtico Multidimensional en lnea'). Se trata de una alternativa a
la tecnologa ROLAP (OLAP-Relacional). Aunque ambos tipos de herramientas
estn diseadas para realizar anlisis de datos a travs de un modelo de datos
multidimensional, MOLAP se diferencia significativamente en que requiere un
preprocesamiento y almacenamiento de la informacin contenida en el cubo OLAP.
MOLAP almacena estos datos en una matriz de almacenamiento multidimensional
optimizada, ms que en una base de datos relacional (o en un ROLAP). Para
optimizar los tiempos de respuesta, el resumen de la informacin es usualmente
calculado por adelantado. Estos valores precalculados o agregaciones son la base
de las ganancias de desempeo de este sistema. Algunos sistemas utilizan
tcnicas de compresin de datos para disminuir el espacio de almacenamiento en
disco debido a los valores precalculados.

3. Implementacin HOLAP (Hybrid Online Analytical Process o Procesamiento

Analtico en lnea Hbrido). Es una combinacin 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 aplicacin tiene
sobre este particionamiento vara 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
gestin y ejecucin de consultas relacionales y de consultas propias de anlisis 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 obtencin 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 analtico en lnea OLAP, es la componente ms poderosa de un Data
Warehouse, ya que es el motor de consultas especializadas del Data Warehouse. Las
herramientas OLAP, son una tecnologa de software para anlisis en lnea,
administracin y ejecucin de consultas, que permiten inferir informacin del
comportamiento del negocio.
Su principal objetivo es el de brindar rpidas respuestas a complejas preguntas, para
interpretar la situacin del negocio y tomar decisiones. Cabe destacar que lo que es
realmente interesante en OLAP, no es la ejecucin de simples consultas tradicionales,
sino la posibilidad de utilizar operadores, como se muestran en la Tabla 6, que permitan
profundizar en la informacin.

Tabla 6: Operaciones definidas dentro de un Data Warehouse

Drill-down

Permite apreciar los datos en un mayor detalle, bajando por una jerarqua
denida en un cubo. Esto brinda la posibilidad de introducir un nuevo nivel o
criterio de agregacin en el anlisis, disgregando los grupos actuales

Drill-up

Permite apreciar los datos en menor nivel de detalle, subiendo por una jerarqua
denida en un cubo. Esto brinda la posibilidad de quitar un nivel o criterio de
agregacin en el anlisis, agregando los grupos actuales.

Drill-acros

Funciona de forma similar a drill-down, con la diferencia que drill-across no se

realiza sobre una jerarqua, sino que su forma es ir de lo general a lo especco,
agregando un atributo a la consulta como nuevo criterio de anlisis.

Roll-across

Funciona de forma similar a drill-up, con la diferencia que roll-across no se hace

sobre una jerarqua, sino que su forma de ir de lo especco a lo general es
quitar un atributo de la consulta, eliminando de esta manera un criterio de
anlisis.

Drill-through

Permite apreciar los datos en su mximo nivel de detalle. Esto brinda la

posibilidad de analizar cules 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 anlisis

31

32

Chapter I

Figura 18: Herramienta de consulta y anlisis

Las Herramienta de Consulta y Anlisis son sistemas que permiten a los usuarios
realizar la exploracin de datos del Data Warehouse, constituyendo la unin entre el
Data Warehouse y los usuarios.
A travs de una interfaz grfica y una serie de pasos, los usuarios generan consultas
que son enviadas desde la Herramienta de Consulta y Anlisis 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 travs de las cuales podemos representar los resultados de
las consultas pueden ser:
Cuadros de mando12
Informes estticos13
Informes dinmicos

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 planicar las actividades del negocio, es por ello que se hace tanto
nfasis en la integracin, limpieza de datos, etc, para poder conseguir que la
informacin posea toda la calidad posible.
Es a travs de las herramientas de consulta y anlisis, 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 coleccin de informes, consultas y anlisis
interactivos que hacen referencia a un tema en particular y que estn relacionados entre s.

13 La eleccin 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

Crtico

Acciones permitidas

Agregar,
modificar,
Consultar
eliminar y consultar

I.1.3.1.6

No crtico

Conceptos complementarios: Datamarts

Un Datamarts (DM) es una versin especial del Data Warehouse. Son subconjuntos de
datos con el propsito de ayudar a que un rea especfica dentro del negocio pueda
tomar mejores decisiones. Los datos existentes en este contexto pueden ser
agrupados, explorados y propagados de mltiples formas para que diversos grupos de
usuarios realicen la explotacin de los mismos de la forma ms conveniente segn sus
necesidades.
En sntesis, se puede decir que los Datamarts son pequeos Data Warehouse
centrados en un tema o un rea de negocio especfico dentro de una organizacin.
Por ejemplo la informacin de personal de una empresa empleados, departamento,
proyectos es difcilmente integrable en un mismo modelo de estrella de ventas.
Incluso en mbitos ms relacionados de una organizacin, ventas y produccin no
resulta fcil. La solucin est en que para cada submbito de la organizacin 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. Lgicamente cada
Datamart tendr unas medidas y dimensiones propias y diferentes de los dems, la
nica dimensin que suele aparecer en todos los Datamarts es la dimensin tiempo, ya
que el Data Warehouse representa informacin histrica.

Figura 20: Datamarts

33

34

Chapter I

Captulo 2. ITOP Management

Consulting
Resumen:
ITOP MC es una empresa de consultara de Negocios y Gestin Empresarial con la que se
ha colaborado en la consecucin de este proyecto. En trminos BI, la empresa ITOP
desempea el papel de Product Owner.

2.1

La empresa
ITOP Management Consulting (ITOP MC) es una empresa experta en Consultora de
Negocios y Gestin Empresarial, especializada en Tecnologas de la Informacin, que
ofrece sus servicios de gestin global a las PYMEs, colaborando con una red slida de
partners y con compaas punteras pertenecientes al sector informtico y empresarial.
ITOP Management Consulting nace en el ao 2006 como una iniciativa de varios
socios con ms de 10 aos de experiencia en el mundo de la Consultora de
Tecnologas de la Informacin. El objetivo principal de la creacin de esta consultora es
ofrecer a la empresa canaria un servicio local de calidad en este terreno de la
consultora cuya demanda y dependencia de empresas de la pennsula 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 consultora 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, Telefnica, Bayer, GlaxoWellcome, ICEX, Turespaa y un largo etctera.

2.2

Filosofa
La integracin 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 energa necesaria para seguir creciendo e invirtiendo en ideas. La filosofa de la
empresa queda reflejada en el nombre ITOP Informacin, Tecnologa, Organizacin,
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

Captulo 3. Descripcin del problema e

integracin de soluciones tecnolgicas
Resumen:
En este captulo se describe el estudio realizado a lo largo del proyecto para la eleccin de
las tecnologas por las que se iban a apostar para la construccin de una solucin BI.

3.1

Introduccin
Sap Business One (Sap BO) es una nica aplicacin de gestin empresarial integrada
integra todas las funciones empresariales bsicas necesarias en cualquier empresa
(incluye gestin financiera, ventas, gestin de atencin al cliente, e-commerce, gestin
de inventarios y operaciones).
El problema a abordar consiste en integrar SAP BO con una solucin BI, de forma que
proporcione a las Pymes informes grficos y cuadros de mando interactivos que
ofrezcan una mayor versatilidad, control de los ingresos, los mrgenes y la liquidez.
Con esta aplicacin de BI, se ofrece funcionalidades para la gestin del conocimiento
que ayudan a las empresas a poner en contacto a "aquellos que saben" con "aquellos
que necesitan saber".

3.2

Anlisis funcional y eleccin

En este captulo se describe el estudio realizado a lo largo del proyecto para la eleccin
de las tecnologas por las que se iban a apostar para la construccin de una solucin
BI.

3.2.1

Anlisis Inicial
La evolucin del Business Intelligence (BI) durante los ltimos 10 aos ha sido muy
interesante, sobre todo en la manera en cmo se han simplificado el desarrollo e
implantacin de proyectos de este tipo, gracias a las tecnologas que han sabido
adaptarse a las necesidades de los usuarios, tanto de perfil desarrollador como
usuarios finales.
En el ao 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 anlisis de la informacin. En aquel momento las herramientas eran algo
primitivas, en cuanto a la presentacin de los datos y al desarrollo de las mismas,

36

teniendo muchas restricciones de formatos en los que se poda mostrar la informacin.

En consecuencia, se tenan que implementar desarrollos adicionales con el objetivo de
complementar las herramientas de BI existentes. El escenario tpico era el desarrollo
en Visual Basic; con este lenguaje se creaba una aplicacin de presentacin enfocada
a un ambiente ms ejecutivo, amigable, permitindoles a los usuarios finales de la
herramienta de BI realizar un anlisis con el ya famoso trmino "Drill Down", que en
aquellos tiempos era lo ltimo en tecnologa14.
Con el tiempo la historia fue cambiando y ahora existen innumerables tecnologas para
llevar a cabo una solucin BI, tanto con herramientas propietarias como con
OpenSource, cuyas dos vertientes tambin fueron analizadas en este proyecto.

I.3.2.1.1

Anlisis de una solucin BI con Software privativo.

Por la parte del Software privativo se encontr que existan muchas empresas
dedicadas a desarrollar software que facilita el desarrollo de una solucin BI. Para
conocer cules de ellas eran las lderes se procedi al estudio del cuadrante de
Gartner del ao 2010. Gartner es una empresa consultora, la cual realiza y publica una
serie de anlisis, de las ms fiables referencias, para conocer el estado y nivel de
madurez de los proveedores de BI ms influyentes de la actualidad. En la Figura 21
muestra el anlisis de Gartner del 2010:

En el eje X completeness of visin se representa el conocimiento de los

proveedores indicando cmo 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 visin 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 categora, 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 solucin de productos amplia, completa y madura, que
evoluciona segn demanda el mercado. Por otra parte tambin nos sugiere
que el proveedor goza de buena salud como empresa y que dispone de
medios suficientes para implantar con xito su solucin en variados escenarios.
Visionaries: En esta categora entraran aquellos proveedores con una buena
puntuacin en completeness of visin pero peor puntuacin en ability to
execute. Por lo tanto aqu estarn las empresas con una fuerte y acertada
visin del mercado actual en Business Intelligence. Sin embargo, a pesar de
sus buenas ideas, an puede que no tengan la capacidad para llevar
implantaciones, bien sea por su tamao 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 solucin. No obstante, suelen ofrecer poca variedad de
productos, o directamente centrarse en un nico aspecto de lo que demanda el
mercado. Tambin puede ocurrir que se trate de un dficit en su canal de
ventas o presencia geogrfica.
Niche Players: La ltima categora en principio es la ms desfavorable. Son
proveedores que no llegan a puntuar lo suficiente en ninguna categora 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 puntuacin en
completeness of visin nos da una idea de que estos proveedores no estn

38

evolucionando sus soluciones suficientemente rpido y de alguna manera

estn 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 ao 2010 como las empresas
lderes en producto BI, son las mejores por lo cual se decide apostar por Microsoft
como una opcin muy interesante para desarrollar este proyecto destacar adems
que la empresa ITOP MC ya posea una serie de licencias por lo que no habra que
realizar una nueva inversin a priori.
Para poder implantar una solucin BI usando tecnologas de Microsoft es necesario los
requerimientos que se muestran en la Tabla 8, resumidos en la Figura 22.
Tabla 8: Requerimientos tecnolgicos bsicos para una solucin BI con Microsoft
Requerimientos de Software

Qu solucin necesitamos?

Qu nos aporta?
Conexiones remotas, trabajo

Sistema Operativo

Windows 2008 R2 64bits

concurrente y Sistema Operativo

Windows convencional
Servidor para realizar y planificar el

Servidor de Integracin de
datos

SQL Server 2008 R2 Integration

proceso de Extraccin,

Services (SSIS)

Transformacin y Carga de los

Servidor de Base de datos

Analista o OLAP

SQL Server 2008 R2 Analisys

Anlisis y optimizacin de los datos

Servicies (SSAS)

almacenados en el DW

datos de origen

Sistema gestor de base de

datos
Servidor de Informes

SQL Server 2008 R2 64bits

Gestin y creacin de almacn de

datos

SQL Server 2008 R2 Reporting

Representacin de informes

Services (SSRS)

alimentados desde un Cubo OLAP

Crystal Xcelsius 2008 (No

pertenece a Microsoft pero est

Cuadros de mando dinmicos

totalmente integrada, con

basados en Flash, exportables a

cualquier producto de esa

Excel, PDF, etc.

empresa)
Cuadros de mando

SharePoint Foundation 2010 +

Performance Point
Silverlight 4.0
Microsoft Office Excel 2007 +
Power Pivot

39

Diseador de cuadro de mando

integrables en los portales Web
corporativos Share Point
Cuadros de mando dinmicos y con
conexin directa al cubo OLAP
Tablas y cuadros de mando
dinmicos con conexin directa a los
cubos OLAP

40

Chapter I

Figura 22: Solucin tecnolgica propuesta para una solucin BI usando herramientas Microsoft

Se realiz adems una comparacin de las caractersticas que nos aporta cada una de
las herramientas de presentacin 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 solucin BI, ya tienen
disponibles el software necesario derivado de la contratacin 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 representacin
SSRS

Crystal
Xcelsius

Performance
Point

Publicacin
SharePoint
Caractersticas
interactivas
Programables
(SDK)
Interfaz Amigable
Integracin con
SAP
Publicables en
Web

40

Silverlight

Microsoft
Excel

Tabla 9: Tabla comparativa del Software de representacin

SSRS

Crystal
Xcelsius

Performance
Point

Silverlight

Microsoft
Excel

Facilidad de uso
Costo de licencia
aceptable
Valoracin 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:
Generacin de informes: SSRS y Microsoft Excel
Creacin de cuadros de mando: Microsoft Excel y Cristal Xcelsius

I.3.2.1.2

Anlisis de una solucin BI con Open Source.

En cuanto al estudio que se realiz por la vertiente del Open Source se escogi la
solucin BI mejor valorada: Pentaho.
La plataforma Open Source Pentaho Business Intelligence cubre muy amplias
necesidades de Anlisis de los Datos y de presentacin de informacin empresarial.
Las soluciones de Pentaho estn escritas en Java y tienen un ambiente de
implementacin tambin basado en IDE Eclipse. Eso hace de Pentaho una solucin
muy flexible para cubrir una amplia gama de necesidades empresariales tanto las
tpicas como las sofisticadas y especificas al negocio.
La Figura 23 muestra un esquema de la estructura de Pentaho.

Figura 23: Estructura de la solucin de Pentaho

Los mdulos de la plataforma Pentaho BI son:

41

42

Chapter I

3.2.2

Reporting.- Mdulo de informes que ofrece la solucin adecuada a las

necesidades de los usuarios. Pentaho Reporting es una solucin basada en el
proyecto JFreeReport y permite generar informes gil y de gran capacidad.
Pentaho Reporting permite la distribucin de los resultados del anlisis en
mltiples formatos todos los informes incluyen la opcin de imprimir o
exportar a formato PDF, XLS, HTML y texto, adems de admitir
programacin de tareas y ejecucin automtica de informes con una
determinada periodicidad.
Anlisis.- Pentaho Anlisis suministra a los usuarios un sistema avanzado de
anlisis de informacin, con uso de las tablas dinmicas pivot tables,
crosstabs, generadas por Mondrian y JPivot. El usuario puede navegar por
los datos, ajustando la visin de los mismos, los filtros de visualizacin,
aadiendo o quitando los campos de agregacin. Los datos pueden ser
representados en una forma de SVG o Flash, los dashboards widgets, o
tambin integrados con los sistemas de Minera de Datos y los portales web o
portlets. Adems, con Microsoft Excel Analysis Services, se puede analizar los
datos dinmicos en Microsoft Excel usando la conexin a OLAP server
Mondrian.
Portal de BI: En este portal web se publica toda la informacin recolectada en
los procesos de anlisis.
Dashboards.- Todos los componentes del mdulo Pentaho Reporting y
Pentaho Anlisis pueden formar parte de un Dashboard. En Pentaho
Dashboards es muy fcil incorporar una gran variedad en tipos de grficos,
tablas y velocmetros Dashboard widgets e integrarlos con los Portlets
JSP, en donde podr visualizar informes, grficos y anlisis OLAP. As como
una librera de cdigo abierto integrada en el Portal de BI que nos proporciona
Pentaho denominada CDF (Community Dashboard Framework).
Data Mining.- Minera de datos se realiza con una herramienta WeKa.
Integracin de Datos.- Se realiza con una herramienta Kettle ETL (Pentaho
Data Integration) que permite implementar los procesos ETL. ltimamente
Pentaho lanz una nueva versin 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.

Conclusin
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 seleccin. Para ms
detalle mirar la Tabla 10.

42

Tabla 10: Tabla comparativa Pentaho vs Microsoft

Pentaho

Microsoft

Documentacin
Integracin con otras herramientas

Slo especificas

Posibilidad de aadir funcionalidades

Integrables con SharePoint
Facilidad para implementar cuadros de
mando

con
el
uso
de
herramientas externas

Coste de Licencias
Curva de aprendizaje
Multiplataforma. Mltiple sistema de
BBDD
Valoracin final

Finalmente se decidi decantarse por la solucin propuesta por Microsoft debido a los
siguientes motivos:

3.3

Documentacin ms homognea, slida y abundante.

Mayor bibliografa que Pentaho, quizs porque esta ltima utiliza herramientas
muy heterogneas entre s, no siguen un mismo patrn de desarrollo, estn en
constante cambios y son desarrolladas por diferentes organizaciones15.
Menor curva de aprendizaje.
Mayor facilidad de desarrollo.
La versin libre de Pentaho tiene elementos muy bsicos que conlleva un
esfuerzo adicional de instalacin y configuracin adicional
ITOP MC, as como sus clientes, ya posean la licencia de Microsoft SQL
Server 2008 Standard y se quera aprovechar esta opcin.

Descripcin del problema

Finalmente, despus de haber decidido cul era la tecnologa que se iba a usar para
implementar la solucin BI con el fin de integrarla con SAP BO, se procede a definir el
problema al que en este trabajo se le da solucin.

15 A fecha 07 de julio de 2011 en la bsqueda realiza de bibliografa sobre Pentaho fue escaso encontrar libros que
realmente entren en profundidad en cmo llevar a cabo un desarrollo completo de BI con Pentaho, ya que lo normal fue
encontrar bibliografa centrada en las herramientas de ETL y de Reporting.

43

44

Chapter I

Se quiere implantar una solucin Business Intelligence en SAP BO de manera que el

cliente que posea esta aplicacin pueda explotar y visualizar los datos, de tal forma que
sea una herramienta que recoja peridicamente los datos claves de su empresa,
convirtindose en un mecanismo para la ayuda en la toma de decisiones empresariales
y/o econmicas acertadas que permitan mejorar su competitividad.
Se elaboran una serie de indicadores de estudios centrndose en unas reas de
negocio especficas, concretamente en gestin de ventas, gestin financiera, gestin
de proyectos y gestin de incidencias. A continuacin se valoraran cules son las
dimensiones y sus jerarquas 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. Descripcin del

trabajo

45

46

Chapter I

Captulo 1. Descripcin de la
metodologa para resolver el problema
Resumen:
Desarrollo gil de Software
Metodologa de desarrollo Scrum
Planificacin del proyecto

1.1

Metodologa de desarrollo
Una metodologa de desarrollo de software se refiere a un framework16 que se usa para
estructurar, planear y controlar el proceso de desarrollo en Sistemas de Informacin. El
objetivo es mejorar la productividad en el desarrollo y la calidad del producto software.
Qu tipo de metodologa se podra utilizar?

Se entiende por metodologa gil de desarrollo de software a una coleccin de valores,

principios y prcticas para modelar software que pueden ser aplicados de manera
simple y ligera. La filosofa de las metodologas giles se basa en dar mayor valor al
individuo, a la colaboracin con el cliente y al desarrollo incremental del software con
iteraciones muy cortas.
En este proyecto se ha apostado por una metodologa gil de desarrollo de software,
intentando evitar los tortuosos y burocrticos caminos de las metodologas
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 metodologas de desarrollo tradicionales
Existen unas costosas fases previas de especificacin de requisitos, anlisis y
diseo
La correccin 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 ms 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 Informacin
asistir al proceso de desarrollo de software.

46

implica mayor dificultad

Las metodologas giles de desarrollo estn especialmente indicadas en proyectos con

requisitos poco definidos y/o cambiantes o cuando se exige reducir drsticamente los
tiempos de desarrollo pero manteniendo una alta calidad. Adems, se aplican bien en
equipos pequeos que resuelven problemas concretos, lo que no est reido con su
aplicacin en el desarrollo de grandes sistemas, ya que una correcta modularizacin de
los mismos es fundamental para su exitosa implantacin. Dividir el trabajo en mdulos
abordables minimiza los fallos y el coste, con lo cual las metodologas giles presentan
diversas ventajas, entre las que podemos destacar las indicadas en la Tabla 12.
Tabla 12: Ventajas de la metodologas 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
Atencin continua a la excelencia tcnica y al buen diseo
Mejora continua de los procesos y el equipo de desarrollo

En este proyecto se ha querido aportar ms dinamismo y adaptabilidad frente a los

cambios, por lo que se ha decidido hacer uso de una metodloga gil, apostando,
dentro del abanico de posibilidades, por la metodologa Scrum debido a que permite
maximizar la realimentacin 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 continuacin.

1.1.1

Metodologa SCRUM
Scrum es una metodologa para la gestin y desarrollo de software basada en un
proceso iterativo e incremental utilizado, comnmente, en entornos basados en el
desarrollo gil de software
Aunque surgi como modelo para el desarrollo de productos tecnolgicos, tambin 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, pudindose tomar como punto de partida para definir el proceso
de desarrollo que se ejecutar durante un proyecto software. A continuacin en la Error:
No se encuentra la fuente de referencia se presenta una ilustracin 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 duracin

fija entre 1 y 4 semanas y terminando en una fecha especfica,
independientemente de haberse finalizado, o no, el trabajo. Cada Sprint se va
sucediendo uno detrs 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
gestin del Sprint, con seguimientos diario del Scrum Daily Meeting
representa una reunin de avance diaria de no ms de 15 minutos, cuyo
propsito es vigilar las tareas realizadas, los recursos necesarios y los
obstculos que se presentan en busca del objetivo fijado.
Dueo 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 sern introducidas en el Sprint Backlog18 o pila del Sprint. Todos
los das el equipo Team realiza un Scrum Daily Meeting, actualizando unas grficas
orientativas que permiten hacer un seguimiento, de forma rpida y sencilla, de las
tareas que faltan para alcanzar su objetivo. Al final del Sprint, el Team hace una
revisin del mismo con los interesados en el proyecto, ensendoles 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 estn hechos19 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 centrndose 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 metodologa
modificndola para se ajustara a las necesidades puntuales de la solucin BI aportada
en este documento.
17 El Product Backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genricas 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 estimacin ayuda al Product Owner a ajustar la lnea
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 extradas del Product Backlog por el Team, teniendo en
cuenta cules de ellas son ms 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 colaboracin con la empresa ITOP MC y esta
desempeaba 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 seran efectivas puesto que no existiran cambios sustanciales que se
pudieran comentar para su valoracin. En su lugar se mantuvieron, siempre que fue
posible, reuniones semanales.

II.1.1.1.2

Planificacin de la solucin BI

A continuacin, en la Tabla 13, se muestra el Product Backlog tal y como se describe

en la metodologa Scrum. Se especificaron en una columna las funcionalidades y al
lado las correspondiente estimacin del tiempo que se dedicar para completar cada
tem. Decir que, aunque tendran que diferenciarse entre requisitos bsicos, prioritarios
o no, todos los requisitos son prioritarios ya que en si son una secuencia de pasos para
construir una solucin BI.

50

Tabla 13: Product Backlog de la solucin BI

tem

Descripcin

Estimacin

Estado del arte

30 das

Bsqueda de una metodologa

15 das

Estudio de las herramientas de desarrollo

15 das

Anlisis de requerimientos

4.1

Identificar Preguntas

15 das

4.2

Identificar Indicadores y Perspectivas

30 das

4.3

Modelo Conceptual

7 das

Anlisis de los OLTP

5.1

Conformar indicadores

30 das

5.2

Establecer correspondencias

7 das

5.3

Nivel de granularidad

7 das

5.4

Modelo conceptual ampliado

7 das

Modelo lgico del Data Warehouse

6.1

Tipo de modelo lgico del Data Warehouse

7 das

6.2

Tablas de dimensiones

15 das

6.3

Tablas de hechos

15 das

6.4

Uniones

15 das

Integracin de datos

7.1

Carga inicial

15 das

7.2

Actualizacin

15 das

Implementacin de ETL con el SSIS

15 das

Implementacin de cubos OLAP con el SSAS

15 das

10

Representacin

15 das

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 ejecucin de
cada punto para detectar cuellos de botellas y, en consecuencia, darles solucin.
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 limitacin a estos Sprints, se ha
impuesto que cada uno tenga como mnimo 6 das de ciclo de vida y, como mximo 7.

52

53

54

Chapter I

Tabla 14: Sprint Backlog de la solucin BI

Backlog

Sprint

Duracin

Descripcin

Estimacin

Real

Estudio del estado del arte

1

1,2,3,4,5

Estado del arte

30 das

30 das

Documentacin

3 das

3 das

Desarrollo de una metodologa

2

7, 8

Bsqueda de una metodologa

15 das

15 das

Documentacin

3 das

3 das

15 das

15 das

Herramientas de desarrollo

10, 11

Estudio

de

las

herramientas

de

desarrollo

12

Documentacin

3 das

3 das

13

Pruebas

7 das

7 das

Identificar Preguntas

7 das

10 das

Identificar Indicadores y Perspectivas

7 das

10 das

21

Modelo Conceptual

7 das

7 das

22

Documentacin

3 das

3 das

23

Pruebas

7 das

7 das

Conformar indicadores

7 das

15 das

29

Establecer correspondencias

7 das

15 das

30

Nivel de granularidad

7 das

15 das

31

Modelo conceptual ampliado

7 das

7 das

22

Documentacin

3 das

3 das

23

Pruebas

7 das

7 das

Anlisis de requerimientos
14, 15
16,17,18,19,2
4

Anlisis de los OLTP

24,25,26,27,2
8
5

Modelo lgico del Data Warehouse

Tipo de modelo lgico 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 acometan por primera vez, hubo cambios de
tecnologas y necesidad de nuevos equipos de trabajo debido a que los que existan no
soportaban la tecnologa elegida, adems no se parte de un caso ideal o terico sino
que se trataba de explotar datos reales donde no se dispona, entre otros problemas,
de una base de datos totalmente depurada (o purificada).

II.1.1.1.3

Planificacin temporal

Este proyecto viene delimitado temporalmente por la necesidad de no exceder las 150
horas de dedicacin, equivalentes a los 15 crditos asignados a esta asignatura.
Respetar este lmite es una tarea difcil, ya que siempre se dedican ms horas en la
parte de desarrollo para intentar cumplir los objetivos fijados, sin contar con el tiempo
dedicado a las reuniones, a la formacin o a incidencias tecnolgicas.
Para la representacin de las tareas y su asignacin temporal, se ha seleccionado el
Diagrama de Gantt. Su objetivo es mostrar el tiempo de dedicacin 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

Captulo 2. Metodologa de
Implementacin de una solucin BI
Resumen:
Metodologa para construir de un Data Warehouse
Metodologa propia para la construccin de un Data Warehouse
Como se mencion en el Captulo Fundamentos Business Intelligence, se denomina
Business Intelligence al conjunto de estrategias y herramientas enfocadas a la
administracin y creacin de conocimiento mediante el anlisis de datos existentes en
una organizacin o empresa. Abarca la comprensin del funcionamiento actual de la
empresa, bien como la anticipacin de acontecimientos futuros, con el objetivo de
ofrecer conocimientos para respaldar las decisiones empresariales. En Figura 25 se
representa el esquema de una solucin BI, teniendo en cuenta que los componentes
bsicos son: OLTP, herramientas ETL Extraccin, Transformacin y Carga, Data
Warehouse, Query Manager y las herramientas de consultas y anlisis como los
cuadros de mandos o generados de informes.

Figura 25: Componentes principales de una solucin BI

Una vez entendido en qu consiste una solucin 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 disea e implementa.
La construccin e implementacin 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, sern diferentes. Lo que se

57

58

Chapter I

debe tener muy en cuenta, es no entrar en la utilizacin de metodologas que requieran

fases extensas de reunin de requerimientos y anlisis, fases de desarrollo monoltica
que conlleve demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es
entregar una primera implementacin que satisfaga una parte de las necesidades, para
demostrar las ventajas del Data Warehouse y motivar a los usuarios.
La metodologa elegida para el diseo del Data Warehouse se ha elaborado a partir de
una metodologa base existente, la cual se ha ampliado y adaptando a nuestro
problema. La ampliacin ha consistido en la adicin de algunos aspectos claves en el
diseo de un Data Warehouse y una metodologa de implementacin para una solucin
de Business Intelligence. La metodologa base de la que se parte fue propuesta por el
Ingeniero Argentino Bernabeu Ricardo Investigacin y Sistematizacin de Conceptos HEFESTO: Metodologa propia para la Construccin de un Data Warehouse 20 (2).

2.1.1

Metodologas para construir un Data Warehouse

En un principio se realiz una bsqueda con el fin de encontrar una metodologa que
se adaptara lo mejor posible a nuestro problema. Se encontraron dos metodologas
interesantes: por un lado Hefesto, anteriormente nombrada, y por otro lado la
desarrollada por SAS, llamada The SAS Rapid Data Warehouse Methodology
(SRDWM). Dicha metodologa es iterativa y desarrolla incrementalmente un proyecto
Data Warehouse dividindolo en cinco fases:
1.
2.
3.
4.
5.

Definicin de los objetivos

Definicin de los requerimientos de informacin
Diseo y modelizacin
Implementacin
Revisin

La razn por la que se desestim el uso de la metodologa SRDWM es debido a la

sencillez y eficacia con la que est elaborada la metodologa Hefesto. Hefesto explica
de forma muy intuitiva los pasos que hay que tomar en cada momento, as como por
qu debemos tomarlos, acompaada siempre con ejemplos y comparaciones. Se toma
como punto de referencia para todas aquellas personas que estn dando sus primeros
pasos en el mundo del Data Warehousing y quizs en ese sentido SRDWM no
aportaba esa sencillez, resultando incluso ms dificultoso. Otra ventaja es que encaja
perfectamente con la metodologa Scrum frente a SRDWM, que al ser una metodologa
iterativa incremental, tendra mayor dificultad de adaptarse a una metodologa de
desarrollo gil. En la Tabla 15 se muestra las principales caractersticas de Hefesto.
Tabla 15: Caractersticas principales en la metodologa Hefesto
Los objetivos y resultados esperados en cada fase se distinguen fcilmente y son sencillos de
comprender
20 A partir de ahora utilizaremos Hefesto para referirnos a ella.

58

Tabla 15: Caractersticas principales en la metodologa 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 lgicos, 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 metodologa
Es independiente de las herramientas que se utilicen para su implementacin
Es independiente de las estructuras fsicas que contengan el DW y de su respectiva distribucin
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 metodologa Hefesto nos dimos cuenta que habra que
adaptarla hacia una situacin real de Data Warehouse ms compleja, pero esto no
supuso ningn problema gracias a la flexibilidad que ofrece.

2.1.2

Metodologa propia para la Construccin de un Data Warehouse

con base en HEFESTO
La metodologa Hefesto sigue las fases de construccin mostradas en la Figura 27.

Figura 26: Metodologa propia de Hefesto para la construccin de un Data Warehouse

Las adaptaciones llevadas a cabo en la metodologa propia de Hefesto, ha consistido en crear

una nueva seccin dedicada a la implementacin, ya que no lo tiene en cuenta por ser
independiente de las herramientas que se utilicen para su implementacin. Adems las fases
de anlisis e integracin tambin sufrieron modificaciones en diversos apartados.
Figura 27: Metodologa propia para la construccin de un Data Warehouse

En la Figura 27 se muestra la metodologa propia con base en Hefesto, donde se puede

apreciar en color rojo las adiciones o reestructuraciones de las fases. A continuacin se van
analizando las fases resaltando los cambios realizados en cada una de ellas.

II.2.1.2.1

Fase 1: Anlisis de Requerimientos

59

60

Chapter I

El primer paso a realizar es identicar los requerimientos de los usuarios a travs de

preguntas que expliciten los objetivos de su organizacin. Luego, se analiza estas
preguntas a n de identicar cules sern los indicadores y perspectivas que sern
tomadas en cuenta para la construccin del Data Warehouse. Finalmente se
confecciona un modelo conceptual en donde se puede visualizar el resultado obtenido
en este primer paso.

II.2.1.2.1.1 Identicar preguntas

El objetivo de este apartado consiste en recolectar las necesidades de informacin,
pudindose llevar a cabo a travs de diversas tcnicas como entrevistas, cuestionarios,
observaciones, entre otras.
El anlisis de los requerimientos de los diferentes usuarios, es el punto de partida de
esta metodologa, ya que nos deben, en cierto modo, guiar la investigacin hacia un
desarrollo que reeje claramente lo que se espera del Data Warehouse, en relacin a
sus funciones y capacidades.
Por todo lo anterior, el fin consiste en obtener e identicar las necesidades de
informacin clave de alto nivel, esencial para llevar a cabo las metas y estrategias de la
empresa, facilitando una toma de decisiones de forma ecaz y eciente a travs de los
KPI (Key Performance Indicators) o indicadores de rendimiento clave.
Debe tenerse en cuenta que dicha informacin, es la que proveer el soporte para
desarrollar las fases sucesivas, por lo cual, es muy importante que se preste especial
atencin al revelar los datos.
Una forma de asegurarse de que se ha realizado un buen anlisis, es corroborar que el
resultado del mismo haga explcitos los objetivos estratgicos planteados por la
empresa que se est estudiando.
Otra forma de encaminar la relevancia, es enfocar las necesidades de informacin en
los procesos principales que desarrolle la empresa en cuestin.
La idea central es formular preguntas complejas sobre el negocio, que incluyan
variables de anlisis que se consideren relevantes, ya que son estas las que permitirn
estudiar la informacin desde diferentes perspectivas.
Cabe destacar que la informacin debe estar soportada de alguna manera por algn
OLTP, ya que de otra forma, no se podr elaborar el Data Warehouse.
Como aportacin a la metodologa Hefesto, en principio se ha seleccionado una serie
de cuestiones que pueden ayudar a identificar qu es lo que quiere medir, evaluar o
ver la empresa:

60

Cules son las metas que tenemos?

Antes que nada se debe definir la meta21 para poder ver los elementos ms
importantes que influyen para llegar al resultado final. Aqu es donde est una de las
claves del xito, hasta dnde quiero llegar y qu tengo que hacer.
Qu elementos influyen en las metas que me he propuesto?
Es posible medir este indicador?
Me ayuda a pensar en qu acciones puedo mejorar?
Tengo con qu comparar este indicador?
Por qu es este un buen indicador?
Qu es lo que estoy midiendo: , tiempo, visitas, %?
Una vez que tengamos nuestro indicador vienen las siguientes preguntas:
Cada cunto es bueno medir este indicador?
Quin debe conocer estos nmeros?
Cmo presentaremos estos nmeros para que se entiendan?
Cmo motivaremos al personal a alcanzar estas metas?
Una vez obtenido el indicador, faltara analizar la perspectiva donde este valor aporta
un significado:
Cul es la perspectiva de anlisis?
Con qu otra medida lo comparo?
Se puede dar el caso que el usuario no tenga muy claro sus necesidades de
informacin o que estas sean demasiadas y, por lo tanto, imposible de abarcar. Es muy
importante centrarse en los puntos clave de informacin y eliminar aquellos que sean
secundarios. Cuando ocurre esto, como refuerzo a las cuestiones, se propone guiar al
usuario pidindole que indique cules son los procesos principales que desarrolla su
empresa, apoyndose en la Gestin de Procesos de Negocio (Business Process
Management o BPM) 22 ya que a travs del modelado de las actividades y procesos se
puede lograr un mejor entendimiento del negocio y muchas veces esto presenta la
oportunidad de mejorarlos.
La automatizacin de los procesos reduce errores, asegurando que los mismos se
comporten siempre de la misma manera y dando elementos que permitan visualizar el
estado de los mismos. La administracin de los procesos permite asegurar que los
mismos se ejecuten eficientemente, obteniendo informacin vital para futuras mejoras,

21 Tener en cuenta que una meta debe ser medible, por lo general, cuantitativamente.

22 Una Gestin de Procesos de Negocio es una metodologa empresarial cuyo objetivo es mejorar la eficiencia a
travs de la gestin sistemtica de los procesos de negocio, que se deben modelar, automatizar y optimizar de forma
continua.

61

62

Chapter I

ya que a travs de la ejecucin diaria de los procesos, se puede identificar posibles

ineficiencias en los mismos, llevando a actuaciones para optimizarlos.
En el caso de estudio presente llevado a cabo para la empresa ITOP, se analiz su
mapa de Procesos de Negocio, pues al ser una empresa con los objetivos bien
marcados, las cuestiones se usaron en segundo lugar, se propone guiar al usuario
pidindole que indique cules son los procesos principales
Qu necesito ver, medir o evaluar?
Cmo necesito analizarlo?

Figura 28: Mapa de procesos ITOP

ITOP MC distinguen tres procesos importantes:

Procesos estratgicos orientados y dirigidos a los procesos clave y de apoyo.

Procesos claves objetivo principal de las actividades que se llevan a cabo en la
empresa o unidad siendo su razn de ser.
Procesos de apoyo soportan a uno o ms de los procesos clave.

Despus de haber analizados los procesos claves, se decidi centrarse en los

procesos Gestin de Proyectos, Soporte a partir de ahora Gestin de Incidencias,
Vender Gestin de Ventas y Direccin Financiera. A continuacin, se procedi a
identicar las necesidades de informacin dentro de cada proceso, que a groso modo
se aprecia en la Tabla 16.

62

Tabla 16: Necesidades de informacin dentro de cada proceso

Cmo
Qu

quiero

medir?

En

representaremos

Cul

es

la

unidad va a

qu

estos

nmeros

perspectiva

de

ser medido?

para

que

anlisis?

se

entiendan?
Total de ventas que
han habido

Gestin

de

Ventas

En qu momento

Euros

ocurri
Quin

Total de beneficio

Euros,

que se ha obtenido

Porcentaje

Cuanto aument las

Euros,

Barras

Que compro

ventas

Porcentaje

SparkLines

Quien lo vendi

Cuanto aument el

Euros,

donde se produjo

beneficio

Porcentaje

la venta

Grfico de Bala
Donde ocurri
Diagrama

de

Cul fue el medio

Relacin

entre

el

capital ajeno y el
capital propio

Direccin
Financiera

Grado

de

endeudamiento

de

los activos

Euros,
Porcentaje

Porcentaje

Rentabilidad de la

Euros,

empresa

Porcentaje

Eficiencia empresa

Cmo

va

Grfico de Bala

Euros,

Proyectos

de

va

Euros,
Porcentaje

Euros

el

aspectos de calidad

Diagrama Barras
Porcentaje

SparkLines
Diagramas control

se refiere

proyecto

ocurri

Grfico de Bala

proyecto en cuanto

Cmo

SparkLines
Grfico de lnea

a costos

Gestin

En qu momento

el

proyecto en cuanto

Cmo

Diagrama Barras

va

Lneas tendencias

el
en

Tiempo

mrgenes de tiempo

63

En qu momento
ocurri

64

Chapter I

Tabla 16: Necesidades de informacin dentro de cada proceso

Cmo
Qu

quiero

medir?

En

representaremos

Cul

es

la

unidad va a

qu

estos

nmeros

perspectiva

de

ser medido?

para

que

anlisis?

se

entiendan?
En

qu

nivel

de

riesgo se encuentra

Porcentaje

el proyecto
Como se encuentra
el

proyecto

en

cuanto al alcance

Atributo23

fijado
Como se encuentra
el

proyecto

cuanto

en
a

Tiempo

adquisiciones
Como se encuentra
el

proyecto

en

cuanto a recursos

Numrico

humanos
Gestin

de

Incidencias

Nmero

de

incidencias abiertas

Grfico de Bala
Numrico

Diagrama

frente a

de

En qu momento
ocurri

Barras

Incidencias

SparkLines

Porcentaje

cerradas

Lneas

Tiempo que se tarda

en responder una

de

tendencias
Grfico de pila

Numrico

incidencia
Tiempo que se tarda
en

cerrar

una

Numrico

incidencia
Fuente

de

Atributo

incidencias
23 Entendemos como atributo una serie de valores definidos por el usuario que le ayuden a entender la medida
evaluada. Ej: Bueno, Malo

64

Tabla 16: Necesidades de informacin dentro de cada proceso

Cmo
Qu

quiero

medir?

En

representaremos

Cul

es

la

unidad va a

qu

estos

nmeros

perspectiva

de

ser medido?

para

que

anlisis?

se

entiendan?
Gravedad

de

la

incidencia
Nmero

Atributo

de

incidentes

Porcentaje

asignados
incorrectamente
Nmero
incidencia

de
Porcentaje

reabiertas

II.2.1.2.1.2 Identicar indicadores y perspectivas

Una vez que se han establecido las preguntas de negocio, se debe proceder a su
descomposicin para descubrir los indicadores que se utilizarn y las perspectivas de
anlisis que intervendrn.
Para ello, se debe tener en cuenta que los indicadores KPI para que sean realmente
efectivos, toman, en general, valores numricos y representan lo que se desea
concretamente analizar, como saldos, promedios, cantidades, sumatorias, frmulas,
entre otros.
En cambio, las perspectivas o dimensiones se reeren a los objetos mediante los
cuales se quiere examinar los indicadores, con el n de responder a las preguntas
planteadas, como clientes, proveedores, sucursales, pases, productos, entre otros,
destacando al tiempo la ms comn de las perspectivas24.
Llegados a este punto, en nuestro caso de estudio se ha elaborado una tabla de KPIs
(ver Tabla 17) a partir de los procesos en lo que ms estaban interesados la empresa.
Tabla 17: Indicadores

24 Las dimensiones o perspectivas, usualmente, se asocian en jerarquas para describir niveles de agrupamiento
especficos explcitos o implcitos y, por lo tanto, las diferentes granularidades nivel de detalle en la visin de
los datos

65

66

Chapter I

Ventas
Finanzas
Gestin de Proyectos
Gestin de Incidencias

Para el proceso de Ventas y Finanzas, la empresa ya tena decidido cuales eran los
indicadores que queran medir; en cambio, los indicadores de Gestin de Proyectos e
Incidencias se hizo un estudio de cules eran los que ms se adaptaban a sus
necesidades de informacin.
Se aprecia en la Tabla 18 los indicadores de Gestin de Ventas, indicando el nombre
del indicador y una breve descripcin de los mismos.
Tabla 18: Gestin de Ventas
Indicadores
Variacin de ventas
Total de ventas
% Beneficio Total
% Variacin del
Beneficio

Descripcin
Mide el porcentaje de variacin de ventas sobre el
ejercicio anterior
Mide el total de ventas que se han realizado
Mide el beneficio total obtenido de las ventas
Mide la variacin del beneficio respecto al histrico

Perspectiva
Tiempo
Cliente
Gestin de Ventas
Canal
Producto
Geografa

Los indicadores de Direccin Financiera figuran en las Tabla 20, Tabla 21, Tabla 22,
Tabla 23 dividindose los ratios financieros en cuatro grandes grupos, como indica la
Tabla 19.
Tabla 19: Grupos de Indicadores de Direccin
Financiera
Ratios de liquidez
Ratios de endeudamiento o solvencia
Ratios de rentabilidad
Ratios de gestin u operativos

66

Tabla 20: Ratios de liquidez

Son los ratios que miden la disponibilidad o solvencia de dinero en efectivo, o la capacidad que tiene la
empresa para cancelar sus obligaciones de corto plazo.
Indicadores de

Descripcin

Perspectivas

Direccin
Financiera
Ratios de
liquidez severa o
Prueba cida

Ratios de liquidez
absoluta o Ratio
de efectividad o
Prueba supercida
Capital de trabajo

Este ratio muestra una medida de liquidez ms precisa que la

anterior, ya que excluye a las existencias (mercaderas o
inventarios) debido a que son activos destinados a la venta y
no al pago de deudas, y, por lo tanto, menos lquidos;
adems de ser sujetas a prdidas en caso de quiebra.
Es un ndice ms exacto de liquidez que el anterior, ya que
considera solamente el efectivo o disponible, que es el dinero
utilizado para pagar las deudas y, a diferencia del ratio
anterior, no toma en cuenta las cuentas por cobrar (clientes)
ya que es dinero que todava no ha ingresado a la empresa.
Si el resultado es menor que 0.5, no se cumple con
obligaciones de corto plazo
Se obtiene de deducir el pasivo corriente al activo corriente.
Lo ideal es que el activo corriente sea mayor que el pasivo
corriente, ya que el excedente puede ser utilizado en la
generacin de ms utilidades.

Tiempo

Tabla 21: Ratios de endeudamiento, solvencia o de apalancamiento

Son aquellos ratios o ndices que miden la relacin entre el capital ajeno fondos o recursos
aportados por los acreedores y el capital propio recursos aportados por los socios o accionistas y
lo que ha generado la propia empresa, as como tambin el grado de endeudamiento de los activos.
Miden el respaldo patrimonial.
Indicadores de Direccin

Descripcin

Perspectivas

Financiera
Ratio de endeudamiento a
corto plazo
Ratio de endeudamiento a
largo plazo
Ratio de endeudamiento total

Ratio de endeudamiento de
activo

Mide la relacin entre los fondos a corto plazo

aportados por los acreedores y los recursos
aportados por la propia empresa.
Mide la relacin entre los fondos a largo plazo
proporcionados por los acreedores, y los
recursos aportados por la propia empresa.
Mide la relacin entre los fondos totales a
corto y largo plazo aportados por los
acreedores, y los aportados por la propia
empresa.
Mide cunto del activo total se ha financiado
con recursos o capital ajeno, tanto a corto
como largo plazo.

67

Tiempo

68

Chapter I

Tabla 22: Ratios de rentabilidad

Muestran la rentabilidad de la empresa en relacin con las ventas, el patrimonio y la inversin,
indicando adems la eficiencia operativa de la gestin empresarial.
Indicadores de Direccin

Descripcin

Perspectivas

Financiera
Ratio de rentabilidad de la
inversin (ROA)

Es el ratio ms representativo de la marcha

global de la empresa, ya que permite apreciar su
capacidad para obtener utilidades en el uso del
total activo.

Ratio de rentabilidad del

patrimonio (ROE)

Este ratio mide la capacidad para generar

utilidades netas con la inversin de los
accionistas y lo que ha generado la propia
empresa (capital propio).

Ratio de rentabilidad bruta

sobre ventas
Ratio de rentabilidad neta
sobre ventas

Ratio de rentabilidad por

accin

Ratio de dividendos por

accin

Llamado tambin margen bruto sobre ventas,

muestra el margen o beneficio de la empresa
respecto a sus ventas.
Es un ratio ms concreto ya que usa el beneficio
neto luego de deducir los costos, gastos e
impuestos.
Llamado tambin utilidad por accin, permite
determinar la utilidad neta que le corresponde a
cada accin. Este ratio es el ms importante
para los inversionistas, pues le permite comparar
con acciones de otras empresas.

Tiempo

El resultado de este ratio representa el monto o

importe que se pagar a cada accionista de
acuerdo a la cantidad de acciones que ste
tenga.

Tabla 23: Ratios de gestin, operativos o de rotacin

Evalan la eficiencia de la empresa en sus cobros, pagos, inventarios y activo.

Indicadores de Direccin
Financiera
Ratio de periodo de cobro
Ratio de rotacin por pagar
Ratio de periodo de pagos

Ratio de rotacin de
inventarios

Descripcin
Indica el nmero de das en que se recuperan las
cuentas por cobrar a sus clientes.
Mide el plazo que la empresa cuenta para
cancelar bonificaciones.
Determina el nmero de das en que la empresa
se demora en pagar sus deudas a los
proveedores.
Indica la rapidez en que los inventarios se
convierten en cuentas por cobrar mediante las
ventas al determinar el nmero de veces que rota
el stock en el almacn durante un ejercicio.

Perspectivas

Tiempo

Por otro lado, para elaborar los indicadores de Gestin de Proyectos e Incidencias,
comentado anteriormente, se tuvo que llevar a cabo una investigacin de cules

68

podran ser los ms que se ajustaban a las necesidades de la empresa y, despus de

sucesivas reuniones con el cliente, se escogieron una serie de ellos.
Para la creacin de los indicadores de Gestin de Proyectos se utiliz como
documentacin el PMBOK25. Comprende dos grandes secciones: la primera sobre los
procesos y contextos de un proyecto, y la segunda sobre las reas de conocimiento
especfico para la gestin de un proyecto.
Las nueve reas del conocimiento mencionadas en el PMBOK se detallan en la Tabla
24.
Tabla 24: Gestin de Proyectos

Gestin de la Integracin del

Proyecto

Gestin del Alcance del Proyecto

Gestin del Tiempo del Proyecto
Gestin de los Costos del Proyecto

Gestin de la Calidad del Proyecto

Gestin de los Recursos Humanos
del Proyecto
Gestin de las Comunicaciones del
Proyecto

Gestin de los Riesgos del

Proyecto
Gestin de las Adquisiciones del
Proyecto

Incluye los procesos y actividades necesarios para

identificar, definir, combinar, unificar y coordinar los
diversos procesos y actividades de la direccin de
proyectos dentro de los grupos de procesos de direccin
de proyectos.
Incluye los procesos necesarios para garantizar que el
proyecto incluya todo (y nicamente todo) el trabajo
requerido para completarla con xito.
Incluye los procesos requeridos para administrar la
finalizacin del proyecto a tiempo.
Incluye los procesos involucrados en estimar,
presupuestar y controlar los costos de modo que se
complete el proyecto dentro del presupuesto aprobado.
Incluye los procesos y actividades de la organizacin
ejecutante que determinan responsabilidades, objetivos y
polticas de calidad a fin de que el proyecto satisfaga las
necesidades por la cuales fue emprendido.
Incluye los procesos que organizan, gestionan y conducen
el equipo del proyecto.
Incluye los procesos requeridos para garantizar que la
generacin,
la
recopilacin,
la
distribucin,
el
almacenamiento, la recuperacin y la disposicin final de
la informacin del proyecto sean adecuados, oportunos y
entregada a quien corresponda (interesado del proyecto o
stakeholders).
Incluye los procesos relacionados con llevar a cabo la
planificacin de la gestin, identificacin, el anlisis, la
planificacin de respuesta a los riesgos, as como su
monitoreo y control en un proyecto.
Incluye los procesos de compra o adquisicin de los
productos, servicios o resultados que es necesario obtener
fuera del equipo del proyecto.

Una vez analizadas y comprendidas estas nueves reas se crearon los siguientes
KPIs correspondientes a dichas reas, como se indica en la Tabla 25, Tabla 26, Tabla
27, Tabla 28, Tabla 29, Tabla 30 y la Tabla 31.
Tabla 25: Gestin de proyectos. Gestin de la Integracin del Proyecto
Indicador

Descripcin

Perspectivas

25 PMBOK es un estndar en la Administracin de Proyectos desarrollado por el Project Management Institute (PMI)
(37).

69

70

Chapter I

% de tiempo dedicado a la
coordinacin del proyecto
Nmero de proyectos
abiertos en relacin con el
nmero de proyectos
cerrados
Nmero de hitos retrasados

Este indicador mide el porcentaje de tiempo

invertido en coordinar un proyecto en
relacin con el tiempo que se tard en
coordinar e implementar el proyecto.
Este indicador mide
el nmero de
proyectos cerrados en relacin con el
nmero de proyectos abiertos.

Tiempo

Un hito es una tarea que representa una

fecha importante en un proyecto, como la
finalizacin de una fase del proyecto.

Tabla 26: Gestin de proyectos. Gestin del tiempo

Indicador
Desviacin del
calendario previsto
para el proyecto
Tasa de tareas
realizadas en los
plazos deseados

Descripcin
La desviacin del calendario previsto es la
diferencia en tiempo entre la lnea base con
respecto al desarrollo actual

Perspectiva

Tiempo

Tasa de tareas realizadas en los plazos

deseados

Tabla 27: Gestin de proyectos. Gestin de calidad

Indicador

Descripcin
La desviacin del retorno prevista de la inversin
(ROI) es la diferencia entre el retorno de la
inversin prevista en la lnea de base y el retorno
real de la inversin.

Desviacin del
retorno de la
inversin prevista
Porcentaje del

Perspectivas

Tiempo

--------------------------------------------------------

proyecto terminado

Tabla 28: Gestin de proyectos. Gestin de costo

Indicador

Valor Ganado (EV)

Valor planificado (PV)

Costo real (AC)

Variacin del
cronograma (SV)
Variacin de costo
(CV)

Descripcin
El valor ganado es el valor del trabajo
completado expresado en trminos del
presupuesto aprobado asignado a dicho trabajo
para una actividad del cronograma o un
componente de la estructura de desglose del
trabajo.
El valor planificado es el presupuesto autorizado
asignado al trabajo que debe ejecutarse para
completar una actividad o un componente de la
estructura de desglose del trabajo.
El costo real (AC) es el costo total en el que se
ha incurrido realmente y que se ha registrado
durante la ejecucin del trabajo realizado para
una actividad o componente de la estructura de
desglose del trabajo.
La variacin del cronograma es una medida del
desempeo del cronograma en un proyecto. La
variacin del cronograma, en la EVM, finalmente
ser igual a cero cuando se complete el
proyecto, porque ya se habrn ganado todos los
valores planificados.
La variacin del costo es una medida del
desempeo del costo en un proyecto.
En la EVM, la CV es particularmente crtica

70

Perspectiva
Tiempo

Tabla 28: Gestin de proyectos. Gestin de costo

Indicador

ndice de desempeo
del cronograma (SPI)

ndice del desempeo

del costo (CPI)

Estimacin a la
conclusin (EAC)

ndice de Desempeo
del Trabajo por
Completar (TCPI)

Descripcin
porque indica la relacin entre el desempeo
real y los costos gastados. En la EVM, una CV
negativa con frecuencia no es recuperable para
el proyecto.
El ndice de desempeo del cronograma es una
medida del avance logrado en un proyecto en
comparacin con el avance planificado.
Puesto que el SPI mide todo el trabajo del
proyecto, el desempeo en la ruta crtica
tambin debe analizase, para determinar si el
proyecto terminar antes o despus de la fecha
de finalizacin programada.
Es una medida del valor del trabajo completado,
en comparacin con el costo o avance reales del
proyecto. Se considera la mtrica ms
importante de la gestin del valor ganado y mide
la eficacia de la gestin del costo para el trabajo
completado.
La EAC puede diferir del presupuesto hasta la
conclusin (BAC).
Si resulta evidente que el BAC ya no es viable,
el director del proyecto debe proyectar una EAC.
Las EAC se basan normalmente en los costos
reales en los que se ha incurrido para completar
el trabajo, ms una estimacin hasta la
conclusin (ETC) para el trabajo restante.
El ndice de desempeo del trabajo por
completar es la proyeccin calculada del
desempeo del costo que debe lograrse para el
trabajo restante, con el propsito de cumplir con
una meta de gestin especificada, tal como el
BAC o la EAC.
Si resulta evidente que el BAC ya no es viable,
el director del proyecto proyecta una estimacin
a la conclusin EAC.

Perspectiva

Tabla 29: Gestin de proyectos. Gestin de Riesgos

Indicador
% de los proyectos que
consideran de riesgo
% de los proyectos con cambios
de alcance
% de los proyectos "en el
control"
Promedio del nmero de
modificaciones realizadas al
proyecto desde su definicin
% de los proyectos a tiempo y
dentro del presupuesto

Descripcin
Porcentaje de proyectos que se
consideran de riesgo
Porcentaje de proyectos activos con
cambios de alcance durante el
proyecto
Porcentaje de proyectos que est
"bajo control", es decir, que son
subjetivamente calificados como el
control basado en tiempo, presupuesto
y calidad
Promedio del nmero de cambios
realizados en la definicin del alcance
del proyecto, es decir, de los proyectos
durante su ciclo de vida
Porcentaje de proyectos que se
ejecutan en el marco de tiempo
previsto y con el presupuesto (gastos)
en funcin de su lnea de base

71

Perspectiva

Tiempo

72

Chapter I

Tabla 30: Gestin de proyectos. Gestin de recursos humanos

Indicador
Promedio del nmero de
personas asignadas al proyecto

Descripcin

Perspectiva

---------------------------------------------------

Tiempo

----

Tabla 31: Gestin de proyectos. Gestin de adquisicin

Indicador

Requisicin de tiempo de
emisin tema

Descripcin
Perspectiva
Para medir el tiempo transcurrido
entre el momento en que una
solicitud de contratacin se inicia y el
Tiempo
momento en que la solicitud se
cumple (expresada en trminos de
das).

A la hora de crear los indicadores de Gestin de Incidencias se ha optado por seguir la

gua de buenas prcticas de ITIL (Biblioteca de Infraestructura de Tecnologas de
Informacin o Information Technology Infrastructure Library) (3) que consiste en un
conjunto de conceptos y prcticas para la gestin de servicios de tecnologas de la
informacin, el desarrollo de tecnologas de la informacin y las operaciones
relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso
conjunto de procedimientos de gestin ideados para ayudar a las organizaciones a
lograr calidad y eficiencia en las operaciones de TI (Tecnologas de la Informacin).
Los indicadores elaborados para el proceso de Gestin de Incidencias se muestran en
la Tabla 32.
Tabla 32: Gestin de Incidencias
Indicador
Tiempo en cerrar la
incidencia
Tiempo promedio que se
tarda en responder
incidentes
Nmero total de incidentes
por fuente

% de los incidentes de
retraso
Nmero de incidentes
graves
% de los incidentes
repetidos
.

Descripcin
Tiempo promedio que se tarda entre el
registro de la incidencia y su cierre.
Tiempo promedio de tiempo (por ejemplo,
en minutos) entre la deteccin de un
incidente y la primera medida tomada para
reparar el incidente.
Nmero de incidentes que se originaron por
razones
de
telecomunicaciones,
la
infraestructura fsica, operacin, soporte,
seguimiento, los socios externos de
eventos, proveedores y otros
Nmero de incidentes de retraso (no se
cierra y no se resuelve dentro del plazo
establecido) en relacin con el nmero de
procedimientos abiertos (no cerrados)
incidentes.
-------------------------------------------------------Porcentaje de incidentes que pueden
clasificarse como un incidente de
repeticin, en relacin con todos los
incidentes reportados en el perodo de

72

Perspectiva
Tiempo

Tabla 32: Gestin de Incidencias

Indicador

Incidente tasa de cola

% de incidentes resueltos
dentro del plazo / destino

Costo promedio para

resolver un incidente
% de incidentes
incorrectamente asignados
Nmero de incidentes
cerrados en relacin con el
nmero de incidentes
abiertos
% de incidentes clasificados
incorrectamente

Descripcin
medicin.
Un incidente se repite si ya ha ocurrido
(varias veces) en el perodo de medicin
El nmero de casos cerrados, en relacin
con el nmero de casos abiertos en un
perodo de tiempo determinado.
Nmero de incidentes cerrados en el plazo
fijado durante la duracin del marco, en
relacin con el nmero de todos los
incidentes cerrados en un perodo de
tiempo determinado.
Un tiempo de duracin-marco se aplica a
cada incidente en el que se recibe, y
establece un lmite en la cantidad de tiempo
disponible para resolver el incidente.
El tiempo de duracin aplica-marco se
deriva de los acuerdos alcanzados con el
cliente sobre la resolucin de incidentes.
Los costes medios para resolver un
incidente se calculan a partir de los costos
fijos y variables del proceso de gestin del
incidente dividido por el nmero total de
incidentes recibidos en el perodo de
medicin.
--------------------------------------------------------

Perspectiva

Se valora la eficacia a la hora de resolver

incidentes
Un incidente puede ser clasificado como
prioridad alta, media y baja

II.2.1.2.1.3 Modelo Conceptual

A continuacin se crea un modelo conceptual a partir de los indicadores y perspectivas
obtenidos en los pasos anteriores.
Con este modelo conceptual lo que se pretende es dar una visin del alcance del
proyecto, aportando una alta definicin de datos lo que nos ayuda en la presentacin,
difusin y entendimiento de los mismos de cara a los usuarios.
De cada proceso analizado anteriormente, se ha creado cuatro mapas conceptuales 26.
A la izquierda se pueden ver las perspectivas que sern unidas a un valo central que
26

Se entiende por mapa conceptual a un mtodo para organizar, de forma sencilla, cualquier tipo de informacin,
ayudando a obtener una mejor comprensin e intercambio de la misma.

73

74

Chapter I

representa y lleva el nombre de la relacin que existe entre ellas. La relacin,

constituye el proceso o rea de estudio elegida. De dicha relacin y entrelazadas con
echas, se desprenden los indicadores, estos se ubican a la derecha del esquema.

Figura 29: Diagrama conceptual de ventas

Como puede apreciarse en la Figura 29 el modelo conceptual permite de un solo

vistazo y sin poseer demasiados conocimientos previos, comprender cules sern los
resultados que se obtendrn, cules son las variables que se utiliza para analizarlos y
la relacin que existe entre ellos.

74

Figura 30: Diagrama conceptual Finanzas

Figura 31: Diagrama conceptual Gestin de Proyectos

75

76

Chapter I

Figura 32: Diagrama conceptual Gestin de Proyectos

Figura 33: Diagrama conceptual Gestin de Incidencias

76

II.2.1.2.2

Fase 2: Anlisis de los OLTP

El siguiente paso consiste en analizar las fuentes OLTP para determinar cmo sern calculados
los indicadores y poder establecer las respectivas correspondencias entre el modelo conceptual
creado en el paso anterior y las fuentes de datos. Luego, se dene qu campos se incluirn en
cada perspectiva. Finalmente, se ampliar el modelo conceptual con la informacin obtenida en
este paso.

II.2.1.2.2.1 Conformar Indicadores

En este paso se debe indicar cmo calcular los indicadores definiendo las medidas que lo
componen y las funciones de sumarizacin que se utilizan para su agregacin.
En adiccin a la metodologa de Hefesto, se ha credo conveniente definir un valor objetivo que
ayude al usuario a entender si el valor del KPI es bueno o malo, es decir, que el indicador total
del ventas nos d un valor de 1000000 euros en el ao 2010 no nos dice nada, pero si
sabemos que en el ao 2009 las ventas fueron de 3000000, se puede concluir que en el ao
2011 el total de ventas ha bajado con respecto al anterior. Otro ejemplo es el caso de proponer
llegar a un total de ventas de 2000000 en el ao 2011 este sera el valor objetivo y nuestro
KPI a da 9 de septiembre de 2011. Si se lleva un total de 1000000, eso quiere decir que si se
quiere conseguir el objetivo antes del nuevo ao, quizs se deba hacer un cambio de estrategia
en las ventas para poder en tres meses llegar al objetivo.
Tabla 33: Indicadores
Gestin de Ventas
Gestin Financiera
Gestin de Proyectos
Gestin de Incidencias

Tabla 34: Conformar Indicadores. Gestin de Ventas

Indicadores

Variacin de
ventas

Medidas

Funcin de sumarizacin

Total de lnea (TL)

Descuento

pie

Valor Objetivo
Un aumento del 2%

de

con respecto al ao

documento (DPD)

anterior

77

78

Chapter I

Tabla 34: Conformar Indicadores. Gestin de Ventas

Indicadores

Medidas

Unidades de

Total de lnea (TL)

ventas

Descuento

Beneficio

Total
%

Funcin de sumarizacin

pie

Un aumento del 2%
de

con respecto al ao

documento (DPD)

anterior

Precio Venta Neto PVN

Un aumento del 2%

Coste

con respecto al ao

artculo

CA

Cantidad C

Variacin

del Beneficio

Valor Objetivo

anterior
Un aumento del 2%

Precio Venta Neto PVN

con respecto al ao

Coste artculo CA

anterior

Tanto para los indicadores de Direccin Financiera, Gestin de Proyectos y Gestin de

Incidencias, no se va representar su funcin de sumarizacin ya que como ya se coment
anteriormente, por motivos de tiempo no se llegaron a implementar.
Tabla 35: Conformar Indicadores. Grupos de
Indicadores de Finanzas
Ratios de liquidez
Ratios de endeudamiento o solvencia
Ratios de rentabilidad
Ratios de gestin u operativos

Tabla 36: Conformar indicadores Ratios de liquidez

Medida

Indicador

Ratios de liquidez severa o prueba acida

Activo Corriente
Pasivo Corriente

Ratios de liquidez severa o prueba cida

Activo Corriente
Existencias
Pasivo Corriente

Ratio de liquides absoluta o de efectividad o

Caja y banco

Prueba supercida

Pasivo Corriente

Capital de trabajo

Activo Corriente
Pasivo Corriente

78

Tabla 37: Conformar indicadores Ratios de endeudamiento o solvencia

Indicador

Medida

Ratio de endeudamiento a corto plazo

Pasivo Corriente
Patrimonio

Ratio de endeudamiento a largo plazo

Pasivo no Corriente
Patrimonio

Ratio de endeudamiento total

Pasivo Corriente
Pasivo no Corriente
Patrimonio

Ratio de endeudamiento de activo

Pasivo Corriente
Pasivo no Corriente
Activo Total

Tabla 38: Conformar indicadores Ratios de rentabilidad

Indicador

Medida

Ratio de rentabilidad de la inversin (ROA)

Utilidad neta
Activos
Utilidad neta

Ratio de rentabilidad del patrimonio (ROE)

Patrimonio
Utilidad Bruta

Ratio de rentabilidad bruta sobre ventas

Patrimonio
Utilidad Bruta

Ratio de rentabilidad neta sobre ventas

Ventas netas
Utilidad neta

Ratio de rentabilidad neta sobre ventas

Ventas netas
Utilidad neta

Ratio de rentabilidad por accin

Nmero de acciones
Dividendos

Ratio de dividendos por accin

Nmero de acciones

Tabla 39: Conformar indicadores Ratios de gestin u operativos

Indicador

Medida
Ventas al crdito

Ratio de rotacin de cobro

Cuentas por cobrar comerciales

Cuentas por cobrar comerciales

Ratio de periodo de cobro

Ventas al crdito

79

80

Chapter I

Tabla 39: Conformar indicadores Ratios de gestin u operativos

Indicador

Medida
Compras al crdito

Ratio de rotacin por pagar

Cuentas por pagar comerciales

Cuentas por pagar comerciales

Ratio de periodo de pagos

Compras al crdito
Ratio de rotacin de inventarios

Costo de ventas
Existencias

Tabla 40: Conformar Indicadores. Gestin de

proyectos
Gestin de la integracin del proyecto
Gestin del tiempo
Gestin de la calidad
Gestin de costos
Gestin de riesgos
Gestin de recursos humanos
Gestin de adquisicin

Tabla 41: Conformar Indicadores. Gestin de la integracin del proyecto

Indicador

Medida

% de tiempo dedicado a la coordinacin del

Tiempo de coordinacin

proyecto

Tiempo implementacin

Nmero de proyectos abiertos en relacin con

Proyectos cerrados

el nmero de proyectos cerrados

Proyectos abiertos

Nmero de hitos retrasados

Hitos retrasados

Tabla 42: Gestin del tiempo

Indicador

Medida

Desviacin del calendario previsto para el

Tiempo previsto

proyecto

Tiempo real

80

Tasa de tareas realizadas en los plazos

Trabajo terminado

deseados

Lnea base prevista

Tabla 43: Conformar Indicadores. Gestin de calidad

Indicador

Medida
Beneficios

Desviacin del retorno de la inversin prevista

Coste iniciales
Tareas terminadas

Porcentaje del proyecto terminado

Tareas incompletas

Tabla 44: Gestin de proyectos. Gestin de costo

Indicador

Medida
Presupuesto autorizado

Valor Ganado (EV)

Trabajo completado

Valor planificado (PV)

Presupuesto asignado a cada actividad

Costo real (AC)

Costo real de cada actividad

Valor Ganado

Variacin del cronograma (SV)

Valor Planificado
Valor Ganado

Variacin de costo (CV)

Costo Real
Valor Ganado

ndice de desempeo del cronograma (SPI)

Valor Planificado
Valor Ganado

ndice del desempeo del costo (CPI)

Costo real de la actividad

Costo real de la actividad
Estimacin para concluir el trabajo restante

Estimacin a la conclusin (EAC)

Presupuesto hasta la conclusin

ndice

de

Desempeo

del

Trabajo

Valor Ganado

por

Costo Real

Completar (TCPI)

Estimacin hasta la conclusin

Tabla 45: Gestin de proyectos. Gestin de riesgos
Indicador

Medida
Proyectos en riesgo

% de los proyectos que consideran de riesgo

Total de proyectos
Proyectos con cambios de alcance

% de los proyectos con cambios de alcance

Total de proyectos
Proyectos en control

% de los proyectos "en el control"

Total de proyectos

81

82

Chapter I

Promedio

del

nmero

de

modificaciones

Numero de modificaciones

realizadas al proyecto desde su definicin

Ciclo de vida del proyecto

% de los proyectos a tiempo y dentro del

Coste de todas las tareas

presupuesto

Calendario del proyecto

Tabla 46: Gestin de proyectos. Gestin de recursos humanos

Indicador

Medida

Promedio del nmero de personas asignadas

Empleados asignados a un proyecto

al proyecto

Total de empleados

Tabla 47: Gestin de proyectos. Gestin de adquisicin

Indicador

Medida
Tiempo de inicio de la solicitud

Requisicin de tiempo de emisin tema

Tiempo de fin de la solicitud

Tabla 48: Gestin de proyectos. Gestin de adquisicin

Indicador

Medida
Tiempo de resolucin

Tiempo en cerrar la incidencia

Tiempo de deteccin
Tiempo total en resolver todas las incidencias
Tiempo de deteccin

Tiempo promedio que se tarda en responder

Tiempo en el que se toma la primera medida

incidentes

Tiempo total que se tard en resolver tolas las

incidencias
Nmero de incidencias

Nmero total de incidentes por fuente

Fuente de inciden

% de incidente no resueltos dentro del plazo

Incidentes retrasados
Procedimientos abiertos

Nmero de incidentes graves

Incidentes graves

% de los incidentes repetidos

Incidentes repetidos

Total de incidentes

Nmero de casos cerrados

% de incidentes tratados en los tiempos

Nmero de casos abiertos

de respuestas acordados

Tiempo en resolver un incidente

82

Tabla 48: Gestin de proyectos. Gestin de adquisicin

Indicador

Medida
Costo fijos del incidentes

Costo promedio para resolver un incidente

Costos variables del proceso de gestin

Total de incidentes
Incidentes incorrectamente asignados

% de incidentes incorrectamente asignados

Incidentes asignados
Total de incidentes

Incidentes abiertos

% de incidentes mal clasificados

Incidentes mal clasificados

Nmero de incidentes cerrados en relacin con

Nmero de casos cerrados

el nmero de incidentes abiertos

Nmero de casos abiertos

83

84

Chapter I

II.2.1.2.2.2 Estudio de OLTP

En este punto se va a estudiar los OLTP disponibles que contengan la informacin
necesaria para poder establecer una correspondencias entre el modelo conceptual y
las fuentes de datos, y de esta manera crear el diagrama conceptual ampliado. La idea
es saber de dnde vamos a obtener los datos que vamos a explotar.
Este apartado ha sufrido una adaptacin con respecto a Hefesto, ya que este propone
hacer una correspondencia entre el OLTP y el diagrama conceptual ya creado. Lo que
se ha hecho es mostrar esta correspondencia directamente en el diagrama conceptual
ampliado, esto es debido a que en el ejemplo que propone Hefesto el esquema de la
base de datos es mucho ms sencillo que el que se realiz para ventas (Figura 34) y
se pueden apreciar las relaciones, pero en el caso que se abarca el resultado no sera
tan aclaratorio.
Para nuestro caso de estudio solo se dispones de una sola fuente de datos que es la
base de datos de que nos proporcion ITOP MC.

Figura 34: Esquema de la base de datos de Ventas

Se analizaron los campos residentes en cada tabla a la que hace referencia la Figura 34
anterior a travs de dos mtodos. Primero se examin la base de datos y el programa SAP BO

84

para hacernos una idea del significado de cada campo, y luego se consult con la encargada
del sistema las dudas que no se pudieron resolver con el mtodo anterior o las surgidas como
consecuencia del examen de la base de datos.
En la Tabla 49 se puede ver la correspondencia entre el modelo conceptual y el OLTP.
Tabla 49: Relacin entre el OLTP y el modelo conceptual
Tabla SAP

Perspectivas o Dimensiones

OITB

Producto

OITM

Familia

@ITOP_SUBF

Subfamilia

OMRC

Fabricantes

OCRD

Cliente

CRD1

Cliente | Direcciones de los clientes27

OTER

Cliente | Sector al que pertenece el Cliente

OOND

Cliente | Subsector al que pertenece el Cliente

OCRG

Cliente | Grupo al que pertenece el Cliente

OSLP

Empleado de ventas

OWHS

Unidad de Negocio | Almacn

OLCT

Sucursal

OINV

Tiempo, Total de ventas, Variacin Ventas, Beneficio, Variacin Beneficio

ORIN

Tiempo, Total de ventas, Variacin Ventas, Beneficio, Variacin Beneficio

OCRY

Geografa | Pas

OCST

Geografa

En la Figura 35 se ha ilustrado un ejemplo de cmo sera esta correspondencia con la tabla

CLIENTE de SAP BO.

Figura 35: Correspondencia entre el modelo conceptual y el OLTP

27 La nomenclatura X|Y intenta especificar que la X es la perspectiva que se est analizando y la Y una perspectiva
hija de X, como por ejemplo: Ao|Mes

85

86

Chapter I

Para crear el esquema de la base de datos de Gestin de Ventas se parte de una base de
datos ya existente; sin embargo, para crear la de Gestin de Proyectos e Incidencias se inicia
desde cero, aprecindose en la Figura 36 dicho esquema.

Figura 36: Esquema de la bases de datos de Gestin de Proyectos e Incidencias

II.2.1.2.2.3 Nivel de Granularidad

La seleccin de la granularidad implica decidir exactamente qu es lo que va a representar en
cada registro de la tabla de hechos. En el caso de estudio que se aborda, la granularidad de la
tabla de hechos de Ventas28 ser la correspondiente a las ventas en cada lnea de factura. La
28 La tabla hecho Ventas es la que contendr las medidas para crear posteriormente los indicadores

86

decisin sobre la granularidad de las tablas de hechos tambin determinar la granularidad de

cada una de las tablas de dimensin. Por ejemplo, si la granularidad de la tabla de hechos
Ventas es la de las ventas realizadas en cada lnea de factura, entonces la granularidad de la
dimensin producto ser los detalles del producto correspondiente a una lnea concreta. Para
que el lector entienda estos conceptos se ha definido la granularidad de la perspectiva
CLIENTE:
OCRD.- En esta tabla estn todos los clientes o Business Partners como los identifica SAP. De
esta tabla nos interesan los siguientes campos:

CardCode.- Es la clave primaria de la tabla y representa un cdigo nico para

identificar a los clientes.

CardType.- En SAP un cliente puede tomar tres roles, Cliente, Proveedor o un

cliente potencial.

ShipToCode.- En esta tabla solo se guardan aquella direccin que el cliente

elige como principal, donde quiere que se le envi la mercanca o la factura. La
direccin marcada como principal se le asocia un nombre para identificarla y es la que
se almacena en este campo.

MailAddres.- Es la calle del destinatario de la mercanca. Esta calle pertenece a

la direccin elegida por el cliente como principal.

MailCity.- Es la ciudad del destinatario de la mercanca. Esta ciudad pertenece

a la direccin elegida por el cliente como principal.

MailCount.- Es el municipio del destinatario de la mercanca. Este municipio

pertenece a la direccin elegida por el cliente como principal.

MailCounttr.- Es el pas del destinatario de la mercanca. Este pas pertenece a

la direccin elegida por el cliente como principal.

State2.- Es la provincia del destinatario de la mercanca. Esta provincia

pertenece a la direccin elegida por el cliente como principal.
CRD1.- Un cliente puede tener ms de una direccin, esto ocurre porque puede tener varias
tiendas. En esta tabla se almacena todas las direcciones del cliente.

CardCode.- Es la clave principal de la tabla y es el campo que vincula la tabla

CRD1 con la OCRD.

AdresType.- Indica si la direccin almacenada en esa fila hace referencia al

lugar donde se entrega la mercanca o por el contrario hacer referencia al lugar donde
se va a entregar.

Address.- Es el nombre de la direccin.

County.- Municipio al que pertenece el cliente.

Country.- Pas al que pertenece el cliente.

State.- Provincia a la que pertenece el cliente.

City.- Ciudad a la que pertenece el cliente.

U_Isla.- Isla a la que pertenece el cliente.

OTER.- Esta tabla almacena todos los territorios a los que pertenece un cliente.

TerritryID.- Es la clave primaria de la tabla e identifica unvocamente a un

territorio. Este campo relaciona la tabla OTER con la tabla OCRD.

87

88

Chapter I

Descript.- Es el Nombre del territorio.

OCRG.- Tabla que identifica el sector al que pertenece el cliente.

GroupCode.- Clave primaria que identifica unvocamente un sector. Este campo

relaciona la tabla OCRG con la tabla OCRD.

GroupType.- Tipo de sector.

GroupName.- Nombre del sector al que pertenece el cliente.

OOND.- Tabla que recoge los subsectores a los que pertenece un cliente.

IndName.- Nombre del subsector.

II.2.1.2.2.4 Modelo Conceptual Ampliado

En este paso se va a ampliar el modelo conceptual, esto va ayudar a tener una
referencia muy visual de que campos del OTLP conforman una perspectiva y cules
son los campos o medidas que se necesitan para crear el indicador. Con este fin se
adjunta debajo de cada perspectiva o dimensin los campos seleccionados y bajo
cada indicador su respectiva frmula de clculo.

Figura 37: Modelo conceptual ampliado Gestin de Ventas

88

II.2.1.2.3

Fase 3: Modelo Lgico del DW

Seguidamente, se disea el modelo lgico de la estructura del Data Warehouse,

teniendo como punto de apoyo el modelo conceptual que ya ha sido creado. Lo primero
que se debe hacer es definir el tipo de modelo que se utiliza, en segundo lugar hacer
un estudio de cmo se van a disear las tablas correspondientes a las dimensiones y
hechos. Por ltimo, se realiza las uniones oportunas entre dichas tablas.

II.2.1.2.3.1 Tipo de Modelo Lgico del DW

Es importante seleccionar el tipo de esquema que se utiliza para soportar la estructura
del Data Warehouse, que se adecue mejor a los requerimientos y necesidades de los
usuarios. Una decisin correcta entre un esquema en estrella, constelacin o copo de
nieve es importante ya que afecta considerablemente la elaboracin del modelo lgico.
En el caso de estudio se opt por un esquema en copo de nieve debido a que las
perspectivas o dimensin se van organizar jerrquicamente. Adems este tipo de
esquema nos da la posibilidad de segregar los datos de las tablas de dimensiones y
proveer un esquema que sustente los requerimientos de diseo, hace una mejor
utilizacin del espacio y, al estar normalizadas las tablas dimensiones, requiere menos
esfuerzos de diseo.

II.2.1.2.3.2 Tablas dimensiones

Las dimensiones establecen el contexto para realizar preguntas acerca de los hechos
contenidos en la tabla de hechos. Un conjunto bien construido de dimensiones hace
que el Data Warehouse sea comprensible y fcil de utilizar. Un conjunto de
dimensiones incompleto o que no se presente adecuadamente reducir la utilidad que
el Data Warehouse tiene para la organizacin. En este apartado se va a proceder a
disear las tablas dimensiones que forman parte del Data Warehouse.
Cada perspectiva definida en el mapa conceptual corresponde con una tabla
dimensin. Para el caso prctico que se est abordando se ha hecho lo siguiente:

Se elige un nombre que identifique la tabla dimensin

Se aade un campo que represente su clave principal
Se definen las jerarquas dentro de las dimensiones
Se redefinen los nombre de los campos si es que no son lo bastante intuitivo

Las jerarquas definidas que siguen las dimensiones se observa en la Figura 38.

89

90

Chapter I

Figura 38: Jerarqua dimensin

Al haber elegido un tipo de esquema en copo de nieve, aquellas tablas de dimensin

donde existen jerarquas, debern ser normalizadas. Se toma como ejemplo la
siguiente tabla dimensin y sus respectivas relaciones padre-hijo entre sus campos:

Figura 39: Jerarqua Dimensin Geografa

Entonces, al normalizar se obtiene las siguientes dimensiones (ver Figura 40, Figura 41, Figura
42, Figura 43, Figura 44, Figura 45 y Figura 46) para cada jerarqua de dimensin.

Figura 40: Dimensin Unidad de Negocio

90

Figura 41: Dimensin Tiempo

Figura 42: Dimensin Cliente

Figura 43: Dimensin Gestin de Ventas

Figura 44: Dimensin Canal

Figura 45: Dimensin Geografa

91

92

Chapter I

Figura 46: Dimensin Producto

II.2.1.2.3.3 Tablas de hechos

Seguidamente de van a definir las tablas de hechos, que son las que almacenan las
medidas a travs de las cuales se constituyen los indicadores de estudio.
Es importante destacar que las tablas de hechos deben contener solamente valores
numricos y aditivos, esto es debido a que en muy pocas oportunidades se harn
consultas por un solo registro de la tabla de hechos, lo comn es traer cientos o quizs
miles de registros a la vez, y en estos casos la nica cosa til por hacer es sumarlos.
En un esquema copo de nieve se deben realizar los siguientes pasos:

Se asigna un nombre a la tabla de hechos que represente la informacin

analizada, rea de investigacin, negocio enfocado. En el presente estudio es
la tabla de hechos de Ventas.
Se define su clave primaria, que se compone de la combinacin de las claves
primarias de cada tabla de dimensin relacionada.
Se crean tantos campos de hechos como medidas seleccionadas en el mapa
conceptual necesarias para crear los indicadores definidos en el modelo
conceptual y se les asigna un nombre representativo, siendo los siguientes:
Tabla 50: Conversin de nombres de los campos (medidas)
seleccionadas en el OLTP
Nombre del campo (medida) real

Nombre en la tabla hecho

Quantity

Cantidad

GrossBuyPr

Precio Coste

INVPrice

Precio de Venta

DiscPrcnt

DtoDocumento

LineTotal

LneaTotal

92

Figura 47: Esquema del diseo de la tabla de hechos

Una vez seleccionados los hechos, es necesario re-examinarlos para determinar si

existe la posibilidad de utilizar valores precalculados. Un ejemplo de la necesidad de
almacenar valores precalculados es el que surge en casos como el presente donde la
tabla de hecho est basada en facturacin o ventas. En el caso de estudio, se ha
aadido como hecho precalculado los que se observan en la Tabla 51.
Tabla 51: Hechos precalculados
Nombre en la tabla hecho

Frmula

PrecioCosteXCantidad

Cantidad * PrecioCoste

PrecioVentaXCantidad

Cantidad * PrecioVenta

TotalVentaLinea

LineaTotal ( (LineaTotal *DtoDocumento)/100)

La tabla de hechos resultante se muestra en la Figura 48.

Figura 48: Diseo de la tabla de Hechos de Venta

93

94

Chapter I

II.2.1.2.3.4 Uniones
A continuacin se hacen las uniones pertinentes entre las tablas dimensiones y el
hecho, observndose el resultado en la Figura 49.

Figura 49: Primera aproximacin al diseo lgico del Data Warehouse.

La Figura 49 muestra una primera aproximacion al diseo lgico del Data Warehouse y
es una primera aproximacin porque hubieron varias hasta conseguir un diseo que
se ajustar a los requerimientos exigidos. Un ejemplo claro est en la Dimensin
Unidad de Negocio, ya que cuando se hizo la carga de los datos resulta que el cliente
no realiza distincion entre Sucursal y Delegacin, por lo tanto, se decide eliminar la
Delegacion y solo almacenar la Sucursal a la que pertenece el cliente. Este cambio se
puede apreciar en la Tabla 52. Otro ejemplo se aprecia en la Tabla 53, con respecto la
dimensin geografa, finalmente solo se almacena el Pais y la Provincia del cliente
debido a que en la base de datos SAP los campos Isla estaban vacos, y tanto el
campo municipio como ciudad eran campos que se rellenaban por los usuarios, lo que
significa que se encontraban casos de no-normalizada informacin al tener, por
ejemplo, S/C de Tenerife escrito de 3 formas distintas S/C de Tenerife, Santa Cruz de
Tenerife, Sta. Cruz de Tenerife aunque exista la solucin de imputacin de datos.
Finalmente se opta por almacenar solo el pais y la provincia.
La Figura 50 muestra el esquema lgico del Data Warehouse final.

94

Tabla 52: Comparacin Dimensiones Unidad de Negocio

Primera aproximacin

ResultadoFinal

Tabla 53: Comparacin Geografa

Primera aproximacin

ResultadoFinal

Figura 50: Esquema lgico del Data Warehouse

95

96

Chapter I

II.2.1.2.4

Fase 4: Integracin de datos

Una vez construido el modelo lgico, se debe proceder a poblarlo con datos, utilizando
tcnicas de extraccin, transformacin y carga (ETL). Posteriormente se procede a
definir las reglas y polticas para su respectiva actualizacin, as como tambin los
procesos que se lleven a cabo.

II.2.1.2.4.1 Extraccin
Es aqu donde, basndose en las necesidades y requisitos de los usuarios, se exploran
las diversas fuentes OLTP que se tengan a disposicin y se extrae la informacin que
se considere relevante al caso.
Si los datos operacionales residen en un SGBD Relacional, el proceso de extraccin se
puede reducir a, por ejemplo, consultas en SQL o rutinas programadas. En cambio, si
se encuentran en un sistema no convencional o fuentes externas nos encontramos con
el inconveniente de que cada sistema separado puede usar una organizacin diferente
de los datos o formatos distintos. La extraccin convierte los datos a un formato
preparado para iniciar el proceso de transformacin.
Una vez que los datos son seleccionados y extrados, se guardan en un
almacenamiento intermedio, de esta manera se podrn manipular los datos sin
interrumpir ni paralizar los procesos del OLTP, ni tampoco el DW.
Un requerimiento importante que se debe exigir a la tarea de extraccin es que sta
cause un impacto mnimo en el sistema origen. Si los datos a extraer son muchos, el
sistema de origen se podra ralentizar e incluso colapsar, provocando que ste no
pueda utilizarse con normalidad para su uso cotidiano. Por esta razn, en sistemas
grandes las operaciones de extraccin suelen programarse en horarios o das donde
este impacto sea nulo o mnimo. A efectos de nuestro caso de estudio los datos residen
en un solo SGBD con lo cual este proceso result bastante sencillo.
En la Figura 51 se puede ver un ejemplo muy simple de extraccin y carga de datos en
un Data Warehouse. En SAP la tabla OCRY contiene la informacin referente a Pases,
extrayndolos a travs de una consulta SQL ver Figura 52 y almacenndola en la
subdimensin Pas (SdPas) en el Data Warehouse.

Figura 51: Ejemplo de extraccin con SSIS

96

Figura 52: Consulta a la base de datos de SAP para extraer los pases almacenados en la tabla OCRY

II.2.1.2.4.2 Transformacin
La fase de transformacin aplica una serie de reglas de negocio o funciones sobre los
datos extrados para convertirlos en datos que sern cargados. Algunas fuentes de
datos requerirn alguna pequea manipulacin de los mismos. Los casos ms
comunes en los que se debe realizar integracin, son los siguientes:

Codicacin

Medida de atributos.

Convenciones de nombramiento.

Fuentes mltiples.

Los procesos de Limpieza de Datos (Data Cleanning) y Calidad de

Datos.
Hay que evitar que el DW sea cargado con valores faltantes o anmalos, al igual que
tambin se deben establecer condiciones y restricciones para asegurar que solo se
utilicen los datos de inters.
Para el caso de estudio, slo se tuvo que centrar en el ltimo punto Procesos de
Limpieza de Datos debido a que se parte de una nica fuente de datos. Se llevaron a
cabo los siguientes procesos de limpieza de datos, como muestra la Tabla 54.
Tabla 54: Transformaciones llevadas a cabo en el proceso ETL
Acciones

Descripcin

Valores nulos

Hubo la obligacin de renombrarlos como Sin valor, debido a que el cliente quiso
contemplar ciertas perspectivas de anlisis para las cuales no almacenaba valores.
Se tom esta decisin en vez de omitirlos para que el cliente, al comprobar los
resultados, pudiera corregir el error y rellenar los campos que son objeto de inters
para su anlisis y as poder llevar a cabo su objetivo.

Codificar

Aquellos campos cuyo contenido no posea una descripcin lo suficientemente

valores

significativa se sustituy por una que si lo fuese, como fue el caso del tipo de
interlocutor comercial que posee SAP. Este campo en la base de datos original
puede tomar los siguientes valores: C, S, L y, como se puede observar, no aportan

97

98

Chapter I

Tabla 54: Transformaciones llevadas a cabo en el proceso ETL

Acciones

Descripcin
significado alguno, sustituyndolos por Cliente, Proveedor y Leads.

Conversin tipo

Se realizaron las conversiones de tipo de dato oportunas para poder almacenar los
datos en el Data Warehouse

Calcular totales
de

mltiples

filas de datos

Se cre un nuevo campo TotalVentaLinea a partir de LineTotal y DiscPrcnt.

Se cre un nuevo campo PrecioCosteXCantidad a partir de Cantidad y PrecioCoste
Se cre un nuevo campo PrecioVentaXCantidad a partir de Cantidad y PrecioVenta

En la Figura 53 se puede ver una serie de transformaciones antes de cargar los datos
en el Data Warehouse. En SAP, la tabla OSLP almacena la informacin referente a los
empleados, pero hay campos como es el campo memo donde se guarda el
departamento al que pertenece dicho empleado, que permite valores nulos. En la
Figura 54 se puede observar como se ha programado la caja Valores nulos para
sustituirlos por la cadena SinValor.

Figura 53: Transformacin de valores nulos de la tabla OSLP de SAP

98

Figura 54: Sustitucin de nulos por la cadena Sin Valor del campo memo perteneciente a la tabla OSLP de SAP

II.2.1.2.4.3 Carga
Esta funcin se encarga, por un lado de realizar las tareas relacionadas con:
Carga Inicial
Actualizacin o mantenimiento peridico
La carga inicial, se reere precisamente a la primera carga de datos que se realiza al
Almacn de Datos. Por lo general, esta tarea consume un tiempo bastante
considerable, ya que se deben insertar registros que han sido generados
aproximadamente y, en casos ideales, durante ms de cinco aos.
En el momento de realizarla, primero se cargan los datos de las dimensiones y luego
las tablas de hechos, teniendo en cuenta siempre, la correcta correspondencia entre
cada elemento. En el caso en que se est utilizando un esquema copo de nieve, cada
vez que existan jerarquas de dimensiones, se comienza cargando las tablas de
dimensiones del nivel ms general al ms detallado.

99

100

Chapter I

Figura 55: Carga del almacn de datos

Antes de realizar una nueva actualizacin, es necesario identicar si se han producido

cambios en las fuentes originales de los datos recogidos, desde la fecha del ltimo
mantenimiento, a n de no atentar contra la consistencia del DW. Para efectuar esta
operacin, se pueden realizar las siguientes acciones:

Cotejar las instancias de los OLTP involucrados.

Utilizar disparadores en los OLTP.

Recurrir a Marcas de Tiempo o Time Stamp en los registros de los OLTP.

Comparar los datos existentes en los dos ambientes (OLTP y DW).

Hacer uso de tcnicas mixtas.

Las polticas de actualizacin que ha convenido con los usuarios son los siguientes:

La informacin se actualiza cada viernes por la noche, esto es as debido a que

cada lunes el cliente necesita saber cmo fueron sus ventas la semana pasada
y, en el caso de que fuera necesario, qu acciones correctivas debe aplicar.

Las dimensiones son todas lentamente cambiantes de Tipo1, cuando un

registro presente un cambio en alguno de los valores de sus campos, se debe
proceder simplemente a actualizar el dato en cuestin, sobrescribiendo el
antiguo, excepto la dimensin cliente que es de Tipo2 lo que requiere que se
agreguen algunas columnas adicionales a la tabla de dimensin, para que
almacenen el historial de cambios.

Los datos de la tabla dimensin tiempo se cargan de manera incremental

teniendo en cuenta la fecha de la ltima actualizacin.

II.2.1.2.5

Fase 5: Creacin de Cubos Multidimensionales

100

Los cubos multidimensionales son una representacin del Data Warehouse, este
representa o convierte los datos planos que se encuentran en filas y columnas, en una
matriz de N dimensiones. Los objetos ms importantes que se pueden incluir en un
cubo multidimensional, son los indicadores, atributos y jerarquas. En nuestro caso de
estudio se crea el cubo de Ventas como se puede ver en la Figura 56.

Figura 56: Cubo de Ventas

Como se puede observar en la Figura 57 se ha resaltado en un cuadrado de color rojo

unos valores denominados miembros calculados que pertenecen a una dimensin o un
grupo de medida que se definen segn una combinacin de datos del cubo,
operadores aritmticos, nmeros y funciones. Las definiciones de miembros calculados
se almacenan en cubos pero sus valores se calculan en el momento de la consulta.
Estos miembros nos van a facilitar crear los KPI de Beneficio total, Variacin de Ventas
y Variacin del Beneficio donde la Tabla 55 ayuda a aclarar estos conceptos.
Tabla 55: Miembro calculado con su frmula y la relacin con el clculo de KPI
Nombre Miembro

Calculo KPI

Measure.Beneficio

Calculo Miembro
PrecioVentaXCantidad

[(PrecioCosteXCantidad*100)/
PrecioVentaXCantidad]

Es una sumarizacin
Measure.Beneficio

de

Measure.Variacion

MeasureBeneficio

Es

de

periodo

101

una

sumarizacin

102

Chapter I

Beneficio

actual
/
MeasureBeneficio
periodo anterior

Measure.VariacinBeneficio

Measure.Variacion
Ventas

Measure.VariacionVentas
periodo
actual
Measure.VariacionVentas
periodo anterior

Es una sumarizacin de
Measure.VariacionVentas

II.2.1.2.6 Fase 6 Implementacin: Sql Server 2008 R2 Integration

Services
Microsoft Integration Services es una plataforma para la creacin de soluciones
empresariales de transformaciones de datos e integracin de datos. Integration
Services sirve para resolver complejos problemas empresariales mediante la copia o
descarga de archivos, el envo de mensajes de correo electrnico como respuesta a
eventos, la actualizacin de almacenamiento de datos, la limpieza y Minera de Datos y
la administracin de objetos y datos de SQL Server.
Integration Services puede extraer y transformar datos de muchos orgenes distintos,
como archivos XML, archivos planos y orgenes de datos relacionales, y,
posteriormente, cargarlos en uno o varios destinos. Las herramientas grficas de
Integration Services se pueden usar para crear soluciones sin escribir una sola lnea de
cdigo.
En los procesos ETL en estudio, se utiliza Integration Services para extraer los datos
de orgenes. Se transforman, limpian y se almacenan, posiblemente en un rea
intermedia, y finalmente en el Data Warehouse, siendo ambas bases de datos
relacionales, alimentadas con datos de los orgenes citados anteriormente. Tambin se
realiza tareas de procesamiento peridico de los cubos de Analisys Services, los cuales
tendrn como origen de datos el Data Warehouse.

Figura 57: Integration Services

102

Por ltimo, destacar que este tipo de herramientas son muy potentes. Los desarrollos
son muy rpidos y permiten crear una gran cantidad de procesos en reducidos periodo
de tiempo de desarrollo e implementacin. Es una herramienta muy intuitiva y muy fcil
de usar. Pero utilizarla sin un previo diseo puede hacer que su potencialidad y
rendimiento disminuya.
Integration Services es un servicio independiente que se instala y ejecuta en un
servidor, y ser el encargado de almacenar y ejecutar los diversos procesos que se
hayan definidos. Estos procesos se almacenan en unos archivos XML que contienen
toda la informacin de ese proceso y que se llaman paquetes.
En la Tabla 56 se enumeran una serie de caractersticas destacables del producto.
Tabla 56: Caractersticas del Integration Services
Permite la integracin con Sistemas de Bases de Datos y con ficheros
Obtiene un alto rendimiento al mantener los datos en memoria, adems permite concurrencia y
paralelismo
Permite gestionar alertas y notificaciones
Tiene tareas de data profiling, limpieza y minera de texto y datos
Desde el punto de vista del desarrollador, dispone de un entorno de desarrollo con el que se
sentir muy familiarizado.

Como principales inconvenientes indican los que figuran en la Tabla 57.

Tabla 57: Inconvenientes del Integration Services
Falta de documentacin que explique en detalle la herramienta, es decir, que abarque problemas
reales y no solamente los ideales.
La necesidad de contar con una tecnologa con altos requisitos.
Poca informacin de cmo optimizar el ETL, es decir, que componentes se deben usar solo en
caso necesario porque ralentizan el proceso, o como sustituirlos por otros.

A continuacin la Figura 58 muestra la ejecucin del Integration Services: las cajas,

marcadas con color verde, indican que ya han sido ejecutadas y han tenido xito, las
amarrillas estn en ejecucin y las blancas estn a las espera. En caso de que durante
el proceso falle alguna caja cambiar el color de amarillo a rojo y terminar la
ejecucin.

103

104

Chapter I

Figura 58: Ejecucin del SSIS

Como se puede ver en la Tabla 59 se han medido los tiempos de ejecucin del proceso
ETL con el programa Interation Services y que ha sido ejecutado con dos mquinas
diferentes la Tabla 58 muestra las caractersticas de cada mquina.
Tabla 58: Caracterstica de las mquinas donde se ejecut el ETL
Mquina A

Mquina B

Tabla 59: Estadsticas de ejecucin

Ejecucin ETL

Tiempo mquina A

Tiempo mquina B

00:02:18.575

00:31:02:04

Una vez poblado el almacn de datos ocup 46MB y contiene la informacin referente
a 4 aos, al realizar actualizaciones semanales se estima que pueda crecer un 0,2%
semanal, por lo tanto es importante el lugar fsico donde se almacene y que cuente con
escalabilidad.

II.2.1.2.7

Fase 7 Implementacin del Modelo lgico del DW SQL SAS

Microsoft, incluye Analysis Services como un componente de SQL Server, que va a

permitir cubrir una serie de necesidades que tienen los usuarios de negocio a la hora
de obtener informacin de nuestros sistemas. Se ha sintetizado dichas necesidades en
la Tabla 60.
Tabla 60: Necesidades cubiertas por SSAS

104

Consultas ad-hoc

Esto implica que el sistema permite al usuario personalizar una consulta en

tiempo real, en vez de estar atado a las consultas prediseadas para informes.
Generalmente las consultas ad hoc permiten a los usuarios con poca
experiencia en SQL tener el mismo acceso a la informacin de la base de
datos, para esto los sistemas que soportan ad hoc poseen GUIs para
generarlas.

Autoservicio

de

informes
Fuente

Permite a los usuarios realizar sus propios informes

de

Se debe ofrecer al usuario una informacin limpia, amigable, elaborada y

informacin de gran

confiable, que le permita obtener informacin analtica para reflejarla en sus

calidad

informes

Tiempo de respuesta

Las consultas ad-hoc como los informes deben tener un tiempo de respuesta

rpidos

rpido

Minera de datos

Segmentar o hacer predicciones en base a grandes volmenes de datos

La caracterstica de datos multidimensionales de Microsoft SQL Server Analysis

Services le permite disear, crear y administrar estructuras multidimensionales que
contienen detalles y datos agregados de numerosos orgenes de datos, como bases de
datos relacionales, en un nico modelo lgico unificado compatible con clculos
integrados.
Los datos multidimensionales de Analysis Services proporcionan un anlisis rpido,
intuitivo y descendente de grandes cantidades de datos basado en este modelo de
datos unificado, que puede llegar a los usuarios en mltiples idiomas y monedas. Esta
caracterstica funciona con Data Warehouse, Data Marts, bases de datos de
produccin y almacenes de datos operativos, y es compatible con el anlisis de datos
histricos y en tiempo real.
La Tabla 61 describe las caractersticas clave de Analysis Services.
Tabla 61: Ventajas Analisys Services
Facilidad de uso
Extensa interfaz de usuario con asistentes
Modelo flexible de datos y eficaz para la definicin y almacenamiento de cubos
Escalabilidad Arquitectura proporciona una gran variedad de escenarios de almacenamiento y
una solucin automatizada para el sndrome de explosin de datos que existe en las tecnologas
OLAP tradicionales.
Integracin de herramientas de administracin, seguridad, orgenes de datos y cach de clienteservidor.
API ampliamente compatibles y arquitectura abierta
Compatibilidad con aplicaciones personalizadas

Los principales inconvenientes de dicha tecnologa se muestran en la Tabla 62.

105

106

Chapter I

Tabla 62: Inconvenientes Analisys Services

Resulta muy difcil cruzar datos de varios Cubos Olap
Dificultad a la hora de explotar la informacin cuando no usamos Microsoft Excel
Falta de documentacin que explique en detalle la herramienta, es decir, que abarque problemas
reales y no solamente los ideales.

La Figura 59 muestra una consulta sobre el Total de Ventas que han ocurrido desde
que se cre la empresa.

Figura 59: Consulta sobre el Total de Ventas al cubo

El cubo ocupa 23.74MB en almacenamiento fsico, recordando que esto se realiza en

un vector multidimensional, ver apartado Data Warehouse Manager, al igual que en el
almacn de datos se deben tomar medidas de escalabilidad para prevenir posibles
problemas futuros de almacenamiento.

II.2.1.2.8

Representacin

En este punto se va a estudiar como representar la informacin que se quiere analizar.

Para ello se van a usar dos herramientas: una de generacin de informes y otra para la
creacin de cuadros de mando.

106

En este proyecto no se lleg a generar informes debido a que no dio tiempo y el cliente
estaba ms interesado en la creacin de cuadros de mando, aun as, se estudia dos
herramientas para la generacin de informes.

II.2.1.2.8.1 Creacin de informes

A la hora de crear informes se estudiaron dos herramientas: Reporting Services y
Microsoft Excel.
Reporting Services (SSRS).- Es una plataforma de creacin de informes
basada en servidos que ofrece una completa funcionalidad de creacin de informes
para una gran variedad de orgenes de datos. Reporting Services contiene un
completo conjunto de herramientas para crear, administrar y entregar informes, as
como interfaces de programacin de aplicaciones con las que los desarrolladores
pueden integrar o extender el procesamiento de los datos y los informes en
aplicaciones personalizadas.
En la Figura 60 se muestra un informe generado con dicha herramienta.

Figura 60: Informe generado con Reporting Services

Microsoft Excel 2007 y 2010. Viene con la posibilidad de generar informes

dinmicos, partiendo de tablas dinmicas que no son ms que consultas a un cubo
OLAP. Esta conexin con el cubo generado por el Analysis Services va a permitir
realizar una gran variedad de consultas al sistema. Con un informe de tabla dinmica
puede resumir, analizar, explorar y presentar un resumen de los datos de la hoja de
clculo o un origen de datos externos. Este tipo de informe es especialmente til
cuando tiene una larga lista de cifras para sumar y los datos agregados o subtotales

107

108

Chapter I

podran servir para mirar los datos desde perspectivas diferentes y comparar las cifras
de datos similares. A continuacin en la Figura 61 se puede ver un informe de tabla
dinmica generado en Excel.

Figura 61: Informe generado con Microsoft Excel

Como se ha comentado, no se genera ningn informe con dicha herramientas, pero si

se hizo una labor de investigacin, donde las conclusiones se reflejan en la Tabla 63.
Tabla 63: Comparacin Reporting Services vs Excel
Reporting Services

Microsoft Excel
En los esquemas permite hasta 7 niveles de
anidamiento
Ms fcil de usar. Muy intuitivo
Si el elemento de informe que controla si la
visualizacin de otro elemento va activarse o
desactivarse no est en la fila o en la columna
anterior o siguiente al elemento controlado, el
esquema tambin se deshabilita.
Procesa millones de filas con casi el mismo
rendimiento que mil filas

Informes ms elaborados con un aspecto visual

muy atractivo
Crear aplicaciones que se incrusten o vinculen
a

un

explorador

Web

para

presentar

manipular el informe mediante direcciones URL.

Crear otras extensiones para el procesamiento,
entrega y procesamiento de datos mediante
Microsoft .NET Framework
Crear aplicaciones para administrar uno o
varios servidores de informes mediante la
interfaz de servicios Web.
Otra

de

las

grandes

caractersticas

de

Reporting Services, es que puede distribuir el

reporte en distintos formatos, como hojas de

108

Excel, documentos PDF, texto, XML, etc.

II.2.1.2.8.2 Creacin de cuadros de mando

A la hora de llevar a cabo el desarrollo de un cuadro de mando integral para la solucin
de BI, se han analizado 4 herramientas:
1. Crystal Xcelsius 2008 (SAP Business Objects)
2. Microsoft Performance Point
3. Silverlight 4.0
4. Microsoft Office Excel 2007

Crystal Xcelsius 2008

Es un software especfico para la implementacin de cuadros de mando. A travs de
una interfaz grfica sencilla permite convertir las hojas de clculo Excel en cuadros de
mando interactivos basados en la tecnologa Adobe Flash. Por iniciativa de la empresa
se lleg a implementar un cuadro de mandos como se puede ver en la Figura 62.

Figura 62: Cuadro de mando implementado en Xcelsius

Finalmente se descart el uso de esta herramienta por las siguientes razones:

El coste de la licencia

Se observa bastante lentitud del software e incomodidad a la hora de trabajar con

las tablas de Excel incrustadas en el programa

109

110

Chapter I

Fallos en la importacin de los datos desde hojas Excel externas

Imposibilidad de alimentar los grficos directamente con consultas en MDX directas

contra la base de datos analtica, con el fin de integrar el cuadro de mando en una
plataforma web y no como un informe dinmico

Microsoft Performance Point

Performance Point es un servicio, de Microsoft SharePoint 2010, de administracin,
supervisin y anlisis empresarial. Cuenta con herramientas para la creacin de
paneles o Dashboards, cuadros de mando o Scorecards, informes e indicadores de
rendimiento KPIs. Se ha descartado tambin el uso de esta solucin por las siguientes
razones:

Coste de las licencias

Aumento de tiempos en el desarrollo ya que conlleva la implantacin de una

plataforma de SharePoint

Microsoft Silverlight 4.0

Silverlight 4.0 es un complemento gratuito para los navegadores de Internet basado en
la plataforma Windows que agrega nuevas funciones multimedia como la reproduccin
de vdeos, grficos vectoriales, animaciones,.. de forma similar a lo que hace Adobe
Flash. Para programar aplicaciones en esta tecnologa se hace uso del IDE Visual
Studio 2010. Pero el tiempo de desarrollo y preparacin necesario para la
implementacin de un cuadro de mando desde cero, hicieron que se descartara el uso
de la misma.
Microsoft Office Excel 2007
Para llevar a cabo el desarrollo de los se ha decido elegir el programa de Microsoft
Office Excel 2007 por las siguientes razones:

Debido a su sencillez e interfaz de conexin bien definida con los cubos de

SSAS

Por su potencia y gran usabilidad en el mundo empresarial

La curva de desarrollo y aprendizaje respecto a otras soluciones, disminuye

considerablemente permitiendo cumplir los plazos del proyecto

Una vez seleccionada la herramienta para implementar el cuadro de mandos se hizo

un estudio previo de cul era la mejor la representacin, para mostrar los indicadores

110

analizados. Para ello se ha seguido una serie de pautas recomendadas por

Stephen Few 29 con el fin de trasmitir la informacin de forma eficaz, siendo:

Se ha prestado especial atencin en los colores utilizados para el diseo del

cuadro de mandos, debido a que el 10% de los hombres y 1% de mujeres son
daltnicos, siendo una de las prcticas ms habituales la representacin de
medidas de alertas a travs de los colores rojo, amarillo y verde, pudiendo llevar a
las personas que sufren este sndrome a la toma de decisiones empresariales
equivocadas.

Figura 63: percepcin de los colores rojo, verde, amarillo por parte de las personas daltnicas

Por lo que se decidi utilizar colores que puedan permitir diferenciar tonalidades por
parte de las personas daltnicas o el uso tipo de grfico donde se resalte la tendencia
positiva o negativa como se ve en la Figura 64.

Figura 64: se observa las representaciones adaptadas para personas daltnicas

Por otro lado se ha hecho una seleccin de todos aquellos grficos que se adaptan
mejor, para la representacin de informacin de negocio atendiendo a los
siguientes criterios:

1. Grfico de bala: Este grafico fue diseado por Stephen Few, creado
especficamente para ser representado en cuadros de mando. Permite de
forma rpida, eficaz y ocupando muy poco espacio identificar si el indicador
que se quiere medir es bueno o malo dentro de un determinado contexto. Este
grfico no se ha llegado a utilizar debido a que no vena como grafico nativo en
Excel 2007, pero se considera que es un buen grafico a tomar en cuenta. En
la Figura 65 tenemos un ejemplo de grfico de vieta

Figura 65: Ejemplo de grfico de bala

29 Stephen Few tiene ms de 20 aos trabajando como innovador en el mudo del IT, como educador y consultor. Ha
centrado sus estudios en la visualizacin para el anlisis de los datos y en la comunicacin de informacin de negocio.

111

112

Chapter I
2. Grfico de barras: Los grficos de barra se han seleccionado ya que permiten
la comparacin de las medidas representadas, as como la rpida localizacin
de los datos ms significativos al estar ordenados. Adems son el tipo de
grfico que predomina en Excel 2007
3. Grfico de pila: Es una variacin al grfico de barras y es recomendable para
una nica serie dividida en diferentes partes.
4. Grfico de lnea: Ideal para la representacin de tendencias, fluctuaciones y
ciclos a lo largo del tiempo, as como un conjunto de datos vara en relacin a
otro.
5. SparkLines: Este grafico es idntico a uno de lnea pero en cambio se
representa sin etiquetado ni escala, normalmente al lado de un indicador con el
fin de representar la tendencia que ha seguido a travs de un periodo de
tiempo.

Tabla 64: Ejemplo de grfico Sparklines

6. Tabla: En una tabla simple muchas veces se puede representar la misma

informacin que en un grfico complejo y ocupando mucho menos espacio.

Se estudi cada uno de los indicadores y se realiz una clasificacin atendiendo a los
criterios antes mencionados.
Tabla 65: Indicadores y su representacin grafica
Indicadores

Tipo de Grafico que se adapta mejor

Grfico de Bala (H - V)

Total de ventas

Grfico de Barras (H - V)
Grfico de Lneas
SparkLines

Variacin de ventas

Grfico de Bala (H - V)
Grfico de Lneas
Grfico de Bala (H - V)

Beneficio

SparkLines
Grfico de Barras (H - V)

Variacin de Beneficio

Grfico de Bala (H - V)
Grfico de Lneas

El cuadro de mandos de Total de Ventas que se ha obtenido al final se muestra en la

Figura 66 y Figura 67.

112

Figura 66: Cuadro de mando de Total de Ventas

Figura 67: Cuadro de mando de Total de Ventas

La Figura 68 y Figura 69 muestra cuadro de mandos de Beneficio.

113

114

Chapter I

Figura 68: Cuadro de mando de Beneficio

Figura 69: Cuadro de mando de Beneficio

114

Captulo 3. Anlisis de los resultados

Resumen:
Anlisis de los resultados obtenidos mediante los cuadros de mandos elaborados

3.1

Resultados

El resultado final de este proyecto queda resumido en los cuatro cuadros de mandos que se
implementaron, de esta manera se proporciona a los gerentes de una compaa una mirada
global de las prestaciones del negocio, con una sola ojeada se podr saber cmo va la
empresa y en qu puntos de la misma se deben emprender medidas correctivas. Permite tanto
guiar el desempeo actual como apuntar al desempeo futuro.

Si analizamos uno de los cuadros de mando que se crearon para Total de Ventas se puede
deducir diversas conclusiones, observando de nuevo la Figura 70.

Figura 70: Cuadro de mando Total de Ventas

En la primera grfica titulada Total de ventas se comparan las ventas de los aos 2008, 2009
y 2010. Se puede observar que el ao donde hubo una mayor cantidad de ventas fue en 2009.
Hay que aclarar que este cliente creo su empresa en el ao 2008 y el 29 de Septiembre de ese
mismo ao fue cuando comenz a emitir facturas, por tanto es comprensible que desde Enero
a Septiembre exista esa diferencia de ventas del ao 2008 con respecto al 2009; en cambio,
los meses de Octubre, Noviembre y Diciembre ms o menos son similares.

115

116

Chapter I

En el ao 2010 las ventas disminuyeron notablemente, sobre todo los meses de Julio a
Diciembre. Se averiguo que en esos meses hubo problemas tcnicos con el programa de
facturacin y no se recogieron datos.
La empresa se fij como objetivo superar las ventas del ao anterior un 2%, dando por sentado
que en el ao 2008, como se acaba de crear, no se pudo comparar.
En el ao 2009, si se observa la Figura 70 la grfica con ttulo Objetivos 2009 indica como de
Enero a Septiembre se alcanza este objetivo, aunque este hecho no es representativo pues en
esos meses del 2008 la empresa aun no tena ventas. En cambio s podemos evaluar este
valor objetivo en los meses de Octubre, Noviembre y Diciembre donde se ve que es en
Noviembre del ao 2009 donde supera ese 2% de objetivo con respecto al ao anterior.
En el grfico Objetivos 2010 de la Figura 70 se puede observar como en los meses de Enero
a Junio se mantiene y, en menor o mayor medida, se cumplen los objetivos. Despus del mes
de Junio, las ventas en el ao 2010 bajan por la razn que ya se ha comentado y se hace
imposible alcanzar el objetivo fijado.
En la Figura 71 se observa el cuadro de mando de Total de Ventas pero ahora se analizan las
ventas por distintas dimensiones en el ao 2009.

Figura 71: Cuadro de mando de Total de Ventas

En la Figura 71 en el grfico Total de ventas por familia de productos, se puede observar cual
es la familia de productos que ms ha vendido, familia Productos cocidos y la que menos es
la familia de Productos mayoristas. Este anlisis es interesante porque quizs se debera
indagar en por qu los Productos mayoristas son unos de los menos vendidos ya que puede

116

interesar realizar una campaa de marketing para promocionarlos o simplemente dejar de

comercializarlos ya que no son rentables.
Si nos centramos ahora en el grafico Total de ventas por provincia de la Figura 71, indica que
la provincia donde ha habido un mayor nmero de ventas es la provincia Sin Valor,
Qu ha ocurrido? Ha habido un error en el grfico?
La respuesta es NO. Lo que ha pasado es que el usuario no ha rellenado en un gran nmero
de facturas del campo provincia del cliente, por tanto este caso sirve de referencia para que el
gerente, que vaya a analizar este grfico, tome medidas para que se recojan estos valores en
el momento de la facturacin, si es que le interesa estudiar el Total de ventas por provincia

117

118

Chapter I

Parte III.

118

Conclusiones, Final

Captulo 1. Conclusiones y posibles

ampliaciones
Inicialmente, el propsito de este proyecto era implantar una solucin BI integrada con
SAP BO que contemplara los procesos de Gestin de Ventas, Gestin de Finanzas,
Gestin de proyectos y Gestin de Incidencias. Sin embargo, solo se lleg a finalizar
para la Gestin de Ventas ya que el objetivo inicial quizs era muy ambicioso y el
tiempo limitado.
Se plante, por tanto, realizar un estudio del arte inicial y una elaboracin de una
metodologa para el desarrollo de una solucin BI.
Este proceso condujo a la consecucin de los siguientes logros.

Estudio del Arte

Se realiz una labor bastante importante de consultora para el estudio y anlisis del
proyecto. Desatancando tres puntos muy importantes:

Estudio de aplicaciones existentes en el mercado y demanda de mercado

respecto a funcionalidades.
Tecnologas destacadas en el sector de BI
Demanda de mercado de soluciones BI

Entendemos que sta es una de las partes ms importantes y duras del proyecto, ya
que de aqu se construye la base de todas las funcionalidades y desarrollo del mismo.

Anlisis y obtencin de requisitos funcionales

Una vez realizado el anlisis del estado del arte se obtienen una serie de requisitos
funcionales con ITOP MC y los miembros del equipo de trabajo, con el fin de satisfacer
la necesidad planteada en el proyecto.
Tras evaluar los requisitos obtenidos se pasa a desarrollarlos mediante la metodologa
de desarrollo gil SCRUM, obteniendo el Product Backlog del proyecto priorizndolo.
La dinmica de trabajo con esta metodologa ha sido enriquecedora a la vez que nos
ha llevado a tener un buen ritmo de trabajo en colaboracin con ITOP MC.

119

120

Chapter I

Elaboracin de una metodologa propia para la creacin de una

solucin BI
Esta metodologa, elaborada con base a la metodologa HEFESTO, fue de vital
importancia para dotar al proyecto de suficiente robustez a la hora de crear una
solucin BI para el proceso de Gestin de Ventas. Una gran ventaja es que se adapta
muy bien a SCRUM, lo que agiliza el proceso de implementacin y una rpida
adaptacin a los cambios que iban surgiendo por motivos de errores de comprensin o
cambios de tecnologas.

Implementacin de la solucin.
Se cre una aplicacin BI para la Gestin de Ventas implementada con herramientas
que Microsoft ha creado para llevar a cabo este tipo de proyectos y se dej preparada
para que pueda ser publicada en una aplicacin Web para que el gerente o
responsable de la empresa pueda consultar los resultados de sus ventas en cualquier
momento. No se realizan grandes clculos y complejos algoritmos, sin embargo, se
han concentrado grandes esfuerzos en la validacin de los datos, en formatearlos de
forma adecuada y crear una serie de cuadros de mandos interactivos y dinmicos.

Posibles ampliaciones
Como posible ampliacin queda implementar una solucin BI para los procesos de
Gestin de Finanzas, Gestin de Proyectos y Gestin de Incidencia, as como sera
interesante integrar un mdulo de Data Mining que sirve de ayuda al gerente o
responsable de la empresa a la hora de tomar decisiones.

Captulo 2.

120

Parte IV.

Bibliografa

Parte V.1. Kniberg, Henrick. . http://www.proyectalis.com/wp-content/uploads/2008/02/scrumy-xp-desde-las-trincheras.pdf. [En lnea] 09 de 06 de 2011.

Parte VI.
2. Dario, Bernabeu R. Investigacin y Sistematizacin de HEFESTO:
Metodologa propia para la Construccin de un Data Warehouse. [En lnea] 09 de 06 de 2011.
Parte VII.
3. Commerce, Office of Government. ITIL Gestin de Servicios TI. [En lnea]
05 de 01 de 2011. http://itil.osiatis.es.
Parte VIII.

4. Alexander, Michael. Crystal Xcelsius for Dummies. 2007.

Parte IX.
5. Berndtsson, M., Hansson, J., Olsson, B., Lundell, B. A Guide for Students
in Computer Science and Information Systems, Springer. 2008.
Parte X.
6. Stephen Few. Information Dashboard Design,
Communication of Data. s.l. : O'Reilly, 2006.

The

Effective

Visual

Parte XI.
7. Doug Harts, Jim Dugan, Tricia Wilcox Almas. Microsoft SQL Server 2008
R2 Analytics & Data Visualization. s.l. : Mac Graw Hill, 2008.
Parte XII.
8. Ramos, Salvador. Microsoft Business Intelligence vea el cubo medio lleno.
s.l. : SolidQ Press, 2011.
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.
Parte XIV.
10. Xavier Hacking, David Lai. SAP BusinessObjects Dashboards 4.0
Cookbook. s.l. : Packt Publishing, 2011.
Parte XV.
11. Roland Bouman, Jos van Dongen. Pentaho Solutions - Business
Intelligence and Data Warehousing with Pentaho and MySQL. s.l. : WILEY.
Parte XVI.
12. Roldn, Mara Carina. Pentaho 3.2 Data Integration, Beginner's Guide.
s.l. : Packt Publishing, 2010.

121

122

Chapter I

Parte XVII.
13. Erik Veerman, Jessica M. Moss, Brian Knight, Brian Knight. Microsoft
SQL Server 2008 Integration Services ProblemDesignSolution. s.l. : Wiley Publishing, Inc,
2010.
Parte XVIII.
14. Nanda, Ashwani. Microsoft SQL Server 2008 Integration Servicies. s.l. :
Mac Graw Hill, 2010.
Parte XIX.
15. Haselden, Kirk. Microsoft SQL Server 2008 Integration Services. s.l. :
UNLEASHED, 2009.
Parte XX.
16. Annimo. The Official Introduction to the ITIL Service Lifecycle. s.l. :
Published by TSO (The Stationery Office).
Parte XXI.
17. Commerce, Office of Government. ITIL Serivce Transition. s.l. : Published
by TSO (The Stationery Office).
Parte XXII.
2009.

18. . ITIL Continual Service Improvement. s.l. : Office Government Comerce,

Parte XXIII.

19. . ITIL Service Design. s.l. : Published by TSO (The Stationery Office).

Parte XXIV.

20. . ITIL Service Operation. s.l. : Published by TSO (The Stationery Office).

Parte XXV.

21. ZELAZNY, GENE. Say it whit Charts. s.l. : McGraw-Hill, 2001.

Parte XXVI.
22. PARMENTER, DAVID. Key Performance Indicators,
Implementing, and Using Winning KPIs. s.l. : John Wiley & Sons, Inc., 2010.

Developing,

Parte XXVII.
23. John Wiley & Sons, Inc., Hoboken, New Jersey. Business Dashboards.
s.l. : John Wiley & Sons, Inc., 2009.
Parte XXVIII. 24. Withee, Ken. Microsoft Business Intelligence for Dummies. s.l. : Wiley
Publishing, Inc, 2010.
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.
Parte XXX.
26. SQL SERVER INTEGRATION SERVICES 2008 LABORATORIOS . s.l. :
INTERMEZZO BUSINESS INTELLIGENCE , 2010.
Parte XXXI.
2010.

27. Inmon, W. H. Building the Data Warehouse. s.l. : Design & Composition,

Parte XXXII.
28. Viera, Robert. Professional Microsft SQL Server 2008 Programming. s.l. :
Wiley Publishing, I nc, 2009.
Parte XXXIII. 29. Ross MistRy, Stacia MisneR. Introduciong Microsoft SQL Server 2008 R2.
s.l. : Microsoft Press, 2010.
Parte XXXIV. 30. Philo Janus, Philo Janus. Pro SQL Server 2008 Analysis Services. s.l. :
Apress, 2010.
Parte XXXV.
31. Rainardi, Vincent. Building a Data Warehouse with Examples in SQL
Server. s.l. : Apress, 2010.
Parte XXXVI. 32. Scott Cameron, Hitachi Consulting. SQL Server 2008 Analysis Services.
s.l. : Vincent Rainardi, 2009.

122

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.
Parte XXXVIII. 34. Langit, Guy Fouch and Lynn. Foundations of SQL Server 2008 R2
Business Intelligence. s.l. : Apress, 2009.
Parte XXXIX. 35. Kimball, Joy Mundy and Marren Thornthwaite with Ralph. The Microsft
Data Warehouse Toolkit whit SQL Server. s.l. : Kimball Group, 2011.
Parte XL.
36. Annimo. Scrum. Definicin de Scrum. [En lnea] 23 de 06 de 2011.
http://es.wikipedia.org/wiki/Scrum.
Parte XLI.

37. Institute, Project Management. PMBOK.

Captulo 1.

123

124

Chapter I

Glosario de trminos
A
agregacin................................................................................................................................................................... 26
Analysis Services..................................................................................................................................43, 102, 103, 105
Atributo....................................................................................................................................................................... 64
Atributos de dimensin...............................................................................................................................................26

B
Business Intelligence.................................................................................1, 2, 3, 14, 15, 17, 38, 40, 42, 45, 55, 56, 127
business key................................................................................................................................................................ 24
Business Models....................................................................................................................................................20, 32

C
claves subrogadas........................................................................................................................................................24
Community Dashboard Framework.............................................................................................................................44
Cuadros de mando................................................................................................................................................33, 41
Cuadros de Mando........................................................................................................................................................3
cubo multidimensional.............................................................................................................22, 23, 26, 27, 28, 32, 99

D
Dashboards................................................................................................................................................................. 43
Data Integration.......................................................................................................................................................... 44
Data Mining................................................................................................................................................................. 44
Data Warehouse.14, 17, 18, 19, 20, 21, 22, 26, 28, 29, 30, 31, 32, 33, 34, 51, 52, 55, 56, 57, 58, 60, 86, 87, 92, 93, 95,
96, 99, 101, 103, 127
Datamarts.............................................................................................................................................................. 17, 34
Decision Support Systems....................................................................................................................................14, 127
Diagrama de Gantt......................................................................................................................................................53
dimensiones........................................22, 23, 24, 25, 26, 27, 28, 29, 30, 34, 45, 51, 52, 65, 86, 87, 97, 98, 99, 114, 127
dimensiones lentamente cambiantes..................................................................................................................24, 127
Drill-acros.................................................................................................................................................................... 32
Drill-down.................................................................................................................................................................... 32
Drill-through................................................................................................................................................................ 32
Drill-up........................................................................................................................................................................ 32
Dueo del producto....................................................................................................................................................49
DW...................................................................................17, 18, 19, 22, 23, 26, 30, 32, 41, 86, 87, 94, 96, 98, 102, 127

E
Eclipse......................................................................................................................................................................... 42

124

ERP...................................................................................................................................................................... 42, 127

Esquema constelacin...........................................................................................................................................23, 29
Esquema en copo de nieve....................................................................................................................................23, 28
Esquema en estrella....................................................................................................................................................28
ETL.........................................................................................................17, 21, 44, 45, 51, 52, 55, 94, 96, 101, 102, 127
Excel............................................................................................................15, 41, 42, 43, 104, 105, 106, 107, 108, 109
Executive Information Systems............................................................................................................................16, 127

F
Finanzas.................................................................................................................................................66, 77, 117, 118

G
Gartner.................................................................................................................................................................. 39, 40
Gestin de Incidencias............................................................................................................64, 66, 71, 72, 76, 77, 117
Gestin de Proyectos........................................................................................................62, 63, 66, 68, 76, 77, 84, 118
Gestin de Ventas.......................................................................................................................63, 66, 76, 84, 117, 118
Grfico de bala.......................................................................................................................................................... 109
Grafico de barras.......................................................................................................................................................109
Grfico de lnea....................................................................................................................................................63, 109
Grfico de pila......................................................................................................................................................64, 109

H
Hechos bsicos............................................................................................................................................................ 26
Hechos derivado.......................................................................................................................................................... 26
Hefesto.............................................................................................................................56, 57, 58, 59, 61, 76, 82, 117
HOLAP......................................................................................................................................................................... 31

I
Indicadores............................................................................................3, 26, 27, 51, 52, 66, 67, 68, 76, 77, 79, 99, 110
Information Technology Infrastructure Library............................................................................................................71
Informes dinmicos.................................................................................................................................................3, 33
Informes estticos.......................................................................................................................................................33
Integration Services...........................................................................................................................................100, 101
inteligencia de negocios................................................................................................................................................3
inteligencia empresarial................................................................................................................................................3
ITOP MC....................................................................................................................36, 37, 40, 42, 45, 50, 62, 117, 127

K
Kettle........................................................................................................................................................................... 44
KPI........................................................................................................................................27, 60, 65, 66, 69, 100, 127

M
Minera de Datos......................................................................................................................................................... 18
MOLAP........................................................................................................................................................................ 31

125

126

Chapter I

O
OLAP............................................................................................................17, 31, 32, 41, 43, 44, 51, 53, 103, 105, 127
OLTP...................................................................................17, 20, 21, 30, 34, 51, 52, 55, 61, 76, 82, 83, 90, 94, 98, 127
Open Source.......................................................................................................................................................... 42, 44
Operational Data Store........................................................................................................................................17, 127

P
Pentaho......................................................................................................................................................42, 43, 44, 45
Performance Point.................................................................................................................................41, 42, 107, 108
PMBOK........................................................................................................................................................................ 68
Product Backlog.......................................................................................................................................49, 50, 51, 117
Product Owner............................................................................................................................................................ 36

Q
Query Manager.....................................................................................................................................................32, 55

R
Ralph Kimball.........................................................................................................................................................25, 39
Reporting..................................................................................................................................41, 43, 45, 105, 106, 107
ROLAP.......................................................................................................................................................................... 31
Roll-across................................................................................................................................................................... 32

S
SAP..........................................................................................................36, 37, 38, 42, 45, 83, 85, 92, 95, 96, 107, 117
Sap BO......................................................................................................................................................................... 38
SCD................................................................................................................................................................ 24, 25, 127
SCRUM....................................................................................................................................................47, 48, 49, 50, 57
ScrumMaster............................................................................................................................................................... 49
SharePoint................................................................................................................................................41, 42, 44, 108
Silverlight...............................................................................................................................................41, 42, 107, 108
Sistema de Informacin.......................................................................................................................................14, 127
Sistemas de Informacin Ejecutiva..............................................................................................................................16
Sistemas Transaccionales.............................................................................................................................................14
Slowly Changing Dimensions...............................................................................................................................24, 127
solucin BI..............................................................................15, 16, 17, 19, 38, 39, 40, 42, 45, 50, 51, 55, 56, 117, 118
SparkLines..............................................................................................................................................63, 64, 109, 110
SPRINT................................................................................................................................................................ 49, 50, 51
SQL Server 2008 R2...............................................................................................................................................40, 41
SQL Server 2008 R2 Analisys Servicies.........................................................................................................................41
SQL Server 2008 R2 Integration Services.....................................................................................................................40
SRDWM....................................................................................................................................................................... 57
subdimensin.............................................................................................................................................................. 95
subrogate key.............................................................................................................................................................. 24

126

T
tabla de hechos.................................................................................................24, 25, 26, 28, 30, 32, 84, 87, 89, 90, 91
Team............................................................................................................................................................................ 49

V
Ventas.........................................................................................................................66, 78, 83, 90, 100, 113, 114, 117

W
WeKa........................................................................................................................................................................... 44

X
Xcelsius.......................................................................................................................................................... 41, 42, 107

127

128

Chapter I

ndice de siglas
SIGLAS

DEFINICIN

BI

Business Intelligence o Inteligencia de Negocios

BPM

Business Process Management o Gestin de Proceso de Negocio

DSS

Decision Support Systems o Soporte al sistema de decisiones

DW

Data Warehouse o Almacn de Datos

EIS

Executive Information Systems o Sistemas de Informacin Ejecutiva

ERP

Enterprise Resource Planning

ETL

Extraccin Transform Load o Extraccin Transformacin y Carga

ITIL

Information Technology Infrastructure o Biblioteca de Infraestructura de

Tecnologas de Informacin

ITOP MC

Informacin
Consulting

KPI

Key Performance Indicators o indicadores de rendimiento clave

ODS

Operational Data Store

OLAP

On-Line Analytical Processing o Procesamiento Analtico en Lnea

OLTP

On-Line Transaction Processing o Bases de Datos Transaccionales

PMI

Project Management Institute

SAP

System, Applications and Products o Sistemas Aplicaciones y

Productos

SDC

Slowly Changing Dimensions o Dimensiones Lentamente Cambiantes

SGBDR

Sistema Gestor de Base de Datos Relacional

SI

Sistema de Informacin

Tecnologa

Organizacin

128

Proceso

Management

SRDWM

The SAS Rapid Data Warehouse Methodology

TI

Tecnologa de la Informacin

Apndices
I.

Actas de las reuniones con la empresa ITOP MC

129

130

Chapter I

130