Business Intelligence paraPYMES

Autor/es: Manuel Alejandro González YanesRebeca Mora Anca

Director/a: Virginia Gutiérrez Rodríguez

Fecha: 12 de Julio de 2011

2 Chapter I

D./Dña. Virginia Gutiérrez Rodríguez Profesora de la Escuela Técnica Superior de Ingeniería

Informática, y adscrito al Departamento de Estadística, Investigación Operativa y Computación

de la Universidad de La Laguna.

CERTIFICA: Que la presente memoria titulada Business Intelligence para PYMES, ha sido

realizada bajo mi dirección por el/los alumno/s D. Manuel Alejandro González Yanes y Dña

Rebeca Mora Anca, y constituye su Proyecto Fin de Carrera de Ingeniería Informática por la

Universidad de La Laguna.

Y para que así conste, en cumplimiento de la legislación vigente y a los efectos que haya lugar,

firmo el presente certificado en La Laguna, a 12 de Julio de 2011

Fdo: D./Dña. Virginia Gutiérrez Rodríguez

2

Resumen

Se denomina inteligencia empresarial, inteligencia de negocios o BI (del inglés Business

Intelligence) al conjunto de estrategias y herramientas enfocadas a la administración y

creación de conocimiento mediante el análisis de datos existentes en una organización o

empresa.

La Business Intelligence actúa como un factor estratégico para una empresa u organización,

generando una potencial ventaja competitiva, que no es otra que proporcionar información

privilegiada para responder a los problemas de negocio: entrada a nuevos mercados,

promociones u ofertas de productos, control financiero, optimización de costes, planificación de

la producción, análisis de perfiles de clientes, rentabilidad de un producto concreto, etc...

Las herramientas de inteligencia abarcan la comprensión del funcionamiento actual de la

empresa como la anticipación de acontecimientos futuros, con el objetivo de ofrecer

conocimientos para respaldar las decisiones empresariales. Las herramientas de Business

Intelligence se basan en la utilización de un Sistema de Información de Inteligencia que se

forma con distintos datos extraídos de producción, con información relacionada con la empresa

o sus ámbitos y con datos económicos.

Las herramientas de Business Intelligence ofrecen a las personas que toman las decisiones

utilidades que facilitan ese proceso como:

Cuadros de Mando para medir la evolución de los Indicadores clave del negocio cómo

controlar las ventas o la situación económica.

Informes dinámicos con los que buscar causas o tendencias de forma sencilla y que

permiten analizar clientes, proveedores, producción, etc. en profundidad.

El problema a abordar consiste en integrar SAP BO con una solución de Business Intelligence

de forma que proporcione a las Pymes informes gráficos y cuadros de mandos interactivos que

ofrezca una mayor versatilidad, control de los ingresos, los márgenes y la liquidez.

3

4 Chapter I

Agradecimientos

A nuestro profesor de la Universidad de La Laguna, Marcos Colebrook, el cual nos animó a

desarrollar este proyecto tan satisfactorio a nivel personal y profesional.

A nuestra directora de proyecto de la Universidad de La Laguna, Virginia Gutiérrez Rodríguez,

la cual trabajó con nosotros a lo largo de todo el proyecto siempre ayudando, aconsejando y

orientándonos en todo momento.

A las personas que forman ITOP Management Consulting, y en especial a Teresa Pestana y

Miguel Fernández, por el apoyo y las horas que han dedicado con nosotros a este proyecto.

Dedicar este proyecto a nuestra familia y amigos por el apoyo y los ánimos prestados en todo

momento incondicionalmente.

Gracias a profesores como José Luis Roda que nos dio grandes consejos y nos proporcionó las

infraestructuras con las que realizar el proyecto, Daniel González que nos descubrió el mundo

del PMBOK e ITIL para poder crear los indicadores, Roberto Dorta que nos ayudó a entender la

ISO9001.

4

5

6 Chapter I

Al término de esta etapa de nuestras vida. Queremos expresar todo nuestro agradecimiento a quienes con su ayuda, apoyo y comprensión, nos alentaron a lograr esta hermosa realidad…

nuestra formación profesional.Tabla de contenidos

Resumen .......................................................................................................... 2

Agradecimientos ............................................................................................. 4

Lista de figuras .............................................................................................. 7

Lista de Tablas ................................................................................................ 8

Parte I.Introducción y fundamentos básicos ................................................... 8

Capítulo 1.Fundamentos Business Intelligence ......................................... 91.1Introducción ................................................................................................................ 9

1.2¿Qué es BI? ................................................................................................................ 9

1.2.1Proceso BI ...................................................................................................... 10

1.2.2Arquitectura de una solución BI ...................................................................... 10

1.3¿Qué es un Data Warehouse? ................................................................................. 10

1.3.1Arquitectura de una solución BI con Data Warehouse ................................... 11

Capítulo 2.ITOP Management Consulting .................................................. 202.1La empresa ............................................................................................................... 20

2.2Filosofía .................................................................................................................... 20

2.3Alianzas .................................................................................................................... 20

Capítulo 3.Descripción del problema e integración de solucionestecnológicas .......................................................................................... 213.1Introducción .............................................................................................................. 21

3.2Análisis funcional y elección ..................................................................................... 21

3.2.1Análisis Inicial ................................................................................................. 21

3.2.2Conclusión ..................................................................................................... 23

3.3 Descripción del problema ........................................................................................ 24

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

Capítulo 1.Descripción de la metodología para resolver el problema . . . 261.1Metodología de desarrollo ........................................................................................ 26

1.1.1Metodología SCRUM ..................................................................................... 27

Capítulo 2.Metodología de Implementación de una solución BI ............. 332.1.1Metodologías para construir un Data Warehouse .......................................... 33

6

2.1.2Metodología propia para la Construcción de un Data Warehouse con base enHEFESTO .................................................................................................... 34

Capítulo 3.Análisis de los resultados ......................................................... 713.1Resultados ................................................................................................................ 71

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

Capítulo 1.Conclusiones y posibles ampliaciones ................................... 74

Parte IV.Bibliografía .......................................................................................... 76

Parte V.1. Kniberg, Henrick. . http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf. [Enlínea] 09 de 06 de 2011. ............................................................................. 76

Parte VI.2. Dario, Bernabeu R. Investigación y Sistematización deHEFESTO: Metodología propia para la Construcción de un DataWarehouse. [En línea] 09 de 06 de 2011. ................................................ 76

Parte VII.3. Commerce, Office of Government. ITIL Gestión de Servicios TI.[En línea] 05 de 01 de 2011. http://itil.osiatis.es. ..................................... 76

Parte VIII.4. Alexander, Michael. Crystal Xcelsius for Dummies. 2007. ....... 76

Parte IX.5. Berndtsson, M., Hansson, J., Olsson, B., Lundell, B. A Guide forStudents in Computer Science and Information Systems, Springer.2008. ............................................................................................................. 76

Parte X.6. Stephen Few. Information Dashboard Design, The EffectiveVisual Communication of Data. s.l. : O'Reilly, 2006. .............................. 76

Parte XI.7. Doug Harts, Jim Dugan, Tricia Wilcox Almas. Microsoft SQLServer 2008 R2 Analytics & Data Visualization. s.l. : Mac Graw Hill,2008. ............................................................................................................. 76

Parte XII.8. Ramos, Salvador. Microsoft Business Intelligence vea el cubomedio lleno. s.l. : SolidQ Press, 2011. ...................................................... 76

7

8 Chapter I

Parte XIII.9. Sivakumar Harinath, Matt Carroll, Sethu Meenakshisundaram,Robert Zare, Denny Guang-Yeu Lee. Professional Microsoft SQLServer Analysis Services 2008 with MDX. s.l. : Wiley Publishing, Inc.,2009. ............................................................................................................. 76

Parte XIV.10. Xavier Hacking, David Lai. SAP BusinessObjectsDashboards 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 andMySQL. s.l. : WILEY. ................................................................................... 76

Parte XVI.12. Roldán, María Carina. Pentaho 3.2 Data Integration,Beginner's Guide. s.l. : Packt Publishing, 2010. ..................................... 76

Parte XVII.13. Erik Veerman, Jessica M. Moss, Brian Knight, Brian Knight.Microsoft® SQL Server® 2008 Integration Services Problem–Design–Solution. s.l. : Wiley Publishing, Inc, 2010. .............................................. 76

Parte XVIII.14. Nanda, Ashwani. Microsoft SQL Server 2008 IntegrationServicies. s.l. : Mac Graw Hill, 2010. ......................................................... 76

Parte XIX.15. Haselden, Kirk. Microsoft® SQL Server 2008 IntegrationServices. s.l. : UNLEASHED, 2009. ........................................................... 76

Parte XX.16. Anónimo. The Official Introduction to the ITIL ServiceLifecycle. 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. : OfficeGovernment Comerce, 2009. ..................................................................... 76

Parte XXIII.19. —. ITIL Service Design. s.l. : Published by TSO (TheStationery Office). ....................................................................................... 76

8

Parte XXIV.20. —. ITIL Service Operation. s.l. : Published by TSO (TheStationery 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. BusinessDashboards. s.l. : John Wiley & Sons, Inc., 2009. .................................. 76

Parte XXVIII.24. Withee, Ken. Microsoft Business Intelligence forDummies. s.l. : Wiley Publishing, Inc, 2010. ............................................ 76

Parte XXIX.25. Lynn Langit, Kevin S. Goff, Davide Mauri, Sahil Malik, andJohn Welch. Smart Business Intelligence Solutions with MicrosoftSQL Server2008. s.l. : Microsoft Press, 2009. ......................................... 76

Parte XXX.26. SQL SERVER INTEGRATION SERVICES 2008LABORATORIOS . 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 2008Programming. s.l. : Wiley Publishing, I nc, 2009. ................................... 76

Parte XXXIII.29. Ross MistRy, Stacia MisneR. Introduciong Microsoft SQLServer 2008 R2. s.l. : Microsoft Press, 2010. ........................................... 77

Parte XXXIV.30. Philo Janus, Philo Janus. Pro SQL Server 2008 AnalysisServices. s.l. : Apress, 2010. ..................................................................... 77

9

10 Chapter I

Parte XXXV.31. Rainardi, Vincent. Building a Data Warehouse withExamples in SQL Server. s.l. : Apress, 2010. .......................................... 77

Parte XXXVI.32. Scott Cameron, Hitachi Consulting. SQL Server 2008Analysis Services. s.l. : Vincent Rainardi, 2009. ..................................... 77

Parte XXXVII.33. Chris Webb, Alberto Ferrari and Marco Russo. ExpertCube Development with Microsoft SQL Server 2008 Analysis Services.s.l. : Marco Russo, 2009. ............................................................................ 77

Parte XXXVIII.34. Langit, Guy Fouché and Lynn. Foundations of SQLServer 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. : KimballGroup, 2011. ................................................................................................ 77

Parte XL.36. Anónimo. Scrum. Definición de Scrum. [En línea] 23 de 06 de2011. http://es.wikipedia.org/wiki/Scrum. ................................................ 77

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

Glosario de términos .................................................................................... 78

Índice de siglas ............................................................................................. 82

Apéndices ...................................................................................................... 84

10

Lista de figuras

11

12 Chapter I

Lista de Tablas

Parte I. Introducción y fundamentos básicos

12

Capítulo 1. Fundamentos Business Intelligence

Resumen:

Introducción a mundo del Business Intelligence

Introducción Data Warehouse y conceptos relacionados

1.1 Introducción

En la actualidad, la gran mayoría de las organizaciones cuenta con un Sistema de

Información1 (SI) que soporta gran parte de las actividades diarias propias del sector de

negocios en donde se esté desempeñando. Este sistema puede ser sencillo o robusto,

todo depende de las exigencias del negocio. Con el transcurso del tiempo, estas

aplicaciones llegan a tener la historia de la organización: los datos almacenados en las

bases de datos pueden ser utilizados para argumentar la decisión que se quiera tomar.

Un estudio realizado en Europa por Information Builders Ibéric mostró el costo que

tiene la falta de Sistemas de Información Orientados para la Toma de Decisiones2 o

Decision Support Systems (DSS) en las organizaciones. Según estos datos, el

empleado europeo medio pierde una media de 67 minutos diariamente buscando

información de la compañía, lo que equivale a un 15,9% de su jornada laboral. Para

una organización de 1.000 empleados que gane unos 50.000 euros al día equivaldría a

7,95 millones de euros al año de salario perdido, debido todo ello a la búsqueda de

información orientada a la toma de decisiones.

El poder competitivo que puede tener una empresa se basa en la calidad y cantidad de

información que sea capaz de usar en la toma de decisiones. Mediante la

implementación de Inteligencia de Negocios o Business Intelligence (BI) se

proporcionan las herramientas necesarias para aprovechar los datos almacenados en

las bases de datos de los Sistemas Transaccionales3 para utilizar la información como

respaldo a las decisiones, reduciendo el efecto negativo que puede traer consigo una

mala determinación. Precisamente, Business Intelligence permite que el proceso de

toma de decisiones esté fundamentado sobre un amplio conocimiento de sí mismo y

del entorno, minimizando de esta manera el riesgo y la incertidumbre.

1 Un Sistema de Información es un conjunto de elementos orientados al tratamiento y administración de datos einformación, organizados y listos para su posterior uso, generados para cubrir una necesidad u objetivo.

2 DSS es un sistema informático utilizado para servir de apoyo, más que automatizar, el proceso de toma dedecisiones.

3 Es un tipo de Sistema de Información diseñado para recolectar, almacenar, modificar y recuperar todo tipo deinformación que es generada por las transacciones en una organización.

13

14 Chapter I

1.2 ¿Qué es BI?

“BI es el conjunto de estrategias y tecnologías que nos van a ayudar a convertir los

datos en información de calidad y dicha información en conocimiento que nos permita

una toma de decisiones más acertada y nos ayude así a mejorar nuestra

competitividad”4

Business Intelligence hace hincapié en los procesos de recolectar y utilizar

efectivamente la información con el fin de mejorar la forma de operar de una

organización, brindando a sus usuarios, el acceso a la información clave que necesitan

para llevar a cabo sus tareas habituales y, en concreto, para poder tomar decisiones

oportunas basadas en datos correctos y certeros —algo peor que no tener información

disponible es tener mucha información y no saber qué hacer con ella. Los datos

almacenados en nuestros sistemas no valen nada si no somos capaces de comprender

su significado, de elaborarlos y transformarlos en información de calidad, que sea

capaz de responder a las preguntas de los usuarios de diferentes áreas de negocios —

ventas, marketing, finanzas, inventarios, entre otras—, como:

¿Cuál es el estado de salud de mi empresa?

¿Cuál es el nivel de satisfacción de mis clientes? ¿Y el de mis empleados?

¿Cuál es la línea de productos más rentables? ¿Es la misma que el año anterior?

¿Cuál es el segmento de clientes al que deberíamos dirigir un nuevo producto?

¿Qué departamentos son los más productivos?

Al contar con la información exacta y en tiempo real, es posible, además de lo anterior,

identificar y corregir situaciones antes de que se conviertan en problemas potenciales o

pérdidas de control de la empresa, pudiendo conseguir nuevas oportunidades o

readaptarse frente a la ocurrencia de sucesos inesperados. A todo ello, a partir de

ahora se denominará solución BI.

¿Quién necesita soluciones de Business Intelligence?

Para ello nos planteamos las siguientes cuestiones:

¿Pasa más tiempo recolectando y preparando información que analizándola?

¿En ocasiones le frustra el no poder encontrar información que usted está seguro que

existe dentro de la empresa?

¿Pasa mucho tiempo tratando de hacer que los informes en Excel luzcan bien?

¿No sabe qué hacer con tanta información que tiene disponible en la empresa?

¿Quiere saber qué productos fueron los más rentables durante un periodo

determinado?

¿Ha perdido oportunidades de negocio por recibir información retrasada?

¿Trabaja horas extras el fin de mes para procesar documentos e informes?

¿No sabe con certeza si su gente está alcanzando los objetivos planeados?

4 Microsoft Business Intelligence: Vea el cubo medio lleno (http://www.solidq.com/sqj/books/Pages/Microsoft-Business-Intelligence-vea-el-cubo-medio-lleno.aspx)

14

¿No tiene idea de por qué sus clientes le devuelven mercancía?

Estas son las soluciones de BI más reconocidas actualmente en el mercado.

Un caso de éxito de solución BI fue un estudio de la cadena de supermercados Wal-

Mart5, donde decidieron iniciar un proyecto de Basket Analysis6 utilizando la

información recogida de las ventas. Descubrieron una correlación estadísticamente

significativa entre la compra de pañales y cerveza. Profundizando en el estudio, vieron

que los compradores de cerveza y pañales eran varones de entre 25 y 35 años que

solían comprar estos productos conjuntamente los viernes por la tarde. La cadena de

supermercado tomo la decisión de colocar las cervezas cerca de los pañales, con la

intención de que los padres que compraban pañales y que no solían comprar cerveza,

se acordasen que faltaba cerveza en casa. Los resultados fueron espectaculares

aumentando un 15% las ventas de cervezas con pañales.

La Inteligencia de Negocios tiene sus raíces en los Sistemas de Información Ejecutiva7o Executive Information Systems (EIS) y en los DSS, pero ha evolucionado y se ha

transformado en todo un conjunto de tecnologías capaces de satisfacer a una gran

gama de usuarios, junto a sus necesidades específicas, en cuanto al análisis de la

información.

1.2.1 Proceso BI

El proceso BI se describe en cinco fases, las cuales se explican teniendo como

referencia la Figura 1, gráfico que sintetiza todo el proceso.

Figura 1: Fases de un proceso BI

5 Wal-Mart es una empresa multinacional de origen estadounidense, el minorista más grande del mundo; y por susventas y número de empleados, la mayor compañía del mundo. Su concepto de negocio es la tienda de autoservicio debajo precio y alto volumen.

6 Las técnicas de basket analysis del mercado permiten analizar los productos que integran la bolsa de la compra y lasrelaciones existentes entre ellos. En este nivel de detalle, la información es muy útil y proporciona a los usuarios denegocio visibilidad directa sobre la bolsa de la compra de cada cliente.

7 Los Sistema de Información Ejecutiva son una herramienta de Business Intelligence, orientada a usuarios de nivelgerencial, que permite monitorizar el estado de las variables de un área o unidad de la empresa a partir de informacióninterna y externa a la misma.

15

16 Chapter I

FASE 1: Dirigir y planear. Fase inicial donde se deberán recoger los

requerimientos de información de los diferentes usuarios así como entender

sus necesidades de información.

FASE 2: Recolección de información. Se estudiaran las diferentes fuentes de

información de la empresa para recolectar aquellos datos que darán

respuestas a las necesidades planteadas en la fase anterior

FASE 3: Procesamiento de datos. En esta fase es donde de integran y cargan

los datos en crudo en un formato utilizable para el análisis. Esta actividad

puede realizarse mediante la creación de una nueva base de datos, agregando

datos a una base de datos ya existente o bien consolidando la información.

FASE 4: Difusión. Finalmente los usuarios a través de una serie de

herramientas podrán explorar los datos de manera sencilla e intuitiva.

1.2.2 Arquitectura de una solución BI

Una solución Business Intelligence parte de los sistemas de origen de una organización

—bases de datos, ERPs, ficheros de texto, entre otros—, sobre los que suele ser

necesario aplicar una transformación estructural para optimizar su proceso analítico.

Para ello se realiza una fase de extracción, transformación y carga (ETL) de datos,

donde se depuran y homogeneizan Esta etapa suele apoyarse en un almacén

intermedio —Operational Data Store— (ODS) que actúa como pasarela entre los

sistemas fuente y los sistemas destino —generalmente un Data Warehouse—, y cuyo

principal objetivo consiste en evitar la saturación de los servidores funcionales de la

organización.

La información resultante, ya unificada, depurada y consolidada, se almacena en un

Data Warehouse (DW) corporativo, que puede servir como base para la construcción

de distintos Datamarts departamentales. Estos Datamarts se caracterizan por poseer la

estructura óptima para el análisis de los datos del área de la organización, ya sea

mediante Bases de Datos Transaccionales (OLTP) o mediante Bases de datos

analíticas (OLAP).

1.3 ¿Qué es un Data Warehouse?

Supóngase que una compañía quiere analizar aquellos países y gama de productos en

los que las ventas vayan excepcionalmente bien. La compañía dispone de una base de

datos transaccional sobre la que operan todas las aplicaciones de la empresa:

producción, venta, facturación, proveedores etc. Lógicamente, de cada venta se

registra la fecha, la cantidad, el comprador y el país de este. Con toda esta información

histórica nos podemos preguntar:

¿Es esta información suficiente para realizar el análisis planteado?

La respuesta hay que buscarla fuera de la base de datos, en el contexto donde se

motiva el análisis. La incorporación de un producto depende de las ventas por

habitantes. Si no tenemos en cuenta la población de cada país, la repuesta al análisis

16

estará sesgada. También puede ocurrir que, dependiendo de la gama del producto, nos

interese información externa verdaderamente específica, como por ejemplo, las horas

de sol anuales de cada país, siendo información valiosa para una compañía de

cosmética: es más difícil vender bronceador en Lituania que en Canarias. Pero este

hecho, que nos parece tan lógico, sólo podrá ser descubierto por herramientas de

Minería de Datos8, si se incorpora información climática de cada país. Con lo cual, cada

organización deberá recoger diferente información que le pueda ser útil para la tarea de

análisis y extracción de conocimiento y en definitiva para la toma de decisiones.

Un Data Warehouse es una base de datos corporativa en la que se integra información

depurada de las diversas fuentes inmersas en la organización o externas a ella, como

se muestra en la Figura 2. Dicha información debe ser homogénea y fiable, se

almacena de forma que permita su análisis desde muy diversas perspectivas, y a su

vez de tiempos de respuestas óptimos.

Figura 2: En un Data Warehouse se integra información de diversas fuentes.

Una de las definiciones más famosas sobre DW, es la de William Harvey Inmon9, que

expone:

“Un Data Warehouse es una colección de datos orientada al negocio, integrada,

variante en el tiempo y no volátil para el soporte del proceso de toma de decisiones de

la gerencia”.

donde en la Tabla 1 se aprecia en profundidad cada una de las características más

detalladas.

8La Minería de Datos consiste en la extracción no trivial de información que reside de manera implícita en los datos.Dicha información era previamente desconocida y podrá resultar útil para algún proceso. En otras palabras, la Mineríade Datos prepara, sondea y explora los datos para sacar la información oculta en ellos.

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

17

18 Chapter I

Tabla 1: Características de un Data Warehouse

Orientado a temas

Los datos están organizados por temas para facilitar el entendimientopor parte de los usuarios, de forma que todos los datos relativos a unmismo elemento de la vida real queden unidos entre sí. Por ejemplo,todos los datos de un cliente pueden estar consolidados en una mismatabla, todos los datos de los productos en otra y así sucesivamente.

Integrado

La integración implica que todos los datos de diversas fuentes que sonproducidos por distintos departamentos, secciones y aplicaciones, tantointernos como externos, deben ser consolidados en una instancia antesde ser agregados al Data Warehouse, y deben, por lo tanto, seranalizados para asegurar su calidad y limpieza, entre otras cosas.Algunas de las inconsistencias más comunes que nos solemosencontrar son: en nomenclatura, unidades, formato de fechas,..

Histórico (variante

en el tiempo)

Los datos, que pueden ir variando en el tiempo, deben quedar reflejadosde forma que al ser consultados reflejen estos cambios y no se altere larealidad que había en el momento que se almacenaron, evitando así laproblemática que ocurre en los sistemas operacionales, que reflejansolamente el estado de la actividad de negocio presente.

No volátilUna vez almacenada la información en el Data Warehouse debe ser desolo lectura, nunca se modifica ni se elimina, debe ser permanente parafuturas consultas.

1.3.1 Arquitectura de una solución BI con Data Warehouse

En este punto —teniendo en cuenta que ya se han detallado claramente las

características generales del Data Warehouse— se define y describe todos los

componentes que intervienen en su arquitectura o ambiente.

A través de la Figura 3 se explicita la estructura del Data Warehouse.

Figura 3: Estructura de un Data Warehouse

La forma de operar de una solución BI a través de un DW se resume de la siguiente

manera:

1. Los datos son extraídos desde aplicaciones, bases de datos, archivos, etc.

Esta información generalmente reside en diferentes tipos de sistemas,

orígenes y arquitecturas y tienen formatos muy variados.

2. Los datos son integrados, transformados y limpiados, para luego ser cargados

en el Data Warehouse.

18

3. Principalmente, la información del Data Warehouse se estructura en cubos

multidimensionales, ya que estos preparan la información para responder a

consultas dinámicas con un buen rendimiento. Pero también pueden utilizarse

otros tipos de estructuras de datos para representar la información del Data

Warehouse, como por ejemplo Business Models10.

4. Los usuarios acceden a los cubos multidimensionales, Business Models (u otro

tipo de estructura de datos) del Data Warehouse utilizando diversas

herramientas de consulta, exploración, análisis, generación de informes, entre

otras.

A continuación se detalla cada uno de los componentes de la arquitectura del Data

Warehouse, teniendo como referencia la Figura 3, resaltando el tema en concreto que

se vaya tratando.

I.1.3.1.1 OLTP Online Transaction Processing

Figura 4:Online Transaction Procesing

Los sistemas OLTP están diseñados para gestionar un gran número de peticiones

concurrentes sobre sus bases de datos. Están enfocados a que cada operación —

transacción— trabaje con pequeñas cantidades de filas, y a ofrecer una respuesta

rápida. Habitualmente utilizan Sistemas de Bases de Datos Relacionales (SGBDR)

para gestionar los datos y suelen estar altamente normalizados.

OLTP representa toda aquella información transaccional que genera la empresa en su

día a día, además de fuentes externas que puede llegar a disponer.

I.1.3.1.2 Load Manager

Figura 5: Load Manager

10 Business Models describe los fundamentos de cómo una organización crea, entrega y captan valores (económicos,sociales, u otras formas de valor).

19

20 Chapter I

En un Data Warehouse se cargan y unifican periódicamente información procedente de

múltiples fuentes, esto implica que deben existir una serie de procesos que leen los

datos de las diferentes fuentes, los transforman, los adaptan al modelo que se haya

definido, los depuran y limpian para luego introducirlos en el Data Warehouse. Esto es

lo que se conoce como procesos ETL —Procesos de Extracción, Transformación y

Carga o Load.

Figura 6: Proceso ETL

A continuación se detalla cada una de estas etapas, donde se expone cuál es el

proceso que llevan a cabo los ETL y se enumera cuáles son sus principales tareas.

Extracción.- Consiste en extraer los datos desde los sistemas de origen. La

mayoría de los proyectos de almacenamiento de información fusionan datos

provenientes de diferentes sistemas de origen, donde cada sistema puede usar

una organización diferente de los datos o formatos distintos. La extracción los

convierte a un formato preparado para iniciar el proceso de transformación.

Una vez que los datos son seleccionados y extraídos, se guardan en un

almacenamiento intermedio, lo cual permite manipular los datos sin interrumpir

ni paralizar los OLTP ni el Data Warehouse.

Transformación: En estos procesos es preciso asegurar que los datos sean

válidos, íntegros y útiles, lo que suele incluir realizar cálculos y generar nuevos

valores. Los datos deben ser depurados para eliminar inconsistencias,

discrepancias y duplicidades. Los casos más comunes en los que se debe

realizar una transformación son los mostrados en la Tabla 2 .

Tabla 2: Casos más comunes de transformaciones ETL

Codificación

Al integrar varias fuentes de datos puede existir más de unaforma de codificar un atributo en común. Ejemplo: En el camposexo algunos diseñadores definen su valor como “M” y “F” otros“Mujer” y “Hombre”. Se debe escoger una forma común paradecodificar los atributos.

Medida de atributos

Los tipos de unidades de medidas utilizados para representar losatributos de una entidad varían considerablemente entre sí, através de los diferentes OLTP. Por ejemplo, al registrar la longitudde un producto determinado, las unidades de medidas puedenser explicitadas en centímetros, metros, pulgadas, etc. Sedeberán estandarizar las unidades de medidas de los atributos,para que todas las fuentes de datos expresen sus valores deigual manera.

Convenciones de

nombramiento

Usualmente, un mismo atributo es nombrado de diversasmaneras en los diferentes OLTP. Por ejemplo, al referirse alnombre del proveedor, puede hacerse como “nombre”,“razón_social”, “proveedor”. Aquí, se debe utilizar la convenciónde nombramiento que para los usuarios sea más comprensible

Fuentes múltiplesUn mismo elemento puede derivarse desde varias fuentes. Eneste caso, se debe elegir aquella fuente que se considere másfiable y apropiada.

20

Tabla 2: Casos más comunes de transformaciones ETL

Limpieza de datos

Su objetivo principal es el de realizar distintos tipos de accionescontra el mayor número de datos erróneos, inconsistentes,irrelevantes o datos faltantes o Missing Values. Las accionesmás comunes son: ignorarlos, eliminar la columna, filtrar lacolumna, reemplazar valor o filtrar fila errónea

Carga.- Esta función se encarga, por un lado de realizar las tareas

relacionadas con:

o Carga Inicial (Initial Load). Es el proceso de incorporar los datos al

Data Warehouse

o Actualización o mantenimiento periódico. Antes de realizar una nueva

actualización, es necesario identificar si se han producido cambios en

las fuentes originales de los datos recogidos, desde la fecha del último

mantenimiento, a fin de no atentar contra la consistencia del Data

Warehouse.

I.1.3.1.3 Data Warehouse Manager

Figura 7: Data Warehouse Manager

Si bien existen diversas estructuras de datos, a través de las cuales se puede

representar los datos del DW, solamente se entrará en detalle en los cubos

multidimensionales, por considerarse que esta estructura de datos es una de las más

utilizadas.

Un cubo multidimensional o hipercubo, representa o convierte los datos planos que se

encuentran en filas y columnas, en una matriz de N dimensiones.

Los datos se organizan en “hechos”, que tienen unos atributos o medidas que pueden

verse en mayor o menor detalle según ciertas “dimensiones”. Por ejemplo, una cadena

de supermercado puede tener como hechos las ventas. Cada venta tiene unas

medidas: importe, cantidad, número de clientes, etc., y se pueden detallar o agregar

varias dimensiones: tiempo de la venta, producto de la venta, lugar de la venta etc. Es

esclarecedor comprobar que las medidas responden generalmente a la pregunta

“cuánto”, mientras que las dimensiones responderán al “cuanto”,”que”,”donde”, etc.

El modelo dimensional es una adaptación del modelo relacional, con el fin de

optimizarlo para dar una rápida respuesta a las consultas realizadas por los usuarios.

Aunque a nivel físico, una vez implementado en un Sistema Gestor de Bases de Datos

21

22 Chapter I

Relacionales, lo que allí se encuentra son tablas y relaciones entre ellas, a nivel

conceptual conocer que existen dos tipos de tablas en un modelo dimensional:

Tablas de dimensiones.- Definen como están los datos organizados

lógicamente y proveen el medio para analizar el contexto del negocio

Tablas de hechos.- Son datos instantáneos en el tiempo, que son filtrados,

agrupados y explorados a través de condiciones definidas en las tablas de

dimensiones.

Las bases de datos multidimensionales implican tres variantes posibles de modelado,

que permiten realizar consultas orientadas a la toma de decisiones, representados en

los siguientes esquemas:

Esquema en estrellas

Esquema en copo de nieve

Esquema constelación

Estos esquemas pueden ser implementados de diversas maneras que,

independientemente al tipo de arquitectura, requieren que toda la estructura de datos

este desnormalizada o semi desnormalizada, para evitar desarrollar uniones complejas

de acceso a la información, con el fin de agilizar la ejecución de consultas. Los

diferentes tipos de implementación son: relacional, multidimensional e híbrido

A continuación se entra en detalle en los diferentes tipos de tablas —dimensiones y

hechos— indicadas anteriormente, así como las características de un cubo

multidimensional y los diferentes esquemas de modelado de un DW.

Tablas de dimensiones

Las tablas de dimensiones definen como están los datos organizados lógicamente y

proveen el medio para analizar el contexto del negocio. Contienen datos cualitativos.

En la Figura 8 podemos ver varias tablas dimensión con sus correspondientes

atributos.

Figura 8: Tablas de Dimensiones

A veces estos atributos están organizados en jerarquías para describir niveles de

agrupamiento específicos explícitos o implícitos) y, por tanto, las diferentes

granularidades o niveles de detalle en la visión de los datos. Las jerarquías forman

distintos niveles, relacionados entre sí, y son utilizados para realizar operaciones

de agrupamiento. Por ejemplo la jerarquía correspondiente a la dimensión tiempo

podría estar formada por los atributos Año, Mes y Día. Los diferentes tipos de

22

jerarquías que se pueden establecer para describir niveles de agrupamiento

específicos se pueden observar en la Figura 9 y se describen en la Tabla 3.

Figura 9: Esquema de organización jerárquica de las dimensiones

Tabla 3: Organización jerárquica de las dimensiones

Dimensiones

degeneradas

Este término hace referencia a un campo que será utilizado como criterio de análisis yque es almacenado en la tabla de hechos.Esto sucede cuando un campo que se utiliza como criterio de análisis posee el mismonivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no sepueden realizar agrupaciones o sumarizaciones a través de este campo, como porejemplo "números de orden", "números de ticket", "números de transacción", etc.

Atributos no

dimensión

Los niveles de la jerarquía también pueden tener atributos descriptivos, donde no sonutilizados para formar niveles de jerarquía, sino para describir detalles en los mismos,como por ejemplo, el número de teléfono, la dirección de correo electrónico, etc.

JerárquicasDescriben diferentes niveles de agrupamiento específicos —explícitos o implícitos— y,por lo tanto, las diferentes granularidades o niveles de detalle en la visión de los datos,como por ejemplo la jerarquía formada por Año, Trimestre, Mes y Día

En las tablas dimensiones, habitualmente no es posible utilizar la clave de negocio —

business key— como clave principal —primary key— e incluso, en el caso que sea

posible, no es aconsejable por temas de rendimiento, ya que desde este punto de vista

es recomendable utilizar número enteros de pocos bytes. Si en un sistema

transaccional tenemos, por ejemplo, una clave principal con dominio char(10), siempre

será más óptimo utilizar un tipo de datos numérico de menos byte como clave principal

en las tablas dimensiones. Se sustituirán las habituales clave de negocio por claves

subrogadas —subrogate key— las cuales serán de tipo numérico y habitualmente

autoincremental. Esta clave no tiene sentido a nivel de negocio, pero la necesitamos

para identificar de forma única cada una de las filas.

Un concepto importante dentro de este apartado son las dimensiones lentamente

cambiantes o Slowly Changing Dimensions (SCD). Son dimensiones en las cuales sus

datos tienden a modificarse a través del tiempo, ya sea de forma ocasional o constante,

o implique a un solo registro o a la tabla completa. Cuando ocurren estos cambios, se

puede optar por seguir alguna de estas dos grandes opciones:

Registrar el historial de cambios.

Reemplazar los valores que sean necesarios.

23

24 Chapter I

Inicialmente Ralph Kimball11 planteó tres estrategias a seguir cuando se tratan las SCD:

tipo 1, tipo 2 y tipo 3, pero, a través de los años, la comunidad de personas que se

encargaba de modelar bases de datos profundizó las definiciones iniciales e incluyó

varios tipos SCD más, como tipo 4 y tipo 6. A continuación se detalla cada tipo de

estrategia SCD:

SCD Tipo 1: Sobreescribir.

SCD Tipo 2: Añadir fila.

SCD Tipo 3: Añadir columna.

SCD Tipo 4: Tabla de Historia separada.

SCD Tipo 6: Híbrido.

De acuerdo a la naturaleza del cambio se debe seleccionar qué Tipo SCD se utilizará y,

en algunos casos, resultará conveniente combinar varias técnicas.

Tablas de Hechos

Las tablas de hechos representan un proceso de negocio, como por ejemplo, las

ventas, las compras, los pagos entre otras. Estas tablas son utilizadas por los analistas

de negocio para apoyar el proceso de toma de decisiones. Contienen datos

cuantitativos.

Los hechos son datos instantáneos en el tiempo, que son filtrados, agrupados y

explorados a través de condiciones definidas en las tablas de dimensiones. El registro

de hecho posee una clave primaria que está compuesta por las claves primarias de las

tablas de dimensiones relacionadas a este.

Figura 10: Tabla de hecho “Ventas”

En la Figura 10 se aprecia la tabla de hechos “VENTAS” ubicada en el centro y

conectada a ella, mediante sus claves primarias, se encuentran las tablas de

dimensiones “CLIENTES”, “PRODUCTOS” y “FECHAS”. Es por ello que la clave

primaria de la tabla de hechos es la combinación de las claves primarias de sus

dimensiones. Los hechos en este caso son “ImporteTotal” y “Utilidad”.

11 Ralph Kimball reconocido como uno de los padres del concepto de Datawarehouse, se ha dedicado desde hace yamás de 10 años al desarrollo de su metodología para que este concepto sea bien aplicado en las organizaciones y seasegure la calidad en el desarrollo de estos proyectos.

24

Es importante a la hora de diseñar una tabla de hechos, tener en cuenta el nivel de

granularidad que va a tener, es decir, el nivel de detalle más atómico que vamos a

encontrar de los datos: no es lo mismo tener una fila por cada venta, que una fila donde

se indiquen las ventas del día para cada artículo y tienda.

Existen dos tipos de hechos:

Hechos básicos.- Se encuentran representados por un campo de una tabla de

hechos. Los campos “precio” y “cantidad” de la Figura 11 son hechos básicos.

Hechos derivado.-: Se forman al combinar uno o más hechos con alguna

operación matemática o lógica y que también residen en una tabla de hechos.

El campo “total” de la Figura 11 es un hecho derivado, ya que se conforma de

la siguiente manera: total = precio * cantidad.

Figura 11: Hechos Básicos y Derivados

Otro concepto importante a tener en cuenta es la agregación, proceso por el cual se

resumen los datos a partir de las filas de detalle de máxima granularidad.

Cubo Multidimensional

Como se ha comentado, si bien existen diversas estructuras de datos, a través de las

cuales se puede representar los datos del DW, solamente se entrará en detalle en los

cubos multidimensionales.

Los objetos más importantes que se pueden incluir en un cubo multidimensional son

los siguientes:

Indicadores.- Sumarizaciones que se efectúan sobre algún hecho o

expresiones pertenecientes a una tabla de hechos.

Atributos de dimensión.- Campos o criterios de análisis, pertenecientes a tablas

de dimensiones.

Jerarquías de dimensiones.- Representa una relación lógica entre dos o más

atributos.

Se puede observar, que el resultado del análisis está dado por los cruces matriciales de

acuerdo a los valores de las dimensiones seleccionadas.

Más específicamente, para acceder a los datos del Data Warehouse, se pueden

ejecutar consultas sobre algún cubo multidimensional previamente definido. Dicho cubo

debe incluir, entre otros objetos, indicadores, atributos y jerarquías basados en los

campos de las tablas de dimensiones y de hechos que se deseen analizar. De esta

manera, las consultas se responden con un alto rendimiento, minimizando al máximo el

25

26 Chapter I

tiempo que hubiese incurrido en realizar dicha consulta sobre una base de datos

transaccional.

Como ejemplo, en la Figura 12 se representa un cubo tridimensional donde las

dimensiones producto, lugar y tiempo se han agregado por artículo, ciudad y trimestre.

La representación de un hecho corresponde a una casilla de dicho cubo, el valor de la

casilla es la medida observada, importe de ventas, concretamente el hecho que se

observa en dicha figura muestra que “el primer trimestre de 2004 la empresa vendió en

Valencia por un importe de 22.00 euros el producto Androbio 33cl”

Figura 12: Ejemplo cubo multidimensional

Resaltar que un cubo no es más que una base de datos multidimensional, en la cual el

almacenamiento físico de los datos se realiza en un vector multidimensional.

Indicadores de rendimiento clave o KPI

Los indicadores de rendimiento clave (KPI) son métricas financieras o no, utilizadas

para cuantificar objetivos que reflejan el rendimiento de una organización,

recogiéndose generalmente en su plan estratégico. Estos indicadores son utilizados en

BI para asistir o ayudar, al estado actual de un negocio, a prescribir una línea de acción

futura. Los indicadores de rendimiento son frecuentemente utilizados para "valorar"

actividades complicadas de medir como los beneficios de desarrollos líderes, eficiencia

de empleados, servicio o satisfacción de un cliente.

Los KPIs deberían preferiblemente cumplir los siguientes criterios esenciales (SMART):

eSpecificos (Specific)

Medibles (Measurable)

Alcanzables (Achievable)

Realista (Realistic)

a Tiempo (Timely)

Atributos

Los atributos constituyen los criterios que se utilizan para analizar los indicadores

dentro de un cubo multidimensional. Los mismos se basan, en su gran mayoría, en los

campos de las tablas de dimensiones y/o expresiones. Dentro de un cubo

multidimensional, los atributos son los ejes del mismo.

26

Jerarquías

Como se comentó en el apartado Data Warehouse Manager de tablas de dimensión,

una jerarquía representa una relación lógica entre dos o más atributos pertenecientes a

un cubo multidimensional. Pueden existir varias en un mismo cubo.

La principal ventaja de manejar jerarquías, reside en poder analizar los datos desde su

nivel más general al más detallado y viceversa, al desplazarse por los diferentes

niveles.

Figura 13: Jerarquía fecha

Esquemas de modelado de un Data Warehouse

Los tipos de esquemas de modelado de un Data Warehouse son los siguientes:

Esquema en estrella.- Consta de una tabla de hechos central y de varias tablas

de dimensiones relacionadas a esta por sus claves. Este modelo debe estar

totalmente desnormalizado. En la Figura 14 se puede apreciar un esquema en

estrella.

Figura 14: Esquema en estrella

Esquema en copo de nieve.- Es una estructura algo más compleja que el

esquema en estrella. Se da cuando alguna de las dimensiones se implementa

con más de una tabla de datos y/o estas se organizan en jerarquías de

dimensiones. La Figura 15 muestra un ejemplo de esquema en copo de nieve.

27

28 Chapter I

Figura 15: Esquema en copo de nieve

Esquema constelación.- Está compuesto por una serie de esquemas en

estrellas, tal como se puede apreciar en Figura 16 No es necesario que las

diferentes tablas de hechos compartan las mismas dimensiones.

Figura 16: Esquema en constelación

En la Tabla 4 se puede observar un resumen comparativo de ambos esquema.

Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse

Modelo Ventajas Inconvenientes

Estrella

La desnormalización permite obviaruniones —Join— entre las tablascuando se realizan consultas,procurando así un mejor tiempo derespuesta y una mayor sencillez conrespecto a su utilización

Más simple de interpretar

Optimiza los tiempos de respuesta ante las consultas

La desnormalización con la que cuentagenera un cierto grado de redundancia

Necesidad de mayor espacio dealmacenamiento

Menos robusto para la carga

Es el más lento de construir

Copo de nieve

Posibilidad de segregar los datos delas tablas de dimensiones y proveer unesquema que sustente losrequerimientos de diseño.

Muy flexible y puede implementarsedespués de que se haya desarrolladoun esquema en estrella.

Hace una mejor utilización del espacio.

Puede desarrollar clases de jerarquíasfuera de las tablas de dimensiones,que permiten realizar análisis de logeneral a lo detallado y viceversa.

Si se poseen múltiples tablas dedimensiones, cada una de ellas convarias jerarquías, se creará un númerode tablas bastante considerable, quepueden llegar al punto de serinmanejables

Al existir muchas uniones y relaciones entre tablas, el desempeño puede verse reducido

La existencia de las diferentes jerarquíasde dimensiones debe estar bienfundamentada, ya que de otro modo lasconsultas demorarán más tiempo en

28

Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse

devolver los resultados, debido a que sedeben realizar las uniones entre lastablas.

Constelación

Permite tener más de una tabla dehechos, por lo cual se podrán analizarmás aspectos claves del negocio conun mínimo esfuerzo adicional dediseño.

Contribuye a la reutilización de lastablas de dimensiones, ya que unamisma tabla de dimensión puedeutilizarse para varias tablas de hechos.

No es soportado por todas las herramientas de consulta y análisis

Data Warehouse vs OLTP

Debido a que, ya se han explicado y caracterizado los distintos tipos de esquemas del

DW, se procederá a exponer las razones de su utilización, como también las causas de

por qué no se emplean simplemente las estructuras de las bases de datos

tradicionales. Esta comparación se puede ver en la Tabla 5.

Tabla 5: OTLP VS Data Warehouse

OLTP Data Warehouse

ObjetivoSoportar actividades transaccionales

Consultar y analizar información estratégica y táctica

Tiempo de datos Operacionales Para la toma de decisiones

Modelo de datos Normalizado Desnormalizado

Consulta SQL SQL más extensiones

Datos consultados 60-90 días 5-10 años

Tipos de consultas Repetitivas, predefinidas No previsibles, dinámicas

Nivel de almacenamiento Nivel de detalleNivel de detalle y diferentes niveles de sumarización

Acciones disponibles Alta, baja, modificación y consulta Carga y consulta

Número de transacciones Elevado Medio o bajo

Tamaño Pequeño-Mediano Grande

Tiempo de respuesta Pequeño Variable

Orientación Orientado a las aplicaciones Orientado al negocio

Sello de tiempoLa clave puede o no tener un elemento de tiempo

La clave tiene un elemento de tiempo

Estructura Generalmente estableGeneralmente varía de acuerdo a su propia evolución y utilización

29

30 Chapter I

Implementación de un Data Warehouse

Los distintos tipos de implementación de un Data Warehouse son los siguientes:

1. Implementación ROLAP (Procesamiento Analítico Online Relacional).- Se trata de

sistemas y herramientas OLAP (Online Analytic Processing) construidos sobre una

base de datos relacional. Típicamente, los datos son detallados, evitando las

agregaciones, y las tablas se encuentran normalizadas. Los esquemas más

comunes sobre los que se trabaja son estrella o copo de nieve, aunque es posible

trabajar sobre cualquier base de datos relacional. La arquitectura está compuesta

por un servidor de banco de datos relacional y el motor OLAP se encuentra en un

servidor dedicado. La principal ventaja de esta arquitectura es que permite el

análisis de una enorme cantidad de datos.

2. Implementación MOLAP (Multidimensional Online Analytical Processing o

'Procesamiento Analítico Multidimensional en línea'). Se trata de una alternativa a

la tecnología ROLAP (OLAP-Relacional). Aunque ambos tipos de herramientas

están diseñadas para realizar análisis de datos a través de un modelo de datos

multidimensional, MOLAP se diferencia significativamente en que requiere un

preprocesamiento y almacenamiento de la información contenida en el cubo OLAP.

MOLAP almacena estos datos en una matriz de almacenamiento multidimensional

optimizada, más que en una base de datos relacional (o en un ROLAP). Para

optimizar los tiempos de respuesta, el resumen de la información es usualmente

calculado por adelantado. Estos valores precalculados o agregaciones son la base

de las ganancias de desempeño de este sistema. Algunos sistemas utilizan

técnicas de compresión de datos para disminuir el espacio de almacenamiento en

disco debido a los valores precalculados.

3. Implementación HOLAP (Hybrid Online Analytical Process o Procesamiento

Analítico en línea Híbrido). Es una combinación de ROLAP y MOLAP. HOLAP

permite almacenar una parte de los datos como en un sistema MOLAP y el resto

como en uno ROLAP. El grado de control que el operador de la aplicación tiene

sobre este particionamiento varía de unos productos a otros.

I.1.3.1.4 Query Manager

Figura 17: Query Manager

Este componente realiza las operaciones necesarias para soportar los procesos de

gestión y ejecución de consultas relacionales y de consultas propias de análisis de

30

datos, es decir, Query Manager recibe las consultas de los usuarios, las aplica a la

estructura de datos correspondiente —cubo multidimensional, Business Models, etc..—

y devuelve los resultados obtenidos.

Cabe aclarar que una consulta a un DW, generalmente consiste en la obtención de

indicadores a partir de los datos —hechos— de una tabla de hechos, restringidas por

las propiedades o condiciones de los atributos que hayan sido creados.

El procesamiento analítico en línea OLAP, es la componente más poderosa de un Data

Warehouse, ya que es el motor de consultas especializadas del Data Warehouse. Las

herramientas OLAP, son una tecnología de software para análisis en línea,

administración y ejecución de consultas, que permiten inferir información del

comportamiento del negocio.

Su principal objetivo es el de brindar rápidas respuestas a complejas preguntas, para

interpretar la situación del negocio y tomar decisiones. Cabe destacar que lo que es

realmente interesante en OLAP, no es la ejecución de simples consultas tradicionales,

sino la posibilidad de utilizar operadores, como se muestran en la Tabla 6, que permitan

profundizar en la información.

Tabla 6: Operaciones definidas dentro de un Data Warehouse

Drill-downPermite apreciar los datos en un mayor detalle, bajando por una jerarquíadefinida en un cubo. Esto brinda la posibilidad de introducir un nuevo nivel ocriterio de agregación en el análisis, disgregando los grupos actuales

Drill-upPermite apreciar los datos en menor nivel de detalle, subiendo por una jerarquíadefinida en un cubo. Esto brinda la posibilidad de quitar un nivel o criterio deagregación en el análisis, agregando los grupos actuales.

Drill-acros Funciona de forma similar a drill-down, con la diferencia que drill-across no serealiza sobre una jerarquía, sino que su forma es ir de lo general a lo específico,agregando un atributo a la consulta como nuevo criterio de análisis.

Roll-across

Funciona de forma similar a drill-up, con la diferencia que roll-across no se hacesobre una jerarquía, sino que su forma de ir de lo específico a lo general esquitar un atributo de la consulta, eliminando de esta manera un criterio deanálisis.

Drill-throughPermite apreciar los datos en su máximo nivel de detalle. Esto brinda laposibilidad de analizar cuáles son los datos relacionados al valor de unIndicador, que se ha sumarizado dentro del cubo multidimensional.

I.1.3.1.5 Herramienta de consulta y análisis

31

32 Chapter I

Figura 18: Herramienta de consulta y análisis

Las Herramienta de Consulta y Análisis son sistemas que permiten a los usuarios

realizar la exploración de datos del Data Warehouse, constituyendo la unión entre el

Data Warehouse y los usuarios.

A través de una interfaz gráfica y una serie de pasos, los usuarios generan consultas

que son enviadas desde la Herramienta de Consulta y Análisis al Data Warehouse,

devolviendo los resultados obtenidos a la herramienta que se los solicitó. Luego estos

resultados son expuestos antes los usuarios en formatos que le sean familiares.

Algunas de las interfaces a través de las cuales podemos representar los resultados de

las consultas pueden ser: Cuadros de mando12

Informes estáticos13

Informes dinámicos

I.1.3.1.5.1 Usuarios

Figura 19: Usuarios

Los usuarios que posee el Data Warehouse son aquellos que se encargan de tomar

decisiones y de planificar las actividades del negocio, es por ello que se hace tanto

énfasis en la integración, limpieza de datos, etc, para poder conseguir que la

información posea toda la calidad posible.

Es a través de las herramientas de consulta y análisis, que los usuarios exploran los

datos en busca de respuestas para poder tomar decisiones proactivas. La diferencia

entre un usuario OLTP y otro Data Warehouse se ven reflejadas en la Tabla 7.

12 Los cuadros de mandos se pueden entender como una colección de informes, consultas y análisisinteractivos que hacen referencia a un tema en particular y que están relacionados entre sí.

13 La elección de uno u otro tipo de informe dependerá fundamentalmente del uso que se pretenda dar adichos informes.

32

Tabla 7: Usuarios OLTP vs usuarios Data Warehouse

Usuarios OLTP Usuarios Data Warehouse

Acceso concurrente Muchos Pocos

Tipo de consultas PredefinidasComplejas, no predecibles y noanticipadas

Registros consultados Pocos Muchos

Tiempo de respuesta Crítico No crítico

Acciones permitidasAgregar, modificar,eliminar y consultar

Consultar

I.1.3.1.6 Conceptos complementarios: Datamarts

Un Datamarts (DM) es una versión especial del Data Warehouse. Son subconjuntos de

datos con el propósito de ayudar a que un área específica dentro del negocio pueda

tomar mejores decisiones. Los datos existentes en este contexto pueden ser

agrupados, explorados y propagados de múltiples formas para que diversos grupos de

usuarios realicen la explotación de los mismos de la forma más conveniente según sus

necesidades.

En síntesis, se puede decir que los Datamarts son pequeños Data Warehouse

centrados en un tema o un área de negocio específico dentro de una organización.

Por ejemplo la información de personal de una empresa —empleados, departamento,

proyectos— es difícilmente integrable en un mismo modelo de estrella de ventas.

Incluso en ámbitos más relacionados de una organización, ventas y producción no

resulta fácil. La solución está en que para cada subámbito de la organización se va a

construir una estructura en estrella. Por tanto, el Data Warehouse estará formado por

muchas estrellas, cada una de estas estrellas es un Datamarts. Lógicamente cada

Datamart tendrá unas medidas y dimensiones propias y diferentes de los demás, la

única dimensión que suele aparecer en todos los Datamarts es la dimensión tiempo, ya

que el Data Warehouse representa información histórica.

Figura 20: Datamarts

33

34 Chapter I

Capítulo 2. ITOP Management Consulting

Resumen:

ITOP MC es una empresa de consultaría de Negocios y Gestión Empresarial con la que se

ha colaborado en la consecución de este proyecto. En términos BI, la empresa ITOP

desempeña el papel de Product Owner.

2.1 La empresa

ITOP Management Consulting (ITOP MC) es una empresa experta en Consultoría de

Negocios y Gestión Empresarial, especializada en Tecnologías de la Información, que

ofrece sus servicios de gestión global a las PYMEs, colaborando con una red sólida de

partners y con compañías punteras pertenecientes al sector informático y empresarial.

ITOP Management Consulting nace en el año 2006 como una iniciativa de varios

socios con más de 10 años de experiencia en el mundo de la Consultoría de

Tecnologías de la Información. El objetivo principal de la creación de esta consultora es

ofrecer a la empresa canaria un servicio local de calidad en este terreno de la

consultoría cuya demanda y dependencia de empresas de la península es muy

grande y ofrecer una oportunidad al consultor que, habiendo desarrollado su carrera

fuera de las islas, quiera volver a ellas pero con el condicionante de encontrar una

empresa en la que pueda seguir evolucionando de forma profesional, y en unas

condiciones similares a las empresas en las que ha estado trabajando.

La experiencia de los socios actuales se ha desarrollado en empresas de gran prestigio

y experiencia dentro del sector de la consultoría a nivel nacional e internacional tales

como: CSC, Indra, Unisys, Realtech, SAP, etc.

Alguno de los clientes con los que se ha trabajado en diferentes proyectos han sido:

Repsol, Telefónica, Bayer, GlaxoWellcome, ICEX, Turespaña y un largo etcétera.

2.2 Filosofía

La integración horizontal que pretende ITOP con todos sus clientes hace que éstos

evolucionen hacia el concepto de socios-clientes. La empresa es consciente de que

tiene mucho que aportar en el crecimiento de sus clientes, al igual que ellos les facilitan

la energía necesaria para seguir creciendo e invirtiendo en ideas. La filosofía de la

empresa queda reflejada en el nombre ITOP —Información, Tecnología, Organización,

Procesos.

34

2.3 Alianzas

Las principales alianzas y áreas de experiencia del equipo de ITOP MC son:

• HP

• Microsoft

• SAP

SAP Business One

SAP R/3

35

36 Chapter I

Capítulo 3. Descripción del problema e integración de soluciones tecnológicas

Resumen:

En este capítulo se describe el estudio realizado a lo largo del proyecto para la elección de

las tecnologías por las que se iban a apostar para la construcción de una solución BI.

3.1 Introducción

Sap Business One (Sap BO) es una única aplicación de gestión empresarial integrada

integra todas las funciones empresariales básicas necesarias en cualquier empresa

(incluye gestión financiera, ventas, gestión de atención al cliente, e-commerce, gestión

de inventarios y operaciones).

El problema a abordar consiste en integrar SAP BO con una solución BI, de forma que

proporcione a las Pymes informes gráficos y cuadros de mando interactivos que

ofrezcan una mayor versatilidad, control de los ingresos, los márgenes y la liquidez.

Con esta aplicación de BI, se ofrece funcionalidades para la gestión del conocimiento

que ayudan a las empresas a poner en contacto a "aquellos que saben" con "aquellos

que necesitan saber".

3.2 Análisis funcional y elección

En este capítulo se describe el estudio realizado a lo largo del proyecto para la elección

de las tecnologías por las que se iban a apostar para la construcción de una solución

BI.

3.2.1 Análisis Inicial

La evolución del Business Intelligence (BI) durante los últimos 10 años ha sido muy

interesante, sobre todo en la manera en cómo se han simplificado el desarrollo e

implantación de proyectos de este tipo, gracias a las tecnologías que han sabido

adaptarse a las necesidades de los usuarios, tanto de perfil desarrollador como

usuarios finales.

En el año 1998 el esfuerzo era realmente muy grande para poder plasmar en un

informe las necesidades del usuario final, con el fin de que pudiera realizar un

monitoreo y análisis de la información. En aquel momento las herramientas eran algo

primitivas, en cuanto a la presentación de los datos y al desarrollo de las mismas,

36

teniendo muchas restricciones de formatos en los que se podía mostrar la información.

En consecuencia, se tenían que implementar desarrollos adicionales con el objetivo de

complementar las herramientas de BI existentes. El escenario típico era el desarrollo

en Visual Basic; con este lenguaje se creaba una aplicación de presentación enfocada

a un ambiente más ejecutivo, amigable, permitiéndoles a los usuarios finales de la

herramienta de BI realizar un análisis con el ya famoso término "Drill Down", que en

aquellos tiempos era lo último en tecnología14.

Con el tiempo la historia fue cambiando y ahora existen innumerables tecnologías para

llevar a cabo una solución BI, tanto con herramientas propietarias como con

OpenSource, cuyas dos vertientes también fueron analizadas en este proyecto.

I.3.2.1.1 Análisis de una solución BI con Software privativo.

Por la parte del Software privativo se encontró que existían muchas empresas

dedicadas a desarrollar software que facilita el desarrollo de una solución BI. Para

conocer cuáles de ellas eran las líderes se procedió al estudio del cuadrante de

Gartner del año 2010. Gartner es una empresa consultora, la cual realiza y publica una

serie de análisis, de las más fiables referencias, para conocer el estado y nivel de

madurez de los proveedores de BI más influyentes de la actualidad. En la Figura 21

muestra el análisis de Gartner del 2010:

En el eje X “completeness of visión” se representa el conocimiento de los

proveedores indicando cómo se puede aprovechar el momento actual del

mercado para generar valor, tanto para sus clientes como para ellos mismos.

En el eje Y “ability to execute” trata de querer medir la habilidad de los

proveedores para ejecutar con éxito su visión del mercado.

14 The Datawarehouse Toolkit de Ralph Kimball

37

38 Chapter I

Figura 21: Cuadrante de Gartner BI 2010

Estos dos baremos dividen al cuadrante en cuatro sectores en donde se clasifican los

proveedores estudiados.

Leaders: Esta categoría, en principio, es la mejor. Situarse aquí significa haber

puntuado alto en los dos ejes de medidas, por lo que se puede esperar de

estos proveedores una solución de productos amplia, completa y madura, que

evoluciona según demanda el mercado. Por otra parte también nos sugiere

que el proveedor goza de buena salud como empresa y que dispone de

medios suficientes para implantar con éxito su solución en variados escenarios.

Visionaries: En esta categoría entrarían aquellos proveedores con una buena

puntuación en “completeness of visión” pero peor puntuación en “ability to

execute”. Por lo tanto aquí estarán las empresas con una fuerte y acertada

visión del mercado actual en Business Intelligence. Sin embargo, a pesar de

sus buenas ideas, aún puede que no tengan la capacidad para llevar

implantaciones, bien sea por su tamaño o por otras circunstancias.

Challengers: Este es el caso contrario al de los Visionaries. Se trata de

proveedores bien posicionados y que ofrecen altas posibilidades de éxito a la

hora de implantar su solución. No obstante, suelen ofrecer poca variedad de

productos, o directamente centrarse en un único aspecto de lo que demanda el

mercado. También puede ocurrir que se trate de un déficit en su canal de

ventas o presencia geográfica.

Niche Players: La última categoría en principio es la más desfavorable. Son

proveedores que no llegan a puntuar lo suficiente en ninguna categoría como

para alcanzar uno de los otros cuadrantes. No obstante, no significa que por

ello sus soluciones no tengan calidad. Por otra parte, la falta de puntuación en

“completeness of visión” nos da una idea de que estos proveedores no están

38

evolucionando sus soluciones suficientemente rápido y de alguna manera

están perdiendo parte de la perspectiva.

Una vez visto que representan las diferentes áreas del cuadrante de Gartner, se

analiza como Oracle y Microsoft, consolidadas en el año 2010 como las empresas

líderes en producto BI, son las mejores por lo cual se decide apostar por Microsoft

como una opción muy interesante para desarrollar este proyecto —destacar además

que la empresa ITOP MC ya poseía una serie de licencias por lo que no habría que

realizar una nueva inversión a priori.

Para poder implantar una solución BI usando tecnologías de Microsoft es necesario los

requerimientos que se muestran en la Tabla 8, resumidos en la Figura 22.

Tabla 8: Requerimientos tecnológicos básicos para una solución BI con Microsoft

Requerimientos de Software ¿Qué solución necesitamos? ¿Qué nos aporta?

Sistema Operativo Windows 2008 R2 64bits

Conexiones remotas, trabajo

concurrente y Sistema Operativo

Windows convencional

Servidor de Integración dedatos

SQL Server 2008 R2 Integration

Services (SSIS)

Servidor para realizar y planificar el

proceso de Extracción,

Transformación y Carga de los

datos de origen

Servidor de Base de datosAnalista o OLAP

SQL Server 2008 R2 Analisys

Servicies (SSAS)

Análisis y optimización de los datos

almacenados en el DW

Sistema gestor de base dedatos SQL Server 2008 R2 64bits

Gestión y creación de almacén de

datos

Servidor de InformesSQL Server 2008 R2 Reporting

Services (SSRS)

Representación de informes

alimentados desde un Cubo OLAP

Cuadros de mando

Crystal Xcelsius 2008 (No

pertenece a Microsoft pero está

totalmente integrada, con

cualquier producto de esa

empresa)

Cuadros de mando dinámicos

basados en Flash, exportables a

Excel, PDF, etc.

SharePoint Foundation 2010 +

Performance Point

Diseñador de cuadro de mando

integrables en los portales Web

corporativos Share Point

Silverlight 4.0Cuadros de mando dinámicos y con

conexión directa al cubo OLAP

Microsoft Office Excel 2007 +

Power Pivot

Tablas y cuadros de mando

dinámicos con conexión directa a los

cubos OLAP

39

40 Chapter I

Figura 22: Solución tecnológica propuesta para una solución BI usando herramientas Microsoft

Se realizó además una comparación de las características que nos aporta cada una de

las herramientas de presentación y cuadros de mando, indicada en la Tabla 9. Con

respecto a la parte de Sistema Gestor de Bases de Datos y Sistema Operativo se parte

del punto que los clientes, a los que se les quieres implantar la solución BI, ya tienen

disponibles el software necesario derivado de la contratación ERP SAP BO, así como

el deseo por parte de ITOP MC de la importancia del uso de Share Point para tener

acceso, tanto externo como interno, a sus cuadros de mando por parte de sus clientes

desde cualquier parte y dispositivo.

Tabla 9: Tabla comparativa del Software de representación

SSRSCrystal

XcelsiusPerformance

PointSilverlight

MicrosoftExcel

PublicaciónSharePoint

Característicasinteractivas

Programables (SDK)

Interfaz Amigable

Integración conSAP

Publicables enWeb

40

Tabla 9: Tabla comparativa del Software de representación

SSRSCrystal

XcelsiusPerformance

PointSilverlight

MicrosoftExcel

Facilidad de uso

Costo de licenciaaceptable

Valoración final

En mayor o menor medida las cuatro herramientas se ajustan a las necesidades por

tanto se escogieron dos y el resto quedaron estudiadas para futuros proyectos:

Generación de informes: SSRS y Microsoft Excel

Creación de cuadros de mando: Microsoft Excel y Cristal Xcelsius

I.3.2.1.2 Análisis de una solución BI con Open Source.

En cuanto al estudio que se realizó por la vertiente del Open Source se escogió la

solución BI mejor valorada: Pentaho.

La plataforma Open Source Pentaho Business Intelligence cubre muy amplias

necesidades de Análisis de los Datos y de presentación de información empresarial.

Las soluciones de Pentaho están escritas en Java y tienen un ambiente de

implementación también basado en IDE Eclipse. Eso hace de Pentaho una solución

muy flexible para cubrir una amplia gama de necesidades empresariales —tanto las

típicas como las sofisticadas y especificas al negocio.

La Figura 23 muestra un esquema de la estructura de Pentaho.

Figura 23: Estructura de la solución de Pentaho

Los módulos de la plataforma Pentaho BI son:

41

42 Chapter I

Reporting.- Módulo de informes que ofrece la solución adecuada a las

necesidades de los usuarios. Pentaho Reporting es una solución basada en el

proyecto JFreeReport y permite generar informes ágil y de gran capacidad.

Pentaho Reporting permite la distribución de los resultados del análisis en

múltiples formatos —todos los informes incluyen la opción de imprimir o

exportar a formato PDF, XLS, HTML y texto—, además de admitir

programación de tareas y ejecución automática de informes con una

determinada periodicidad.

Análisis.- Pentaho Análisis suministra a los usuarios un sistema avanzado de

análisis de información, con uso de las tablas dinámicas —pivot tables,

crosstabs—, generadas por Mondrian y JPivot. El usuario puede navegar por

los datos, ajustando la visión de los mismos, los filtros de visualización,

añadiendo o quitando los campos de agregación. Los datos pueden ser

representados en una forma de SVG o Flash, los dashboards widgets, o

también integrados con los sistemas de Minería de Datos y los portales web o

portlets. Además, con Microsoft Excel Analysis Services, se puede analizar los

datos dinámicos en Microsoft Excel —usando la conexión a OLAP server

Mondrian.

Portal de BI: En este portal web se publica toda la información recolectada en

los procesos de análisis.

Dashboards.- Todos los componentes del módulo Pentaho Reporting y

Pentaho Análisis pueden formar parte de un Dashboard. En Pentaho

Dashboards es muy fácil incorporar una gran variedad en tipos de gráficos,

tablas y velocímetros —Dashboard widgets— e integrarlos con los Portlets

JSP, en donde podrá visualizar informes, gráficos y análisis OLAP. Así como

una librería de código abierto integrada en el Portal de BI que nos proporciona

Pentaho denominada CDF (Community Dashboard Framework).

Data Mining.- Minería de datos se realiza con una herramienta WeKa.

Integración de Datos.- Se realiza con una herramienta Kettle ETL (Pentaho

Data Integration) que permite implementar los procesos ETL. Últimamente

Pentaho lanzó una nueva versión PDI 3.0, que marcó un gran paso adelante

en OSBI ETL y que hizo Pentaho Data Integration una alternativa interesante

para las herramientas comerciales.

3.2.2 Conclusión

Una vez estudiada la vertiente del software privativo y Open Source se procedió a

comparar y decidir por cual se va optar para desarrollar el proyecto. Resaltar que

ambas herramientas fueron instaladas y testeadas antes de su selección. Para más

detalle mirar la Tabla 10.

42

Tabla 10: Tabla comparativa Pentaho vs Microsoft

Pentaho Microsoft

Documentación

Integración con otras herramientas Sólo especificas

Posibilidad de añadir funcionalidades

Integrables con SharePoint

Facilidad para implementar cuadros de

mando

con el uso de

herramientas externas

Coste de Licencias

Curva de aprendizaje

Multiplataforma. Múltiple sistema de

BBDD

Valoración final

Finalmente se decidió decantarse por la solución propuesta por Microsoft debido a los

siguientes motivos:

Documentación más homogénea, sólida y abundante.

Mayor bibliografía que Pentaho, quizás porque esta última utiliza herramientas

muy heterogéneas entre sí, no siguen un mismo patrón de desarrollo, están en

constante cambios y son desarrolladas por diferentes organizaciones15.

Menor curva de aprendizaje.

Mayor facilidad de desarrollo.

La versión libre de Pentaho tiene elementos muy básicos que conlleva un

esfuerzo adicional de instalación y configuración adicional

ITOP MC, así como sus clientes, ya poseían la licencia de Microsoft SQL

Server 2008 Standard y se quería aprovechar esta opción.

3.3 Descripción del problema

Finalmente, después de haber decidido cuál era la tecnología que se iba a usar para

implementar la solución BI con el fin de integrarla con SAP BO, se procede a definir el

problema al que en este trabajo se le da solución.

15 A fecha 07 de julio de 2011 en la búsqueda realiza de bibliografía sobre Pentaho fue escaso encontrar libros querealmente entren en profundidad en cómo llevar a cabo un desarrollo completo de BI con Pentaho, ya que lo normal fueencontrar bibliografía centrada en las herramientas de ETL y de Reporting.

43

44 Chapter I

Se quiere implantar una solución Business Intelligence en SAP BO de manera que el

cliente que posea esta aplicación pueda explotar y visualizar los datos, de tal forma que

sea una herramienta que recoja periódicamente los datos claves de su empresa,

convirtiéndose en un mecanismo para la ayuda en la toma de decisiones empresariales

y/o económicas acertadas que permitan mejorar su competitividad.

Se elaboran una serie de indicadores de estudios centrándose en unas áreas de

negocio específicas, concretamente en gestión de ventas, gestión financiera, gestión

de proyectos y gestión de incidencias. A continuación se valoraran cuáles son las

dimensiones y sus jerarquías por las cuales se analiza dichos indicadores, para acto

seguido elaborar los diferentes cubos.

Por último se implementa los cuadros de mandos e informes necesarios que le permite

al usuario final visualizar, medir y tomar decisiones con respecto a su empresa.

44

Parte II. Cuerpo principal. Descripción deltrabajo

45

46 Chapter I

Capítulo 1. Descripción de la metodología para resolver el problema

Resumen:

Desarrollo ágil de Software

Metodología de desarrollo Scrum

Planificación del proyecto

1.1 Metodología de desarrollo

Una metodología de desarrollo de software se refiere a un framework16 que se usa para

estructurar, planear y controlar el proceso de desarrollo en Sistemas de Información. El

objetivo es mejorar la productividad en el desarrollo y la calidad del producto software.

¿Qué tipo de metodología se podría utilizar?

Se entiende por metodología ágil de desarrollo de software a una colección de valores,

principios y prácticas para modelar software que pueden ser aplicados de manera

simple y ligera. La filosofía de las metodologías ágiles se basa en dar mayor valor al

individuo, a la colaboración con el cliente y al desarrollo incremental del software con

iteraciones muy cortas.

En este proyecto se ha apostado por una metodología ágil de desarrollo de software,

intentando evitar los tortuosos y burocráticos caminos de las metodologías

tradicionales, debido a que presentan los siguientes problemas a la hora de abordar

proyectos, como se muestra en la Tabla 11.

Tabla 11: Desventajas de las metodologías de desarrollo tradicionales

Existen unas costosas fases previas de especificación de requisitos, análisis y

diseño

La corrección de errores durante el desarrollo será costosa, es decir, se pierde

flexibilidad ante los cambios

El proceso de desarrollo está encorsetado por documentos firmados

El desarrollo es más lento y entender un sistema complejo en su globalidad

16 Un framework que se usa para estructurar, planear y controlar el proceso de desarrollo en Sistemas de Información asistir al proceso de desarrollo de software.

46

implica mayor dificultad

Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con

requisitos poco definidos y/o cambiantes o cuando se exige reducir drásticamente los

tiempos de desarrollo pero manteniendo una alta calidad. Además, se aplican bien en

equipos pequeños que resuelven problemas concretos, lo que no está reñido con su

aplicación en el desarrollo de grandes sistemas, ya que una correcta modularización de

los mismos es fundamental para su exitosa implantación. Dividir el trabajo en módulos

abordables minimiza los fallos y el coste, con lo cual las metodologías ágiles presentan

diversas ventajas, entre las que podemos destacar las indicadas en la Tabla 12.

Tabla 12: Ventajas de la metodologías de desarrollo ágiles

Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo

Entrega continua y en plazos breves de software funcional

Trabajo conjunto entre el cliente y el equipo de desarrollo

Importancia de la simplicidad, eliminado el trabajo innecesario

Atención continua a la excelencia técnica y al buen diseño

Mejora continua de los procesos y el equipo de desarrollo

En este proyecto se ha querido aportar más dinamismo y adaptabilidad frente a los

cambios, por lo que se ha decidido hacer uso de una metodóloga ágil, apostando,

dentro del abanico de posibilidades, por la metodología Scrum debido a que permite

maximizar la realimentación sobre el desarrollo —pudiendo corregir problemas y

mitigar riesgos de forma temprana—, a su creciente uso en los equipos de desarrollo

software a nivel internacional, así como otras ventajas que se adaptaban de forma

eficiente con la naturaleza del problema abordado, como se detallará a continuación.

1.1.1 Metodología SCRUM

Scrum es una metodología para la gestión y desarrollo de software basada en un

proceso iterativo e incremental utilizado, comúnmente, en entornos basados en el

desarrollo ágil de software

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se

emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y

flexibilidad —situaciones frecuentes en el desarrollo de determinados sistemas de

software.

47

48 Chapter I

Scrum es un modelo de referencia que define un conjunto de tareas —que se engloban

en trabajos— y roles, pudiéndose tomar como punto de partida para definir el proceso

de desarrollo que se ejecutará durante un proyecto software. A continuación en la Error:

No se encuentra la fuente de referencia se presenta una ilustración donde se puede

apreciar los elementos que lo integran —roles, artefactos, eventos— así como sus

conexiones.

Scrum estructura el desarrollo en ciclos de trabajo llamados Sprints, siendo de duración

fija —entre 1 y 4 semanas— y terminando en una fecha específica,

independientemente de haberse finalizado, o no, el trabajo. Cada Sprint se va

sucediendo uno detrás de otro. Dentro de Scrum se diferencian los siguientes roles

principales, presentes en los Sprints:

48

ScrumMaster es la persona que vela por el cumplimiento de las normas de

Scrum. Trabaja de forma similar a un director de proyecto, llevando a cabo la

gestión del Sprint, con seguimientos diario del Scrum Daily Meeting —

representa una reunión de avance diaria de no más de 15 minutos, cuyo

propósito es vigilar las tareas realizadas, los recursos necesarios y los

obstáculos que se presentan— en busca del objetivo fijado.

Dueño del producto (Product Owner) representa a los clientes externos o

internos

Equipo de desarrolladores (Team) es el grupo de personas encargadas de

implementar los requisitos del cliente, así como de elegir las tareas que se

comprometen hacer en cada Sprint.

Al comienzo de cada Sprint, un equipo Team selecciona las tareas del Product

Backlog17 o pila del producto —se trata de una lista, previamente priorizada por el

Product Owner—, y se comprometen a terminarlas al final del Sprint. Las tareas

elegidas por el Team serán introducidas en el Sprint Backlog18 o pila del Sprint. Todos

los días el equipo Team realiza un Scrum Daily Meeting, actualizando unas gráficas

orientativas que permiten hacer un seguimiento, de forma rápida y sencilla, de las

tareas que faltan para alcanzar su objetivo. Al final del Sprint, el Team hace una

revisión del mismo con los interesados en el proyecto, enseñándoles lo construido: se

obtienen comentarios y observaciones que pueden incorporar al siguiente Sprint.

Scrum pone énfasis en productos que funcionen al final del Sprint, es decir, que

realmente estén “hechos”19 —en el caso de software significa estar integrado,

completamente probado y potencialmente para entregar.

Un tema importante en Scrum es “inspeccionar y adaptar” (1). El desarrollo

inevitablemente implica aprender e innovar, haciendo hincapié en tiempos no muy

extensos de desarrollo y centrándose en analizar el producto resultante midiendo la

eficacia obtenida, ajustando el objetivo del producto iterativamente o en continuo

feedback.

II.1.1.1.1 Scrum en el proyecto

Dada la naturaleza y la magnitud del proyecto, se optó por aplicar esta metodología

modificándola para se ajustara a las necesidades puntuales de la solución BI aportada

en este documento.

17 El Product Backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todoslos requerimientos, funcionalidades deseables, etc. priorizadas. Contiene estimaciones a grosso modo, tanto del valorpara el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al Product Owner a ajustar la líneatemporal 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 aimplementar durante el siguiente Sprint. Estas tareas son extraídas del Product Backlog por el Team, teniendo encuenta cuáles de ellas son más prioritarias.

19 Scrum y XP desde las Trincheras. Henrick Kniberg (1)

49

50 Chapter I

En primer lugar, los roles de los participantes no estaban bien definidos ya que se trata

de un Proyecto Final de Carrera en colaboración con la empresa ITOP MC y esta

desempeñaba el tanto el papel de Product Owner como el de Scrum Master.

Por otro lado no se consideró mantener reuniones diarias para el seguimiento de los

Sprint, ya que no serían efectivas puesto que no existirían cambios sustanciales que se

pudieran comentar para su valoración. En su lugar se mantuvieron, siempre que fue

posible, reuniones semanales.

II.1.1.1.2 Planificación de la solución BI

A continuación, en la Tabla 13, se muestra el Product Backlog tal y como se describe

en la metodología Scrum. Se especificaron en una columna las funcionalidades y al

lado las correspondiente estimación del tiempo que se dedicará para completar cada

ítem. Decir que, aunque tendrían que diferenciarse entre requisitos básicos, prioritarios

o no, todos los requisitos son prioritarios ya que en si son una secuencia de pasos para

construir una solución BI.

50

Tabla 13: Product Backlog de la solución BI

Ítem Descripción Estimación

1 Estado del arte 30 días

2 Búsqueda de una metodología 15 días

3 Estudio de las herramientas de desarrollo 15 días

4 Análisis de requerimientos

4.1 Identificar Preguntas 15 días

4.2 Identificar Indicadores y Perspectivas 30 días

4.3 Modelo Conceptual 7 días

5 Análisis de los OLTP

5.1 Conformar indicadores 30 días

5.2 Establecer correspondencias 7 días

5.3 Nivel de granularidad 7 días

5.4 Modelo conceptual ampliado 7 días

6 Modelo lógico del Data Warehouse

6.1 Tipo de modelo lógico del Data Warehouse 7 días

6.2 Tablas de dimensiones 15 días

6.3 Tablas de hechos 15 días

6.4 Uniones 15 días

7 Integración de datos

7.1 Carga inicial 15 días

7.2 Actualización 15 días

8 Implementación de ETL con el SSIS 15 días

9 Implementación de cubos OLAP con el SSAS 15 días

10 Representación 15 días

A partir del Product Backlog se ha elaborado el Sprint Backlog. Esta lista de tareas

permitirá organizar el trabajo del Team para optimizar el uso de los recursos

disponibles, obtener resultados en plazos de tiempo breves y controlar la ejecución de

cada punto para detectar “cuellos de botellas” y, en consecuencia, darles solución.

La estrategia que se ha seguido para definir los distintos Sprints ha sido tomar cada

ítem del Product Backlog como una etapa a completar. Cada una de estas etapas

contendrá tantos Sprints como tareas contenga la etapa, de manera que cada sprint

51

52 Chapter I

tenga como objetivo el desarrollo de una tarea. Como limitación a estos Sprints, se ha

impuesto que cada uno tenga como mínimo 6 días de ciclo de vida y, como máximo 7.

52

53

54 Chapter I

Tabla 14: Sprint Backlog de la solución BI

Backlog Sprint DescripciónDuración

Estimación Real

1

Estudio del estado del arte

1,2,3,4,5 Estado del arte 30 días 30 días

6 Documentación 3 días 3 días

2

Desarrollo de una metodología

7, 8 Búsqueda de una metodología 15 días 15 días

9 Documentación 3 días 3 días

3

Herramientas de desarrollo

10, 11Estudio de las herramientas de

desarrollo15 días 15 días

12 Documentación 3 días 3 días

13 Pruebas 7 días 7 días

4

Análisis de requerimientos

14, 15 Identificar Preguntas 7 días 10 días

16,17,18,19,2

0Identificar Indicadores y Perspectivas 7 días 10 días

21 Modelo Conceptual 7 días 7 días

22 Documentación 3 días 3 días

23 Pruebas 7 días 7 días

5

Análisis de los OLTP

24,25,26,27,2

8Conformar indicadores 7 días 15 días

29 Establecer correspondencias 7 días 15 días

30 Nivel de granularidad 7 días 15 días

31 Modelo conceptual ampliado 7 días 7 días

22 Documentación 3 días 3 días

23 Pruebas 7 días 7 días

Modelo lógico del Data Warehouse

Tipo de modelo lógico del Data

54

En la Tabla 14 se puede observar el tiempo estimado para cada tarea, de forma que se

cumpla con el requisito temporal impuesto para los Sprints y, en la última columna de la

derecha, el tiempo real dedicado a cada una de ellas. Se observa que en varios casos

el tiempo empleado ha sido mayor que el estimado, circunstancia que viene explicada

por el hecho de que, dichas tareas, presentaban una mayor complejidad de la

esperada, eran novedosas pues se acometían por primera vez, hubo cambios de

tecnologías y necesidad de nuevos equipos de trabajo debido a que los que existían no

soportaban la tecnología elegida, además no se parte de un caso ideal o teórico sino

que se trataba de explotar datos reales donde no se disponía, entre otros problemas,

de una base de datos totalmente depurada (o purificada).

II.1.1.1.3 Planificación temporal

Este proyecto viene delimitado temporalmente por la necesidad de no exceder las 150

horas de dedicación, equivalentes a los 15 créditos asignados a esta asignatura.

Respetar este límite es una tarea difícil, ya que siempre se dedican más horas en la

parte de desarrollo para intentar cumplir los objetivos fijados, sin contar con el tiempo

dedicado a las reuniones, a la formación o a incidencias tecnológicas.

Para la representación de las tareas y su asignación temporal, se ha seleccionado el

Diagrama de Gantt. Su objetivo es mostrar el tiempo de dedicación previsto para

diferentes tareas o actividades a lo largo de un tiempo total determinado. El diagrama

de Gantt de este proyecto se puede ver reflejado en la Figura 24.

55

56 Chapter I

Figura 24: Diagrama de Gantt

56

Capítulo 2. Metodología de Implementación de una solución BI

Resumen:

Metodología para construir de un Data Warehouse

Metodología propia para la construcción de un Data Warehouse

Como se mencionó en el Capítulo Fundamentos Business Intelligence, se denomina

Business Intelligence al conjunto de estrategias y herramientas enfocadas a la

administración y creación de conocimiento mediante el análisis de datos existentes en

una organización o empresa. Abarca la comprensión del funcionamiento actual de la

empresa, bien como la anticipación de acontecimientos futuros, con el objetivo de

ofrecer conocimientos para respaldar las decisiones empresariales. En Figura 25 se

representa el esquema de una solución BI, teniendo en cuenta que los componentes

básicos son: OLTP, herramientas ETL —Extracción, Transformación y Carga—, Data

Warehouse, Query Manager y las herramientas de consultas y análisis como los

cuadros de mandos o generados de informes.

Figura 25: Componentes principales de una solución BI

Una vez entendido en qué consiste una solución BI, se puede observar que uno de los

pilares es el Data Warehouse ya que contiene los datos que vamos a analizar, por eso

es importante como se diseña e implementa.

La construcción e implementación de un Data Warehouse puede adaptarse muy bien a

cualquier ciclo de vida de desarrollo de software, con la salvedad de que para algunas

fases las acciones que se han de realizar, en particular, serán diferentes. Lo que se

57

58 Chapter I

debe tener muy en cuenta, es no entrar en la utilización de metodologías que requieran

fases extensas de reunión de requerimientos y análisis, fases de desarrollo monolítica

que conlleve demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es

entregar una primera implementación que satisfaga una parte de las necesidades, para

demostrar las ventajas del Data Warehouse y motivar a los usuarios.

La metodología elegida para el diseño del Data Warehouse se ha elaborado a partir de

una metodología base existente, la cual se ha ampliado y adaptando a nuestro

problema. La ampliación ha consistido en la adición de algunos aspectos claves en el

diseño de un Data Warehouse y una metodología de implementación para una solución

de Business Intelligence. La metodología base de la que se parte fue propuesta por el

Ingeniero Argentino Bernabeu Ricardo “Investigación y Sistematización de Conceptos -

HEFESTO: Metodología propia para la Construcción de un Data Warehouse ”20 (2).

2.1.1 Metodologías para construir un Data Warehouse

En un principio se realizó una búsqueda con el fin de encontrar una metodología que

se adaptara lo mejor posible a nuestro problema. Se encontraron dos metodologías

interesantes: por un lado Hefesto, anteriormente nombrada, y por otro lado la

desarrollada por SAS, llamada The SAS Rapid Data Warehouse Methodology

(SRDWM). Dicha metodología es iterativa y desarrolla incrementalmente un proyecto

Data Warehouse dividiéndolo en cinco fases:

1. Definición de los objetivos

2. Definición de los requerimientos de información

3. Diseño y modelización

4. Implementación

5. Revisión

La razón por la que se desestimó el uso de la metodología SRDWM es debido a la

sencillez y eficacia con la que está elaborada la metodología Hefesto. Hefesto explica

de forma muy intuitiva los pasos que hay que tomar en cada momento, así como por

qué debemos tomarlos, acompañada siempre con ejemplos y comparaciones. Se toma

como punto de referencia para todas aquellas personas que estén dando sus primeros

pasos en el mundo del Data Warehousing y quizás en ese sentido SRDWM no

aportaba esa sencillez, resultando incluso más dificultoso. Otra ventaja es que encaja

perfectamente con la metodología Scrum frente a SRDWM, que al ser una metodología

iterativa incremental, tendría mayor dificultad de adaptarse a una metodología de

desarrollo ágil. En la Tabla 15 se muestra las principales características de Hefesto.

Tabla 15: Características principales en la metodología Hefesto

Los objetivos y resultados esperados en cada fase se distinguen fácilmente y son sencillos de

comprender

20 A partir de ahora utilizaremos Hefesto para referirnos a ella.

58

Tabla 15: Características principales en la metodología Hefesto

Se basa en los requerimientos de los usuarios, por lo cual su estructura es capaz de adaptarse

con facilidad y rapidez ante los cambios en el negocio

Cuando se culmina con una fase, los resultados obtenidos se convierten en el punto de partida

para llevar a cabo el paso siguiente

Utiliza modelos conceptuales y lógicos, los cuales son sencillos de interpretar y analizar

Se aplica tanto para Data Warehouse como para Data Mart

Es independiente del tipo de ciclo de vida que se emplee para contener la metodología

Es independiente de las herramientas que se utilicen para su implementación

Es independiente de las estructuras físicas que contengan el DW y de su respectiva distribución

Reduce la resistencia al cambio, ya que involucra a los usuarios finales en cada etapa para que

tome decisiones respecto al comportamiento y funciones del Data Warehouse

Durante el estudio de la metodología Hefesto nos dimos cuenta que habría que

adaptarla hacia una situación real de Data Warehouse más compleja, pero esto no

supuso ningún problema gracias a la flexibilidad que ofrece.

2.1.2 Metodología propia para la Construcción de un Data Warehouse con base en HEFESTO

La metodología Hefesto sigue las fases de construcción mostradas en la Figura 27.

Figura 26: Metodología propia de Hefesto para la construcción de un Data Warehouse

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

una nueva sección dedicada a la implementación, ya que no lo tiene en cuenta por ser

independiente de las herramientas que se utilicen para su implementación. Además las fases

de análisis e integración también sufrieron modificaciones en diversos apartados.

Figura 27: Metodología propia para la construcción de un Data Warehouse

En la Figura 27 se muestra la metodología propia con base en Hefesto, donde se puede

apreciar en color rojo las adiciones o reestructuraciones de las fases. A continuación se van

analizando las fases resaltando los cambios realizados en cada una de ellas.

II.2.1.2.1 Fase 1: Análisis de Requerimientos

59

60 Chapter I

El primer paso a realizar es identificar los requerimientos de los usuarios a través de

preguntas que expliciten los objetivos de su organización. Luego, se analiza estas

preguntas a fin de identificar cuáles serán los indicadores y perspectivas que serán

tomadas en cuenta para la construcción 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 Identificar preguntas

El objetivo de este apartado consiste en recolectar las necesidades de información,

pudiéndose llevar a cabo a través de diversas técnicas como entrevistas, cuestionarios,

observaciones, entre otras.

El análisis de los requerimientos de los diferentes usuarios, es el punto de partida de

esta metodología, ya que nos deben, en cierto modo, guiar la investigación hacia un

desarrollo que refleje claramente lo que se espera del Data Warehouse, en relación a

sus funciones y capacidades.

Por todo lo anterior, el fin consiste en obtener e identificar las necesidades de

información clave de alto nivel, esencial para llevar a cabo las metas y estrategias de la

empresa, facilitando una toma de decisiones de forma eficaz y eficiente a través de los

KPI (Key Performance Indicators) o indicadores de rendimiento clave.

Debe tenerse en cuenta que dicha información, es la que proveerá el soporte para

desarrollar las fases sucesivas, por lo cual, es muy importante que se preste especial

atención al revelar los datos.

Una forma de asegurarse de que se ha realizado un buen análisis, es corroborar que el

resultado del mismo haga explícitos los objetivos estratégicos planteados por la

empresa que se está estudiando.

Otra forma de encaminar la relevancia, es enfocar las necesidades de información en

los procesos principales que desarrolle la empresa en cuestión.

La idea central es formular preguntas complejas sobre el negocio, que incluyan

variables de análisis que se consideren relevantes, ya que son estas las que permitirán

estudiar la información desde diferentes perspectivas.

Cabe destacar que la información debe estar soportada de alguna manera por algún

OLTP, ya que de otra forma, no se podrá elaborar el Data Warehouse.

Como aportación a la metodología 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

¿Cuáles son las metas que tenemos?

Antes que nada se debe definir la meta21 para poder ver los elementos más

importantes que influyen para llegar al resultado final. Aquí es donde está una de las

claves del éxito, hasta dónde 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 cuánto es bueno medir este indicador?

¿Quién debe conocer estos números?

¿Cómo presentaremos estos números para que se entiendan?

¿Cómo motivaremos al personal a alcanzar estas metas?

Una vez obtenido el indicador, faltaría analizar la perspectiva donde este valor aporta

un significado:

¿Cuál es la perspectiva de análisis?

¿Con qué otra medida lo comparo?

Se puede dar el caso que el usuario no tenga muy claro sus necesidades de

información o que estas sean demasiadas y, por lo tanto, imposible de abarcar. Es muy

importante centrarse en los puntos clave de información y eliminar aquellos que sean

secundarios. Cuando ocurre esto, como refuerzo a las cuestiones, se propone guiar al

usuario pidiéndole que indique cuáles son los procesos principales que desarrolla su

empresa, apoyándose en la Gestión de Procesos de Negocio (Business Process

Management o BPM) 22 ya que a través 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 automatización 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 administración de los procesos permite asegurar que los

mismos se ejecuten eficientemente, obteniendo información vital para futuras mejoras,

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

22 Una Gestión de Procesos de Negocio es una metodología empresarial cuyo objetivo es mejorar la eficiencia através de la gestión sistemática de los procesos de negocio, que se deben modelar, automatizar y optimizar de formacontinua.

61

62 Chapter I

ya que a través de la ejecución 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

pidiéndole que indique cuáles son los procesos principales

¿Qué necesito ver, medir o evaluar?

¿Cómo necesito analizarlo?

Figura 28: Mapa de procesos ITOP

ITOP MC distinguen tres procesos importantes:

Procesos estratégicos 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 razón de ser.

Procesos de apoyo soportan a uno o más de los procesos clave.

Después de haber analizados los procesos claves, se decidió centrarse en los

procesos Gestión de Proyectos, Soporte – a partir de ahora Gestión de Incidencias–,

Vender –Gestión de Ventas– y Dirección Financiera. A continuación, se procedió a

identificar las necesidades de información dentro de cada proceso, que a groso modo

se aprecia en la Tabla 16.

62

Tabla 16: Necesidades de información dentro de cada proceso

¿Qué quiero

medir?

¿En qué

unidad va a

ser medido?

¿Cómo

representaremos

estos números

para que se

entiendan?

¿Cuál es la

perspectiva de

análisis?

Gestión de

Ventas

Total de ventas que

han habidoEuros

Gráfico de Bala

Diagrama de

Barras

SparkLines

En qué momento

ocurrió

Quién

Donde ocurrió

Que compro

Quien lo vendió

Cuál fue el medio

donde se produjo

la venta

Total de beneficio

que se ha obtenido

Euros,

Porcentaje

Cuanto aumentó las

ventas

Euros,

Porcentaje

Cuanto aumentó el

beneficio

Euros,

Porcentaje

Dirección

Financiera

Relación entre el

capital ajeno y el

capital propio

Euros,

Porcentaje

Gráfico de Bala

Diagrama Barras

SparkLines

Gráfico de línea

En qué momento

ocurrió

Grado de

endeudamiento de

los activos

Euros,

Porcentaje

Rentabilidad de la

empresa

Euros,

Porcentaje

Eficiencia empresaEuros,

Porcentaje

Gestión de

Proyectos

Cómo va el

proyecto en cuanto

a costos

Euros

Gráfico de Bala

Diagrama Barras

SparkLines

Diagramas control

Líneas tendencias

En qué momento

ocurrió

Cómo va el

proyecto en cuanto

aspectos de calidad

se refiere

Porcentaje

Cómo va el

proyecto en

márgenes de tiempo

Tiempo

63

64 Chapter I

Tabla 16: Necesidades de información dentro de cada proceso

¿Qué quiero

medir?

¿En qué

unidad va a

ser medido?

¿Cómo

representaremos

estos números

para que se

entiendan?

¿Cuál es la

perspectiva de

análisis?

En qué nivel de

riesgo se encuentra

el proyecto

Porcentaje

Como se encuentra

el proyecto en

cuanto al alcance

fijado

Atributo23

Como se encuentra

el proyecto en

cuanto a

adquisiciones

Tiempo

Como se encuentra

el proyecto en

cuanto a recursos

humanos

Numérico

Gestión de

Incidencias

Número de

incidencias abiertas

frente a

Numérico

Gráfico de Bala

Diagrama de

Barras

SparkLines

Líneas de

tendencias

Gráfico de pila

En qué momento

ocurrió

Incidencias

cerradasPorcentaje

Tiempo que se tarda

en responder una

incidencia

Numérico

Tiempo que se tarda

en cerrar una

incidencia

Numérico

Fuente de

incidencias

Atributo

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

64

Tabla 16: Necesidades de información dentro de cada proceso

¿Qué quiero

medir?

¿En qué

unidad va a

ser medido?

¿Cómo

representaremos

estos números

para que se

entiendan?

¿Cuál es la

perspectiva de

análisis?

Gravedad de la

incidenciaAtributo

Número de

incidentes

asignados

incorrectamente

Porcentaje

Número de

incidencia

reabiertas

Porcentaje

II.2.1.2.1.2 Identificar indicadores y perspectivas

Una vez que se han establecido las preguntas de negocio, se debe proceder a su

descomposición para descubrir los indicadores que se utilizarán y las perspectivas de

análisis que intervendrán.

Para ello, se debe tener en cuenta que los indicadores KPI para que sean realmente

efectivos, toman, en general, valores numéricos y representan lo que se desea

concretamente analizar, como saldos, promedios, cantidades, sumatorias, fórmulas,

entre otros.

En cambio, las perspectivas o dimensiones se refieren a los objetos mediante los

cuales se quiere examinar los indicadores, con el fin de responder a las preguntas

planteadas, como clientes, proveedores, sucursales, países, productos, entre otros,

destacando al tiempo —la más común de las perspectivas24.

Llegados a este punto, en nuestro caso de estudio se ha elaborado una tabla de KPI´s

(ver Tabla 17) a partir de los procesos en lo que más estaban interesados la empresa.

Tabla 17: Indicadores

24 Las dimensiones o perspectivas, usualmente, se asocian en jerarquías para describir niveles de agrupamientoespecíficos —explícitos o implícitos— y, por lo tanto, las diferentes granularidades —nivel de detalle— en la visión delos datos

65

66 Chapter I

Ventas

Finanzas

Gestión de Proyectos

Gestión de Incidencias

Para el proceso de Ventas y Finanzas, la empresa ya tenía decidido cuales eran los

indicadores que querían medir; en cambio, los indicadores de Gestión de Proyectos e

Incidencias se hizo un estudio de cuáles eran los que más se adaptaban a sus

necesidades de información.

Se aprecia en la Tabla 18 los indicadores de Gestión de Ventas, indicando el nombre

del indicador y una breve descripción de los mismos.

Tabla 18: Gestión de Ventas

Indicadores Descripción Perspectiva

Variación de ventasMide el porcentaje de variación de ventas sobre elejercicio anterior Tiempo

ClienteGestión de VentasCanalProductoGeografía

Total de ventas Mide el total de ventas que se han realizado

% Beneficio Total Mide el beneficio total obtenido de las ventas

% Variación del

BeneficioMide la variación del beneficio respecto al histórico

Los indicadores de Dirección Financiera figuran en las Tabla 20, Tabla 21, Tabla 22,

Tabla 23 dividiéndose los ratios financieros en cuatro grandes grupos, como indica la

Tabla 19.

Tabla 19: Grupos de Indicadores de Dirección

Financiera

Ratios de liquidezRatios de endeudamiento o solvencia

Ratios de rentabilidadRatios de gestión 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

Dirección

Financiera

Descripción Perspectivas

Ratios de

liquidez severa o

Prueba ácida

Este ratio muestra una medida de liquidez más precisa que laanterior, ya que excluye a las existencias (mercaderías oinventarios) debido a que son activos destinados a la venta yno al pago de deudas, y, por lo tanto, menos líquidos;además de ser sujetas a pérdidas en caso de quiebra.

TiempoRatios de liquidez

absoluta o Ratio

de efectividad o

Prueba superácida

Es un índice más exacto de liquidez que el anterior, ya queconsidera solamente el efectivo o disponible, que es el dineroutilizado para pagar las deudas y, a diferencia del ratioanterior, no toma en cuenta las cuentas por cobrar (clientes)ya que es dinero que todavía no ha ingresado a la empresa.Si el resultado es menor que 0.5, no se cumple conobligaciones de corto plazo

Capital de trabajoSe obtiene de deducir el pasivo corriente al activo corriente.Lo ideal es que el activo corriente sea mayor que el pasivocorriente, ya que el excedente puede ser utilizado en lageneración de más utilidades.

Tabla 21: Ratios de endeudamiento, solvencia o de apalancamiento

Son aquellos ratios o índices que miden la relación 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 también el grado de endeudamiento de los activos.

Miden el respaldo patrimonial.

Indicadores de Dirección

Financiera

Descripción Perspectivas

Ratio de endeudamiento a

corto plazo

Mide la relación entre los fondos a corto plazoaportados por los acreedores y los recursosaportados por la propia empresa.

TiempoRatio de endeudamiento a

largo plazo

Mide la relación entre los fondos a largo plazoproporcionados por los acreedores, y losrecursos aportados por la propia empresa.

Ratio de endeudamiento totalMide la relación entre los fondos totales acorto y largo plazo aportados por losacreedores, y los aportados por la propiaempresa.

Ratio de endeudamiento de

activo

Mide cuánto del activo total se ha financiadocon recursos o capital ajeno, tanto a cortocomo largo plazo.

67

68 Chapter I

Tabla 22: Ratios de rentabilidad

Muestran la rentabilidad de la empresa en relación con las ventas, el patrimonio y la inversión,

indicando además la eficiencia operativa de la gestión empresarial.

Indicadores de Dirección

Financiera

Descripción Perspectivas

Ratio de rentabilidad de lainversión (ROA)

Es el ratio más representativo de la marchaglobal de la empresa, ya que permite apreciar sucapacidad para obtener utilidades en el uso deltotal activo.

Tiempo

Ratio de rentabilidad delpatrimonio (ROE)

Este ratio mide la capacidad para generarutilidades netas con la inversión de losaccionistas y lo que ha generado la propiaempresa (capital propio).

Ratio de rentabilidad brutasobre ventas

Llamado también margen bruto sobre ventas,muestra el margen o beneficio de la empresarespecto a sus ventas.

Ratio de rentabilidad netasobre ventas

Es un ratio más concreto ya que usa el beneficioneto luego de deducir los costos, gastos eimpuestos.

Ratio de rentabilidad poracción

Llamado también utilidad por acción, permitedeterminar la utilidad neta que le corresponde acada acción. Este ratio es el más importantepara los inversionistas, pues le permite compararcon acciones de otras empresas.

Ratio de dividendos poracción

El resultado de este ratio representa el monto oimporte que se pagará a cada accionista deacuerdo a la cantidad de acciones que éstetenga.

Tabla 23: Ratios de gestión, operativos o de rotación

Evalúan la eficiencia de la empresa en sus cobros, pagos, inventarios y activo.

Indicadores de Dirección

FinancieraDescripción

Perspectivas

Ratio de periodo de cobro Indica el número de días en que se recuperan lascuentas por cobrar a sus clientes.

Tiempo

Ratio de rotación por pagar Mide el plazo que la empresa cuenta paracancelar bonificaciones.

Ratio de periodo de pagosDetermina el número de días en que la empresase demora en pagar sus deudas a losproveedores.

Ratio de rotación deinventarios

Indica la rapidez en que los inventarios seconvierten en cuentas por cobrar mediante lasventas al determinar el número de veces que rotael stock en el almacén durante un ejercicio.

Por otro lado, para elaborar los indicadores de Gestión de Proyectos e Incidencias,

comentado anteriormente, se tuvo que llevar a cabo una investigación de cuáles

68

podrían ser los más que se ajustaban a las necesidades de la empresa y, después de

sucesivas reuniones con el cliente, se escogieron una serie de ellos.

Para la creación de los indicadores de Gestión de Proyectos se utilizó como

documentación el PMBOK25. Comprende dos grandes secciones: la primera sobre los

procesos y contextos de un proyecto, y la segunda sobre las áreas de conocimiento

específico para la gestión de un proyecto.

Las nueve áreas del conocimiento mencionadas en el PMBOK se detallan en la Tabla

24.

Tabla 24: Gestión de Proyectos

Gestión de la Integración delProyecto

Incluye los procesos y actividades necesarios paraidentificar, definir, combinar, unificar y coordinar losdiversos procesos y actividades de la dirección deproyectos dentro de los grupos de procesos de direcciónde proyectos.

Gestión del Alcance del ProyectoIncluye los procesos necesarios para garantizar que elproyecto incluya todo (y únicamente todo) el trabajorequerido para completarla con éxito.

Gestión del Tiempo del ProyectoIncluye los procesos requeridos para administrar lafinalización del proyecto a tiempo.

Gestión de los Costos del ProyectoIncluye los procesos involucrados en estimar,presupuestar y controlar los costos de modo que secomplete el proyecto dentro del presupuesto aprobado.

Gestión de la Calidad del Proyecto

Incluye los procesos y actividades de la organizaciónejecutante que determinan responsabilidades, objetivos ypolíticas de calidad a fin de que el proyecto satisfaga lasnecesidades por la cuales fue emprendido.

Gestión de los Recursos Humanosdel Proyecto

Incluye los procesos que organizan, gestionan y conducenel equipo del proyecto.

Gestión de las Comunicaciones delProyecto

Incluye los procesos requeridos para garantizar que lageneración, la recopilación, la distribución, elalmacenamiento, la recuperación y la disposición final dela información del proyecto sean adecuados, oportunos yentregada a quien corresponda (interesado del proyecto ostakeholders).

Gestión de los Riesgos delProyecto

Incluye los procesos relacionados con llevar a cabo laplanificación de la gestión, identificación, el análisis, laplanificación de respuesta a los riesgos, así como sumonitoreo y control en un proyecto.

Gestión de las Adquisiciones delProyecto

Incluye los procesos de compra o adquisición de losproductos, servicios o resultados que es necesario obtenerfuera del equipo del proyecto.

Una vez analizadas y comprendidas estas nueves áreas se crearon los siguientes

KPI’s 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: Gestión de proyectos. Gestión de la Integración del Proyecto

Indicador Descripción Perspectivas

25 PMBOK es un estándar en la Administración de Proyectos desarrollado por el Project Management Institute (PMI)(37).

69

70 Chapter I

% de tiempo dedicado a lacoordinación del proyecto

Este indicador mide el porcentaje de tiempoinvertido en coordinar un proyecto enrelación con el tiempo que se tardó encoordinar e implementar el proyecto.

TiempoNúmero de proyectos

abiertos en relación con elnúmero de proyectos

cerrados

Este indicador mide el número deproyectos cerrados en relación con elnúmero de proyectos abiertos.

Número de hitos retrasadosUn hito es una tarea que representa unafecha importante en un proyecto, como lafinalización de una fase del proyecto.

Tabla 26: Gestión de proyectos. Gestión del tiempo

Indicador Descripción PerspectivaDesviación del

calendario previstopara el proyecto

La desviación del calendario previsto es ladiferencia en tiempo entre la línea base conrespecto al desarrollo actual

TiempoTasa de tareas

realizadas en losplazos deseados

Tasa de tareas realizadas en los plazos deseados

Tabla 27: Gestión de proyectos. Gestión de calidad

Indicador Descripción Perspectivas

Desviación delretorno de la

inversión prevista

La desviación del retorno prevista de la inversión(ROI) es la diferencia entre el retorno de lainversión prevista en la línea de base y el retornoreal de la inversión. Tiempo

Porcentaje del

proyecto terminado

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

Tabla 28: Gestión de proyectos. Gestión de costo

Indicador Descripción Perspectiva

Valor Ganado (EV)

El valor ganado es el valor del trabajocompletado expresado en términos delpresupuesto aprobado asignado a dicho trabajopara una actividad del cronograma o uncomponente de la estructura de desglose deltrabajo.

Tiempo

Valor planificado (PV)El valor planificado es el presupuesto autorizadoasignado al trabajo que debe ejecutarse paracompletar una actividad o un componente de laestructura de desglose del trabajo.

Costo real (AC)

El costo real (AC) es el costo total en el que seha incurrido realmente y que se ha registradodurante la ejecución del trabajo realizado parauna actividad o componente de la estructura dedesglose del trabajo.

Variación delcronograma (SV)

La variación del cronograma es una medida deldesempeño del cronograma en un proyecto. Lavariación del cronograma, en la EVM, finalmenteserá igual a cero cuando se complete elproyecto, porque ya se habrán ganado todos losvalores planificados.

Variación de costo(CV)

La variación del costo es una medida deldesempeño del costo en un proyecto.En la EVM, la CV es particularmente crítica

70

Tabla 28: Gestión de proyectos. Gestión de costo

Indicador Descripción Perspectivaporque indica la relación entre el desempeñoreal y los costos gastados. En la EVM, una CVnegativa con frecuencia no es recuperable parael proyecto.

Índice de desempeñodel cronograma (SPI)

El índice de desempeño del cronograma es unamedida del avance logrado en un proyecto encomparación con el avance planificado.Puesto que el SPI mide todo el trabajo delproyecto, el desempeño en la ruta críticatambién debe analizase, para determinar si elproyecto terminará antes o después de la fechade finalización programada.

Índice del desempeñodel costo (CPI)

Es una medida del valor del trabajo completado,en comparación con el costo o avance reales delproyecto. Se considera la métrica másimportante de la gestión del valor ganado y midela eficacia de la gestión del costo para el trabajocompletado.

Estimación a laconclusión (EAC)

La EAC puede diferir del presupuesto hasta laconclusión (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 costosreales en los que se ha incurrido para completarel trabajo, más una estimación hasta laconclusión (ETC) para el trabajo restante.

Índice de Desempeñodel Trabajo por

Completar (TCPI)

El índice de desempeño del trabajo porcompletar es la proyección calculada deldesempeño del costo que debe lograrse para eltrabajo restante, con el propósito de cumplir conuna meta de gestión especificada, tal como elBAC o la EAC. Si resulta evidente que el BAC ya no es viable,el director del proyecto proyecta una estimacióna la conclusión EAC.

Tabla 29: Gestión de proyectos. Gestión de Riesgos

Indicador Descripción Perspectiva% de los proyectos que

consideran de riesgoPorcentaje de proyectos que seconsideran de riesgo

Tiempo

% de los proyectos con cambiosde alcance

Porcentaje de proyectos activos concambios de alcance durante elproyecto

% de los proyectos "en elcontrol"

Porcentaje de proyectos que está"bajo control", es decir, que sonsubjetivamente calificados como elcontrol basado en tiempo, presupuestoy calidad

Promedio del número demodificaciones realizadas alproyecto desde su definición

Promedio del número de cambiosrealizados en la definición del alcancedel proyecto, es decir, de los proyectosdurante su ciclo de vida

% de los proyectos a tiempo ydentro del presupuesto

Porcentaje de proyectos que seejecutan en el marco de tiempoprevisto y con el presupuesto (gastos)en función de su línea de base

71

72 Chapter I

Tabla 30: Gestión de proyectos. Gestión de recursos humanos

Indicador Descripción Perspectiva

Promedio del número depersonas asignadas al proyecto

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

----

Tiempo

Tabla 31: Gestión de proyectos. Gestión de adquisición

Indicador Descripción Perspectiva

Requisición de tiempo deemisión tema

Para medir el tiempo transcurridoentre el momento en que unasolicitud de contratación se inicia y elmomento en que la solicitud secumple (expresada en términos dedías).

Tiempo

A la hora de crear los indicadores de Gestión de Incidencias se ha optado por seguir la

guía de buenas prácticas de ITIL (Biblioteca de Infraestructura de Tecnologías de

Información o Information Technology Infrastructure Library) (3) que consiste en un

conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la

información, el desarrollo de tecnologías de la información y las operaciones

relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso

conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a

lograr calidad y eficiencia en las operaciones de TI (Tecnologías de la Información).

Los indicadores elaborados para el proceso de Gestión de Incidencias se muestran en

la Tabla 32.

Tabla 32: Gestión de Incidencias

Indicador Descripción Perspectiva Tiempo en cerrar la

incidenciaTiempo promedio que se tarda entre elregistro de la incidencia y su cierre.

Tiempo

Tiempo promedio que setarda en responder

incidentes

Tiempo promedio de tiempo (por ejemplo,en minutos) entre la detección de unincidente y la primera medida tomada parareparar el incidente.

Número total de incidentespor fuente

Número de incidentes que se originaron porrazones de telecomunicaciones, lainfraestructura física, operación, soporte,seguimiento, los socios externos deeventos, proveedores y otros

% de los incidentes deretraso

Número de incidentes de retraso (no secierra y no se resuelve dentro del plazoestablecido) en relación con el número deprocedimientos abiertos (no cerrados)incidentes.

Número de incidentesgraves

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

% de los incidentesrepetidos

.

Porcentaje de incidentes que puedenclasificarse como un incidente derepetición, en relación con todos losincidentes reportados en el período de

72

Tabla 32: Gestión de Incidencias

Indicador Descripción Perspectivamedición. Un incidente se repite si ya ha ocurrido(varias veces) en el período de medición

Incidente tasa de colaEl número de casos cerrados, en relacióncon el número de casos abiertos en unperíodo de tiempo determinado.

% de incidentes resueltosdentro del plazo / destino

Número de incidentes cerrados en el plazofijado durante la duración del marco, enrelación con el número de todos losincidentes cerrados en un período detiempo determinado. Un tiempo de duración-marco se aplica acada incidente en el que se recibe, yestablece un límite en la cantidad de tiempodisponible para resolver el incidente. El tiempo de duración aplica-marco sederiva de los acuerdos alcanzados con elcliente sobre la resolución de incidentes.

Costo promedio pararesolver un incidente

Los costes medios para resolver unincidente se calculan a partir de los costosfijos y variables del proceso de gestión delincidente dividido por el número total deincidentes recibidos en el período demedición.

% de incidentesincorrectamente asignados

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

Número de incidentescerrados en relación con el

número de incidentesabiertos

Se valora la eficacia a la hora de resolverincidentes

% de incidentes clasificadosincorrectamente

Un incidente puede ser clasificado comoprioridad alta, media y baja

II.2.1.2.1.3 Modelo Conceptual

A continuación 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 visión del alcance del

proyecto, aportando una alta definición de datos lo que nos ayuda en la presentación,

difusión y entendimiento de los mismos de cara a los usuarios.

De cada proceso analizado anteriormente, se ha creado cuatro mapas conceptuales26.

A la izquierda se pueden ver las perspectivas que serán unidas a un óvalo central que

26 Se entiende por mapa conceptual a un método para organizar, de forma sencilla, cualquier tipo de información,ayudando a obtener una mejor comprensión e intercambio de la misma.

73

74 Chapter I

representa y lleva el nombre de la relación que existe entre ellas. La relación,

constituye el proceso o área de estudio elegida. De dicha relación y entrelazadas con

flechas, 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 cuáles serán los

resultados que se obtendrán, cuáles son las variables que se utiliza para analizarlos y

la relación que existe entre ellos.

74

Figura 30: Diagrama conceptual Finanzas

Figura 31: Diagrama conceptual Gestión de Proyectos

75

76 Chapter I

Figura 32: Diagrama conceptual Gestión de Proyectos

Figura 33: Diagrama conceptual Gestión de Incidencias

76

II.2.1.2.2 Fase 2: Análisis de los OLTP

El siguiente paso consiste en analizar las fuentes OLTP para determinar cómo serán 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 define qué campos se incluirán en

cada perspectiva. Finalmente, se ampliará el modelo conceptual con la información obtenida en

este paso.

II.2.1.2.2.1 Conformar Indicadores

En este paso se debe indicar cómo calcular los indicadores definiendo las medidas que lo

componen y las funciones de sumarización que se utilizan para su agregación.

En adicción a la metodología de Hefesto, se ha creído 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 año 2010 no nos dice nada, pero si

sabemos que en el año 2009 las ventas fueron de 3000000, se puede concluir que en el año

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 año 2011 —este sería el valor objetivo y nuestro

KPI a día 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 año, quizás se deba hacer un cambio de estrategia

en las ventas para poder en tres meses llegar al objetivo.

Tabla 33: Indicadores

Gestión de VentasGestión Financiera

Gestión de Proyectos

Gestión de Incidencias

Tabla 34: Conformar Indicadores. Gestión de Ventas

Indicadores Medidas Función de sumarización Valor Objetivo

Variación de

ventas

Total de línea (TL)

Descuento pie de

documento (DPD)

Un aumento del 2%

con respecto al año

anterior

77

78 Chapter I

Tabla 34: Conformar Indicadores. Gestión de Ventas

Indicadores Medidas Función de sumarización Valor Objetivo

Unidades de

ventas

Total de línea (TL)

Descuento pie de

documento (DPD)

Un aumento del 2%

con respecto al año

anterior

% Beneficio

Total

Precio Venta Neto PVN

Coste artículo CA

Cantidad C

Un aumento del 2%

con respecto al año

anterior

% Variación

del Beneficio

Precio Venta Neto PVN

Coste artículo CA

Un aumento del 2%

con respecto al año

anterior

Tanto para los indicadores de Dirección Financiera, Gestión de Proyectos y Gestión de

Incidencias, no se va representar su función de sumarización 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 gestión 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

Prueba superácida

Caja y banco

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 inversión (ROA) Utilidad neta

Activos

Ratio de rentabilidad del patrimonio (ROE) Utilidad neta

Patrimonio

Ratio de rentabilidad bruta sobre ventas Utilidad Bruta

Patrimonio

Ratio de rentabilidad neta sobre ventasUtilidad Bruta

Ventas netas

Ratio de rentabilidad neta sobre ventasUtilidad neta

Ventas netas

Ratio de rentabilidad por acción Utilidad neta

Número de acciones

Ratio de dividendos por acción Dividendos

Número de acciones

Tabla 39: Conformar indicadores Ratios de gestión u operativos

Indicador Medida

Ratio de rotación de cobro Ventas al crédito

Cuentas por cobrar comerciales

Ratio de periodo de cobro Cuentas por cobrar comerciales

Ventas al crédito

79

80 Chapter I

Tabla 39: Conformar indicadores Ratios de gestión u operativos

Indicador Medida

Ratio de rotación por pagar Compras al crédito

Cuentas por pagar comerciales

Ratio de periodo de pagos Cuentas por pagar comerciales

Compras al crédito

Ratio de rotación de inventarios Costo de ventas

Existencias

Tabla 40: Conformar Indicadores. Gestión de

proyectos

Gestión de la integración del proyecto

Gestión del tiempo

Gestión de la calidad

Gestión de costos

Gestión de riesgos

Gestión de recursos humanos

Gestión de adquisición

Tabla 41: Conformar Indicadores. Gestión de la integración del proyecto

Indicador Medida

% de tiempo dedicado a la coordinación del

proyecto

Tiempo de coordinación

Tiempo implementación

Número de proyectos abiertos en relación con

el número de proyectos cerrados

Proyectos cerrados

Proyectos abiertos

Número de hitos retrasados Hitos retrasados

Tabla 42: Gestión del tiempo

Indicador Medida

Desviación del calendario previsto para el

proyecto

Tiempo previsto

Tiempo real

80

Tasa de tareas realizadas en los plazos

deseados

Trabajo terminado

Línea base prevista

Tabla 43: Conformar Indicadores. Gestión de calidad

Indicador Medida

Desviación del retorno de la inversión previstaBeneficios

Coste iniciales

Porcentaje del proyecto terminadoTareas terminadas

Tareas incompletas

Tabla 44: Gestión de proyectos. Gestión de costo

Indicador Medida

Valor Ganado (EV)Presupuesto autorizado

Trabajo completado

Valor planificado (PV) Presupuesto asignado a cada actividad

Costo real (AC) Costo real de cada actividad

Variación del cronograma (SV)Valor Ganado

Valor Planificado

Variación de costo (CV)Valor Ganado

Costo Real

Índice de desempeño del cronograma (SPI)Valor Ganado

Valor Planificado

Índice del desempeño del costo (CPI)Valor Ganado

Costo real de la actividad

Estimación a la conclusión (EAC)

Costo real de la actividad

Estimación para concluir el trabajo restante

Índice de Desempeño del Trabajo por

Completar (TCPI)

Presupuesto hasta la conclusión

Valor Ganado

Costo Real

Estimación hasta la conclusión

Tabla 45: Gestión de proyectos. Gestión de riesgos

Indicador Medida

% de los proyectos que consideran de riesgoProyectos en riesgo

Total de proyectos

% de los proyectos con cambios de alcance Proyectos con cambios de alcance

Total de proyectos

% de los proyectos "en el control"Proyectos en control

Total de proyectos

81

82 Chapter I

Promedio del número de modificaciones

realizadas al proyecto desde su definición

Numero de modificaciones

Ciclo de vida del proyecto

% de los proyectos a tiempo y dentro del

presupuesto

Coste de todas las tareas

Calendario del proyecto

Tabla 46: Gestión de proyectos. Gestión de recursos humanos

Indicador Medida

Promedio del número de personas asignadas

al proyecto

Empleados asignados a un proyecto

Total de empleados

Tabla 47: Gestión de proyectos. Gestión de adquisición

Indicador Medida

Requisición de tiempo de emisión temaTiempo de inicio de la solicitud

Tiempo de fin de la solicitud

Tabla 48: Gestión de proyectos. Gestión de adquisición

Indicador Medida

Tiempo en cerrar la incidencia

Tiempo de resolución

Tiempo de detección

Tiempo total en resolver todas las incidencias

Tiempo promedio que se tarda en responder

incidentes

Tiempo de detección

Tiempo en el que se toma la primera medida

Tiempo total que se tardó en resolver tolas las

incidencias

Número total de incidentes por fuenteNúmero de incidencias

Fuente de inciden

% de incidente no resueltos dentro del plazo Incidentes retrasados

Procedimientos abiertos

Número de incidentes graves Incidentes graves

% de los incidentes repetidos

.Incidentes repetidos

Total de incidentes

% de incidentes tratados en los tiempos

de respuestas acordados

Número de casos cerrados

Número de casos abiertos

Tiempo en resolver un incidente

82

Tabla 48: Gestión de proyectos. Gestión de adquisición

Indicador Medida

Costo promedio para resolver un incidente

Costo fijos del incidentes

Costos variables del proceso de gestión

Total de incidentes

% de incidentes incorrectamente asignados

Incidentes incorrectamente asignados

Incidentes asignados

Total de incidentes

% de incidentes mal clasificadosIncidentes abiertos

Incidentes mal clasificados

Número de incidentes cerrados en relación con

el número de incidentes abiertos

Número de casos cerrados

Número 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 información

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 dónde vamos a obtener los datos que vamos a explotar.

Este apartado ha sufrido una adaptación 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 más 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 sería

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 través de dos métodos. 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 método 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: Relación 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 | Almacén

OLCT Sucursal

OINV Tiempo, Total de ventas, Variación Ventas, Beneficio, Variación Beneficio

ORIN Tiempo, Total de ventas, Variación Ventas, Beneficio, Variación Beneficio

OCRY Geografía | País

OCST Geografía

En la Figura 35 se ha ilustrado un ejemplo de cómo sería 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 perspectivahija de X, como por ejemplo: Año|Mes

85

86 Chapter I

Para crear el esquema de la base de datos de Gestión de Ventas se parte de una base de

datos ya existente; sin embargo, para crear la de Gestión de Proyectos e Incidencias se inicia

desde cero, apreciándose en la Figura 36 dicho esquema.

Figura 36: Esquema de la bases de datos de Gestión de Proyectos e Incidencias

II.2.1.2.2.3 Nivel de Granularidad

La selección 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 línea de factura. La

28 La tabla hecho Ventas es la que contendrá las medidas para crear posteriormente los indicadores

86

decisión sobre la granularidad de las tablas de hechos también determinará la granularidad de

cada una de las tablas de dimensión. Por ejemplo, si la granularidad de la tabla de hechos

Ventas es la de las ventas realizadas en cada línea de factura, entonces la granularidad de la

dimensión producto será los detalles del producto correspondiente a una línea concreta. Para

que el lector entienda estos conceptos se ha definido la granularidad de la perspectiva

CLIENTE:

OCRD.- En esta tabla están 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 código ú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 dirección que el cliente

elige como principal, donde quiere que se le envié la mercancía o la factura. La

dirección 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 mercancía. Esta calle pertenece a

la dirección elegida por el cliente como principal.

MailCity.- Es la ciudad del destinatario de la mercancía. Esta ciudad pertenece

a la dirección elegida por el cliente como principal.

MailCount.- Es el municipio del destinatario de la mercancía. Este municipio

pertenece a la dirección elegida por el cliente como principal.

MailCounttr.- Es el país del destinatario de la mercancía. Este país pertenece a

la dirección elegida por el cliente como principal.

State2.- Es la provincia del destinatario de la mercancía. Esta provincia

pertenece a la dirección elegida por el cliente como principal.

CRD1.- Un cliente puede tener más de una dirección, 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 dirección almacenada en esa fila hace referencia al

lugar donde se entrega la mercancía o por el contrario hacer referencia al lugar donde

se va a entregar.

Address.- Es el nombre de la dirección.

County.- Municipio al que pertenece el cliente.

Country.- País 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 unívocamente 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 unívocamente 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 cuáles

son los campos o medidas que se necesitan para crear el indicador. Con este fin se

adjunta debajo de cada perspectiva o dimensión los campos seleccionados y bajo

cada indicador su respectiva fórmula de cálculo.

Figura 37: Modelo conceptual ampliado Gestión de Ventas

88

II.2.1.2.3 Fase 3: Modelo Lógico del DW

Seguidamente, se diseña el modelo lógico 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 cómo se van a diseñar 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 Lógico 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 decisión correcta entre un esquema en estrella, constelación o copo de

nieve es importante ya que afecta considerablemente la elaboración del modelo lógico.

En el caso de estudio se optó por un esquema en copo de nieve debido a que las

perspectivas o dimensión se van organizar jerárquicamente. Además 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 diseño, hace una mejor

utilización del espacio y, al estar normalizadas las tablas dimensiones, requiere menos

esfuerzos de diseño.

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 fácil de utilizar. Un conjunto de

dimensiones incompleto o que no se presente adecuadamente reducirá la utilidad que

el Data Warehouse tiene para la organización. En este apartado se va a proceder a

diseñar las tablas dimensiones que forman parte del Data Warehouse.

Cada perspectiva definida en el mapa conceptual corresponde con una tabla

dimensión. Para el caso práctico que se está abordando se ha hecho lo siguiente:

Se elige un nombre que identifique la tabla dimensión

Se añade un campo que represente su clave principal

Se definen las jerarquías dentro de las dimensiones

Se redefinen los nombre de los campos si es que no son lo bastante intuitivo

Las jerarquías definidas que siguen las dimensiones se observa en la Figura 38.

89

90 Chapter I

Figura 38: Jerarquía dimensión

Al haber elegido un tipo de esquema en copo de nieve, aquellas tablas de dimensión

donde existen jerarquías, deberán ser normalizadas. Se toma como ejemplo la

siguiente tabla dimensión y sus respectivas relaciones “padre-hijo” entre sus campos:

Figura 39: Jerarquía Dimensión Geografía

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 jerarquía de dimensión.

Figura 40: Dimensión Unidad de Negocio

90

Figura 41: Dimensión Tiempo

Figura 42: Dimensión Cliente

Figura 43: Dimensión Gestión de Ventas

Figura 44: Dimensión Canal

Figura 45: Dimensión Geografía

91

92 Chapter I

Figura 46: Dimensión 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 través de las cuales se constituyen los indicadores de estudio.

Es importante destacar que las tablas de hechos deben contener solamente valores

numéricos y aditivos, esto es debido a que en muy pocas oportunidades se harán

consultas por un solo registro de la tabla de hechos, lo común es traer cientos o quizás

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 información

analizada, área de investigación, negocio enfocado. En el presente estudio es

la tabla de hechos de Ventas.

Se define su clave primaria, que se compone de la combinación de las claves

primarias de cada tabla de dimensión 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: Conversión 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 LíneaTotal

92

Figura 47: Esquema del diseño 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 facturación o ventas. En el caso de estudio, se ha

añadido como hecho precalculado los que se observan en la Tabla 51.

Tabla 51: Hechos precalculados

Nombre en la tabla hecho Fórmula

PrecioCosteXCantidad Cantidad * PrecioCoste

PrecioVentaXCantidad Cantidad * PrecioVenta

TotalVentaLinea LineaTotal –( (LineaTotal *DtoDocumento)/100)

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

Figura 48: Diseño de la tabla de Hechos de Venta

93

94 Chapter I

II.2.1.2.3.4 Uniones

A continuación se hacen las uniones pertinentes entre las tablas dimensiones y el

hecho, observándose el resultado en la Figura 49.

Figura 49: Primera aproximación al diseño lógico del Data Warehouse.

La Figura 49 muestra una primera aproximacion al diseño lógico del Data Warehouse y

es una “primera aproximación” porque hubieron varias hasta conseguir un diseño que

se ajustará a los requerimientos exigidos. Un ejemplo claro está en la Dimensión

Unidad de Negocio, ya que cuando se hizo la carga de los datos resulta que el cliente

no realiza distincion entre Sucursal y Delegación, 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

dimensión geografía, finalmente solo se almacena el Pais y la Provincia del cliente

debido a que en la base de datos SAP los campos Isla estaban vacíos, 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 información 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 existía la solución de imputación de datos.

Finalmente se opta por almacenar solo el pais y la provincia.

La Figura 50 muestra el esquema lógico del Data Warehouse final.

94

Tabla 52: Comparación Dimensiones Unidad de Negocio

Primera aproximación ResultadoFinal

Tabla 53: Comparación Geografía

Primera aproximación ResultadoFinal

Figura 50: Esquema lógico del Data Warehouse

95

96 Chapter I

II.2.1.2.4 Fase 4: Integración de datos

Una vez construido el modelo lógico, se debe proceder a poblarlo con datos, utilizando

técnicas de extracción, transformación y carga (ETL). Posteriormente se procede a

definir las reglas y políticas para su respectiva actualización, así como también los

procesos que se lleven a cabo.

II.2.1.2.4.1 Extracción

Es aquí donde, basándose en las necesidades y requisitos de los usuarios, se exploran

las diversas fuentes OLTP que se tengan a disposición y se extrae la información que

se considere relevante al caso.

Si los datos operacionales residen en un SGBD Relacional, el proceso de extracción 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 organización diferente

de los datos o formatos distintos. La extracción convierte los datos a un formato

preparado para iniciar el proceso de transformación.

Una vez que los datos son seleccionados y extraídos, se guardan en un

almacenamiento intermedio, de esta manera se podrán 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 extracción es que ésta

cause un impacto mínimo en el sistema origen. Si los datos a extraer son muchos, el

sistema de origen se podría ralentizar e incluso colapsar, provocando que éste no

pueda utilizarse con normalidad para su uso cotidiano. Por esta razón, en sistemas

grandes las operaciones de extracción suelen programarse en horarios o días donde

este impacto sea nulo o mínimo. 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 extracción y carga de datos en

un Data Warehouse. En SAP la tabla OCRY contiene la información referente a Países,

extrayéndolos a través de una consulta SQL —ver Figura 52— y almacenándola en la

subdimensión País (SdPaís) en el Data Warehouse.

Figura 51: Ejemplo de extracción con SSIS

96

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

II.2.1.2.4.2 Transformación

La fase de transformación aplica una serie de reglas de negocio o funciones sobre los

datos extraídos para convertirlos en datos que serán cargados. Algunas fuentes de

datos requerirán alguna pequeña manipulación de los mismos. Los casos más

comunes en los que se debe realizar integración, son los siguientes:

Codificación

Medida de atributos.

Convenciones de nombramiento.

Fuentes múltiples.

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

Hay que evitar que el DW sea cargado con valores faltantes o anómalos, al igual que

también se deben establecer condiciones y restricciones para asegurar que solo se

utilicen los datos de interés.

Para el caso de estudio, sólo 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 Descripción

Valores nulos Hubo la obligación de renombrarlos como “Sin valor”, debido a que el cliente quiso

contemplar ciertas perspectivas de análisis para las cuales no almacenaba valores.

Se tomó esta decisión en vez de omitirlos para que el cliente, al comprobar los

resultados, pudiera corregir el error y rellenar los campos que son objeto de interés

para su análisis y así poder llevar a cabo su objetivo.

Codificar

valores

Aquellos campos cuyo contenido no poseía una descripción lo suficientemente

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 Descripción

significado alguno, sustituyéndolos por Cliente, Proveedor y Leads.

Conversión tipo Se realizaron las conversiones de tipo de dato oportunas para poder almacenar los

datos en el Data Warehouse

Calcular totales

de múltiples

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 información 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: Transformación de valores nulos de la tabla OSLP de SAP

98

Figura 54: Sustitución 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 función se encarga, por un lado de realizar las tareas relacionadas con:

Carga Inicial

Actualización o mantenimiento periódico

La carga inicial, se refiere precisamente a la primera carga de datos que se realiza al

Almacén 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 más de cinco años.

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 jerarquías de dimensiones, se comienza cargando las tablas de

dimensiones del nivel más general al más detallado.

99

100 Chapter I

Figura 55: Carga del almacén de datos

Antes de realizar una nueva actualización, es necesario identificar si se han producido

cambios en las fuentes originales de los datos recogidos, desde la fecha del último

mantenimiento, a fin de no atentar contra la consistencia del DW. Para efectuar esta

operación, 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 técnicas mixtas.

Las políticas de actualización que ha convenido con los usuarios son los siguientes:

La información se actualiza cada viernes por la noche, esto es así debido a que

cada lunes el cliente necesita saber cómo 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 cuestión, sobrescribiendo el

antiguo, excepto la dimensión cliente que es de Tipo2 lo que requiere que se

agreguen algunas columnas adicionales a la tabla de dimensión, para que

almacenen el historial de cambios.

Los datos de la tabla dimensión tiempo se cargan de manera incremental

teniendo en cuenta la fecha de la última actualización.

II.2.1.2.5 Fase 5: Creación de Cubos Multidimensionales

100

Los cubos multidimensionales son una representación 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 más importantes que se pueden incluir en un

cubo multidimensional, son los indicadores, atributos y jerarquías. 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 dimensión o un

grupo de medida que se definen según una combinación de datos del cubo,

operadores aritméticos, números 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, Variación de Ventas

y Variación del Beneficio donde la Tabla 55 ayuda a aclarar estos conceptos.

Tabla 55: Miembro calculado con su fórmula y la relación con el cálculo de KPI

Nombre Miembro Calculo Miembro Calculo KPI

Measure.Beneficio

PrecioVentaXCantidad –[(PrecioCosteXCantidad*100)/PrecioVentaXCantidad]

Es una sumarización de

Measure.Beneficio

Measure.Variacion MeasureBeneficio periodo Es una sumarización de

101

102 Chapter I

Beneficioactual / MeasureBeneficio

periodo anteriorMeasure.VariaciónBeneficio

Measure.Variacion

Ventas

Measure.VariacionVentas

periodo actual /

Measure.VariacionVentas

periodo anterior

Es una sumarización de

Measure.VariacionVentas

II.2.1.2.6 Fase 6 Implementación: Sql Server 2008 R2 IntegrationServices

Microsoft Integration Services es una plataforma para la creación de soluciones

empresariales de transformaciones de datos e integración de datos. Integration

Services sirve para resolver complejos problemas empresariales mediante la copia o

descarga de archivos, el envío de mensajes de correo electrónico como respuesta a

eventos, la actualización de almacenamiento de datos, la limpieza y Minería de Datos y

la administración de objetos y datos de SQL Server.

Integration Services puede extraer y transformar datos de muchos orígenes distintos,

como archivos XML, archivos planos y orígenes de datos relacionales, y,

posteriormente, cargarlos en uno o varios destinos. Las herramientas gráficas de

Integration Services se pueden usar para crear soluciones sin escribir una sola línea de

código.

En los procesos ETL en estudio, se utiliza Integration Services para extraer los datos

de orígenes. 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 orígenes citados anteriormente. También se

realiza tareas de procesamiento periódico de los cubos de Analisys Services, los cuales

tendrán 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 rápidos y permiten crear una gran cantidad de procesos en reducidos periodo

de tiempo de desarrollo e implementación. Es una herramienta muy intuitiva y muy fácil

de usar. Pero utilizarla sin un previo diseño 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 información de ese proceso y que se llaman paquetes.

En la Tabla 56 se enumeran una serie de características destacables del producto.

Tabla 56: Características del Integration Services

Permite la integración con Sistemas de Bases de Datos y con ficheros

Obtiene un alto rendimiento al mantener los datos en memoria, además permite concurrencia y

paralelismo

Permite gestionar alertas y notificaciones

Tiene tareas de “data profiling”, limpieza y minería 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 documentación que explique en detalle la herramienta, es decir, que abarque problemas

reales y no solamente los ideales.

La necesidad de contar con una tecnología con altos requisitos.

Poca información de cómo optimizar el ETL, es decir, que componentes se deben usar solo en

caso necesario porque ralentizan el proceso, o como sustituirlos por otros.

A continuación la Figura 58 muestra la ejecución del Integration Services: las cajas,

marcadas con color verde, indican que ya han sido ejecutadas y han tenido éxito, las

amarrillas están en ejecución y las blancas están a las espera. En caso de que durante

el proceso falle alguna caja cambiará el color de amarillo a rojo y terminará la

ejecución.

103

104 Chapter I

Figura 58: Ejecución del SSIS

Como se puede ver en la Tabla 59 se han medido los tiempos de ejecución del proceso

ETL con el programa Interation Services y que ha sido ejecutado con dos máquinas

diferentes —la Tabla 58 muestra las características de cada máquina.

Tabla 58: Característica de las máquinas donde se ejecutó el ETL

Máquina A

Máquina B

Tabla 59: Estadísticas de ejecución

Tiempo máquina A Tiempo máquina B

Ejecución ETL 00:02:18.575 00:31:02:04

Una vez poblado el almacén de datos ocupó 46MB y contiene la información referente

a 4 años, al realizar actualizaciones semanales se estima que pueda crecer un 0,2%

semanal, por lo tanto es importante el lugar físico donde se almacene y que cuente con

escalabilidad.

II.2.1.2.7 Fase 7 Implementación del Modelo lógico 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 información 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 prediseñadas para informes.

Generalmente las consultas ad hoc permiten a los usuarios con poca

experiencia en SQL tener el mismo acceso a la información de la base de

datos, para esto los sistemas que soportan ad hoc poseen GUIs para

generarlas.

Autoservicio de

informes Permite a los usuarios realizar sus propios informes

Fuente de

información de gran

calidad

Se debe ofrecer al usuario una información limpia, amigable, elaborada y

confiable, que le permita obtener información analítica para reflejarla en sus

informes

Tiempo de respuesta

rápidos

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

rápido

Minería de datos Segmentar o hacer predicciones en base a grandes volúmenes de datos

La característica de datos multidimensionales de Microsoft SQL Server Analysis

Services le permite diseñar, crear y administrar estructuras multidimensionales que

contienen detalles y datos agregados de numerosos orígenes de datos, como bases de

datos relacionales, en un único modelo lógico unificado compatible con cálculos

integrados.

Los datos multidimensionales de Analysis Services proporcionan un análisis rápido,

intuitivo y descendente de grandes cantidades de datos basado en este modelo de

datos unificado, que puede llegar a los usuarios en múltiples idiomas y monedas. Esta

característica funciona con Data Warehouse, Data Marts, bases de datos de

producción y almacenes de datos operativos, y es compatible con el análisis de datos

históricos y en tiempo real.

La Tabla 61 describe las características 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 definición y almacenamiento de cubos

Escalabilidad Arquitectura proporciona una gran variedad de escenarios de almacenamiento y

una solución automatizada para el síndrome de explosión de datos que existe en las tecnologías

OLAP tradicionales.

Integración de herramientas de administración, seguridad, orígenes de datos y caché de cliente-

servidor.

API ampliamente compatibles y arquitectura abierta

Compatibilidad con aplicaciones personalizadas

Los principales inconvenientes de dicha tecnología se muestran en la Tabla 62.

105

106 Chapter I

Tabla 62: Inconvenientes Analisys Services

Resulta muy difícil cruzar datos de varios Cubos Olap

Dificultad a la hora de explotar la información cuando no usamos Microsoft Excel

Falta de documentación 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 físico, recordando que esto se realiza en

un vector multidimensional, ver apartado Data Warehouse Manager, al igual que en el

almacén de datos se deben tomar medidas de escalabilidad para prevenir posibles

problemas futuros de almacenamiento.

II.2.1.2.8 Representación

En este punto se va a estudiar como representar la información que se quiere analizar.

Para ello se van a usar dos herramientas: una de generación de informes y otra para la

creación de cuadros de mando.

106

En este proyecto no se llegó a generar informes debido a que no dio tiempo y el cliente

estaba más interesado en la creación de cuadros de mando, aun así, se estudia dos

herramientas para la generación de informes.

II.2.1.2.8.1 Creación de informes

A la hora de crear informes se estudiaron dos herramientas: Reporting Services y

Microsoft Excel.

Reporting Services (SSRS).- Es una plataforma de creación de informes

basada en servidos que ofrece una completa funcionalidad de creación de informes

para una gran variedad de orígenes de datos. Reporting Services contiene un

completo conjunto de herramientas para crear, administrar y entregar informes, así

como interfaces de programación 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

dinámicos, partiendo de tablas dinámicas que no son más que consultas a un cubo

OLAP. Esta conexión con el cubo generado por el Analysis Services va a permitir

realizar una gran variedad de consultas al sistema. Con un informe de tabla dinámica

puede resumir, analizar, explorar y presentar un resumen de los datos de la hoja de

cálculo 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

podrían servir para mirar los datos desde perspectivas diferentes y comparar las cifras

de datos similares. A continuación en la Figura 61 se puede ver un informe de tabla

dinámica generado en Excel.

Figura 61: Informe generado con Microsoft Excel

Como se ha comentado, no se genera ningún informe con dicha herramientas, pero si

se hizo una labor de investigación, donde las conclusiones se reflejan en la Tabla 63.

Tabla 63: Comparación Reporting Services vs Excel

Reporting Services Microsoft Excel

En los esquemas permite hasta 7 niveles de

anidamiento

Más fácil de usar. Muy intuitivo

Si el elemento de informe que controla si la

visualización de otro elemento va activarse o

desactivarse no está en la fila o en la columna

anterior o siguiente al elemento controlado, el

esquema también se deshabilita.

Procesa millones de filas con casi el mismo

rendimiento que mil filas

Informes más elaborados con un aspecto visual

muy atractivo

Crear aplicaciones que se incrusten o vinculen

a un explorador Web para presentar y

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 características 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 Creación de cuadros de mando

A la hora de llevar a cabo el desarrollo de un cuadro de mando integral para la solución

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 específico para la implementación de cuadros de mando. A través de

una interfaz gráfica sencilla permite convertir las hojas de cálculo Excel en cuadros de

mando interactivos basados en la tecnología 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 conlas tablas de Excel incrustadas en el programa

109

110 Chapter I

Fallos en la importación de los datos desde hojas Excel externas

Imposibilidad de alimentar los gráficos directamente con consultas en MDX directascontra la base de datos analítica, con el fin de integrar el cuadro de mando en unaplataforma web y no como un informe dinámico

Microsoft Performance Point

Performance Point es un servicio, de Microsoft SharePoint 2010, de administración,

supervisión y análisis empresarial. Cuenta con herramientas para la creación de

paneles o Dashboards, cuadros de mando o Scorecards, informes e indicadores de

rendimiento KPIs. Se ha descartado también el uso de esta solución por las siguientes

razones:

Coste de las licencias

Aumento de tiempos en el desarrollo ya que conlleva la implantación de unaplataforma 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 reproducción

de vídeos, gráficos vectoriales, animaciones,.. de forma similar a lo que hace Adobe

Flash. Para programar aplicaciones en esta tecnología se hace uso del IDE Visual

Studio 2010. Pero el tiempo de desarrollo y preparación necesario para la

implementación 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 conexión bien definida con los cubos deSSAS

Por su potencia y gran usabilidad en el mundo empresarial

La curva de desarrollo y aprendizaje respecto a otras soluciones, disminuyeconsiderablemente permitiendo cumplir los plazos del proyecto

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

un estudio previo de cuál era la mejor la representación, 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 información de forma eficaz, siendo:

Se ha prestado especial atención en los colores utilizados para el diseño delcuadro de mandos, debido a que el 10% de los hombres y 1% de mujeres sondaltónicos, siendo una de las prácticas más habituales la representación demedidas de alertas a través de los colores rojo, amarillo y verde, pudiendo llevar alas personas que sufren este síndrome a la toma de decisiones empresarialesequivocadas.

Figura 63: percepción de los colores rojo, verde, amarillo por parte de las personas daltónicas

Por lo que se decidió utilizar colores que puedan permitir diferenciar tonalidades por

parte de las personas daltónicas o el uso tipo de gráfico donde se resalte la tendencia

positiva o negativa como se ve en la Figura 64.

Figura 64: se observa las representaciones adaptadas para personas daltónicas

Por otro lado se ha hecho una selección de todos aquellos gráficos que se adaptanmejor, para la representación de información de negocio atendiendo a lossiguientes criterios:

1. Gráfico de bala: Este grafico fue diseñado por Stephen Few, creadoespecíficamente para ser representado en cuadros de mando. Permite deforma rápida, eficaz y ocupando muy poco espacio identificar si el indicadorque se quiere medir es bueno o malo dentro de un determinado contexto. Estegráfico no se ha llegado a utilizar debido a que no venía como grafico nativo enExcel 2007, pero se considera que es un buen grafico a tomar en cuenta. Enla Figura 65 tenemos un ejemplo de gráfico de viñeta

Figura 65: Ejemplo de gráfico de bala

29 Stephen Few tiene más de 20 años trabajando como innovador en el mudo del IT, como educador y consultor. Hacentrado sus estudios en la visualización para el análisis de los datos y en la comunicación de información de negocio.

111

112 Chapter I

2. Gráfico de barras: Los gráficos de barra se han seleccionado ya que permitenla comparación de las medidas representadas, así como la rápida localizaciónde los datos más significativos al estar ordenados. Además son el tipo degráfico que predomina en Excel 2007

3. Gráfico de pila: Es una variación al gráfico de barras y es recomendable parauna única serie dividida en diferentes partes.

4. Gráfico de línea: Ideal para la representación de tendencias, fluctuaciones yciclos a lo largo del tiempo, así como un conjunto de datos varía en relación aotro.

5. SparkLines: Este grafico es idéntico a uno de línea pero en cambio serepresenta sin etiquetado ni escala, normalmente al lado de un indicador con elfin de representar la tendencia que ha seguido a través de un periodo detiempo.

Tabla 64: Ejemplo de gráfico Sparklines

6. Tabla: En una tabla simple muchas veces se puede representar la mismainformación que en un gráfico complejo y ocupando mucho menos espacio.

Se estudió cada uno de los indicadores y se realizó una clasificación atendiendo a los

criterios antes mencionados.

Tabla 65: Indicadores y su representación grafica

Indicadores Tipo de Grafico que se adapta mejor

Total de ventas

Gráfico de Bala (H - V)

Gráfico de Barras (H - V)

Gráfico de Líneas

SparkLines

Variación de ventasGráfico de Bala (H - V)

Gráfico de Líneas

Beneficio

Gráfico de Bala (H - V)

SparkLines

Gráfico de Barras (H - V)

Variación de BeneficioGráfico de Bala (H - V)

Gráfico de Líneas

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

Capítulo 3. Análisis de los resultados

Resumen:

Análisis 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 compañía una mirada

global de las prestaciones del negocio, con una sola ojeada se podrá saber cómo va la

empresa y en qué puntos de la misma se deben emprender medidas correctivas. Permite tanto

guiar el desempeño actual como apuntar al desempeño 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 gráfica titulada “Total de ventas” se comparan las ventas de los años 2008, 2009

y 2010. Se puede observar que el año donde hubo una mayor cantidad de ventas fue en 2009.

Hay que aclarar que este cliente creo su empresa en el año 2008 y el 29 de Septiembre de ese

mismo año fue cuando comenzó a emitir facturas, por tanto es comprensible que desde Enero

a Septiembre exista esa diferencia de ventas del año 2008 con respecto al 2009; en cambio,

los meses de Octubre, Noviembre y Diciembre más o menos son similares.

115

116 Chapter I

En el año 2010 las ventas disminuyeron notablemente, sobre todo los meses de Julio a

Diciembre. Se averiguo que en esos meses hubo problemas técnicos con el programa de

facturación y no se recogieron datos.

La empresa se fijó como objetivo superar las ventas del año anterior un 2%, dando por sentado

que en el año 2008, como se acaba de crear, no se pudo comparar.

En el año 2009, si se observa la Figura 70 la gráfica con título “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 tenía 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 año 2009 donde supera ese 2% de objetivo con respecto al año anterior.

En el gráfico “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. Después del mes

de Junio, las ventas en el año 2010 bajan por la razón 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 año 2009.

Figura 71: Cuadro de mando de “Total de Ventas”

En la Figura 71 en el gráfico “Total de ventas por familia de productos”, se puede observar cual

es la familia de productos que más ha vendido, familia “Productos cocidos” y la que menos es

la familia de “Productos mayoristas”. Este análisis es interesante porque quizás se debería

indagar en por qué los “Productos mayoristas” son unos de los menos vendidos ya que puede

116

interesar realizar una campaña 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 número de ventas es la provincia “Sin Valor”,

¿Qué ha ocurrido? ¿Ha habido un error en el gráfico?

La respuesta es NO. Lo que ha pasado es que el usuario no ha rellenado en un gran número

de facturas del campo provincia del cliente, por tanto este caso sirve de referencia para que el

gerente, que vaya a analizar este gráfico, tome medidas para que se recojan estos valores en

el momento de la facturación, si es que le interesa estudiar el “Total de ventas por provincia”

117

118 Chapter I

Parte III. Conclusiones, Final

118

Capítulo 1. Conclusiones y posibles ampliaciones

Inicialmente, el propósito de este proyecto era implantar una solución BI integrada con

SAP BO que contemplara los procesos de Gestión de Ventas, Gestión de Finanzas,

Gestión de proyectos y Gestión de Incidencias. Sin embargo, solo se llegó a finalizar

para la Gestión de Ventas ya que el objetivo inicial quizás era muy ambicioso y el

tiempo limitado.

Se planteó, por tanto, realizar un estudio del arte inicial y una elaboración de una

metodología para el desarrollo de una solución BI.

Este proceso condujo a la consecución de los siguientes logros.

Estudio del Arte

Se realizó una labor bastante importante de consultoría para el estudio y análisis del

proyecto. Desatancando tres puntos muy importantes:

Estudio de aplicaciones existentes en el mercado y demanda de mercado

respecto a funcionalidades.

Tecnologías destacadas en el sector de BI

Demanda de mercado de soluciones BI

Entendemos que ésta es una de las partes más importantes y duras del proyecto, ya

que de aquí se construye la base de todas las funcionalidades y desarrollo del mismo.

Análisis y obtención de requisitos funcionales

Una vez realizado el análisis 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 metodología

de desarrollo ágil SCRUM, obteniendo el Product Backlog del proyecto priorizándolo.

La dinámica de trabajo con esta metodología ha sido enriquecedora a la vez que nos

ha llevado a tener un buen ritmo de trabajo en colaboración con ITOP MC.

119

120 Chapter I

Elaboración de una metodología propia para la creación de unasolución BI

Esta metodología, elaborada con base a la metodología “HEFESTO”, fue de vital

importancia para dotar al proyecto de suficiente robustez a la hora de crear una

solución BI para el proceso de Gestión de Ventas. Una gran ventaja es que se adapta

muy bien a SCRUM, lo que agiliza el proceso de implementación y una rápida

adaptación a los cambios que iban surgiendo por motivos de errores de comprensión o

cambios de tecnologías.

Implementación de la solución.

Se creó una aplicación BI para la “Gestión 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 aplicación Web para que el gerente o

responsable de la empresa pueda consultar los resultados de sus ventas en cualquier

momento. No se realizan grandes cálculos y complejos algoritmos, sin embargo, se

han concentrado grandes esfuerzos en la validación de los datos, en formatearlos de

forma adecuada y crear una serie de cuadros de mandos interactivos y dinámicos.

Posibles ampliaciones

Como posible ampliación queda implementar una solución BI para los procesos de

Gestión de Finanzas, Gestión de Proyectos y Gestión de Incidencia, así como sería

interesante integrar un módulo de Data Mining que sirve de ayuda al gerente o

responsable de la empresa a la hora de tomar decisiones.

Capítulo 2.

120

Parte IV. Bibliografía

Parte V.1. Kniberg, Henrick. . http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-

y-xp-desde-las-trincheras.pdf. [En línea] 09 de 06 de 2011.

Parte VI. 2. Dario, Bernabeu R. Investigación y Sistematización de HEFESTO:

Metodología propia para la Construcción de un Data Warehouse. [En línea] 09 de 06 de 2011.

Parte VII. 3. Commerce, Office of Government. ITIL Gestión de Servicios TI. [En línea]

05 de 01 de 2011. http://itil.osiatis.es.

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, The Effective Visual

Communication of Data. s.l. : O'Reilly, 2006.

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. Roldán, María 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 Problem–Design–Solution. 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. Anónimo. 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. 18. —. ITIL Continual Service Improvement. s.l. : Office Government Comerce,

2009.

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, Developing,

Implementing, and Using Winning KPIs. s.l. : John Wiley & Sons, Inc., 2010.

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. 27. Inmon, W. H. Building the Data Warehouse. s.l. : Design & Composition,

2010.

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. Anónimo. Scrum. Definición de Scrum. [En línea] 23 de 06 de 2011.

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

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

Capítulo 1.

123

124 Chapter I

Glosario de términos

A

agregación...................................................................................................................................................................26

Analysis Services..................................................................................................................................43, 102, 103, 105

Atributo.......................................................................................................................................................................64

Atributos de dimensión...............................................................................................................................................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

Dueño 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 constelación...........................................................................................................................................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

Gestión de Incidencias............................................................................................................64, 66, 71, 72, 76, 77, 117

Gestión de Proyectos........................................................................................................62, 63, 66, 68, 76, 77, 84, 118

Gestión de Ventas.......................................................................................................................63, 66, 76, 84, 117, 118

Gráfico de bala..........................................................................................................................................................109

Grafico de barras.......................................................................................................................................................109

Gráfico de línea....................................................................................................................................................63, 109

Gráfico de pila......................................................................................................................................................64, 109

H

Hechos básicos............................................................................................................................................................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 dinámicos.................................................................................................................................................3, 33

Informes estáticos.......................................................................................................................................................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

Minería 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 Información.......................................................................................................................................14, 127

Sistemas de Información Ejecutiva..............................................................................................................................16

Sistemas Transaccionales.............................................................................................................................................14

Slowly Changing Dimensions...............................................................................................................................24, 127

solución 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

subdimensión..............................................................................................................................................................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 DEFINICIÓN

BI Business Intelligence o Inteligencia de Negocios

BPM Business Process Management o Gestión de Proceso de Negocio

DSS Decision Support Systems o Soporte al sistema de decisiones

DW Data Warehouse o Almacén de Datos

EIS Executive Information Systems o Sistemas de Información Ejecutiva

ERP Enterprise Resource Planning

ETL Extracción Transform Load o Extracción Transformación y Carga

ITILInformation Technology Infrastructure o Biblioteca de Infraestructura de

Tecnologías de Información

ITOP MCInformación Tecnología Organización Proceso Management

Consulting

KPI Key Performance Indicators o indicadores de rendimiento clave

ODS Operational Data Store

OLAP On-Line Analytical Processing o Procesamiento Analítico en Línea

OLTP On-Line Transaction Processing o Bases de Datos Transaccionales

PMI Project Management Institute

SAPSystem, 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 Información

128

SRDWM The SAS Rapid Data Warehouse Methodology

TI Tecnología de la Información

Apéndices

I. Actas de las reuniones con la empresa ITOP MC

129

130 Chapter I

130