Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Business Intelligence para
PYMES
Autor/es: Manuel Alejandro González Yanes
Rebeca Mora Anca
Director/a: Virginia Gutiérrez...
2 Chapter I
D./Dña. Virginia Gutiérrez Rodríguez Profesora de la Escuela Técnica Superior de Ingeniería
Informática, y ads...
Resumen
Se denomina inteligencia empresarial, inteligencia de negocios o BI (del inglés Business
Intelligence) al conjunto...
4 Chapter I
Agradecimientos
A nuestro profesor de la Universidad de La Laguna, Marcos Colebrook, el cual nos animó a
desar...
5
6 Chapter I
Al término de esta etapa de nuestras vida. Queremos expresar todo nuestro agradecimiento a
quienes con su ayud...
2.1.2Metodología propia para la Construcción de un Data Warehouse con base en
HEFESTO........................................
8 Chapter I
Parte XIII.9. Sivakumar Harinath, Matt Carroll, Sethu Meenakshisundaram,
Robert Zare, Denny Guang-Yeu Lee. Pro...
Parte XXIV.20. —. ITIL Service Operation. s.l. : Published by TSO (The
Stationery Office)....................................
10 Chapter I
Parte XXXV.31. Rainardi, Vincent. Building a Data Warehouse with
Examples in SQL Server. s.l. : Apress, 2010....
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 Wa...
14 Chapter I
1.2 ¿Qué es BI?
“BI es el conjunto de estrategias y tecnologías que nos van a ayudar a convertir los
datos en...
¿No tiene idea de por qué sus clientes le devuelven mercancía?
Estas son las soluciones de BI más reconocidas actualmente ...
16 Chapter I
 FASE 1: Dirigir y planear. Fase inicial donde se deberán recoger los
requerimientos de información de los d...
estará sesgada. También puede ocurrir que, dependiendo de la gama del producto, nos
interese información externa verdadera...
18 Chapter I
Tabla 1: Características de un Data Warehouse
Orientado a temas
Los datos están organizados por temas para fa...
3. Principalmente, la información del Data Warehouse se estructura en cubos
multidimensionales, ya que estos preparan la i...
20 Chapter I
En un Data Warehouse se cargan y unifican periódicamente información procedente de
múltiples fuentes, esto im...
Tabla 2: Casos más comunes de transformaciones ETL
Limpieza de datos
Su objetivo principal es el de realizar distintos tip...
22 Chapter I
Relacionales, lo que allí se encuentra son tablas y relaciones entre ellas, a nivel
conceptual conocer que ex...
jerarquías que se pueden establecer para describir niveles de agrupamiento
específicos se pueden observar en la Figura 9 y...
24 Chapter I
Inicialmente Ralph Kimball11
planteó tres estrategias a seguir cuando se tratan las SCD:
tipo 1, tipo 2 y tip...
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,...
26 Chapter I
tiempo que hubiese incurrido en realizar dicha consulta sobre una base de datos
transaccional.
Como ejemplo, ...
Jerarquías
Como se comentó en el apartado Data Warehouse Manager de tablas de dimensión,
una jerarquía representa una rela...
28 Chapter I
Figura 15: Esquema en copo de nieve
 Esquema constelación.- Está compuesto por una serie de esquemas en
estr...
Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse
devolver los resultados, debido a que se
deben r...
30 Chapter I
Implementación de un Data Warehouse
Los distintos tipos de implementación de un Data Warehouse son los siguie...
datos, es decir, Query Manager recibe las consultas de los usuarios, las aplica a la
estructura de datos correspondiente —...
32 Chapter I
Figura 18: Herramienta de consulta y análisis
Las Herramienta de Consulta y Análisis son sistemas que permite...
Tabla 7: Usuarios OLTP vs usuarios Data Warehouse
Usuarios OLTP Usuarios Data Warehouse
Acceso concurrente Muchos Pocos
Ti...
34 Chapter I
Capítulo 2. ITOP Management
Consulting
Resumen:
ITOP MC es una empresa de consultaría de Negocios y Gestión E...
2.3 Alianzas
Las principales alianzas y áreas de experiencia del equipo de ITOP MC son:
• HP
• Microsoft
• SAP
 SAP Busin...
36 Chapter I
Capítulo 3. Descripción del problema e
integración de soluciones tecnológicas
Resumen:
En este capítulo se de...
teniendo muchas restricciones de formatos en los que se podía mostrar la información.
En consecuencia, se tenían que imple...
38 Chapter I
Figura 21: Cuadrante de Gartner BI 2010
Estos dos baremos dividen al cuadrante en cuatro sectores en donde se...
evolucionando sus soluciones suficientemente rápido y de alguna manera
están perdiendo parte de la perspectiva.
Una vez vi...
40 Chapter I
Figura 22: Solución tecnológica propuesta para una solución BI usando herramientas Microsoft
Se realizó ademá...
Tabla 9: Tabla comparativa del Software de representación
SSRS
Crystal
Xcelsius
Performance
Point
Silverlight
Microsoft
Ex...
42 Chapter I
 Reporting.- Módulo de informes que ofrece la solución adecuada a las
necesidades de los usuarios. Pentaho R...
Tabla 10: Tabla comparativa Pentaho vs Microsoft
Pentaho Microsoft
Documentación
Integración con otras herramientas Sólo e...
44 Chapter I
Se quiere implantar una solución Business Intelligence en SAP BO de manera que el
cliente que posea esta apli...
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
Meto...
implica mayor dificultad
Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con
requisitos p...
48 Chapter I
Scrum es un modelo de referencia que define un conjunto de tareas —que se engloban
en trabajos— y roles, pudi...
 ScrumMaster es la persona que vela por el cumplimiento de las normas de
Scrum. Trabaja de forma similar a un director de...
50 Chapter I
En primer lugar, los roles de los participantes no estaban bien definidos ya que se trata
de un Proyecto Fina...
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 metodo...
52 Chapter I
tenga como objetivo el desarrollo de una tarea. Como limitación a estos Sprints, se ha
impuesto que cada uno ...
53
54 Chapter I
Tabla 14: Sprint Backlog de la solución BI
Backlog Sprint Descripción
Duración
Estimación Real
1
Estudio del ...
En la Tabla 14 se puede observar el tiempo estimado para cada tarea, de forma que se
cumpla con el requisito temporal impu...
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
Meto...
58 Chapter I
debe tener muy en cuenta, es no entrar en la utilización de metodologías que requieran
fases extensas de reun...
Tabla 15: Características principales en la metodología Hefesto
Se basa en los requerimientos de los usuarios, por lo cual...
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Business intelligence para Pymes
Upcoming SlideShare
Loading in …5
×

Business intelligence para Pymes

1,900 views

Published on

Memoria de mi Proyecto Fin de Carrera

Published in: Technology
  • Be the first to comment

Business intelligence para Pymes

  1. 1. 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. 2. 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
  3. 3. 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. 4. 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. 5. 5
  6. 6. 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
  7. 7. 2.1.2Metodología propia para la Construcción de un Data Warehouse con base en HEFESTO....................................................................................................34 Capítulo 3.Análisis de los resultados.........................................................71 3.1Resultados................................................................................................................71 Parte III.Conclusiones, Final............................................................................73 Capítulo 1.Conclusiones y posibles ampliaciones...................................74 Parte IV.Bibliografía..........................................................................................76 Parte V.1. Kniberg, Henrick. . http://www.proyectalis.com/wp- content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf. [En línea] 09 de 06 de 2011. .............................................................................76 Parte VI.2. Dario, Bernabeu R. Investigación y Sistematización de HEFESTO: Metodología propia para la Construcción de un Data Warehouse. [En línea] 09 de 06 de 2011. ................................................76 Parte VII.3. Commerce, Office of Government. ITIL Gestión de Servicios TI. [En línea] 05 de 01 de 2011. http://itil.osiatis.es......................................76 Parte VIII.4. Alexander, Michael. Crystal Xcelsius for Dummies. 2007........76 Parte IX.5. Berndtsson, M., Hansson, J., Olsson, B., Lundell, B. A Guide for Students in Computer Science and Information Systems, Springer. 2008..............................................................................................................76 Parte X.6. Stephen Few. Information Dashboard Design, The Effective Visual Communication of Data. s.l. : O'Reilly, 2006...............................76 Parte XI.7. Doug Harts, Jim Dugan, Tricia Wilcox Almas. Microsoft SQL Server 2008 R2 Analytics & Data Visualization. s.l. : Mac Graw Hill, 2008..............................................................................................................76 Parte XII.8. Ramos, Salvador. Microsoft Business Intelligence vea el cubo medio lleno. s.l. : SolidQ Press, 2011.......................................................76 7
  8. 8. 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
  9. 9. 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. 10. 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
  11. 11. Lista de figuras 11
  12. 12. 12 Chapter I Lista de Tablas Parte I. Introducción y fundamentos básicos 12
  13. 13. Capítulo 1. Fundamentos Business Intelligence Resumen: Introducción a mundo del Business Intelligence Introducción Data Warehouse y conceptos relacionados 1.1 Introducción En la actualidad, la gran mayoría de las organizaciones cuenta con un Sistema de Información1 (SI) que soporta gran parte de las actividades diarias propias del sector de negocios en donde se esté desempeñando. Este sistema puede ser sencillo o robusto, todo depende de las exigencias del negocio. Con el transcurso del tiempo, estas aplicaciones llegan a tener la historia de la organización: los datos almacenados en las bases de datos pueden ser utilizados para argumentar la decisión que se quiera tomar. Un estudio realizado en Europa por Information Builders Ibéric mostró el costo que tiene la falta de Sistemas de Información Orientados para la Toma de Decisiones2 o Decision Support Systems (DSS) en las organizaciones. Según estos datos, el empleado europeo medio pierde una media de 67 minutos diariamente buscando información de la compañía, lo que equivale a un 15,9% de su jornada laboral. Para una organización de 1.000 empleados que gane unos 50.000 euros al día equivaldría a 7,95 millones de euros al año de salario perdido, debido todo ello a la búsqueda de información orientada a la toma de decisiones. El poder competitivo que puede tener una empresa se basa en la calidad y cantidad de información que sea capaz de usar en la toma de decisiones. Mediante la implementación de Inteligencia de Negocios o Business Intelligence (BI) se proporcionan las herramientas necesarias para aprovechar los datos almacenados en las bases de datos de los Sistemas Transaccionales3 para utilizar la información como respaldo a las decisiones, reduciendo el efecto negativo que puede traer consigo una mala determinación. Precisamente, Business Intelligence permite que el proceso de toma de decisiones esté fundamentado sobre un amplio conocimiento de sí mismo y del entorno, minimizando de esta manera el riesgo y la incertidumbre. 1 Un Sistema de Información es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su posterior uso, generados para cubrir una necesidad u objetivo. 2 DSS es un sistema informático utilizado para servir de apoyo, más que automatizar, el proceso de toma de decisiones. 3 Es un tipo de Sistema de Información diseñado para recolectar, almacenar, modificar y recuperar todo tipo de información que es generada por las transacciones en una organización. 13
  14. 14. 14 Chapter I 1.2 ¿Qué es BI? “BI es el conjunto de estrategias y tecnologías que nos van a ayudar a convertir los datos en información de calidad y dicha información en conocimiento que nos permita una toma de decisiones más acertada y nos ayude así a mejorar nuestra competitividad”4 Business Intelligence hace hincapié en los procesos de recolectar y utilizar efectivamente la información con el fin de mejorar la forma de operar de una organización, brindando a sus usuarios, el acceso a la información clave que necesitan para llevar a cabo sus tareas habituales y, en concreto, para poder tomar decisiones oportunas basadas en datos correctos y certeros —algo peor que no tener información disponible es tener mucha información y no saber qué hacer con ella. Los datos almacenados en nuestros sistemas no valen nada si no somos capaces de comprender su significado, de elaborarlos y transformarlos en información de calidad, que sea capaz de responder a las preguntas de los usuarios de diferentes áreas de negocios — ventas, marketing, finanzas, inventarios, entre otras—, como: ¿Cuál es el estado de salud de mi empresa? ¿Cuál es el nivel de satisfacción de mis clientes? ¿Y el de mis empleados? ¿Cuál es la línea de productos más rentables? ¿Es la misma que el año anterior? ¿Cuál es el segmento de clientes al que deberíamos dirigir un nuevo producto? ¿Qué departamentos son los más productivos? Al contar con la información exacta y en tiempo real, es posible, además de lo anterior, identificar y corregir situaciones antes de que se conviertan en problemas potenciales o pérdidas de control de la empresa, pudiendo conseguir nuevas oportunidades o readaptarse frente a la ocurrencia de sucesos inesperados. A todo ello, a partir de ahora se denominará solución BI. ¿Quién necesita soluciones de Business Intelligence? Para ello nos planteamos las siguientes cuestiones: ¿Pasa más tiempo recolectando y preparando información que analizándola? ¿En ocasiones le frustra el no poder encontrar información que usted está seguro que existe dentro de la empresa? ¿Pasa mucho tiempo tratando de hacer que los informes en Excel luzcan bien? ¿No sabe qué hacer con tanta información que tiene disponible en la empresa? ¿Quiere saber qué productos fueron los más rentables durante un periodo determinado? ¿Ha perdido oportunidades de negocio por recibir información retrasada? ¿Trabaja horas extras el fin de mes para procesar documentos e informes? ¿No sabe con certeza si su gente está alcanzando los objetivos planeados? 4 Microsoft Business Intelligence: Vea el cubo medio lleno (http://www.solidq.com/sqj/books/Pages/Microsoft-Business- Intelligence-vea-el-cubo-medio-lleno.aspx) 14
  15. 15. ¿No tiene idea de por qué sus clientes le devuelven mercancía? Estas son las soluciones de BI más reconocidas actualmente en el mercado. Un caso de éxito de solución BI fue un estudio de la cadena de supermercados Wal- Mart5 , donde decidieron iniciar un proyecto de Basket Analysis6 utilizando la información recogida de las ventas. Descubrieron una correlación estadísticamente significativa entre la compra de pañales y cerveza. Profundizando en el estudio, vieron que los compradores de cerveza y pañales eran varones de entre 25 y 35 años que solían comprar estos productos conjuntamente los viernes por la tarde. La cadena de supermercado tomo la decisión de colocar las cervezas cerca de los pañales, con la intención de que los padres que compraban pañales y que no solían comprar cerveza, se acordasen que faltaba cerveza en casa. Los resultados fueron espectaculares aumentando un 15% las ventas de cervezas con pañales. La Inteligencia de Negocios tiene sus raíces en los Sistemas de Información Ejecutiva 7 o Executive Information Systems (EIS) y en los DSS, pero ha evolucionado y se ha transformado en todo un conjunto de tecnologías capaces de satisfacer a una gran gama de usuarios, junto a sus necesidades especí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. 16. 16 Chapter I  FASE 1: Dirigir y planear. Fase inicial donde se deberán recoger los requerimientos de información de los diferentes usuarios así como entender sus necesidades de información.  FASE 2: Recolección de información. Se estudiaran las diferentes fuentes de información de la empresa para recolectar aquellos datos que darán respuestas a las necesidades planteadas en la fase anterior  FASE 3: Procesamiento de datos. En esta fase es donde de integran y cargan los datos en crudo en un formato utilizable para el análisis. Esta actividad puede realizarse mediante la creación de una nueva base de datos, agregando datos a una base de datos ya existente o bien consolidando la información.  FASE 4: Difusión. Finalmente los usuarios a través de una serie de herramientas podrán explorar los datos de manera sencilla e intuitiva. 1.2.2 Arquitectura de una solución BI Una solución Business Intelligence parte de los sistemas de origen de una organización —bases de datos, ERPs, ficheros de texto, entre otros—, sobre los que suele ser necesario aplicar una transformación estructural para optimizar su proceso analítico. Para ello se realiza una fase de extracción, transformación y carga (ETL) de datos, donde se depuran y homogeneizan Esta etapa suele apoyarse en un almacén intermedio —Operational Data Store— (ODS) que actúa como pasarela entre los sistemas fuente y los sistemas destino —generalmente un Data Warehouse—, y cuyo principal objetivo consiste en evitar la saturación de los servidores funcionales de la organización. La información resultante, ya unificada, depurada y consolidada, se almacena en un Data Warehouse (DW) corporativo, que puede servir como base para la construcción de distintos Datamarts departamentales. Estos Datamarts se caracterizan por poseer la estructura óptima para el análisis de los datos del área de la organización, ya sea mediante Bases de Datos Transaccionales (OLTP) o mediante Bases de datos analíticas (OLAP). 1.3 ¿Qué es un Data Warehouse? Supóngase que una compañía quiere analizar aquellos países y gama de productos en los que las ventas vayan excepcionalmente bien. La compañía dispone de una base de datos transaccional sobre la que operan todas las aplicaciones de la empresa: producción, venta, facturación, proveedores etc. Lógicamente, de cada venta se registra la fecha, la cantidad, el comprador y el país de este. Con toda esta información histórica nos podemos preguntar: ¿Es esta información suficiente para realizar el análisis planteado? La respuesta hay que buscarla fuera de la base de datos, en el contexto donde se motiva el análisis. La incorporación de un producto depende de las ventas por habitantes. Si no tenemos en cuenta la población de cada país, la repuesta al análisis 16
  17. 17. estará sesgada. También puede ocurrir que, dependiendo de la gama del producto, nos interese información externa verdaderamente específica, como por ejemplo, las horas de sol anuales de cada país, siendo información valiosa para una compañía de cosmética: es más difícil vender bronceador en Lituania que en Canarias. Pero este hecho, que nos parece tan lógico, sólo podrá ser descubierto por herramientas de Minería de Datos8 , si se incorpora información climática de cada país. Con lo cual, cada organización deberá recoger diferente información que le pueda ser útil para la tarea de análisis y extracción de conocimiento y en definitiva para la toma de decisiones. Un Data Warehouse es una base de datos corporativa en la que se integra información depurada de las diversas fuentes inmersas en la organización o externas a ella, como se muestra en la Figura 2. Dicha información debe ser homogénea y fiable, se almacena de forma que permita su análisis desde muy diversas perspectivas, y a su vez de tiempos de respuestas óptimos. Figura 2: En un Data Warehouse se integra información de diversas fuentes. Una de las definiciones más famosas sobre DW, es la de William Harvey Inmon9 , que expone: “Un Data Warehouse es una colección de datos orientada al negocio, integrada, variante en el tiempo y no volátil para el soporte del proceso de toma de decisiones de la gerencia”. donde en la Tabla 1 se aprecia en profundidad cada una de las características más detalladas. 8La Minería de Datos consiste en la extracción no trivial de información que reside de manera implícita en los datos. Dicha información era previamente desconocida y podrá resultar útil para algún proceso. En otras palabras, la Minerí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. 18. 18 Chapter I Tabla 1: Características de un Data Warehouse Orientado a temas Los datos están organizados por temas para facilitar el entendimiento por parte de los usuarios, de forma que todos los datos relativos a un mismo elemento de la vida real queden unidos entre sí. Por ejemplo, todos los datos de un cliente pueden estar consolidados en una misma tabla, todos los datos de los productos en otra y así sucesivamente. Integrado La integración implica que todos los datos de diversas fuentes que son producidos por distintos departamentos, secciones y aplicaciones, tanto internos como externos, deben ser consolidados en una instancia antes de ser agregados al Data Warehouse, y deben, por lo tanto, ser analizados para asegurar su calidad y limpieza, entre otras cosas. Algunas de las inconsistencias más comunes que nos solemos encontrar son: en nomenclatura, unidades, formato de fechas,.. Histórico (variante en el tiempo) Los datos, que pueden ir variando en el tiempo, deben quedar reflejados de forma que al ser consultados reflejen estos cambios y no se altere la realidad que había en el momento que se almacenaron, evitando así la problemática que ocurre en los sistemas operacionales, que reflejan solamente el estado de la actividad de negocio presente. No volátil Una vez almacenada la información en el Data Warehouse debe ser de solo lectura, nunca se modifica ni se elimina, debe ser permanente para futuras consultas. 1.3.1 Arquitectura de una solución BI con Data Warehouse En este punto —teniendo en cuenta que ya se han detallado claramente las características generales del Data Warehouse— se 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
  19. 19. 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. 20. 20 Chapter I En un Data Warehouse se cargan y unifican periódicamente información procedente de múltiples fuentes, esto implica que deben existir una serie de procesos que leen los datos de las diferentes fuentes, los transforman, los adaptan al modelo que se haya definido, los depuran y limpian para luego introducirlos en el Data Warehouse. Esto es lo que se conoce como procesos ETL —Procesos de Extracción, Transformación y Carga o Load. Figura 6: Proceso ETL A continuación se detalla cada una de estas etapas, donde se expone cuál es el proceso que llevan a cabo los ETL y se enumera cuáles son sus principales tareas.  Extracción.- Consiste en extraer los datos desde los sistemas de origen. La mayoría de los proyectos de almacenamiento de información fusionan datos provenientes de diferentes sistemas de origen, donde cada sistema puede usar una organización diferente de los datos o formatos distintos. La extracción los convierte a un formato preparado para iniciar el proceso de transformación. Una vez que los datos son seleccionados y extraídos, se guardan en un almacenamiento intermedio, lo cual permite manipular los datos sin interrumpir ni paralizar los OLTP ni el Data Warehouse.  Transformación: En estos procesos es preciso asegurar que los datos sean válidos, íntegros y útiles, lo que suele incluir realizar cálculos y generar nuevos valores. Los datos deben ser depurados para eliminar inconsistencias, discrepancias y duplicidades. Los casos más comunes en los que se debe realizar una transformación son los mostrados en la Tabla 2 . Tabla 2: Casos más comunes de transformaciones ETL Codificación Al integrar varias fuentes de datos puede existir más de una forma de codificar un atributo en común. Ejemplo: En el campo sexo algunos diseñadores definen su valor como “M” y “F” otros “Mujer” y “Hombre”. Se debe escoger una forma común para decodificar los atributos. Medida de atributos Los tipos de unidades de medidas utilizados para representar los atributos de una entidad varían considerablemente entre sí, a través de los diferentes OLTP. Por ejemplo, al registrar la longitud de un producto determinado, las unidades de medidas pueden ser explicitadas en centímetros, metros, pulgadas, etc. Se deberán estandarizar las unidades de medidas de los atributos, para que todas las fuentes de datos expresen sus valores de igual manera. Convenciones de nombramiento Usualmente, un mismo atributo es nombrado de diversas maneras en los diferentes OLTP. Por ejemplo, al referirse al nombre del proveedor, puede hacerse como “nombre”, “razón_social”, “proveedor”. Aquí, se debe utilizar la convención de nombramiento que para los usuarios sea más comprensible Fuentes múltiples Un mismo elemento puede derivarse desde varias fuentes. En este caso, se debe elegir aquella fuente que se considere más fiable y apropiada. 20
  21. 21. Tabla 2: Casos más comunes de transformaciones ETL Limpieza de datos Su objetivo principal es el de realizar distintos tipos de acciones contra el mayor número de datos erróneos, inconsistentes, irrelevantes o datos faltantes o Missing Values. Las acciones más comunes son: ignorarlos, eliminar la columna, filtrar la columna, reemplazar valor o filtrar fila errónea  Carga.- Esta función se encarga, por un lado de realizar las tareas relacionadas con: o Carga Inicial (Initial Load). Es el proceso de incorporar los datos al Data Warehouse o Actualización o mantenimiento periódico. Antes de realizar una nueva actualización, es necesario identificar si se han producido cambios en las fuentes originales de los datos recogidos, desde la fecha del último mantenimiento, a fin de no atentar contra la consistencia del Data Warehouse. I.1.3.1.3 Data Warehouse Manager Figura 7: Data Warehouse Manager Si bien existen diversas estructuras de datos, a través de las cuales se puede representar los datos del DW, solamente se entrará en detalle en los cubos multidimensionales, por considerarse que esta estructura de datos es una de las más utilizadas. Un cubo multidimensional o hipercubo, representa o convierte los datos planos que se encuentran en filas y columnas, en una matriz de N dimensiones. Los datos se organizan en “hechos”, que tienen unos atributos o medidas que pueden verse en mayor o menor detalle según ciertas “dimensiones”. Por ejemplo, una cadena de supermercado puede tener como hechos las ventas. Cada venta tiene unas medidas: importe, cantidad, número de clientes, etc., y se pueden detallar o agregar varias dimensiones: tiempo de la venta, producto de la venta, lugar de la venta etc. Es esclarecedor comprobar que las medidas responden generalmente a la pregunta “cuánto”, mientras que las dimensiones responderán al “cuanto”,”que”,”donde”, etc. El modelo dimensional es una adaptación del modelo relacional, con el fin de optimizarlo para dar una rápida respuesta a las consultas realizadas por los usuarios. Aunque a nivel físico, una vez implementado en un Sistema Gestor de Bases de Datos 21
  22. 22. 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
  23. 23. jerarquías que se pueden establecer para describir niveles de agrupamiento específicos se pueden observar en la Figura 9 y se describen en la Tabla 3. Figura 9: Esquema de organización jerárquica de las dimensiones Tabla 3: Organización jerárquica de las dimensiones Dimensiones degeneradas Este término hace referencia a un campo que será utilizado como criterio de análisis y que es almacenado en la tabla de hechos. Esto sucede cuando un campo que se utiliza como criterio de análisis posee el mismo nivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no se pueden realizar agrupaciones o sumarizaciones a través de este campo, como por ejemplo "números de orden", "números de ticket", "números de transacción", etc. Atributos no dimensión Los niveles de la jerarquía también pueden tener atributos descriptivos, donde no son utilizados para formar niveles de jerarquía, sino para describir detalles en los mismos, como por ejemplo, el número de teléfono, la dirección de correo electrónico, etc. Jerárquicas Describen diferentes niveles de agrupamiento específicos —explícitos o implícitos— y, por lo tanto, las diferentes granularidades o niveles de detalle en la visión de los datos, como por ejemplo la jerarquía formada por Año, Trimestre, Mes y Día En las tablas dimensiones, habitualmente no es posible utilizar la clave de negocio — business key— como clave principal —primary key— e incluso, en el caso que sea posible, no es aconsejable por temas de rendimiento, ya que desde este punto de vista es recomendable utilizar número enteros de pocos bytes. Si en un sistema transaccional tenemos, por ejemplo, una clave principal con dominio char(10), siempre será más óptimo utilizar un tipo de datos numérico de menos byte como clave principal en las tablas dimensiones. Se sustituirán las habituales clave de negocio por claves subrogadas —subrogate key— las cuales serán de tipo numérico y habitualmente autoincremental. Esta clave no tiene sentido a nivel de negocio, pero la necesitamos para identificar de forma única cada una de las filas. Un concepto importante dentro de este apartado son las dimensiones lentamente cambiantes o Slowly Changing Dimensions (SCD). Son dimensiones en las cuales sus datos tienden a modificarse a través del tiempo, ya sea de forma ocasional o constante, o implique a un solo registro o a la tabla completa. Cuando ocurren estos cambios, se puede optar por seguir alguna de estas dos grandes opciones:  Registrar el historial de cambios.  Reemplazar los valores que sean necesarios. 23
  24. 24. 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
  25. 25. 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. 26. 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
  27. 27. 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. 28. 28 Chapter I Figura 15: Esquema en copo de nieve  Esquema constelación.- Está compuesto por una serie de esquemas en estrellas, tal como se puede apreciar en Figura 16 No es necesario que las diferentes tablas de hechos compartan las mismas dimensiones. Figura 16: Esquema en constelación En la Tabla 4 se puede observar un resumen comparativo de ambos esquema. Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse Modelo Ventajas Inconvenientes Estrella La desnormalización permite obviar uniones —Join— entre las tablas cuando se realizan consultas, procurando así un mejor tiempo de respuesta y una mayor sencillez con respecto a su utilización Más simple de interpretar Optimiza los tiempos de respuesta ante las consultas La desnormalización con la que cuenta genera un cierto grado de redundancia Necesidad de mayor espacio de almacenamiento Menos robusto para la carga Es el más lento de construir Copo de nieve Posibilidad de segregar los datos de las tablas de dimensiones y proveer un esquema que sustente los requerimientos de diseño. Muy flexible y puede implementarse después de que se haya desarrollado un esquema en estrella. Hace una mejor utilización del espacio. Puede desarrollar clases de jerarquías fuera de las tablas de dimensiones, que permiten realizar análisis de lo general a lo detallado y viceversa. Si se poseen múltiples tablas de dimensiones, cada una de ellas con varias jerarquías, se creará un número de tablas bastante considerable, que pueden llegar al punto de ser inmanejables Al existir muchas uniones y relaciones entre tablas, el desempeño puede verse reducido La existencia de las diferentes jerarquías de dimensiones debe estar bien fundamentada, ya que de otro modo las consultas demorarán más tiempo en 28
  29. 29. Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse devolver los resultados, debido a que se deben realizar las uniones entre las tablas. Constelació n Permite tener más de una tabla de hechos, por lo cual se podrán analizar más aspectos claves del negocio con un mínimo esfuerzo adicional de diseño. Contribuye a la reutilización de las tablas de dimensiones, ya que una misma tabla de dimensión puede utilizarse para varias tablas de hechos. No es soportado por todas las herramientas de consulta y análisis Data Warehouse vs OLTP Debido a que, ya se han explicado y caracterizado los distintos tipos de esquemas del DW, se procederá a exponer las razones de su utilización, como también las causas de por qué no se emplean simplemente las estructuras de las bases de datos tradicionales. Esta comparación se puede ver en la Tabla 5. Tabla 5: OTLP VS Data Warehouse OLTP Data Warehouse Objetivo Soportar actividades transaccionales Consultar y analizar información estratégica y táctica Tiempo de datos Operacionales Para la toma de decisiones Modelo de datos Normalizado Desnormalizado Consulta SQL SQL más extensiones Datos consultados 60-90 días 5-10 años Tipos de consultas Repetitivas, predefinidas No previsibles, dinámicas Nivel de almacenamiento Nivel de detalle Nivel de detalle y diferentes niveles de sumarización Acciones disponibles Alta, baja, modificación y consulta Carga y consulta Número de transacciones Elevado Medio o bajo Tamaño Pequeño-Mediano Grande Tiempo de respuesta Pequeño Variable Orientación Orientado a las aplicaciones Orientado al negocio Sello de tiempo La clave puede o no tener un elemento de tiempo La clave tiene un elemento de tiempo Estructura Generalmente estable Generalmente varía de acuerdo a su propia evolución y utilización 29
  30. 30. 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
  31. 31. 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. 32. 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
  33. 33. Tabla 7: Usuarios OLTP vs usuarios Data Warehouse Usuarios OLTP Usuarios Data Warehouse Acceso concurrente Muchos Pocos Tipo de consultas Predefinidas Complejas, no predecibles y no anticipadas Registros consultados Pocos Muchos Tiempo de respuesta Crítico No crítico Acciones permitidas Agregar, modificar, eliminar y consultar Consultar I.1.3.1.6 Conceptos complementarios: Datamarts Un Datamarts (DM) es una versión especial del Data Warehouse. Son subconjuntos de datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de los mismos de la forma más conveniente según sus necesidades. En síntesis, se puede decir que los Datamarts son pequeños Data Warehouse centrados en un tema o un área de negocio específico dentro de una organización. Por ejemplo la información de personal de una empresa —empleados, departamento, proyectos— es difícilmente integrable en un mismo modelo de estrella de ventas. Incluso en ámbitos más relacionados de una organización, ventas y producción no resulta fácil. La solución está en que para cada subámbito de la organización se va a construir una estructura en estrella. Por tanto, el Data Warehouse estará formado por muchas estrellas, cada una de estas estrellas es un Datamarts. Lógicamente cada Datamart tendrá unas medidas y dimensiones propias y diferentes de los demás, la única dimensión que suele aparecer en todos los Datamarts es la dimensión tiempo, ya que el Data Warehouse representa información histórica. Figura 20: Datamarts 33
  34. 34. 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
  35. 35. 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. 36. 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
  37. 37. 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. 38. 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
  39. 39. evolucionando sus soluciones suficientemente rápido y de alguna manera están perdiendo parte de la perspectiva. Una vez visto que representan las diferentes áreas del cuadrante de Gartner, se analiza como Oracle y Microsoft, consolidadas en el año 2010 como las empresas líderes en producto BI, son las mejores por lo cual se decide apostar por Microsoft como una opción muy interesante para desarrollar este proyecto —destacar además que la empresa ITOP MC ya poseía una serie de licencias por lo que no habría que realizar una nueva inversión a priori. Para poder implantar una solución BI usando tecnologías de Microsoft es necesario los requerimientos que se muestran en la Tabla 8, resumidos en la Figura 22. Tabla 8: Requerimientos tecnológicos básicos para una solución BI con Microsoft Requerimientos de Software ¿Qué solución necesitamos? ¿Qué nos aporta? Sistema Operativo Windows 2008 R2 64bits Conexiones remotas, trabajo concurrente y Sistema Operativo Windows convencional Servidor de Integración de datos SQL Server 2008 R2 Integration Services (SSIS) Servidor para realizar y planificar el proceso de Extracción, Transformación y Carga de los datos de origen Servidor de Base de datos Analista o OLAP SQL Server 2008 R2 Analisys Servicies (SSAS) Análisis y optimización de los datos almacenados en el DW Sistema gestor de base de datos SQL Server 2008 R2 64bits Gestión y creación de almacén de datos Servidor de Informes SQL Server 2008 R2 Reporting Services (SSRS) Representación de informes alimentados desde un Cubo OLAP Cuadros de mando Crystal Xcelsius 2008 (No pertenece a Microsoft pero está totalmente integrada, con cualquier producto de esa empresa) Cuadros de mando dinámicos basados en Flash, exportables a Excel, PDF, etc. SharePoint Foundation 2010 + Performance Point Diseñador de cuadro de mando integrables en los portales Web corporativos Share Point Silverlight 4.0 Cuadros de mando dinámicos y con conexión directa al cubo OLAP Microsoft Office Excel 2007 + Power Pivot Tablas y cuadros de mando dinámicos con conexión directa a los cubos OLAP 39
  40. 40. 40 Chapter I Figura 22: Solución tecnológica propuesta para una solución BI usando herramientas Microsoft Se realizó además una comparación de las características que nos aporta cada una de las herramientas de presentación y cuadros de mando, indicada en la Tabla 9. Con respecto a la parte de Sistema Gestor de Bases de Datos y Sistema Operativo se parte del punto que los clientes, a los que se les quieres implantar la solución BI, ya tienen disponibles el software necesario derivado de la contratación ERP SAP BO, así como el deseo por parte de ITOP MC de la importancia del uso de Share Point para tener acceso, tanto externo como interno, a sus cuadros de mando por parte de sus clientes desde cualquier parte y dispositivo. Tabla 9: Tabla comparativa del Software de representación SSRS Crystal Xcelsius Performance Point Silverlight Microsoft Excel Publicación SharePoint Características interactivas Programables (SDK) Interfaz Amigable Integración con SAP Publicables en Web 40
  41. 41. 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. 42. 42 Chapter I  Reporting.- Módulo de informes que ofrece la solución adecuada a las necesidades de los usuarios. Pentaho Reporting es una solución basada en el proyecto JFreeReport y permite generar informes ágil y de gran capacidad. Pentaho Reporting permite la distribución de los resultados del análisis en múltiples formatos —todos los informes incluyen la opción de imprimir o exportar a formato PDF, XLS, HTML y texto—, además de admitir programación de tareas y ejecución automática de informes con una determinada periodicidad.  Análisis.- Pentaho Análisis suministra a los usuarios un sistema avanzado de análisis de información, con uso de las tablas dinámicas —pivot tables, crosstabs—, generadas por Mondrian y JPivot. El usuario puede navegar por los datos, ajustando la visión de los mismos, los filtros de visualización, añadiendo o quitando los campos de agregación. Los datos pueden ser representados en una forma de SVG o Flash, los dashboards widgets, o también integrados con los sistemas de Minería de Datos y los portales web o portlets. Además, con Microsoft Excel Analysis Services, se puede analizar los datos dinámicos en Microsoft Excel —usando la conexión a OLAP server Mondrian.  Portal de BI: En este portal web se publica toda la información recolectada en los procesos de análisis.  Dashboards.- Todos los componentes del módulo Pentaho Reporting y Pentaho Análisis pueden formar parte de un Dashboard. En Pentaho Dashboards es muy fácil incorporar una gran variedad en tipos de gráficos, tablas y velocímetros —Dashboard widgets— e integrarlos con los Portlets JSP, en donde podrá visualizar informes, gráficos y análisis OLAP. Así como una librería de código abierto integrada en el Portal de BI que nos proporciona Pentaho denominada CDF (Community Dashboard Framework).  Data Mining.- Minería de datos se realiza con una herramienta WeKa.  Integración de Datos.- Se realiza con una herramienta Kettle ETL (Pentaho Data Integration) que permite implementar los procesos ETL. Últimamente Pentaho lanzó una nueva versión PDI 3.0, que marcó un gran paso adelante en OSBI ETL y que hizo Pentaho Data Integration una alternativa interesante para las herramientas comerciales. 3.2.2 Conclusión Una vez estudiada la vertiente del software privativo y Open Source se procedió a comparar y decidir por cual se va optar para desarrollar el proyecto. Resaltar que ambas herramientas fueron instaladas y testeadas antes de su selección. Para más detalle mirar la Tabla 10. 42
  43. 43. Tabla 10: Tabla comparativa Pentaho vs Microsoft Pentaho Microsoft Documentación Integración con otras herramientas Sólo especificas Posibilidad de añadir funcionalidades Integrables con SharePoint Facilidad para implementar cuadros de mando con el uso de herramientas externas Coste de Licencias Curva de aprendizaje Multiplataforma. Múltiple sistema de BBDD Valoración final Finalmente se decidió decantarse por la solución propuesta por Microsoft debido a los siguientes motivos:  Documentación más homogénea, sólida y abundante.  Mayor bibliografía que Pentaho, quizás porque esta última utiliza herramientas muy heterogéneas entre sí, no siguen un mismo patrón de desarrollo, están en constante cambios y son desarrolladas por diferentes organizaciones15 .  Menor curva de aprendizaje.  Mayor facilidad de desarrollo.  La versión libre de Pentaho tiene elementos muy básicos que conlleva un esfuerzo adicional de instalación y configuración adicional  ITOP MC, así como sus clientes, ya poseían la licencia de Microsoft SQL Server 2008 Standard y se quería aprovechar esta opción. 3.3 Descripción del problema Finalmente, después de haber decidido cuál era la tecnología que se iba a usar para implementar la solución BI con el fin de integrarla con SAP BO, se procede a definir el problema al que en este trabajo se le da solución. 15 A fecha 07 de julio de 2011 en la búsqueda realiza de bibliografía sobre Pentaho fue escaso encontrar libros que realmente entren en profundidad en cómo llevar a cabo un desarrollo completo de BI con Pentaho, ya que lo normal fue encontrar bibliografía centrada en las herramientas de ETL y de Reporting. 43
  44. 44. 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
  45. 45. Parte II. Cuerpo principal. Descripción del trabajo 45
  46. 46. 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
  47. 47. 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. 48. 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
  49. 49.  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. 50. 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
  51. 51. 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. 52. 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. 53. 53
  54. 54. 54 Chapter I Tabla 14: Sprint Backlog de la solución BI Backlog Sprint Descripción Duración Estimación Real 1 Estudio del estado del arte 1,2,3,4,5 Estado del arte 30 días 30 días 6 Documentación 3 días 3 días 2 Desarrollo de una metodología 7, 8 Búsqueda de una metodología 15 días 15 días 9 Documentación 3 días 3 días 3 Herramientas de desarrollo 10, 11 Estudio de las herramientas de desarrollo 15 días 15 días 12 Documentación 3 días 3 días 13 Pruebas 7 días 7 días 4 Análisis de requerimientos 14, 15 Identificar Preguntas 7 días 10 días 16,17,18,19,2 0 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 5 Análisis de los OLTP 24,25,26,27,2 8 Conformar indicadores 7 días 15 días 29 Establecer correspondencias 7 días 15 días 30 Nivel de granularidad 7 días 15 días 31 Modelo conceptual ampliado 7 días 7 días 22 Documentación 3 días 3 días 23 Pruebas 7 días 7 días Modelo lógico del Data Warehouse Tipo de modelo lógico del Data 54
  55. 55. 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. 56. 56 Chapter I Figura 24: Diagrama de Gantt 56
  57. 57. 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. 58. 58 Chapter I debe tener muy en cuenta, es no entrar en la utilización de metodologías que requieran fases extensas de reunión de requerimientos y análisis, fases de desarrollo monolítica que conlleve demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es entregar una primera implementación que satisfaga una parte de las necesidades, para demostrar las ventajas del Data Warehouse y motivar a los usuarios. La metodología elegida para el diseño del Data Warehouse se ha elaborado a partir de una metodología base existente, la cual se ha ampliado y adaptando a nuestro problema. La ampliación ha consistido en la adición de algunos aspectos claves en el diseño de un Data Warehouse y una metodología de implementación para una solución de Business Intelligence. La metodología base de la que se parte fue propuesta por el Ingeniero Argentino Bernabeu Ricardo “Investigación y Sistematización de Conceptos - HEFESTO: Metodología propia para la Construcción de un Data Warehouse ”20 (2). 2.1.1 Metodologías para construir un Data Warehouse En un principio se realizó una búsqueda con el fin de encontrar una metodología que se adaptara lo mejor posible a nuestro problema. Se encontraron dos metodologías interesantes: por un lado Hefesto, anteriormente nombrada, y por otro lado la desarrollada por SAS, llamada The SAS Rapid Data Warehouse Methodology (SRDWM). Dicha metodología es iterativa y desarrolla incrementalmente un proyecto Data Warehouse dividiéndolo en cinco fases: 1. Definición de los objetivos 2. Definición de los requerimientos de información 3. Diseño y modelización 4. Implementación 5. Revisión La razón por la que se desestimó el uso de la metodología SRDWM es debido a la sencillez y eficacia con la que está elaborada la metodología Hefesto. Hefesto explica de forma muy intuitiva los pasos que hay que tomar en cada momento, así como por qué debemos tomarlos, acompañada siempre con ejemplos y comparaciones. Se toma como punto de referencia para todas aquellas personas que estén dando sus primeros pasos en el mundo del Data Warehousing y quizás en ese sentido SRDWM no aportaba esa sencillez, resultando incluso más dificultoso. Otra ventaja es que encaja perfectamente con la metodología Scrum frente a SRDWM, que al ser una metodología iterativa incremental, tendría mayor dificultad de adaptarse a una metodología de desarrollo ágil. En la Tabla 15 se muestra las principales características de Hefesto. Tabla 15: Características principales en la metodología Hefesto Los objetivos y resultados esperados en cada fase se distinguen fácilmente y son sencillos de comprender 20 A partir de ahora utilizaremos Hefesto para referirnos a ella. 58
  59. 59. 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

×