• Author / Uploaded
• publiwil

• Categories
• Almacén de datos
• Toma de decisiones
• Bases de datos
• Tabla (Base de datos)
• Información

Citation preview

Business Intelligence para PYMES

Autor/es:

Manuel Alejandro González Yanes Rebeca Mora Anca

Director/a: Virginia Gutiérrez Rodríguez Fecha: 12 de Julio de 2011

2

Chapter I

D./Dña. Virginia Gutiérrez Rodríguez Profesora de la Escuela Técnica Superior de Ingeniería Informática, y adscrito al Departamento de Estadística, Investigación Operativa y Computación de la Universidad de La Laguna.

CERTIFICA: Que la presente memoria titulada Business Intelligence para PYMES, ha sido realizada bajo mi dirección por el/los alumno/s D. Manuel Alejandro González Yanes y Dña Rebeca Mora Anca, y constituye su Proyecto Fin de Carrera de Ingeniería Informática por la Universidad de La Laguna.

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

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

2

Resumen Se denomina inteligencia empresarial, inteligencia de negocios o BI (del inglés Business Intelligence) al conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa. La Business Intelligence actúa como un factor estratégico para una empresa u organización, generando una potencial ventaja competitiva, que no es otra que proporcionar información privilegiada para responder a los problemas de negocio: entrada a nuevos mercados, promociones u ofertas de productos, control financiero, optimización de costes, planificación de la producción, análisis de perfiles de clientes, rentabilidad de un producto concreto, etc... Las herramientas de inteligencia abarcan la comprensión del funcionamiento actual de la empresa como la anticipación de acontecimientos futuros, con el objetivo de ofrecer conocimientos para respaldar las decisiones empresariales. Las herramientas de Business Intelligence se basan en la utilización de un Sistema de Información de Inteligencia que se forma con distintos datos extraídos de producción, con información relacionada con la empresa o sus ámbitos y con datos económicos. Las herramientas de Business Intelligence ofrecen a las personas que toman las decisiones utilidades que facilitan ese proceso como: 

Cuadros de Mando para medir la evolución de los Indicadores clave del negocio cómo controlar las ventas o la situación económica.



Informes dinámicos con los que buscar causas o tendencias de forma sencilla y que permiten analizar clientes, proveedores, producción, etc. en profundidad.

El problema a abordar consiste en integrar SAP BO con una solución de Business Intelligence de forma que proporcione a las Pymes informes gráficos y cuadros de mandos interactivos que ofrezca una mayor versatilidad, control de los ingresos, los márgenes y la liquidez.

3

4

Chapter I

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

4

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......................................... 9 1.1Introducción................................................................................................................ 9 1.2¿Qué es BI?................................................................................................................ 9 1.2.1Proceso BI...................................................................................................... 10 1.2.2Arquitectura de una solución BI...................................................................... 10 1.3¿Qué es un Data Warehouse?................................................................................. 10 1.3.1Arquitectura de una solución BI con Data Warehouse ................................... 11

Capítulo 2.ITOP Management Consulting..................................................20 2.1La empresa............................................................................................................... 20 2.2Filosofía.................................................................................................................... 20 2.3Alianzas.................................................................................................................... 20

Capítulo 3.Descripción del problema e integración de soluciones tecnológicas .......................................................................................... 21 3.1Introducción.............................................................................................................. 21 3.2Análisis funcional y elección..................................................................................... 21 3.2.1Análisis Inicial................................................................................................. 21 3.2.2Conclusión ..................................................................................................... 23 3.3 Descripción del problema........................................................................................ 24

Parte II.Cuerpo principal. Descripción del trabajo........................................25 Capítulo 1.Descripción de la metodología para resolver el problema. . .26 1.1Metodología de desarrollo........................................................................................ 26 1.1.1Metodología SCRUM..................................................................................... 27

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

6

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

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

Parte III.Conclusiones, Final............................................................................73 Capítulo 1.Conclusiones y posibles ampliaciones...................................74

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

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

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

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

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

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

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

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

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

7

8

Chapter I

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

Parte XIV.10. Xavier Hacking, David Lai. SAP BusinessObjects Dashboards 4.0 Cookbook. s.l. : Packt Publishing, 2011......................76

Parte XV.11. Roland Bouman, Jos van Dongen. Pentaho Solutions Business Intelligence and Data Warehousing with Pentaho and MySQL. s.l. : WILEY....................................................................................76

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

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

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

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

Parte XX.16. Anónimo. The Official Introduction to the ITIL Service Lifecycle. s.l. : Published by TSO (The Stationery Office).....................76

Parte XXI.17. Commerce, Office of Government. ITIL Serivce Transition. s.l. : Published by TSO (The Stationery Office)...................................... 76

Parte XXII.18. —. ITIL Continual Service Improvement. s.l. : Office Government Comerce, 2009......................................................................76

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

8

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

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

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

Parte XXVII.23. John Wiley & Sons, Inc., Hoboken, New Jersey. Business Dashboards. s.l. : John Wiley & Sons, Inc., 2009................................... 76

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

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

Parte XXX.26. SQL SERVER INTEGRATION SERVICES 2008 LABORATORIOS . s.l. : INTERMEZZO BUSINESS INTELLIGENCE , 2010..............................................................................................................76

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

Parte XXXII.28. Viera, Robert. Professional Microsft SQL Server 2008 Programming. s.l. : Wiley Publishing, I nc, 2009.................................... 76

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

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

9

10

Chapter I

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

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

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

Parte XXXVIII.34. Langit, Guy Fouché and Lynn. Foundations of SQL Server 2008 R2 Business Intelligence. s.l. : Apress, 2009.....................77

Parte XXXIX.35. Kimball, Joy Mundy and Marren Thornthwaite with Ralph. The Microsft Data Warehouse Toolkit whit SQL Server. s.l. : Kimball Group, 2011.................................................................................................77

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

Parte XLI.37. Institute, Project Management. PMBOK. ................................77 Glosario de términos....................................................................................78 Índice de siglas.............................................................................................82 Apéndices......................................................................................................84

10

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 Decisiones 2 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 Transaccionales 3 para utilizar la información como respaldo a las decisiones, reduciendo el efecto negativo que puede traer consigo una mala determinación. Precisamente, Business Intelligence permite que el proceso de toma de decisiones esté fundamentado sobre un amplio conocimiento de sí mismo y del entorno, minimizando de esta manera el riesgo y la incertidumbre.

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

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

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

13

14

1.2

Chapter I

¿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-BusinessIntelligence-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 WalMart5, donde decidieron iniciar un proyecto de Basket Analysis 6 utilizando la información recogida de las ventas. Descubrieron una correlación estadísticamente significativa entre la compra de pañales y cerveza. Profundizando en el estudio, vieron que los compradores de cerveza y pañales eran varones de entre 25 y 35 años que solían comprar estos productos conjuntamente los viernes por la tarde. La cadena de supermercado tomo la decisión de colocar las cervezas cerca de los pañales, con la intención de que los padres que compraban pañales y que no solían comprar cerveza, se acordasen que faltaba cerveza en casa. Los resultados fueron espectaculares aumentando un 15% las ventas de cervezas con pañales. La Inteligencia de Negocios tiene sus raíces en los Sistemas de Información Ejecutiva 7 o Executive Information Systems (EIS) y en los DSS, pero ha evolucionado y se ha transformado en todo un conjunto de tecnologías capaces de satisfacer a una gran gama de usuarios, junto a sus necesidades especí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 sus ventas y número de empleados, la mayor compañía del mundo. Su concepto de negocio es la tienda de autoservicio de bajo precio y alto volumen.

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

7

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

15

16

Chapter I









1.2.2

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.

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 Inmon 9, que expone: “Un Data Warehouse es una colección de datos orientada al negocio, integrada, variante en el tiempo y no volátil para el soporte del proceso de toma de decisiones de la gerencia”. donde en la Tabla 1 se aprecia en profundidad cada una de las características más detalladas.

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

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

17

18

Chapter I

Tabla 1: Características de un Data Warehouse

Orientado a temas

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

Integrado

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

Histórico (variante en el tiempo)

No volátil

1.3.1

Los datos, que pueden ir variando en el tiempo, deben quedar reflejados de forma que al ser consultados reflejen estos cambios y no se altere la realidad que había en el momento que se almacenaron, evitando así la problemática que ocurre en los sistemas operacionales, que reflejan solamente el estado de la actividad de negocio presente. Una vez almacenada la información en el Data Warehouse debe ser de solo lectura, nunca se modifica ni se elimina, debe ser permanente para futuras consultas.

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

Al integrar varias fuentes de datos puede existir más de una forma de codificar un atributo en común. Ejemplo: En el campo sexo algunos diseñadores definen su valor como “M” y “F” otros Codificación “Mujer” y “Hombre”. Se debe escoger una forma común para decodificar los atributos. Los tipos de unidades de medidas utilizados para representar los atributos de una entidad varían considerablemente entre sí, a través de los diferentes OLTP. Por ejemplo, al registrar la longitud de un producto determinado, las unidades de medidas pueden Medida de atributos ser explicitadas en centímetros, metros, pulgadas, etc. Se deberán estandarizar las unidades de medidas de los atributos, para que todas las fuentes de datos expresen sus valores de igual manera. Usualmente, un mismo atributo es nombrado de diversas maneras en los diferentes OLTP. Por ejemplo, al referirse al Convenciones de nombre del proveedor, puede hacerse como “nombre”, nombramiento “razón_social”, “proveedor”. Aquí, se debe utilizar la convención de nombramiento que para los usuarios sea más comprensible Un mismo elemento puede derivarse desde varias fuentes. En este caso, se debe elegir aquella fuente que se considere más Fuentes múltiples fiable y apropiada.

20

Tabla 2: Casos más comunes de transformaciones ETL

Limpieza de datos



I.1.3.1.3

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

Carga.- Esta función se encarga, por un lado de realizar las tareas relacionadas con: o Carga Inicial (Initial Load). Es el proceso de incorporar los datos al Data Warehouse o Actualización o mantenimiento periódico. Antes de realizar una nueva actualización, es necesario identificar si se han producido cambios en las fuentes originales de los datos recogidos, desde la fecha del último mantenimiento, a fin de no atentar contra la consistencia del Data Warehouse.

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 Este término hace referencia a un campo que será utilizado como criterio de análisis y que es almacenado en la tabla de hechos. Dimensiones Esto sucede cuando un campo que se utiliza como criterio de análisis posee el mismo degeneradas nivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no se pueden realizar agrupaciones o sumarizaciones a través de este campo, como por ejemplo "números de orden", "números de ticket", "números de transacción", etc. Atributos no Los niveles de la jerarquía también pueden tener atributos descriptivos, donde no son utilizados para formar niveles de jerarquía, sino para describir detalles en los mismos, dimensión como por ejemplo, el número de teléfono, la dirección de correo electrónico, etc. Describen diferentes niveles de agrupamiento específicos —explícitos o implícitos— y, Jerárquicas por lo tanto, las diferentes granularidades o niveles de detalle en la visión de los datos, como por ejemplo la jerarquía formada por Año, Trimestre, Mes y Día

En las tablas dimensiones, habitualmente no es posible utilizar la clave de negocio — business key— como clave principal —primary key— e incluso, en el caso que sea posible, no es aconsejable por temas de rendimiento, ya que desde este punto de vista es recomendable utilizar número enteros de pocos bytes. Si en un sistema transaccional tenemos, por ejemplo, una clave principal con dominio char(10), siempre será más óptimo utilizar un tipo de datos numérico de menos byte como clave principal en las tablas dimensiones. Se sustituirán las habituales clave de negocio por claves subrogadas —subrogate key— las cuales serán de tipo numérico y habitualmente autoincremental. Esta clave no tiene sentido a nivel de negocio, pero la necesitamos para identificar de forma única cada una de las filas. Un concepto importante dentro de este apartado son las dimensiones lentamente cambiantes o Slowly Changing Dimensions (SCD). Son dimensiones en las cuales sus datos tienden a modificarse a través del tiempo, ya sea de forma ocasional o constante, o implique a un solo registro o a la tabla completa. Cuando ocurren estos cambios, se puede optar por seguir alguna de estas dos grandes opciones:  

Registrar el historial de cambios. Reemplazar los valores que sean necesarios.

23

24

Chapter I

Inicialmente Ralph Kimball11 planteó tres estrategias a seguir cuando se tratan las SCD: tipo 1, tipo 2 y tipo 3, pero, a través de los años, la comunidad de personas que se encargaba de modelar bases de datos profundizó las definiciones iniciales e incluyó varios tipos SCD más, como tipo 4 y tipo 6. A continuación se detalla cada tipo de estrategia SCD: SCD Tipo 1: Sobreescribir. SCD Tipo 2: Añadir fila. SCD Tipo 3: Añadir columna. SCD Tipo 4: Tabla de Historia separada. SCD Tipo 6: Híbrido. De acuerdo a la naturaleza del cambio se debe seleccionar qué Tipo SCD se utilizará y, en algunos casos, resultará conveniente combinar varias técnicas.

Tablas de Hechos Las tablas de hechos representan un proceso de negocio, como por ejemplo, las ventas, las compras, los pagos entre otras. Estas tablas son utilizadas por los analistas de negocio para apoyar el proceso de toma de decisiones. Contienen datos cuantitativos. Los hechos son datos instantáneos en el tiempo, que son filtrados, agrupados y explorados a través de condiciones definidas en las tablas de dimensiones. El registro de hecho posee una clave primaria que está compuesta por las claves primarias de las tablas de dimensiones relacionadas a este.

Figura 10: Tabla de hecho “Ventas”

En la Figura 10 se aprecia la tabla de hechos “VENTAS” ubicada en el centro y conectada a ella, mediante sus claves primarias, se encuentran las tablas de dimensiones “CLIENTES”, “PRODUCTOS” y “FECHAS”. Es por ello que la clave primaria de la tabla de hechos es la combinación de las claves primarias de sus dimensiones. Los hechos en este caso son “ImporteTotal” y “Utilidad”.

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

24

Es importante a la hora de diseñar una tabla de hechos, tener en cuenta el nivel de granularidad que va a tener, es decir, el nivel de detalle más atómico que vamos a encontrar de los datos: no es lo mismo tener una fila por cada venta, que una fila donde se indiquen las ventas del día para cada artículo y tienda. Existen dos tipos de hechos:  Hechos básicos.- Se encuentran representados por un campo de una tabla de hechos. Los campos “precio” y “cantidad” de la Figura 11 son hechos básicos.  Hechos derivado.-: Se forman al combinar uno o más hechos con alguna operación matemática o lógica y que también residen en una tabla de hechos. El campo “total” de la Figura 11 es un hecho derivado, ya que se conforma de la siguiente manera: total = precio * cantidad.

Figura 11: Hechos Básicos y Derivados

Otro concepto importante a tener en cuenta es la agregación, proceso por el cual se resumen los datos a partir de las filas de detalle de máxima granularidad.

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

Indicadores.- Sumarizaciones que se efectúan sobre algún hecho o expresiones pertenecientes a una tabla de hechos. Atributos de dimensión.- Campos o criterios de análisis, pertenecientes a tablas de dimensiones. Jerarquías de dimensiones.- Representa una relación lógica entre dos o más atributos.

Se puede observar, que el resultado del análisis está dado por los cruces matriciales de acuerdo a los valores de las dimensiones seleccionadas. Más especí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

Estrella

Copo de nieve

Ventajas

Inconvenientes

La desnormalización permite obviar uniones —Join— entre las tablas cuando se realizan consultas, procurando así un mejor tiempo de respuesta y una mayor sencillez con respecto a su utilización

La desnormalización con la que cuenta genera un cierto grado de redundancia Necesidad de almacenamiento

mayor

espacio

Más simple de interpretar

Menos robusto para la carga

Optimiza los tiempos de respuesta ante las consultas

Es el más lento de construir

Posibilidad de segregar los datos de las tablas de dimensiones y proveer un esquema que sustente los requerimientos de diseño.

de

Si se poseen múltiples tablas de dimensiones, cada una de ellas con varias jerarquías, se creará un número de tablas bastante considerable, que pueden llegar al punto de ser Muy flexible y puede implementarse inmanejables después de que se haya desarrollado un esquema en estrella. Al existir muchas uniones y relaciones entre tablas, el desempeño puede verse Hace una mejor utilización del espacio. reducido Puede desarrollar clases de jerarquías La existencia de las diferentes jerarquías fuera de las tablas de dimensiones, de dimensiones debe estar bien que permiten realizar análisis de lo fundamentada, ya que de otro modo las general a lo detallado y viceversa. consultas demorarán más tiempo en

28

Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse devolver los resultados, debido a que se deben realizar las uniones entre las tablas.

Constelació n

Permite tener más de una tabla de hechos, por lo cual se podrán analizar más aspectos claves del negocio con un mínimo esfuerzo adicional de No es soportado por todas las diseño. herramientas de consulta y análisis Contribuye a la reutilización de las tablas de dimensiones, ya que una misma tabla de dimensión puede utilizarse para varias tablas de hechos.

Data Warehouse vs OLTP Debido a que, ya se han explicado y caracterizado los distintos tipos de esquemas del DW, se procederá a exponer las razones de su utilización, como también las causas de por qué no se emplean simplemente las estructuras de las bases de datos tradicionales. Esta comparación se puede ver en la Tabla 5. Tabla 5: OTLP VS Data Warehouse OLTP

Data Warehouse

Objetivo

Soportar actividades transaccionales

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

Tiempo de datos

Operacionales

Para la toma de decisiones

Modelo de datos

Normalizado

Desnormalizado

Consulta

SQL

SQL más extensiones

Datos consultados

60-90 días

5-10 años

Tipos de consultas

Repetitivas, predefinidas

No previsibles, dinámicas

Nivel de almacenamiento

Nivel de detalle

Nivel de detalle y diferentes niveles de sumarización

Acciones disponibles

Alta, baja, modificación y consulta

Carga y consulta

Número de transacciones

Elevado

Medio o bajo

Tamaño

Pequeño-Mediano

Grande

Tiempo de respuesta

Pequeño

Variable

Orientación

Orientado a las aplicaciones

Orientado al negocio

Sello de tiempo

La clave puede o no tener un elemento de tiempo

La clave tiene un elemento de tiempo

Estructura

Generalmente estable

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

29

30

Chapter I

Implementación de un Data Warehouse Los distintos tipos de implementación de un Data Warehouse son los siguientes: 1. Implementación ROLAP (Procesamiento Analítico Online Relacional).- Se trata de sistemas y herramientas OLAP (Online Analytic Processing) construidos sobre una base de datos relacional. Típicamente, los datos son detallados, evitando las agregaciones, y las tablas se encuentran normalizadas. Los esquemas más comunes sobre los que se trabaja son estrella o copo de nieve, aunque es posible trabajar sobre cualquier base de datos relacional. La arquitectura está compuesta por un servidor de banco de datos relacional y el motor OLAP se encuentra en un servidor dedicado. La principal ventaja de esta arquitectura es que permite el análisis de una enorme cantidad de datos. 2.

Implementación MOLAP (Multidimensional Online Analytical Processing o 'Procesamiento Analítico Multidimensional en línea'). Se trata de una alternativa a la tecnología ROLAP (OLAP-Relacional). Aunque ambos tipos de herramientas están diseñadas para realizar análisis de datos a través de un modelo de datos multidimensional, MOLAP se diferencia significativamente en que requiere un preprocesamiento y almacenamiento de la información contenida en el cubo OLAP. MOLAP almacena estos datos en una matriz de almacenamiento multidimensional optimizada, más que en una base de datos relacional (o en un ROLAP). Para optimizar los tiempos de respuesta, el resumen de la información es usualmente calculado por adelantado. Estos valores precalculados o agregaciones son la base de las ganancias de desempeño de este sistema. Algunos sistemas utilizan técnicas de compresión de datos para disminuir el espacio de almacenamiento en disco debido a los valores precalculados.

3. Implementación HOLAP (Hybrid Online Analytical Process o Procesamiento Analítico en línea Híbrido). Es una combinación de ROLAP y MOLAP. HOLAP permite almacenar una parte de los datos como en un sistema MOLAP y el resto como en uno ROLAP. El grado de control que el operador de la aplicación tiene sobre este particionamiento varía de unos productos a otros.

I.1.3.1.4

Query Manager

Figura 17: Query Manager

Este componente realiza las operaciones necesarias para soportar los procesos de gestión y ejecución de consultas relacionales y de consultas propias de análisis de

30

datos, es decir, Query Manager recibe las consultas de los usuarios, las aplica a la estructura de datos correspondiente —cubo multidimensional, Business Models, etc..— y devuelve los resultados obtenidos. Cabe aclarar que una consulta a un DW, generalmente consiste en la obtención de indicadores a partir de los datos —hechos— de una tabla de hechos, restringidas por las propiedades o condiciones de los atributos que hayan sido creados. El procesamiento analítico en línea OLAP, es la componente más poderosa de un Data Warehouse, ya que es el motor de consultas especializadas del Data Warehouse. Las herramientas OLAP, son una tecnología de software para análisis en línea, administración y ejecución de consultas, que permiten inferir información del comportamiento del negocio. Su principal objetivo es el de brindar rápidas respuestas a complejas preguntas, para interpretar la situación del negocio y tomar decisiones. Cabe destacar que lo que es realmente interesante en OLAP, no es la ejecución de simples consultas tradicionales, sino la posibilidad de utilizar operadores, como se muestran en la Tabla 6, que permitan profundizar en la información.

Tabla 6: Operaciones definidas dentro de un Data Warehouse

Drill-down

Permite apreciar los datos en un mayor detalle, bajando por una jerarquía definida en un cubo. Esto brinda la posibilidad de introducir un nuevo nivel o criterio de agregación en el análisis, disgregando los grupos actuales

Drill-up

Permite apreciar los datos en menor nivel de detalle, subiendo por una jerarquía definida en un cubo. Esto brinda la posibilidad de quitar un nivel o criterio de agregación en el análisis, agregando los grupos actuales.

Drill-acros

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

Roll-across

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

Drill-through

Permite apreciar los datos en su máximo nivel de detalle. Esto brinda la posibilidad de analizar cuáles son los datos relacionados al valor de un Indicador, que se ha sumarizado dentro del cubo multidimensional.

I.1.3.1.5

Herramienta de consulta y análisis

31

32

Chapter I

Figura 18: Herramienta de consulta y análisis

Las Herramienta de Consulta y Análisis son sistemas que permiten a los usuarios realizar la exploración de datos del Data Warehouse, constituyendo la unión entre el Data Warehouse y los usuarios. A través de una interfaz gráfica y una serie de pasos, los usuarios generan consultas que son enviadas desde la Herramienta de Consulta y Análisis al Data Warehouse, devolviendo los resultados obtenidos a la herramienta que se los solicitó. Luego estos resultados son expuestos antes los usuarios en formatos que le sean familiares. Algunas de las interfaces a través de las cuales podemos representar los resultados de las consultas pueden ser:  Cuadros de mando12  Informes estáticos13  Informes dinámicos

I.1.3.1.5.1

Usuarios

Figura 19: Usuarios

Los usuarios que posee el Data Warehouse son aquellos que se encargan de tomar decisiones y de 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álisis interactivos que hacen referencia a un tema en particular y que están relacionados entre sí.

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

32

Tabla 7: Usuarios OLTP vs usuarios Data Warehouse Usuarios OLTP

Usuarios Data Warehouse

Acceso concurrente

Muchos

Pocos

Tipo de consultas

Predefinidas

Complejas, no predecibles y no anticipadas

Registros consultados Pocos

Muchos

Tiempo de respuesta

Crítico

Acciones permitidas

Agregar, modificar, Consultar eliminar y consultar

I.1.3.1.6

No crítico

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? Conexiones remotas, trabajo

Sistema Operativo

Windows 2008 R2 64bits

concurrente y Sistema Operativo Windows convencional Servidor para realizar y planificar el

Servidor de Integración de datos

SQL Server 2008 R2 Integration

proceso de Extracción,

Services (SSIS)

Transformación y Carga de los

Servidor de Base de datos Analista o OLAP

SQL Server 2008 R2 Analisys

Análisis y optimización de los datos

Servicies (SSAS)

almacenados en el DW

datos de origen

Sistema gestor de base de datos Servidor de Informes

SQL Server 2008 R2 64bits

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

SQL Server 2008 R2 Reporting

Representación de informes

Services (SSRS)

alimentados desde un Cubo OLAP

Crystal Xcelsius 2008 (No pertenece a Microsoft pero está

Cuadros de mando dinámicos

totalmente integrada, con

basados en Flash, exportables a

cualquier producto de esa

Excel, PDF, etc.

empresa) Cuadros de mando

SharePoint Foundation 2010 + Performance Point Silverlight 4.0 Microsoft Office Excel 2007 + Power Pivot

39

Diseñador de cuadro de mando integrables en los portales Web corporativos Share Point Cuadros de mando dinámicos y con conexión directa al cubo OLAP Tablas y cuadros de mando dinámicos con conexión directa a los cubos OLAP

40

Chapter I

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

Se realizó además una comparación de las características que nos aporta cada una de las herramientas de presentación y cuadros de mando, indicada en la Tabla 9. Con respecto a la parte de Sistema Gestor de Bases de Datos y Sistema Operativo se parte del punto que los clientes, a los que se les quieres implantar la solución BI, ya tienen disponibles el software necesario derivado de la contratación ERP SAP BO, así como el deseo por parte de ITOP MC de la importancia del uso de Share Point para tener acceso, tanto externo como interno, a sus cuadros de mando por parte de sus clientes desde cualquier parte y dispositivo. Tabla 9: Tabla comparativa del Software de representación SSRS

Crystal Xcelsius

Performance Point

Publicación SharePoint Características interactivas Programables (SDK) Interfaz Amigable Integración con SAP Publicables en Web

40

Silverlight

Microsoft Excel

Tabla 9: Tabla comparativa del Software de representación SSRS

Crystal Xcelsius

Performance Point

Silverlight

Microsoft Excel

Facilidad de uso Costo de licencia aceptable Valoración final

En mayor o menor medida las cuatro herramientas se ajustan a las necesidades por tanto se escogieron dos y el resto quedaron estudiadas para futuros proyectos:  Generación de informes: SSRS y Microsoft Excel  Creación de cuadros de mando: Microsoft Excel y Cristal Xcelsius

I.3.2.1.2

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

En cuanto al estudio que se realizó por la vertiente del Open Source se escogió la solución BI mejor valorada: Pentaho. La plataforma Open Source Pentaho Business Intelligence cubre muy amplias necesidades de Análisis de los Datos y de presentación de información empresarial. Las soluciones de Pentaho están escritas en Java y tienen un ambiente de implementación también basado en IDE Eclipse. Eso hace de Pentaho una solución muy flexible para cubrir una amplia gama de necesidades empresariales —tanto las típicas como las sofisticadas y especificas al negocio. La Figura 23 muestra un esquema de la estructura de Pentaho.

Figura 23: Estructura de la solución de Pentaho

Los módulos de la plataforma Pentaho BI son:

41

42

Chapter I





 

 

3.2.2

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.

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:  

   

3.3

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.

Descripción del problema Finalmente, después de haber decidido cuál era la tecnología que se iba a usar para implementar la solución BI con el fin de integrarla con SAP BO, se procede a definir el problema al que en este trabajo se le da solución.

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

43

44

Chapter I

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

44

Parte II.

Cuerpo principal. Descripción del trabajo

45

46

Chapter I

Capítulo 1. Descripción de la metodología para resolver el problema Resumen: Desarrollo ágil de Software Metodología de desarrollo Scrum Planificación del proyecto

1.1

Metodología de desarrollo Una metodología de desarrollo de software se refiere a un framework16 que se usa para estructurar, planear y controlar el proceso de desarrollo en Sistemas de Información. El objetivo es mejorar la productividad en el desarrollo y la calidad del producto software. ¿Qué tipo de metodología se podría utilizar?

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

46

implica mayor dificultad

Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con requisitos poco definidos y/o cambiantes o cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Además, se aplican bien en equipos pequeños que resuelven problemas concretos, lo que no está reñido con su aplicación en el desarrollo de grandes sistemas, ya que una correcta modularización de los mismos es fundamental para su exitosa implantación. Dividir el trabajo en módulos abordables minimiza los fallos y el coste, con lo cual las metodologías ágiles presentan diversas ventajas, entre las que podemos destacar las indicadas en la Tabla 12. Tabla 12: Ventajas de la metodologías de desarrollo ágiles Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo Entrega continua y en plazos breves de software funcional Trabajo conjunto entre el cliente y el equipo de desarrollo Importancia de la simplicidad, eliminado el trabajo innecesario Atención continua a la excelencia técnica y al buen diseño Mejora continua de los procesos y el equipo de desarrollo

En este proyecto se ha querido aportar más dinamismo y adaptabilidad frente a los cambios, por lo que se ha decidido hacer uso de una metodóloga ágil, apostando, dentro del abanico de posibilidades, por la metodología Scrum debido a que permite maximizar la realimentación sobre el desarrollo —pudiendo corregir problemas y mitigar riesgos de forma temprana—, a su creciente uso en los equipos de desarrollo software a nivel internacional, así como otras ventajas que se adaptaban de forma eficiente con la naturaleza del problema abordado, como se detallará a continuación.

1.1.1

Metodología SCRUM Scrum es una metodología para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado, comúnmente, en entornos basados en el desarrollo ágil de software Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad —situaciones frecuentes en el desarrollo de determinados sistemas de software.

47

48

Chapter I

Scrum es un modelo de referencia que define un conjunto de tareas —que se engloban en trabajos— y roles, pudiéndose tomar como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto software. A continuación en la Error: No se encuentra la fuente de referencia se presenta una ilustración donde se puede apreciar los elementos que lo integran —roles, artefactos, eventos— así como sus conexiones.

Scrum estructura el desarrollo en ciclos de trabajo llamados Sprints, siendo de duración fija —entre 1 y 4 semanas— y terminando en una fecha específica, independientemente de haberse finalizado, o no, el trabajo. Cada Sprint se va sucediendo uno detrás de otro. Dentro de Scrum se diferencian los siguientes roles principales, presentes en los Sprints:

48



 

ScrumMaster es la persona que vela por el cumplimiento de las normas de Scrum. Trabaja de forma similar a un director de proyecto, llevando a cabo la gestión del Sprint, con seguimientos diario del Scrum Daily Meeting — representa una reunión de avance diaria de no más de 15 minutos, cuyo propósito es vigilar las tareas realizadas, los recursos necesarios y los obstáculos que se presentan— en busca del objetivo fijado. Dueño del producto (Product Owner) representa a los clientes externos o internos Equipo de desarrolladores (Team) es el grupo de personas encargadas de implementar los requisitos del cliente, así como de elegir las tareas que se comprometen hacer en cada Sprint.

Al comienzo de cada Sprint, un equipo Team selecciona las tareas del Product Backlog17 o pila del producto —se trata de una lista, previamente priorizada por el Product Owner—, y se comprometen a terminarlas al final del Sprint. Las tareas elegidas por el Team serán introducidas en el Sprint Backlog18 o pila del Sprint. Todos los días el equipo Team realiza un Scrum Daily Meeting, actualizando unas gráficas orientativas que permiten hacer un seguimiento, de forma rápida y sencilla, de las tareas que faltan para alcanzar su objetivo. Al final del Sprint, el Team hace una revisión del mismo con los interesados en el proyecto, enseñándoles lo construido: se obtienen comentarios y observaciones que pueden incorporar al siguiente Sprint. Scrum pone énfasis en productos que funcionen al final del Sprint, es decir, que realmente estén “hechos”19 —en el caso de software significa estar integrado, completamente probado y potencialmente para entregar. Un tema importante en Scrum es “inspeccionar y adaptar” (1). El desarrollo inevitablemente implica aprender e innovar, haciendo hincapié en tiempos no muy extensos de desarrollo y centrándose en analizar el producto resultante midiendo la eficacia obtenida, ajustando el objetivo del producto iterativamente o en continuo feedback.

II.1.1.1.1

Scrum en el proyecto

Dada la naturaleza y la magnitud del proyecto, se optó por aplicar esta metodología modificándola para se ajustara a las necesidades puntuales de la solución BI aportada en este documento. 17 El Product Backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas. Contiene estimaciones a grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al Product Owner a ajustar la línea temporal y la prioridad de las diferentes tareas.

18 El

Sprint Backlog es un documento detallado donde se incluye la lista de tareas o elementos que el equipo va a implementar durante el siguiente Sprint. Estas tareas son extraídas del Product Backlog por el Team, teniendo en cuenta cuáles de ellas son más prioritarias.

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

49

50

Chapter I

En primer lugar, los roles de los participantes no estaban bien definidos ya que se trata de un Proyecto Final de Carrera en colaboración con la empresa ITOP MC y esta desempeñaba el tanto el papel de Product Owner como el de Scrum Master. Por otro lado no se consideró mantener reuniones diarias para el seguimiento de los Sprint, ya que no serían efectivas puesto que no existirían cambios sustanciales que se pudieran comentar para su valoración. En su lugar se mantuvieron, siempre que fue posible, reuniones semanales.

II.1.1.1.2

Planificación de la solución BI

A continuación, en la Tabla 13, se muestra el Product Backlog tal y como se describe en la metodología Scrum. Se especificaron en una columna las funcionalidades y al lado las correspondiente estimación del tiempo que se dedicará para completar cada ítem. Decir que, aunque tendrían que diferenciarse entre requisitos básicos, prioritarios o no, todos los requisitos son prioritarios ya que en si son una secuencia de pasos para construir una solución BI.

50

Tabla 13: Product Backlog de la solución BI Ítem

Descripción

Estimación

1

Estado del arte

30 días

2

Búsqueda de una metodología

15 días

3

Estudio de las herramientas de desarrollo

15 días

4

Análisis de requerimientos

4.1

Identificar Preguntas

15 días

4.2

Identificar Indicadores y Perspectivas

30 días

4.3

Modelo Conceptual

7 días

5

Análisis de los OLTP

5.1

Conformar indicadores

30 días

5.2

Establecer correspondencias

7 días

5.3

Nivel de granularidad

7 días

5.4

Modelo conceptual ampliado

7 días

6

Modelo lógico del Data Warehouse

6.1

Tipo de modelo lógico del Data Warehouse

7 días

6.2

Tablas de dimensiones

15 días

6.3

Tablas de hechos

15 días

6.4

Uniones

15 días

7

Integración de datos

7.1

Carga inicial

15 días

7.2

Actualización

15 días

8

Implementación de ETL con el SSIS

15 días

9

Implementación de cubos OLAP con el SSAS

15 días

10

Representación

15 días

A partir del Product Backlog se ha elaborado el Sprint Backlog. Esta lista de tareas permitirá organizar el trabajo del Team para optimizar el uso de los recursos disponibles, obtener resultados en plazos de tiempo breves y controlar la ejecución de cada punto para detectar “cuellos de botellas” y, en consecuencia, darles solución. La estrategia que se ha seguido para definir los distintos Sprints ha sido tomar cada ítem del Product Backlog como una etapa a completar. Cada una de estas etapas contendrá tantos Sprints como tareas contenga la etapa, de manera que cada sprint

51

52

Chapter I

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

52

53

54

Chapter I

Tabla 14: Sprint Backlog de la solución BI

Backlog

Sprint

Duración

Descripción

Estimación

Real

Estudio del estado del arte 1

1,2,3,4,5

Estado del arte

30 días

30 días

6

Documentación

3 días

3 días

Desarrollo de una metodología 2

7, 8

Búsqueda de una metodología

15 días

15 días

9

Documentación

3 días

3 días

15 días

15 días

Herramientas de desarrollo

3

10, 11

Estudio

de

las

herramientas

de

desarrollo

12

Documentación

3 días

3 días

13

Pruebas

7 días

7 días

Identificar Preguntas

7 días

10 días

Identificar 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

Conformar indicadores

7 días

15 días

29

Establecer correspondencias

7 días

15 días

30

Nivel de granularidad

7 días

15 días

31

Modelo conceptual ampliado

7 días

7 días

22

Documentación

3 días

3 días

23

Pruebas

7 días

7 días

Análisis de requerimientos 14, 15 16,17,18,19,2 4

0

Análisis de los OLTP 24,25,26,27,2 8 5

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. 2. 3. 4. 5.

Definición de los objetivos Definición de los requerimientos de información Diseño y modelización Implementación 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 a través de la gestión sistemática de los procesos de negocio, que se deben modelar, automatizar y optimizar de forma continua.

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 ¿Cómo ¿Qué

quiero

medir?

¿En

representaremos

¿Cuál

es

la

unidad va a

qué

estos

números

perspectiva

de

ser medido?

para

que

análisis?

se

entiendan? Total de ventas que han habido

Gestión

de

Ventas

En qué momento

Euros

ocurrió Quién

Total de beneficio

Euros,

que se ha obtenido

Porcentaje

Cuanto aumentó las

Euros,

Barras

Que compro

ventas

Porcentaje

SparkLines

Quien lo vendió

Cuanto aumentó el

Euros,

donde se produjo

beneficio

Porcentaje

la venta

Gráfico de Bala Donde ocurrió Diagrama

de

Cuál fue el medio

Relación

entre

el

capital ajeno y el capital propio

Dirección Financiera

Grado

de

endeudamiento

de

los activos

Euros, Porcentaje

Porcentaje

Rentabilidad de la

Euros,

empresa

Porcentaje

Eficiencia empresa

Cómo

va

Gráfico de Bala

Euros,

Proyectos

de

va

Euros, Porcentaje

Euros

el

aspectos de calidad

Diagrama Barras Porcentaje

SparkLines Diagramas control

se refiere

proyecto

ocurrió

Gráfico de Bala

proyecto en cuanto

Cómo

SparkLines Gráfico de línea

a costos

Gestión

En qué momento

el

proyecto en cuanto

Cómo

Diagrama Barras

va

Líneas tendencias

el en

Tiempo

márgenes de tiempo

63

En qué momento ocurrió

64

Chapter I

Tabla 16: Necesidades de información dentro de cada proceso ¿Cómo ¿Qué

quiero

medir?

¿En

representaremos

¿Cuál

es

la

unidad va a

qué

estos

números

perspectiva

de

ser medido?

para

que

análisis?

se

entiendan? En

qué

nivel

de

riesgo se encuentra

Porcentaje

el proyecto Como se encuentra el

proyecto

en

cuanto al alcance

Atributo23

fijado Como se encuentra el

proyecto

cuanto

en a

Tiempo

adquisiciones Como se encuentra el

proyecto

en

cuanto a recursos

Numérico

humanos Gestión

de

Incidencias

Número

de

incidencias abiertas

Gráfico de Bala Numérico

Diagrama

frente a

de

En qué momento ocurrió

Barras

Incidencias

SparkLines

Porcentaje

cerradas

Líneas

Tiempo que se tarda en responder una

de

tendencias Gráfico de pila

Numérico

incidencia Tiempo que se tarda en

cerrar

una

Numérico

incidencia Fuente

de

Atributo

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

64

Tabla 16: Necesidades de información dentro de cada proceso ¿Cómo ¿Qué

quiero

medir?

¿En

representaremos

¿Cuál

es

la

unidad va a

qué

estos

números

perspectiva

de

ser medido?

para

que

análisis?

se

entiendan? Gravedad

de

la

incidencia Número

Atributo

de

incidentes

Porcentaje

asignados incorrectamente Número incidencia

de Porcentaje

reabiertas

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 agrupamiento específicos —explícitos o implícitos— y, por lo tanto, las diferentes granularidades —nivel de detalle— en la visión de los 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 Variación de ventas Total de ventas % Beneficio Total % Variación del Beneficio

Descripción Mide el porcentaje de variación de ventas sobre el ejercicio anterior Mide el total de ventas que se han realizado Mide el beneficio total obtenido de las ventas Mide la variación del beneficio respecto al histórico

Perspectiva Tiempo Cliente Gestión de Ventas Canal Producto Geografía

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 liquidez Ratios de endeudamiento o solvencia Ratios de rentabilidad Ratios 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

Descripción

Perspectivas

Dirección Financiera Ratios de liquidez severa o Prueba ácida

Ratios de liquidez absoluta o Ratio de efectividad o Prueba superácida Capital de trabajo

Este ratio muestra una medida de liquidez más precisa que la anterior, ya que excluye a las existencias (mercaderías o inventarios) debido a que son activos destinados a la venta y no al pago de deudas, y, por lo tanto, menos líquidos; además de ser sujetas a pérdidas en caso de quiebra. Es un índice más exacto de liquidez que el anterior, ya que considera solamente el efectivo o disponible, que es el dinero utilizado para pagar las deudas y, a diferencia del ratio anterior, no toma en cuenta las cuentas por cobrar (clientes) ya que es dinero que todavía no ha ingresado a la empresa. Si el resultado es menor que 0.5, no se cumple con obligaciones de corto plazo Se obtiene de deducir el pasivo corriente al activo corriente. Lo ideal es que el activo corriente sea mayor que el pasivo corriente, ya que el excedente puede ser utilizado en la generación de más utilidades.

Tiempo

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

Descripción

Perspectivas

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

Ratio de endeudamiento de activo

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

67

Tiempo

68

Chapter I

Tabla 22: Ratios de rentabilidad Muestran la rentabilidad de la empresa en 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

Descripción

Perspectivas

Financiera Ratio de rentabilidad de la inversión (ROA)

Es el ratio más representativo de la marcha global de la empresa, ya que permite apreciar su capacidad para obtener utilidades en el uso del total activo.

Ratio de rentabilidad del patrimonio (ROE)

Este ratio mide la capacidad para generar utilidades netas con la inversión de los accionistas y lo que ha generado la propia empresa (capital propio).

Ratio de rentabilidad bruta sobre ventas Ratio de rentabilidad neta sobre ventas

Ratio de rentabilidad por acción

Ratio de dividendos por acción

Llamado también margen bruto sobre ventas, muestra el margen o beneficio de la empresa respecto a sus ventas. Es un ratio más concreto ya que usa el beneficio neto luego de deducir los costos, gastos e impuestos. Llamado también utilidad por acción, permite determinar la utilidad neta que le corresponde a cada acción. Este ratio es el más importante para los inversionistas, pues le permite comparar con acciones de otras empresas.

Tiempo

El resultado de este ratio representa el monto o importe que se pagará a cada accionista de acuerdo a la cantidad de acciones que éste tenga.

Tabla 23: Ratios de 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 Financiera Ratio de periodo de cobro Ratio de rotación por pagar Ratio de periodo de pagos

Ratio de rotación de inventarios

Descripción Indica el número de días en que se recuperan las cuentas por cobrar a sus clientes. Mide el plazo que la empresa cuenta para cancelar bonificaciones. Determina el número de días en que la empresa se demora en pagar sus deudas a los proveedores. Indica la rapidez en que los inventarios se convierten en cuentas por cobrar mediante las ventas al determinar el número de veces que rota el stock en el almacén durante un ejercicio.

Perspectivas

Tiempo

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 del Proyecto

Gestión del Alcance del Proyecto Gestión del Tiempo del Proyecto Gestión de los Costos del Proyecto

Gestión de la Calidad del Proyecto Gestión de los Recursos Humanos del Proyecto Gestión de las Comunicaciones del Proyecto

Gestión de los Riesgos del Proyecto Gestión de las Adquisiciones del Proyecto

Incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades de la dirección de proyectos dentro de los grupos de procesos de dirección de proyectos. Incluye los procesos necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarla con éxito. Incluye los procesos requeridos para administrar la finalización del proyecto a tiempo. Incluye los procesos involucrados en estimar, presupuestar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado. Incluye los procesos y actividades de la organización ejecutante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por la cuales fue emprendido. Incluye los procesos que organizan, gestionan y conducen el equipo del proyecto. Incluye los procesos requeridos para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto sean adecuados, oportunos y entregada a quien corresponda (interesado del proyecto o stakeholders). Incluye los procesos relacionados con llevar a cabo la planificación de la gestión, identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitoreo y control en un proyecto. Incluye los procesos de compra o adquisición de los productos, servicios o resultados que es necesario obtener fuera del equipo del proyecto.

Una vez analizadas y comprendidas estas nueves áreas se crearon los siguientes 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 la coordinación del proyecto Número de proyectos abiertos en relación con el número de proyectos cerrados Número de hitos retrasados

Este indicador mide el porcentaje de tiempo invertido en coordinar un proyecto en relación con el tiempo que se tardó en coordinar e implementar el proyecto. Este indicador mide el número de proyectos cerrados en relación con el número de proyectos abiertos.

Tiempo

Un hito es una tarea que representa una fecha importante en un proyecto, como la finalización de una fase del proyecto.

Tabla 26: Gestión de proyectos. Gestión del tiempo Indicador Desviación del calendario previsto para el proyecto Tasa de tareas realizadas en los plazos deseados

Descripción La desviación del calendario previsto es la diferencia en tiempo entre la línea base con respecto al desarrollo actual

Perspectiva

Tiempo

Tasa de tareas realizadas en los plazos deseados

Tabla 27: Gestión de proyectos. Gestión de calidad Indicador

Descripción La desviación del retorno prevista de la inversión (ROI) es la diferencia entre el retorno de la inversión prevista en la línea de base y el retorno real de la inversión.

Desviación del retorno de la inversión prevista Porcentaje del

Perspectivas

Tiempo

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

proyecto terminado

Tabla 28: Gestión de proyectos. Gestión de costo Indicador

Valor Ganado (EV)

Valor planificado (PV)

Costo real (AC)

Variación del cronograma (SV) Variación de costo (CV)

Descripción El valor ganado es el valor del trabajo completado expresado en términos del presupuesto aprobado asignado a dicho trabajo para una actividad del cronograma o un componente de la estructura de desglose del trabajo. El valor planificado es el presupuesto autorizado asignado al trabajo que debe ejecutarse para completar una actividad o un componente de la estructura de desglose del trabajo. El costo real (AC) es el costo total en el que se ha incurrido realmente y que se ha registrado durante la ejecución del trabajo realizado para una actividad o componente de la estructura de desglose del trabajo. La variación del cronograma es una medida del desempeño del cronograma en un proyecto. La variación del cronograma, en la EVM, finalmente será igual a cero cuando se complete el proyecto, porque ya se habrán ganado todos los valores planificados. La variación del costo es una medida del desempeño del costo en un proyecto. En la EVM, la CV es particularmente crítica

70

Perspectiva Tiempo

Tabla 28: Gestión de proyectos. Gestión de costo Indicador

Índice de desempeño del cronograma (SPI)

Índice del desempeño del costo (CPI)

Estimación a la conclusión (EAC)

Índice de Desempeño del Trabajo por Completar (TCPI)

Descripción porque indica la relación entre el desempeño real y los costos gastados. En la EVM, una CV negativa con frecuencia no es recuperable para el proyecto. El índice de desempeño del cronograma es una medida del avance logrado en un proyecto en comparación con el avance planificado. Puesto que el SPI mide todo el trabajo del proyecto, el desempeño en la ruta crítica también debe analizase, para determinar si el proyecto terminará antes o después de la fecha de finalización programada. Es una medida del valor del trabajo completado, en comparación con el costo o avance reales del proyecto. Se considera la métrica más importante de la gestión del valor ganado y mide la eficacia de la gestión del costo para el trabajo completado. La EAC puede diferir del presupuesto hasta la conclusió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 costos reales en los que se ha incurrido para completar el trabajo, más una estimación hasta la conclusión (ETC) para el trabajo restante. El índice de desempeño del trabajo por completar es la proyección calculada del desempeño del costo que debe lograrse para el trabajo restante, con el propósito de cumplir con una meta de gestión especificada, tal como el BAC o la EAC. Si resulta evidente que el BAC ya no es viable, el director del proyecto proyecta una estimación a la conclusión EAC.

Perspectiva

Tabla 29: Gestión de proyectos. Gestión de Riesgos Indicador % de los proyectos que consideran de riesgo % de los proyectos con cambios de alcance % de los proyectos "en el control" Promedio del número de modificaciones realizadas al proyecto desde su definición % de los proyectos a tiempo y dentro del presupuesto

Descripción Porcentaje de proyectos que se consideran de riesgo Porcentaje de proyectos activos con cambios de alcance durante el proyecto Porcentaje de proyectos que está "bajo control", es decir, que son subjetivamente calificados como el control basado en tiempo, presupuesto y calidad Promedio del número de cambios realizados en la definición del alcance del proyecto, es decir, de los proyectos durante su ciclo de vida Porcentaje de proyectos que se ejecutan en el marco de tiempo previsto y con el presupuesto (gastos) en función de su línea de base

71

Perspectiva

Tiempo

72

Chapter I

Tabla 30: Gestión de proyectos. Gestión de recursos humanos Indicador Promedio del número de personas asignadas al proyecto

Descripción

Perspectiva

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

Tiempo

----

Tabla 31: Gestión de proyectos. Gestión de adquisición Indicador

Requisición de tiempo de emisión tema

Descripción Perspectiva Para medir el tiempo transcurrido entre el momento en que una solicitud de contratación se inicia y el Tiempo momento en que la solicitud se cumple (expresada en términos de días).

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 Tiempo en cerrar la incidencia Tiempo promedio que se tarda en responder incidentes Número total de incidentes por fuente

% de los incidentes de retraso Número de incidentes graves % de los incidentes repetidos .

Descripción Tiempo promedio que se tarda entre el registro de la incidencia y su cierre. Tiempo promedio de tiempo (por ejemplo, en minutos) entre la detección de un incidente y la primera medida tomada para reparar el incidente. Número de incidentes que se originaron por razones de telecomunicaciones, la infraestructura física, operación, soporte, seguimiento, los socios externos de eventos, proveedores y otros Número de incidentes de retraso (no se cierra y no se resuelve dentro del plazo establecido) en relación con el número de procedimientos abiertos (no cerrados) incidentes. -------------------------------------------------------Porcentaje de incidentes que pueden clasificarse como un incidente de repetición, en relación con todos los incidentes reportados en el período de

72

Perspectiva Tiempo

Tabla 32: Gestión de Incidencias Indicador

Incidente tasa de cola

% de incidentes resueltos dentro del plazo / destino

Costo promedio para resolver un incidente % de incidentes incorrectamente asignados Número de incidentes cerrados en relación con el número de incidentes abiertos % de incidentes clasificados incorrectamente

Descripción medición. Un incidente se repite si ya ha ocurrido (varias veces) en el período de medición El número de casos cerrados, en relación con el número de casos abiertos en un período de tiempo determinado. Número de incidentes cerrados en el plazo fijado durante la duración del marco, en relación con el número de todos los incidentes cerrados en un período de tiempo determinado. Un tiempo de duración-marco se aplica a cada incidente en el que se recibe, y establece un límite en la cantidad de tiempo disponible para resolver el incidente. El tiempo de duración aplica-marco se deriva de los acuerdos alcanzados con el cliente sobre la resolución de incidentes. Los costes medios para resolver un incidente se calculan a partir de los costos fijos y variables del proceso de gestión del incidente dividido por el número total de incidentes recibidos en el período de medición. --------------------------------------------------------

Perspectiva

Se valora la eficacia a la hora de resolver incidentes Un incidente puede ser clasificado como prioridad alta, media y baja

II.2.1.2.1.3 Modelo Conceptual A 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 conceptuales 26. 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 Ventas Gestión Financiera Gestión de Proyectos Gestión de Incidencias

Tabla 34: Conformar Indicadores. Gestión de Ventas Indicadores

Variación de ventas

Medidas

Función de sumarización

Total de línea (TL) Descuento

pie

Valor Objetivo Un aumento del 2%

de

con respecto al año

documento (DPD)

anterior

77

78

Chapter I

Tabla 34: Conformar Indicadores. Gestión de Ventas Indicadores

Medidas

Unidades de

Total de línea (TL)

ventas

Descuento

%

Beneficio

Total %

Función de sumarización

pie

Un aumento del 2% de

con respecto al año

documento (DPD)

anterior

Precio Venta Neto PVN

Un aumento del 2%

Coste

con respecto al año

artículo

CA

Cantidad C

Variación

del Beneficio

Valor Objetivo

anterior Un aumento del 2%

Precio Venta Neto PVN

con respecto al año

Coste artículo CA

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

Caja y banco

Prueba superácida

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 Utilidad neta

Ratio de rentabilidad del patrimonio (ROE)

Patrimonio Utilidad Bruta

Ratio de rentabilidad bruta sobre ventas

Patrimonio Utilidad Bruta

Ratio de rentabilidad neta sobre ventas

Ventas netas Utilidad neta

Ratio de rentabilidad neta sobre ventas

Ventas netas Utilidad neta

Ratio de rentabilidad por acción

Número de acciones Dividendos

Ratio de dividendos por acción

Número de acciones

Tabla 39: Conformar indicadores Ratios de gestión u operativos Indicador

Medida Ventas al crédito

Ratio de rotación de cobro

Cuentas por cobrar comerciales Cuentas por cobrar comerciales

Ratio de periodo de cobro

Ventas al crédito

79

80

Chapter I

Tabla 39: Conformar indicadores Ratios de gestión u operativos Indicador

Medida Compras al crédito

Ratio de rotación por pagar

Cuentas por pagar comerciales Cuentas por pagar comerciales

Ratio de periodo de pagos

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

Tiempo de coordinación

proyecto

Tiempo implementación

Número de proyectos abiertos en relación con

Proyectos cerrados

el número de 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

Tiempo previsto

proyecto

Tiempo real

80

Tasa de tareas realizadas en los plazos

Trabajo terminado

deseados

Línea base prevista

Tabla 43: Conformar Indicadores. Gestión de calidad Indicador

Medida Beneficios

Desviación del retorno de la inversión prevista

Coste iniciales Tareas terminadas

Porcentaje del proyecto terminado

Tareas incompletas

Tabla 44: Gestión de proyectos. Gestión de costo Indicador

Medida Presupuesto autorizado

Valor Ganado (EV)

Trabajo completado

Valor planificado (PV)

Presupuesto asignado a cada actividad

Costo real (AC)

Costo real de cada actividad Valor Ganado

Variación del cronograma (SV)

Valor Planificado Valor Ganado

Variación de costo (CV)

Costo Real Valor Ganado

Índice de desempeño del cronograma (SPI)

Valor Planificado Valor Ganado

Índice del desempeño del costo (CPI)

Costo real de la actividad Costo real de la actividad Estimación para concluir el trabajo restante

Estimación a la conclusión (EAC)

Presupuesto hasta la conclusión Índice

de

Desempeño

del

Trabajo

Valor Ganado

por

Costo Real

Completar (TCPI)

Estimación hasta la conclusión Tabla 45: Gestión de proyectos. Gestión de riesgos Indicador

Medida Proyectos en riesgo

% de los proyectos que consideran de riesgo

Total de proyectos Proyectos con cambios de alcance

% de los proyectos con cambios de alcance

Total de proyectos Proyectos en control

% de los proyectos "en el control"

Total de proyectos

81

82

Chapter I

Promedio

del

número

de

modificaciones

Numero de modificaciones

realizadas al proyecto desde su definición

Ciclo de vida del proyecto

% de los proyectos a tiempo y dentro del

Coste de todas las tareas

presupuesto

Calendario del proyecto

Tabla 46: Gestión de proyectos. Gestión de recursos humanos Indicador

Medida

Promedio del número de personas asignadas

Empleados asignados a un proyecto

al proyecto

Total de empleados

Tabla 47: Gestión de proyectos. Gestión de adquisición Indicador

Medida Tiempo de inicio de la solicitud

Requisición de tiempo de emisión tema

Tiempo de fin de la solicitud

Tabla 48: Gestión de proyectos. Gestión de adquisición

Indicador

Medida Tiempo de resolución

Tiempo en cerrar la incidencia

Tiempo de detección Tiempo total en resolver todas las incidencias Tiempo de detección

Tiempo promedio que se tarda en responder

Tiempo en el que se toma la primera medida

incidentes

Tiempo total que se tardó en resolver tolas las incidencias Número de incidencias

Número total de incidentes por fuente

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

Número de casos cerrados

% de incidentes tratados en los tiempos

Número de casos abiertos

de respuestas acordados

Tiempo en resolver un incidente

82

Tabla 48: Gestión de proyectos. Gestión de adquisición

Indicador

Medida Costo fijos del incidentes

Costo promedio para resolver un incidente

Costos variables del proceso de gestión Total de incidentes Incidentes incorrectamente asignados

% de incidentes incorrectamente asignados

Incidentes asignados Total de incidentes

Incidentes abiertos

% de incidentes mal clasificados

Incidentes mal clasificados

Número de incidentes cerrados en relación con

Número de casos cerrados

el número de incidentes abiertos

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 perspectiva hija 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 de Datos. 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

Aquellos campos cuyo contenido no poseía una descripción lo suficientemente

valores

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

97

98

Chapter I

Tabla 54: Transformaciones llevadas a cabo en el proceso ETL Acciones

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 KPI

Measure.Beneficio

Calculo Miembro PrecioVentaXCantidad – [(PrecioCosteXCantidad*100)/ PrecioVentaXCantidad]

Es una sumarización Measure.Beneficio

de

Measure.Variacion

MeasureBeneficio

Es

de

periodo

101

una

sumarización

102

Chapter I

Beneficio

actual / MeasureBeneficio periodo anterior

Measure.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 Integration Services 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

Ejecución ETL

Tiempo máquina A

Tiempo máquina B

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 Fuente

Permite a los usuarios realizar sus propios informes

de

Se debe ofrecer al usuario una información limpia, amigable, elaborada y

información de gran

confiable, que le permita obtener información analítica para reflejarla en sus

calidad

informes

Tiempo de respuesta

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

rápidos

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 clienteservidor. 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 con las 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 directas contra la base de datos analítica, con el fin de integrar el cuadro de mando en una plataforma 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 una plataforma de SharePoint

Microsoft Silverlight 4.0 Silverlight 4.0 es un complemento gratuito para los navegadores de Internet basado en la plataforma Windows que agrega nuevas funciones multimedia como la 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 de SSAS



Por su potencia y gran usabilidad en el mundo empresarial



La curva de desarrollo y aprendizaje respecto a otras soluciones, disminuye considerablemente permitiendo cumplir los plazos del proyecto

Una vez seleccionada la herramienta para implementar el cuadro de mandos se hizo un estudio previo de 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 del cuadro de mandos, debido a que el 10% de los hombres y 1% de mujeres son daltónicos, siendo una de las prácticas más habituales la representación de medidas de alertas a través de los colores rojo, amarillo y verde, pudiendo llevar a las personas que sufren este síndrome a la toma de decisiones empresariales equivocadas.

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 adaptan mejor, para la representación de información de negocio atendiendo a los siguientes criterios:

1. Gráfico de bala: Este grafico fue diseñado por Stephen Few, creado específicamente para ser representado en cuadros de mando. Permite de forma rápida, eficaz y ocupando muy poco espacio identificar si el indicador que se quiere medir es bueno o malo dentro de un determinado contexto. Este gráfico no se ha llegado a utilizar debido a que no venía como grafico nativo en Excel 2007, pero se considera que es un buen grafico a tomar en cuenta. En la Figura 65 tenemos un ejemplo de 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. Ha centrado 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 permiten la comparación de las medidas representadas, así como la rápida localización de los datos más significativos al estar ordenados. Además son el tipo de gráfico que predomina en Excel 2007 3. Gráfico de pila: Es una variación al gráfico de barras y es recomendable para una única serie dividida en diferentes partes. 4. Gráfico de línea: Ideal para la representación de tendencias, fluctuaciones y ciclos a lo largo del tiempo, así como un conjunto de datos varía en relación a otro. 5. SparkLines: Este grafico es idéntico a uno de línea pero en cambio se representa sin etiquetado ni escala, normalmente al lado de un indicador con el fin de representar la tendencia que ha seguido a través de un periodo de tiempo.

Tabla 64: Ejemplo de gráfico Sparklines

6. Tabla: En una tabla simple muchas veces se puede representar la misma informació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 Gráfico de Bala (H - V)

Total de ventas

Gráfico de Barras (H - V) Gráfico de Líneas SparkLines

Variación de ventas

Gráfico de Bala (H - V) Gráfico de Líneas Gráfico de Bala (H - V)

Beneficio

SparkLines Gráfico de Barras (H - V)

Variación de Beneficio

Grá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.

118

Conclusiones, Final

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 una solució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/scrumy-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, Communication of Data. s.l. : O'Reilly, 2006.

The

Effective

Visual

Parte XI. 7. Doug Harts, Jim Dugan, Tricia Wilcox Almas. Microsoft SQL Server 2008 R2 Analytics & Data Visualization. s.l. : Mac Graw Hill, 2008. Parte XII. 8. Ramos, Salvador. Microsoft Business Intelligence vea el cubo medio lleno. s.l. : SolidQ Press, 2011. Parte XIII. 9. Sivakumar Harinath, Matt Carroll, Sethu Meenakshisundaram, Robert Zare, Denny Guang-Yeu Lee. Professional Microsoft SQL Server Analysis Services 2008 with MDX. s.l. : Wiley Publishing, Inc., 2009. Parte XIV. 10. Xavier Hacking, David Lai. SAP BusinessObjects Dashboards 4.0 Cookbook. s.l. : Packt Publishing, 2011. Parte XV. 11. Roland Bouman, Jos van Dongen. Pentaho Solutions - Business Intelligence and Data Warehousing with Pentaho and MySQL. s.l. : WILEY. Parte XVI. 12. 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. 2009.

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

Parte XXIII.

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

Parte XXIV.

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

Parte XXV.

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

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

Developing,

Parte XXVII. 23. John Wiley & Sons, Inc., Hoboken, New Jersey. Business Dashboards. s.l. : John Wiley & Sons, Inc., 2009. Parte XXVIII. 24. Withee, Ken. Microsoft Business Intelligence for Dummies. s.l. : Wiley Publishing, Inc, 2010. Parte XXIX. 25. Lynn Langit, Kevin S. Goff, Davide Mauri, Sahil Malik, and John Welch. Smart Business Intelligence Solutions with Microsoft SQL Server2008. s.l. : Microsoft Press, 2009. Parte XXX. 26. SQL SERVER INTEGRATION SERVICES 2008 LABORATORIOS . s.l. : INTERMEZZO BUSINESS INTELLIGENCE , 2010. Parte XXXI. 2010.

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

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

122

Parte XXXVII. 33. Chris Webb, Alberto Ferrari and Marco Russo. Expert Cube Development with Microsoft SQL Server 2008 Analysis Services. s.l. : Marco Russo, 2009. Parte XXXVIII. 34. Langit, Guy Fouché and Lynn. Foundations of SQL Server 2008 R2 Business Intelligence. s.l. : Apress, 2009. Parte XXXIX. 35. Kimball, Joy Mundy and Marren Thornthwaite with Ralph. The Microsft Data Warehouse Toolkit whit SQL Server. s.l. : Kimball Group, 2011. Parte XL. 36. 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

ITIL

Information Technology Infrastructure o Biblioteca de Infraestructura de Tecnologías de Información

ITOP MC

Información 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

SAP

System, Applications and Products o Sistemas Aplicaciones y Productos

SDC

Slowly Changing Dimensions o Dimensiones Lentamente Cambiantes

SGBDR

Sistema Gestor de Base de Datos Relacional

SI

Sistema de Información

Tecnología

Organización

128

Proceso

Management

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