Upload
rebeca-mora-anca
View
757
Download
8
Embed Size (px)
DESCRIPTION
Memoria de mi Proyecto Fin de Carrera
Citation preview
Business Intelligence paraPYMES
Autor/es: Manuel Alejandro González YanesRebeca Mora Anca
Director/a: Virginia Gutiérrez Rodríguez
Fecha: 12 de Julio de 2011
2 Chapter I
D./Dña. Virginia Gutiérrez Rodríguez Profesora de la Escuela Técnica Superior de Ingeniería
Informática, y adscrito al Departamento de Estadística, Investigación Operativa y Computación
de la Universidad de La Laguna.
CERTIFICA: Que la presente memoria titulada Business Intelligence para PYMES, ha sido
realizada bajo mi dirección por el/los alumno/s D. Manuel Alejandro González Yanes y Dña
Rebeca Mora Anca, y constituye su Proyecto Fin de Carrera de Ingeniería Informática por la
Universidad de La Laguna.
Y para que así conste, en cumplimiento de la legislación vigente y a los efectos que haya lugar,
firmo el presente certificado en La Laguna, a 12 de Julio de 2011
Fdo: D./Dña. Virginia Gutiérrez Rodríguez
2
Resumen
Se denomina inteligencia empresarial, inteligencia de negocios o BI (del inglés Business
Intelligence) al conjunto de estrategias y herramientas enfocadas a la administración y
creación de conocimiento mediante el análisis de datos existentes en una organización o
empresa.
La Business Intelligence actúa como un factor estratégico para una empresa u organización,
generando una potencial ventaja competitiva, que no es otra que proporcionar información
privilegiada para responder a los problemas de negocio: entrada a nuevos mercados,
promociones u ofertas de productos, control financiero, optimización de costes, planificación de
la producción, análisis de perfiles de clientes, rentabilidad de un producto concreto, etc...
Las herramientas de inteligencia abarcan la comprensión del funcionamiento actual de la
empresa como la anticipación de acontecimientos futuros, con el objetivo de ofrecer
conocimientos para respaldar las decisiones empresariales. Las herramientas de Business
Intelligence se basan en la utilización de un Sistema de Información de Inteligencia que se
forma con distintos datos extraídos de producción, con información relacionada con la empresa
o sus ámbitos y con datos económicos.
Las herramientas de Business Intelligence ofrecen a las personas que toman las decisiones
utilidades que facilitan ese proceso como:
Cuadros de Mando para medir la evolución de los Indicadores clave del negocio cómo
controlar las ventas o la situación económica.
Informes dinámicos con los que buscar causas o tendencias de forma sencilla y que
permiten analizar clientes, proveedores, producción, etc. en profundidad.
El problema a abordar consiste en integrar SAP BO con una solución de Business Intelligence
de forma que proporcione a las Pymes informes gráficos y cuadros de mandos interactivos que
ofrezca una mayor versatilidad, control de los ingresos, los márgenes y la liquidez.
3
4 Chapter I
Agradecimientos
A nuestro profesor de la Universidad de La Laguna, Marcos Colebrook, el cual nos animó a
desarrollar este proyecto tan satisfactorio a nivel personal y profesional.
A nuestra directora de proyecto de la Universidad de La Laguna, Virginia Gutiérrez Rodríguez,
la cual trabajó con nosotros a lo largo de todo el proyecto siempre ayudando, aconsejando y
orientándonos en todo momento.
A las personas que forman ITOP Management Consulting, y en especial a Teresa Pestana y
Miguel Fernández, por el apoyo y las horas que han dedicado con nosotros a este proyecto.
Dedicar este proyecto a nuestra familia y amigos por el apoyo y los ánimos prestados en todo
momento incondicionalmente.
Gracias a profesores como José Luis Roda que nos dio grandes consejos y nos proporcionó las
infraestructuras con las que realizar el proyecto, Daniel González que nos descubrió el mundo
del PMBOK e ITIL para poder crear los indicadores, Roberto Dorta que nos ayudó a entender la
ISO9001.
4
5
6 Chapter I
Al término de esta etapa de nuestras vida. Queremos expresar todo nuestro agradecimiento a quienes con su ayuda, apoyo y comprensión, nos alentaron a lograr esta hermosa realidad…
nuestra formación profesional.Tabla de contenidos
Resumen .......................................................................................................... 2
Agradecimientos ............................................................................................. 4
Lista de figuras .............................................................................................. 7
Lista de Tablas ................................................................................................ 8
Parte I.Introducción y fundamentos básicos ................................................... 8
Capítulo 1.Fundamentos Business Intelligence ......................................... 91.1Introducción ................................................................................................................ 9
1.2¿Qué es BI? ................................................................................................................ 9
1.2.1Proceso BI ...................................................................................................... 10
1.2.2Arquitectura de una solución BI ...................................................................... 10
1.3¿Qué es un Data Warehouse? ................................................................................. 10
1.3.1Arquitectura de una solución BI con Data Warehouse ................................... 11
Capítulo 2.ITOP Management Consulting .................................................. 202.1La empresa ............................................................................................................... 20
2.2Filosofía .................................................................................................................... 20
2.3Alianzas .................................................................................................................... 20
Capítulo 3.Descripción del problema e integración de solucionestecnológicas .......................................................................................... 213.1Introducción .............................................................................................................. 21
3.2Análisis funcional y elección ..................................................................................... 21
3.2.1Análisis Inicial ................................................................................................. 21
3.2.2Conclusión ..................................................................................................... 23
3.3 Descripción del problema ........................................................................................ 24
Parte II.Cuerpo principal. Descripción del trabajo ........................................ 25
Capítulo 1.Descripción de la metodología para resolver el problema . . . 261.1Metodología de desarrollo ........................................................................................ 26
1.1.1Metodología SCRUM ..................................................................................... 27
Capítulo 2.Metodología de Implementación de una solución BI ............. 332.1.1Metodologías para construir un Data Warehouse .......................................... 33
6
2.1.2Metodología propia para la Construcción de un Data Warehouse con base enHEFESTO .................................................................................................... 34
Capítulo 3.Análisis de los resultados ......................................................... 713.1Resultados ................................................................................................................ 71
Parte III.Conclusiones, Final ............................................................................ 73
Capítulo 1.Conclusiones y posibles ampliaciones ................................... 74
Parte IV.Bibliografía .......................................................................................... 76
Parte V.1. Kniberg, Henrick. . http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf. [Enlínea] 09 de 06 de 2011. ............................................................................. 76
Parte VI.2. Dario, Bernabeu R. Investigación y Sistematización deHEFESTO: Metodología propia para la Construcción de un DataWarehouse. [En línea] 09 de 06 de 2011. ................................................ 76
Parte VII.3. Commerce, Office of Government. ITIL Gestión de Servicios TI.[En línea] 05 de 01 de 2011. http://itil.osiatis.es. ..................................... 76
Parte VIII.4. Alexander, Michael. Crystal Xcelsius for Dummies. 2007. ....... 76
Parte IX.5. Berndtsson, M., Hansson, J., Olsson, B., Lundell, B. A Guide forStudents in Computer Science and Information Systems, Springer.2008. ............................................................................................................. 76
Parte X.6. Stephen Few. Information Dashboard Design, The EffectiveVisual Communication of Data. s.l. : O'Reilly, 2006. .............................. 76
Parte XI.7. Doug Harts, Jim Dugan, Tricia Wilcox Almas. Microsoft SQLServer 2008 R2 Analytics & Data Visualization. s.l. : Mac Graw Hill,2008. ............................................................................................................. 76
Parte XII.8. Ramos, Salvador. Microsoft Business Intelligence vea el cubomedio lleno. s.l. : SolidQ Press, 2011. ...................................................... 76
7
8 Chapter I
Parte XIII.9. Sivakumar Harinath, Matt Carroll, Sethu Meenakshisundaram,Robert Zare, Denny Guang-Yeu Lee. Professional Microsoft SQLServer Analysis Services 2008 with MDX. s.l. : Wiley Publishing, Inc.,2009. ............................................................................................................. 76
Parte XIV.10. Xavier Hacking, David Lai. SAP BusinessObjectsDashboards 4.0 Cookbook. s.l. : Packt Publishing, 2011. ..................... 76
Parte XV.11. Roland Bouman, Jos van Dongen. Pentaho Solutions -Business Intelligence and Data Warehousing with Pentaho andMySQL. s.l. : WILEY. ................................................................................... 76
Parte XVI.12. Roldán, María Carina. Pentaho 3.2 Data Integration,Beginner's Guide. s.l. : Packt Publishing, 2010. ..................................... 76
Parte XVII.13. Erik Veerman, Jessica M. Moss, Brian Knight, Brian Knight.Microsoft® SQL Server® 2008 Integration Services Problem–Design–Solution. s.l. : Wiley Publishing, Inc, 2010. .............................................. 76
Parte XVIII.14. Nanda, Ashwani. Microsoft SQL Server 2008 IntegrationServicies. s.l. : Mac Graw Hill, 2010. ......................................................... 76
Parte XIX.15. Haselden, Kirk. Microsoft® SQL Server 2008 IntegrationServices. s.l. : UNLEASHED, 2009. ........................................................... 76
Parte XX.16. Anónimo. The Official Introduction to the ITIL ServiceLifecycle. s.l. : Published by TSO (The Stationery Office). .................... 76
Parte XXI.17. Commerce, Office of Government. ITIL Serivce Transition.s.l. : Published by TSO (The Stationery Office). ..................................... 76
Parte XXII.18. —. ITIL Continual Service Improvement. s.l. : OfficeGovernment Comerce, 2009. ..................................................................... 76
Parte XXIII.19. —. ITIL Service Design. s.l. : Published by TSO (TheStationery Office). ....................................................................................... 76
8
Parte XXIV.20. —. ITIL Service Operation. s.l. : Published by TSO (TheStationery Office). ....................................................................................... 76
Parte XXV.21. ZELAZNY, GENE. Say it whit Charts. s.l. : McGraw-Hill, 2001. ...................................................................................................................... 76
Parte XXVI.22. PARMENTER, DAVID. Key Performance Indicators,Developing, Implementing, and Using Winning KPIs. s.l. : John Wiley &Sons, Inc., 2010. .......................................................................................... 76
Parte XXVII.23. John Wiley & Sons, Inc., Hoboken, New Jersey. BusinessDashboards. s.l. : John Wiley & Sons, Inc., 2009. .................................. 76
Parte XXVIII.24. Withee, Ken. Microsoft Business Intelligence forDummies. s.l. : Wiley Publishing, Inc, 2010. ............................................ 76
Parte XXIX.25. Lynn Langit, Kevin S. Goff, Davide Mauri, Sahil Malik, andJohn Welch. Smart Business Intelligence Solutions with MicrosoftSQL Server2008. s.l. : Microsoft Press, 2009. ......................................... 76
Parte XXX.26. SQL SERVER INTEGRATION SERVICES 2008LABORATORIOS . s.l. : INTERMEZZO BUSINESS INTELLIGENCE ,2010. ............................................................................................................. 76
Parte XXXI.27. Inmon, W. H. Building the Data Warehouse. s.l. : Design &Composition, 2010. ..................................................................................... 76
Parte XXXII.28. Viera, Robert. Professional Microsft SQL Server 2008Programming. s.l. : Wiley Publishing, I nc, 2009. ................................... 76
Parte XXXIII.29. Ross MistRy, Stacia MisneR. Introduciong Microsoft SQLServer 2008 R2. s.l. : Microsoft Press, 2010. ........................................... 77
Parte XXXIV.30. Philo Janus, Philo Janus. Pro SQL Server 2008 AnalysisServices. s.l. : Apress, 2010. ..................................................................... 77
9
10 Chapter I
Parte XXXV.31. Rainardi, Vincent. Building a Data Warehouse withExamples in SQL Server. s.l. : Apress, 2010. .......................................... 77
Parte XXXVI.32. Scott Cameron, Hitachi Consulting. SQL Server 2008Analysis Services. s.l. : Vincent Rainardi, 2009. ..................................... 77
Parte XXXVII.33. Chris Webb, Alberto Ferrari and Marco Russo. ExpertCube Development with Microsoft SQL Server 2008 Analysis Services.s.l. : Marco Russo, 2009. ............................................................................ 77
Parte XXXVIII.34. Langit, Guy Fouché and Lynn. Foundations of SQLServer 2008 R2 Business Intelligence. s.l. : Apress, 2009. .................... 77
Parte XXXIX.35. Kimball, Joy Mundy and Marren Thornthwaite with Ralph.The Microsft Data Warehouse Toolkit whit SQL Server. s.l. : KimballGroup, 2011. ................................................................................................ 77
Parte XL.36. Anónimo. Scrum. Definición de Scrum. [En línea] 23 de 06 de2011. http://es.wikipedia.org/wiki/Scrum. ................................................ 77
Parte XLI.37. Institute, Project Management. PMBOK. ................................ 77
Glosario de términos .................................................................................... 78
Índice de siglas ............................................................................................. 82
Apéndices ...................................................................................................... 84
10
Lista de figuras
11
12 Chapter I
Lista de Tablas
Parte I. Introducción y fundamentos básicos
12
Capítulo 1. Fundamentos Business Intelligence
Resumen:
Introducción a mundo del Business Intelligence
Introducción Data Warehouse y conceptos relacionados
1.1 Introducción
En la actualidad, la gran mayoría de las organizaciones cuenta con un Sistema de
Información1 (SI) que soporta gran parte de las actividades diarias propias del sector de
negocios en donde se esté desempeñando. Este sistema puede ser sencillo o robusto,
todo depende de las exigencias del negocio. Con el transcurso del tiempo, estas
aplicaciones llegan a tener la historia de la organización: los datos almacenados en las
bases de datos pueden ser utilizados para argumentar la decisión que se quiera tomar.
Un estudio realizado en Europa por Information Builders Ibéric mostró el costo que
tiene la falta de Sistemas de Información Orientados para la Toma de Decisiones2 o
Decision Support Systems (DSS) en las organizaciones. Según estos datos, el
empleado europeo medio pierde una media de 67 minutos diariamente buscando
información de la compañía, lo que equivale a un 15,9% de su jornada laboral. Para
una organización de 1.000 empleados que gane unos 50.000 euros al día equivaldría a
7,95 millones de euros al año de salario perdido, debido todo ello a la búsqueda de
información orientada a la toma de decisiones.
El poder competitivo que puede tener una empresa se basa en la calidad y cantidad de
información que sea capaz de usar en la toma de decisiones. Mediante la
implementación de Inteligencia de Negocios o Business Intelligence (BI) se
proporcionan las herramientas necesarias para aprovechar los datos almacenados en
las bases de datos de los Sistemas Transaccionales3 para utilizar la información como
respaldo a las decisiones, reduciendo el efecto negativo que puede traer consigo una
mala determinación. Precisamente, Business Intelligence permite que el proceso de
toma de decisiones esté fundamentado sobre un amplio conocimiento de sí mismo y
del entorno, minimizando de esta manera el riesgo y la incertidumbre.
1 Un Sistema de Información es un conjunto de elementos orientados al tratamiento y administración de datos einformación, organizados y listos para su posterior uso, generados para cubrir una necesidad u objetivo.
2 DSS es un sistema informático utilizado para servir de apoyo, más que automatizar, el proceso de toma dedecisiones.
3 Es un tipo de Sistema de Información diseñado para recolectar, almacenar, modificar y recuperar todo tipo deinformación que es generada por las transacciones en una organización.
13
14 Chapter I
1.2 ¿Qué es BI?
“BI es el conjunto de estrategias y tecnologías que nos van a ayudar a convertir los
datos en información de calidad y dicha información en conocimiento que nos permita
una toma de decisiones más acertada y nos ayude así a mejorar nuestra
competitividad”4
Business Intelligence hace hincapié en los procesos de recolectar y utilizar
efectivamente la información con el fin de mejorar la forma de operar de una
organización, brindando a sus usuarios, el acceso a la información clave que necesitan
para llevar a cabo sus tareas habituales y, en concreto, para poder tomar decisiones
oportunas basadas en datos correctos y certeros —algo peor que no tener información
disponible es tener mucha información y no saber qué hacer con ella. Los datos
almacenados en nuestros sistemas no valen nada si no somos capaces de comprender
su significado, de elaborarlos y transformarlos en información de calidad, que sea
capaz de responder a las preguntas de los usuarios de diferentes áreas de negocios —
ventas, marketing, finanzas, inventarios, entre otras—, como:
¿Cuál es el estado de salud de mi empresa?
¿Cuál es el nivel de satisfacción de mis clientes? ¿Y el de mis empleados?
¿Cuál es la línea de productos más rentables? ¿Es la misma que el año anterior?
¿Cuál es el segmento de clientes al que deberíamos dirigir un nuevo producto?
¿Qué departamentos son los más productivos?
Al contar con la información exacta y en tiempo real, es posible, además de lo anterior,
identificar y corregir situaciones antes de que se conviertan en problemas potenciales o
pérdidas de control de la empresa, pudiendo conseguir nuevas oportunidades o
readaptarse frente a la ocurrencia de sucesos inesperados. A todo ello, a partir de
ahora se denominará solución BI.
¿Quién necesita soluciones de Business Intelligence?
Para ello nos planteamos las siguientes cuestiones:
¿Pasa más tiempo recolectando y preparando información que analizándola?
¿En ocasiones le frustra el no poder encontrar información que usted está seguro que
existe dentro de la empresa?
¿Pasa mucho tiempo tratando de hacer que los informes en Excel luzcan bien?
¿No sabe qué hacer con tanta información que tiene disponible en la empresa?
¿Quiere saber qué productos fueron los más rentables durante un periodo
determinado?
¿Ha perdido oportunidades de negocio por recibir información retrasada?
¿Trabaja horas extras el fin de mes para procesar documentos e informes?
¿No sabe con certeza si su gente está alcanzando los objetivos planeados?
4 Microsoft Business Intelligence: Vea el cubo medio lleno (http://www.solidq.com/sqj/books/Pages/Microsoft-Business-Intelligence-vea-el-cubo-medio-lleno.aspx)
14
¿No tiene idea de por qué sus clientes le devuelven mercancía?
Estas son las soluciones de BI más reconocidas actualmente en el mercado.
Un caso de éxito de solución BI fue un estudio de la cadena de supermercados Wal-
Mart5, donde decidieron iniciar un proyecto de Basket Analysis6 utilizando la
información recogida de las ventas. Descubrieron una correlación estadísticamente
significativa entre la compra de pañales y cerveza. Profundizando en el estudio, vieron
que los compradores de cerveza y pañales eran varones de entre 25 y 35 años que
solían comprar estos productos conjuntamente los viernes por la tarde. La cadena de
supermercado tomo la decisión de colocar las cervezas cerca de los pañales, con la
intención de que los padres que compraban pañales y que no solían comprar cerveza,
se acordasen que faltaba cerveza en casa. Los resultados fueron espectaculares
aumentando un 15% las ventas de cervezas con pañales.
La Inteligencia de Negocios tiene sus raíces en los Sistemas de Información Ejecutiva7o Executive Information Systems (EIS) y en los DSS, pero ha evolucionado y se ha
transformado en todo un conjunto de tecnologías capaces de satisfacer a una gran
gama de usuarios, junto a sus necesidades específicas, en cuanto al análisis de la
información.
1.2.1 Proceso BI
El proceso BI se describe en cinco fases, las cuales se explican teniendo como
referencia la Figura 1, gráfico que sintetiza todo el proceso.
Figura 1: Fases de un proceso BI
5 Wal-Mart es una empresa multinacional de origen estadounidense, el minorista más grande del mundo; y por susventas y número de empleados, la mayor compañía del mundo. Su concepto de negocio es la tienda de autoservicio debajo precio y alto volumen.
6 Las técnicas de basket analysis del mercado permiten analizar los productos que integran la bolsa de la compra y lasrelaciones existentes entre ellos. En este nivel de detalle, la información es muy útil y proporciona a los usuarios denegocio visibilidad directa sobre la bolsa de la compra de cada cliente.
7 Los Sistema de Información Ejecutiva son una herramienta de Business Intelligence, orientada a usuarios de nivelgerencial, que permite monitorizar el estado de las variables de un área o unidad de la empresa a partir de informacióninterna y externa a la misma.
15
16 Chapter I
FASE 1: Dirigir y planear. Fase inicial donde se deberán recoger los
requerimientos de información de los diferentes usuarios así como entender
sus necesidades de información.
FASE 2: Recolección de información. Se estudiaran las diferentes fuentes de
información de la empresa para recolectar aquellos datos que darán
respuestas a las necesidades planteadas en la fase anterior
FASE 3: Procesamiento de datos. En esta fase es donde de integran y cargan
los datos en crudo en un formato utilizable para el análisis. Esta actividad
puede realizarse mediante la creación de una nueva base de datos, agregando
datos a una base de datos ya existente o bien consolidando la información.
FASE 4: Difusión. Finalmente los usuarios a través de una serie de
herramientas podrán explorar los datos de manera sencilla e intuitiva.
1.2.2 Arquitectura de una solución BI
Una solución Business Intelligence parte de los sistemas de origen de una organización
—bases de datos, ERPs, ficheros de texto, entre otros—, sobre los que suele ser
necesario aplicar una transformación estructural para optimizar su proceso analítico.
Para ello se realiza una fase de extracción, transformación y carga (ETL) de datos,
donde se depuran y homogeneizan Esta etapa suele apoyarse en un almacén
intermedio —Operational Data Store— (ODS) que actúa como pasarela entre los
sistemas fuente y los sistemas destino —generalmente un Data Warehouse—, y cuyo
principal objetivo consiste en evitar la saturación de los servidores funcionales de la
organización.
La información resultante, ya unificada, depurada y consolidada, se almacena en un
Data Warehouse (DW) corporativo, que puede servir como base para la construcción
de distintos Datamarts departamentales. Estos Datamarts se caracterizan por poseer la
estructura óptima para el análisis de los datos del área de la organización, ya sea
mediante Bases de Datos Transaccionales (OLTP) o mediante Bases de datos
analíticas (OLAP).
1.3 ¿Qué es un Data Warehouse?
Supóngase que una compañía quiere analizar aquellos países y gama de productos en
los que las ventas vayan excepcionalmente bien. La compañía dispone de una base de
datos transaccional sobre la que operan todas las aplicaciones de la empresa:
producción, venta, facturación, proveedores etc. Lógicamente, de cada venta se
registra la fecha, la cantidad, el comprador y el país de este. Con toda esta información
histórica nos podemos preguntar:
¿Es esta información suficiente para realizar el análisis planteado?
La respuesta hay que buscarla fuera de la base de datos, en el contexto donde se
motiva el análisis. La incorporación de un producto depende de las ventas por
habitantes. Si no tenemos en cuenta la población de cada país, la repuesta al análisis
16
estará sesgada. También puede ocurrir que, dependiendo de la gama del producto, nos
interese información externa verdaderamente específica, como por ejemplo, las horas
de sol anuales de cada país, siendo información valiosa para una compañía de
cosmética: es más difícil vender bronceador en Lituania que en Canarias. Pero este
hecho, que nos parece tan lógico, sólo podrá ser descubierto por herramientas de
Minería de Datos8, si se incorpora información climática de cada país. Con lo cual, cada
organización deberá recoger diferente información que le pueda ser útil para la tarea de
análisis y extracción de conocimiento y en definitiva para la toma de decisiones.
Un Data Warehouse es una base de datos corporativa en la que se integra información
depurada de las diversas fuentes inmersas en la organización o externas a ella, como
se muestra en la Figura 2. Dicha información debe ser homogénea y fiable, se
almacena de forma que permita su análisis desde muy diversas perspectivas, y a su
vez de tiempos de respuestas óptimos.
Figura 2: En un Data Warehouse se integra información de diversas fuentes.
Una de las definiciones más famosas sobre DW, es la de William Harvey Inmon9, que
expone:
“Un Data Warehouse es una colección de datos orientada al negocio, integrada,
variante en el tiempo y no volátil para el soporte del proceso de toma de decisiones de
la gerencia”.
donde en la Tabla 1 se aprecia en profundidad cada una de las características más
detalladas.
8La Minería de Datos consiste en la extracción no trivial de información que reside de manera implícita en los datos.Dicha información era previamente desconocida y podrá resultar útil para algún proceso. En otras palabras, la Mineríade Datos prepara, sondea y explora los datos para sacar la información oculta en ellos.
9 William Harvey Inmon es reconocido por muchos como “ el padre del Data Warehouse”
17
18 Chapter I
Tabla 1: Características de un Data Warehouse
Orientado a temas
Los datos están organizados por temas para facilitar el entendimientopor parte de los usuarios, de forma que todos los datos relativos a unmismo elemento de la vida real queden unidos entre sí. Por ejemplo,todos los datos de un cliente pueden estar consolidados en una mismatabla, todos los datos de los productos en otra y así sucesivamente.
Integrado
La integración implica que todos los datos de diversas fuentes que sonproducidos por distintos departamentos, secciones y aplicaciones, tantointernos como externos, deben ser consolidados en una instancia antesde ser agregados al Data Warehouse, y deben, por lo tanto, seranalizados para asegurar su calidad y limpieza, entre otras cosas.Algunas de las inconsistencias más comunes que nos solemosencontrar son: en nomenclatura, unidades, formato de fechas,..
Histórico (variante
en el tiempo)
Los datos, que pueden ir variando en el tiempo, deben quedar reflejadosde forma que al ser consultados reflejen estos cambios y no se altere larealidad que había en el momento que se almacenaron, evitando así laproblemática que ocurre en los sistemas operacionales, que reflejansolamente el estado de la actividad de negocio presente.
No volátilUna vez almacenada la información en el Data Warehouse debe ser desolo lectura, nunca se modifica ni se elimina, debe ser permanente parafuturas consultas.
1.3.1 Arquitectura de una solución BI con Data Warehouse
En este punto —teniendo en cuenta que ya se han detallado claramente las
características generales del Data Warehouse— se define y describe todos los
componentes que intervienen en su arquitectura o ambiente.
A través de la Figura 3 se explicita la estructura del Data Warehouse.
Figura 3: Estructura de un Data Warehouse
La forma de operar de una solución BI a través de un DW se resume de la siguiente
manera:
1. Los datos son extraídos desde aplicaciones, bases de datos, archivos, etc.
Esta información generalmente reside en diferentes tipos de sistemas,
orígenes y arquitecturas y tienen formatos muy variados.
2. Los datos son integrados, transformados y limpiados, para luego ser cargados
en el Data Warehouse.
18
3. Principalmente, la información del Data Warehouse se estructura en cubos
multidimensionales, ya que estos preparan la información para responder a
consultas dinámicas con un buen rendimiento. Pero también pueden utilizarse
otros tipos de estructuras de datos para representar la información del Data
Warehouse, como por ejemplo Business Models10.
4. Los usuarios acceden a los cubos multidimensionales, Business Models (u otro
tipo de estructura de datos) del Data Warehouse utilizando diversas
herramientas de consulta, exploración, análisis, generación de informes, entre
otras.
A continuación se detalla cada uno de los componentes de la arquitectura del Data
Warehouse, teniendo como referencia la Figura 3, resaltando el tema en concreto que
se vaya tratando.
I.1.3.1.1 OLTP Online Transaction Processing
Figura 4:Online Transaction Procesing
Los sistemas OLTP están diseñados para gestionar un gran número de peticiones
concurrentes sobre sus bases de datos. Están enfocados a que cada operación —
transacción— trabaje con pequeñas cantidades de filas, y a ofrecer una respuesta
rápida. Habitualmente utilizan Sistemas de Bases de Datos Relacionales (SGBDR)
para gestionar los datos y suelen estar altamente normalizados.
OLTP representa toda aquella información transaccional que genera la empresa en su
día a día, además de fuentes externas que puede llegar a disponer.
I.1.3.1.2 Load Manager
Figura 5: Load Manager
10 Business Models describe los fundamentos de cómo una organización crea, entrega y captan valores (económicos,sociales, u otras formas de valor).
19
20 Chapter I
En un Data Warehouse se cargan y unifican periódicamente información procedente de
múltiples fuentes, esto implica que deben existir una serie de procesos que leen los
datos de las diferentes fuentes, los transforman, los adaptan al modelo que se haya
definido, los depuran y limpian para luego introducirlos en el Data Warehouse. Esto es
lo que se conoce como procesos ETL —Procesos de Extracción, Transformación y
Carga o Load.
Figura 6: Proceso ETL
A continuación se detalla cada una de estas etapas, donde se expone cuál es el
proceso que llevan a cabo los ETL y se enumera cuáles son sus principales tareas.
Extracción.- Consiste en extraer los datos desde los sistemas de origen. La
mayoría de los proyectos de almacenamiento de información fusionan datos
provenientes de diferentes sistemas de origen, donde cada sistema puede usar
una organización diferente de los datos o formatos distintos. La extracción los
convierte a un formato preparado para iniciar el proceso de transformación.
Una vez que los datos son seleccionados y extraídos, se guardan en un
almacenamiento intermedio, lo cual permite manipular los datos sin interrumpir
ni paralizar los OLTP ni el Data Warehouse.
Transformación: En estos procesos es preciso asegurar que los datos sean
válidos, íntegros y útiles, lo que suele incluir realizar cálculos y generar nuevos
valores. Los datos deben ser depurados para eliminar inconsistencias,
discrepancias y duplicidades. Los casos más comunes en los que se debe
realizar una transformación son los mostrados en la Tabla 2 .
Tabla 2: Casos más comunes de transformaciones ETL
Codificación
Al integrar varias fuentes de datos puede existir más de unaforma de codificar un atributo en común. Ejemplo: En el camposexo algunos diseñadores definen su valor como “M” y “F” otros“Mujer” y “Hombre”. Se debe escoger una forma común paradecodificar los atributos.
Medida de atributos
Los tipos de unidades de medidas utilizados para representar losatributos de una entidad varían considerablemente entre sí, através de los diferentes OLTP. Por ejemplo, al registrar la longitudde un producto determinado, las unidades de medidas puedenser explicitadas en centímetros, metros, pulgadas, etc. Sedeberán estandarizar las unidades de medidas de los atributos,para que todas las fuentes de datos expresen sus valores deigual manera.
Convenciones de
nombramiento
Usualmente, un mismo atributo es nombrado de diversasmaneras en los diferentes OLTP. Por ejemplo, al referirse alnombre del proveedor, puede hacerse como “nombre”,“razón_social”, “proveedor”. Aquí, se debe utilizar la convenciónde nombramiento que para los usuarios sea más comprensible
Fuentes múltiplesUn mismo elemento puede derivarse desde varias fuentes. Eneste caso, se debe elegir aquella fuente que se considere másfiable y apropiada.
20
Tabla 2: Casos más comunes de transformaciones ETL
Limpieza de datos
Su objetivo principal es el de realizar distintos tipos de accionescontra el mayor número de datos erróneos, inconsistentes,irrelevantes o datos faltantes o Missing Values. Las accionesmás comunes son: ignorarlos, eliminar la columna, filtrar lacolumna, reemplazar valor o filtrar fila errónea
Carga.- Esta función se encarga, por un lado de realizar las tareas
relacionadas con:
o Carga Inicial (Initial Load). Es el proceso de incorporar los datos al
Data Warehouse
o Actualización o mantenimiento periódico. Antes de realizar una nueva
actualización, es necesario identificar si se han producido cambios en
las fuentes originales de los datos recogidos, desde la fecha del último
mantenimiento, a fin de no atentar contra la consistencia del Data
Warehouse.
I.1.3.1.3 Data Warehouse Manager
Figura 7: Data Warehouse Manager
Si bien existen diversas estructuras de datos, a través de las cuales se puede
representar los datos del DW, solamente se entrará en detalle en los cubos
multidimensionales, por considerarse que esta estructura de datos es una de las más
utilizadas.
Un cubo multidimensional o hipercubo, representa o convierte los datos planos que se
encuentran en filas y columnas, en una matriz de N dimensiones.
Los datos se organizan en “hechos”, que tienen unos atributos o medidas que pueden
verse en mayor o menor detalle según ciertas “dimensiones”. Por ejemplo, una cadena
de supermercado puede tener como hechos las ventas. Cada venta tiene unas
medidas: importe, cantidad, número de clientes, etc., y se pueden detallar o agregar
varias dimensiones: tiempo de la venta, producto de la venta, lugar de la venta etc. Es
esclarecedor comprobar que las medidas responden generalmente a la pregunta
“cuánto”, mientras que las dimensiones responderán al “cuanto”,”que”,”donde”, etc.
El modelo dimensional es una adaptación del modelo relacional, con el fin de
optimizarlo para dar una rápida respuesta a las consultas realizadas por los usuarios.
Aunque a nivel físico, una vez implementado en un Sistema Gestor de Bases de Datos
21
22 Chapter I
Relacionales, lo que allí se encuentra son tablas y relaciones entre ellas, a nivel
conceptual conocer que existen dos tipos de tablas en un modelo dimensional:
Tablas de dimensiones.- Definen como están los datos organizados
lógicamente y proveen el medio para analizar el contexto del negocio
Tablas de hechos.- Son datos instantáneos en el tiempo, que son filtrados,
agrupados y explorados a través de condiciones definidas en las tablas de
dimensiones.
Las bases de datos multidimensionales implican tres variantes posibles de modelado,
que permiten realizar consultas orientadas a la toma de decisiones, representados en
los siguientes esquemas:
Esquema en estrellas
Esquema en copo de nieve
Esquema constelación
Estos esquemas pueden ser implementados de diversas maneras que,
independientemente al tipo de arquitectura, requieren que toda la estructura de datos
este desnormalizada o semi desnormalizada, para evitar desarrollar uniones complejas
de acceso a la información, con el fin de agilizar la ejecución de consultas. Los
diferentes tipos de implementación son: relacional, multidimensional e híbrido
A continuación se entra en detalle en los diferentes tipos de tablas —dimensiones y
hechos— indicadas anteriormente, así como las características de un cubo
multidimensional y los diferentes esquemas de modelado de un DW.
Tablas de dimensiones
Las tablas de dimensiones definen como están los datos organizados lógicamente y
proveen el medio para analizar el contexto del negocio. Contienen datos cualitativos.
En la Figura 8 podemos ver varias tablas dimensión con sus correspondientes
atributos.
Figura 8: Tablas de Dimensiones
A veces estos atributos están organizados en jerarquías para describir niveles de
agrupamiento específicos explícitos o implícitos) y, por tanto, las diferentes
granularidades o niveles de detalle en la visión de los datos. Las jerarquías forman
distintos niveles, relacionados entre sí, y son utilizados para realizar operaciones
de agrupamiento. Por ejemplo la jerarquía correspondiente a la dimensión tiempo
podría estar formada por los atributos Año, Mes y Día. Los diferentes tipos de
22
jerarquías que se pueden establecer para describir niveles de agrupamiento
específicos se pueden observar en la Figura 9 y se describen en la Tabla 3.
Figura 9: Esquema de organización jerárquica de las dimensiones
Tabla 3: Organización jerárquica de las dimensiones
Dimensiones
degeneradas
Este término hace referencia a un campo que será utilizado como criterio de análisis yque es almacenado en la tabla de hechos.Esto sucede cuando un campo que se utiliza como criterio de análisis posee el mismonivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no sepueden realizar agrupaciones o sumarizaciones a través de este campo, como porejemplo "números de orden", "números de ticket", "números de transacción", etc.
Atributos no
dimensión
Los niveles de la jerarquía también pueden tener atributos descriptivos, donde no sonutilizados para formar niveles de jerarquía, sino para describir detalles en los mismos,como por ejemplo, el número de teléfono, la dirección de correo electrónico, etc.
JerárquicasDescriben diferentes niveles de agrupamiento específicos —explícitos o implícitos— y,por lo tanto, las diferentes granularidades o niveles de detalle en la visión de los datos,como por ejemplo la jerarquía formada por Año, Trimestre, Mes y Día
En las tablas dimensiones, habitualmente no es posible utilizar la clave de negocio —
business key— como clave principal —primary key— e incluso, en el caso que sea
posible, no es aconsejable por temas de rendimiento, ya que desde este punto de vista
es recomendable utilizar número enteros de pocos bytes. Si en un sistema
transaccional tenemos, por ejemplo, una clave principal con dominio char(10), siempre
será más óptimo utilizar un tipo de datos numérico de menos byte como clave principal
en las tablas dimensiones. Se sustituirán las habituales clave de negocio por claves
subrogadas —subrogate key— las cuales serán de tipo numérico y habitualmente
autoincremental. Esta clave no tiene sentido a nivel de negocio, pero la necesitamos
para identificar de forma única cada una de las filas.
Un concepto importante dentro de este apartado son las dimensiones lentamente
cambiantes o Slowly Changing Dimensions (SCD). Son dimensiones en las cuales sus
datos tienden a modificarse a través del tiempo, ya sea de forma ocasional o constante,
o implique a un solo registro o a la tabla completa. Cuando ocurren estos cambios, se
puede optar por seguir alguna de estas dos grandes opciones:
Registrar el historial de cambios.
Reemplazar los valores que sean necesarios.
23
24 Chapter I
Inicialmente Ralph Kimball11 planteó tres estrategias a seguir cuando se tratan las SCD:
tipo 1, tipo 2 y tipo 3, pero, a través de los años, la comunidad de personas que se
encargaba de modelar bases de datos profundizó las definiciones iniciales e incluyó
varios tipos SCD más, como tipo 4 y tipo 6. A continuación se detalla cada tipo de
estrategia SCD:
SCD Tipo 1: Sobreescribir.
SCD Tipo 2: Añadir fila.
SCD Tipo 3: Añadir columna.
SCD Tipo 4: Tabla de Historia separada.
SCD Tipo 6: Híbrido.
De acuerdo a la naturaleza del cambio se debe seleccionar qué Tipo SCD se utilizará y,
en algunos casos, resultará conveniente combinar varias técnicas.
Tablas de Hechos
Las tablas de hechos representan un proceso de negocio, como por ejemplo, las
ventas, las compras, los pagos entre otras. Estas tablas son utilizadas por los analistas
de negocio para apoyar el proceso de toma de decisiones. Contienen datos
cuantitativos.
Los hechos son datos instantáneos en el tiempo, que son filtrados, agrupados y
explorados a través de condiciones definidas en las tablas de dimensiones. El registro
de hecho posee una clave primaria que está compuesta por las claves primarias de las
tablas de dimensiones relacionadas a este.
Figura 10: Tabla de hecho “Ventas”
En la Figura 10 se aprecia la tabla de hechos “VENTAS” ubicada en el centro y
conectada a ella, mediante sus claves primarias, se encuentran las tablas de
dimensiones “CLIENTES”, “PRODUCTOS” y “FECHAS”. Es por ello que la clave
primaria de la tabla de hechos es la combinación de las claves primarias de sus
dimensiones. Los hechos en este caso son “ImporteTotal” y “Utilidad”.
11 Ralph Kimball reconocido como uno de los padres del concepto de Datawarehouse, se ha dedicado desde hace yamás de 10 años al desarrollo de su metodología para que este concepto sea bien aplicado en las organizaciones y seasegure la calidad en el desarrollo de estos proyectos.
24
Es importante a la hora de diseñar una tabla de hechos, tener en cuenta el nivel de
granularidad que va a tener, es decir, el nivel de detalle más atómico que vamos a
encontrar de los datos: no es lo mismo tener una fila por cada venta, que una fila donde
se indiquen las ventas del día para cada artículo y tienda.
Existen dos tipos de hechos:
Hechos básicos.- Se encuentran representados por un campo de una tabla de
hechos. Los campos “precio” y “cantidad” de la Figura 11 son hechos básicos.
Hechos derivado.-: Se forman al combinar uno o más hechos con alguna
operación matemática o lógica y que también residen en una tabla de hechos.
El campo “total” de la Figura 11 es un hecho derivado, ya que se conforma de
la siguiente manera: total = precio * cantidad.
Figura 11: Hechos Básicos y Derivados
Otro concepto importante a tener en cuenta es la agregación, proceso por el cual se
resumen los datos a partir de las filas de detalle de máxima granularidad.
Cubo Multidimensional
Como se ha comentado, si bien existen diversas estructuras de datos, a través de las
cuales se puede representar los datos del DW, solamente se entrará en detalle en los
cubos multidimensionales.
Los objetos más importantes que se pueden incluir en un cubo multidimensional son
los siguientes:
Indicadores.- Sumarizaciones que se efectúan sobre algún hecho o
expresiones pertenecientes a una tabla de hechos.
Atributos de dimensión.- Campos o criterios de análisis, pertenecientes a tablas
de dimensiones.
Jerarquías de dimensiones.- Representa una relación lógica entre dos o más
atributos.
Se puede observar, que el resultado del análisis está dado por los cruces matriciales de
acuerdo a los valores de las dimensiones seleccionadas.
Más específicamente, para acceder a los datos del Data Warehouse, se pueden
ejecutar consultas sobre algún cubo multidimensional previamente definido. Dicho cubo
debe incluir, entre otros objetos, indicadores, atributos y jerarquías basados en los
campos de las tablas de dimensiones y de hechos que se deseen analizar. De esta
manera, las consultas se responden con un alto rendimiento, minimizando al máximo el
25
26 Chapter I
tiempo que hubiese incurrido en realizar dicha consulta sobre una base de datos
transaccional.
Como ejemplo, en la Figura 12 se representa un cubo tridimensional donde las
dimensiones producto, lugar y tiempo se han agregado por artículo, ciudad y trimestre.
La representación de un hecho corresponde a una casilla de dicho cubo, el valor de la
casilla es la medida observada, importe de ventas, concretamente el hecho que se
observa en dicha figura muestra que “el primer trimestre de 2004 la empresa vendió en
Valencia por un importe de 22.00 euros el producto Androbio 33cl”
Figura 12: Ejemplo cubo multidimensional
Resaltar que un cubo no es más que una base de datos multidimensional, en la cual el
almacenamiento físico de los datos se realiza en un vector multidimensional.
Indicadores de rendimiento clave o KPI
Los indicadores de rendimiento clave (KPI) son métricas financieras o no, utilizadas
para cuantificar objetivos que reflejan el rendimiento de una organización,
recogiéndose generalmente en su plan estratégico. Estos indicadores son utilizados en
BI para asistir o ayudar, al estado actual de un negocio, a prescribir una línea de acción
futura. Los indicadores de rendimiento son frecuentemente utilizados para "valorar"
actividades complicadas de medir como los beneficios de desarrollos líderes, eficiencia
de empleados, servicio o satisfacción de un cliente.
Los KPIs deberían preferiblemente cumplir los siguientes criterios esenciales (SMART):
eSpecificos (Specific)
Medibles (Measurable)
Alcanzables (Achievable)
Realista (Realistic)
a Tiempo (Timely)
Atributos
Los atributos constituyen los criterios que se utilizan para analizar los indicadores
dentro de un cubo multidimensional. Los mismos se basan, en su gran mayoría, en los
campos de las tablas de dimensiones y/o expresiones. Dentro de un cubo
multidimensional, los atributos son los ejes del mismo.
26
Jerarquías
Como se comentó en el apartado Data Warehouse Manager de tablas de dimensión,
una jerarquía representa una relación lógica entre dos o más atributos pertenecientes a
un cubo multidimensional. Pueden existir varias en un mismo cubo.
La principal ventaja de manejar jerarquías, reside en poder analizar los datos desde su
nivel más general al más detallado y viceversa, al desplazarse por los diferentes
niveles.
Figura 13: Jerarquía fecha
Esquemas de modelado de un Data Warehouse
Los tipos de esquemas de modelado de un Data Warehouse son los siguientes:
Esquema en estrella.- Consta de una tabla de hechos central y de varias tablas
de dimensiones relacionadas a esta por sus claves. Este modelo debe estar
totalmente desnormalizado. En la Figura 14 se puede apreciar un esquema en
estrella.
Figura 14: Esquema en estrella
Esquema en copo de nieve.- Es una estructura algo más compleja que el
esquema en estrella. Se da cuando alguna de las dimensiones se implementa
con más de una tabla de datos y/o estas se organizan en jerarquías de
dimensiones. La Figura 15 muestra un ejemplo de esquema en copo de nieve.
27
28 Chapter I
Figura 15: Esquema en copo de nieve
Esquema constelación.- Está compuesto por una serie de esquemas en
estrellas, tal como se puede apreciar en Figura 16 No es necesario que las
diferentes tablas de hechos compartan las mismas dimensiones.
Figura 16: Esquema en constelación
En la Tabla 4 se puede observar un resumen comparativo de ambos esquema.
Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse
Modelo Ventajas Inconvenientes
Estrella
La desnormalización permite obviaruniones —Join— entre las tablascuando se realizan consultas,procurando así un mejor tiempo derespuesta y una mayor sencillez conrespecto a su utilización
Más simple de interpretar
Optimiza los tiempos de respuesta ante las consultas
La desnormalización con la que cuentagenera un cierto grado de redundancia
Necesidad de mayor espacio dealmacenamiento
Menos robusto para la carga
Es el más lento de construir
Copo de nieve
Posibilidad de segregar los datos delas tablas de dimensiones y proveer unesquema que sustente losrequerimientos de diseño.
Muy flexible y puede implementarsedespués de que se haya desarrolladoun esquema en estrella.
Hace una mejor utilización del espacio.
Puede desarrollar clases de jerarquíasfuera de las tablas de dimensiones,que permiten realizar análisis de logeneral a lo detallado y viceversa.
Si se poseen múltiples tablas dedimensiones, cada una de ellas convarias jerarquías, se creará un númerode tablas bastante considerable, quepueden llegar al punto de serinmanejables
Al existir muchas uniones y relaciones entre tablas, el desempeño puede verse reducido
La existencia de las diferentes jerarquíasde dimensiones debe estar bienfundamentada, ya que de otro modo lasconsultas demorarán más tiempo en
28
Tabla 4: Resumen comparativo de los tipos de modelos de un Data Warehouse
devolver los resultados, debido a que sedeben realizar las uniones entre lastablas.
Constelación
Permite tener más de una tabla dehechos, por lo cual se podrán analizarmás aspectos claves del negocio conun mínimo esfuerzo adicional dediseño.
Contribuye a la reutilización de lastablas de dimensiones, ya que unamisma tabla de dimensión puedeutilizarse para varias tablas de hechos.
No es soportado por todas las herramientas de consulta y análisis
Data Warehouse vs OLTP
Debido a que, ya se han explicado y caracterizado los distintos tipos de esquemas del
DW, se procederá a exponer las razones de su utilización, como también las causas de
por qué no se emplean simplemente las estructuras de las bases de datos
tradicionales. Esta comparación se puede ver en la Tabla 5.
Tabla 5: OTLP VS Data Warehouse
OLTP Data Warehouse
ObjetivoSoportar actividades transaccionales
Consultar y analizar información estratégica y táctica
Tiempo de datos Operacionales Para la toma de decisiones
Modelo de datos Normalizado Desnormalizado
Consulta SQL SQL más extensiones
Datos consultados 60-90 días 5-10 años
Tipos de consultas Repetitivas, predefinidas No previsibles, dinámicas
Nivel de almacenamiento Nivel de detalleNivel de detalle y diferentes niveles de sumarización
Acciones disponibles Alta, baja, modificación y consulta Carga y consulta
Número de transacciones Elevado Medio o bajo
Tamaño Pequeño-Mediano Grande
Tiempo de respuesta Pequeño Variable
Orientación Orientado a las aplicaciones Orientado al negocio
Sello de tiempoLa clave puede o no tener un elemento de tiempo
La clave tiene un elemento de tiempo
Estructura Generalmente estableGeneralmente varía de acuerdo a su propia evolución y utilización
29
30 Chapter I
Implementación de un Data Warehouse
Los distintos tipos de implementación de un Data Warehouse son los siguientes:
1. Implementación ROLAP (Procesamiento Analítico Online Relacional).- Se trata de
sistemas y herramientas OLAP (Online Analytic Processing) construidos sobre una
base de datos relacional. Típicamente, los datos son detallados, evitando las
agregaciones, y las tablas se encuentran normalizadas. Los esquemas más
comunes sobre los que se trabaja son estrella o copo de nieve, aunque es posible
trabajar sobre cualquier base de datos relacional. La arquitectura está compuesta
por un servidor de banco de datos relacional y el motor OLAP se encuentra en un
servidor dedicado. La principal ventaja de esta arquitectura es que permite el
análisis de una enorme cantidad de datos.
2. Implementación MOLAP (Multidimensional Online Analytical Processing o
'Procesamiento Analítico Multidimensional en línea'). Se trata de una alternativa a
la tecnología ROLAP (OLAP-Relacional). Aunque ambos tipos de herramientas
están diseñadas para realizar análisis de datos a través de un modelo de datos
multidimensional, MOLAP se diferencia significativamente en que requiere un
preprocesamiento y almacenamiento de la información contenida en el cubo OLAP.
MOLAP almacena estos datos en una matriz de almacenamiento multidimensional
optimizada, más que en una base de datos relacional (o en un ROLAP). Para
optimizar los tiempos de respuesta, el resumen de la información es usualmente
calculado por adelantado. Estos valores precalculados o agregaciones son la base
de las ganancias de desempeño de este sistema. Algunos sistemas utilizan
técnicas de compresión de datos para disminuir el espacio de almacenamiento en
disco debido a los valores precalculados.
3. Implementación HOLAP (Hybrid Online Analytical Process o Procesamiento
Analítico en línea Híbrido). Es una combinación de ROLAP y MOLAP. HOLAP
permite almacenar una parte de los datos como en un sistema MOLAP y el resto
como en uno ROLAP. El grado de control que el operador de la aplicación tiene
sobre este particionamiento varía de unos productos a otros.
I.1.3.1.4 Query Manager
Figura 17: Query Manager
Este componente realiza las operaciones necesarias para soportar los procesos de
gestión y ejecución de consultas relacionales y de consultas propias de análisis de
30
datos, es decir, Query Manager recibe las consultas de los usuarios, las aplica a la
estructura de datos correspondiente —cubo multidimensional, Business Models, etc..—
y devuelve los resultados obtenidos.
Cabe aclarar que una consulta a un DW, generalmente consiste en la obtención de
indicadores a partir de los datos —hechos— de una tabla de hechos, restringidas por
las propiedades o condiciones de los atributos que hayan sido creados.
El procesamiento analítico en línea OLAP, es la componente más poderosa de un Data
Warehouse, ya que es el motor de consultas especializadas del Data Warehouse. Las
herramientas OLAP, son una tecnología de software para análisis en línea,
administración y ejecución de consultas, que permiten inferir información del
comportamiento del negocio.
Su principal objetivo es el de brindar rápidas respuestas a complejas preguntas, para
interpretar la situación del negocio y tomar decisiones. Cabe destacar que lo que es
realmente interesante en OLAP, no es la ejecución de simples consultas tradicionales,
sino la posibilidad de utilizar operadores, como se muestran en la Tabla 6, que permitan
profundizar en la información.
Tabla 6: Operaciones definidas dentro de un Data Warehouse
Drill-downPermite apreciar los datos en un mayor detalle, bajando por una jerarquíadefinida en un cubo. Esto brinda la posibilidad de introducir un nuevo nivel ocriterio de agregación en el análisis, disgregando los grupos actuales
Drill-upPermite apreciar los datos en menor nivel de detalle, subiendo por una jerarquíadefinida en un cubo. Esto brinda la posibilidad de quitar un nivel o criterio deagregación en el análisis, agregando los grupos actuales.
Drill-acros Funciona de forma similar a drill-down, con la diferencia que drill-across no serealiza sobre una jerarquía, sino que su forma es ir de lo general a lo específico,agregando un atributo a la consulta como nuevo criterio de análisis.
Roll-across
Funciona de forma similar a drill-up, con la diferencia que roll-across no se hacesobre una jerarquía, sino que su forma de ir de lo específico a lo general esquitar un atributo de la consulta, eliminando de esta manera un criterio deanálisis.
Drill-throughPermite apreciar los datos en su máximo nivel de detalle. Esto brinda laposibilidad de analizar cuáles son los datos relacionados al valor de unIndicador, que se ha sumarizado dentro del cubo multidimensional.
I.1.3.1.5 Herramienta de consulta y análisis
31
32 Chapter I
Figura 18: Herramienta de consulta y análisis
Las Herramienta de Consulta y Análisis son sistemas que permiten a los usuarios
realizar la exploración de datos del Data Warehouse, constituyendo la unión entre el
Data Warehouse y los usuarios.
A través de una interfaz gráfica y una serie de pasos, los usuarios generan consultas
que son enviadas desde la Herramienta de Consulta y Análisis al Data Warehouse,
devolviendo los resultados obtenidos a la herramienta que se los solicitó. Luego estos
resultados son expuestos antes los usuarios en formatos que le sean familiares.
Algunas de las interfaces a través de las cuales podemos representar los resultados de
las consultas pueden ser: Cuadros de mando12
Informes estáticos13
Informes dinámicos
I.1.3.1.5.1 Usuarios
Figura 19: Usuarios
Los usuarios que posee el Data Warehouse son aquellos que se encargan de tomar
decisiones y de planificar las actividades del negocio, es por ello que se hace tanto
énfasis en la integración, limpieza de datos, etc, para poder conseguir que la
información posea toda la calidad posible.
Es a través de las herramientas de consulta y análisis, que los usuarios exploran los
datos en busca de respuestas para poder tomar decisiones proactivas. La diferencia
entre un usuario OLTP y otro Data Warehouse se ven reflejadas en la Tabla 7.
12 Los cuadros de mandos se pueden entender como una colección de informes, consultas y análisisinteractivos que hacen referencia a un tema en particular y que están relacionados entre sí.
13 La elección de uno u otro tipo de informe dependerá fundamentalmente del uso que se pretenda dar adichos informes.
32
Tabla 7: Usuarios OLTP vs usuarios Data Warehouse
Usuarios OLTP Usuarios Data Warehouse
Acceso concurrente Muchos Pocos
Tipo de consultas PredefinidasComplejas, no predecibles y noanticipadas
Registros consultados Pocos Muchos
Tiempo de respuesta Crítico No crítico
Acciones permitidasAgregar, modificar,eliminar y consultar
Consultar
I.1.3.1.6 Conceptos complementarios: Datamarts
Un Datamarts (DM) es una versión especial del Data Warehouse. Son subconjuntos de
datos con el propósito de ayudar a que un área específica dentro del negocio pueda
tomar mejores decisiones. Los datos existentes en este contexto pueden ser
agrupados, explorados y propagados de múltiples formas para que diversos grupos de
usuarios realicen la explotación de los mismos de la forma más conveniente según sus
necesidades.
En síntesis, se puede decir que los Datamarts son pequeños Data Warehouse
centrados en un tema o un área de negocio específico dentro de una organización.
Por ejemplo la información de personal de una empresa —empleados, departamento,
proyectos— es difícilmente integrable en un mismo modelo de estrella de ventas.
Incluso en ámbitos más relacionados de una organización, ventas y producción no
resulta fácil. La solución está en que para cada subámbito de la organización se va a
construir una estructura en estrella. Por tanto, el Data Warehouse estará formado por
muchas estrellas, cada una de estas estrellas es un Datamarts. Lógicamente cada
Datamart tendrá unas medidas y dimensiones propias y diferentes de los demás, la
única dimensión que suele aparecer en todos los Datamarts es la dimensión tiempo, ya
que el Data Warehouse representa información histórica.
Figura 20: Datamarts
33
34 Chapter I
Capítulo 2. ITOP Management Consulting
Resumen:
ITOP MC es una empresa de consultaría de Negocios y Gestión Empresarial con la que se
ha colaborado en la consecución de este proyecto. En términos BI, la empresa ITOP
desempeña el papel de Product Owner.
2.1 La empresa
ITOP Management Consulting (ITOP MC) es una empresa experta en Consultoría de
Negocios y Gestión Empresarial, especializada en Tecnologías de la Información, que
ofrece sus servicios de gestión global a las PYMEs, colaborando con una red sólida de
partners y con compañías punteras pertenecientes al sector informático y empresarial.
ITOP Management Consulting nace en el año 2006 como una iniciativa de varios
socios con más de 10 años de experiencia en el mundo de la Consultoría de
Tecnologías de la Información. El objetivo principal de la creación de esta consultora es
ofrecer a la empresa canaria un servicio local de calidad en este terreno de la
consultoría cuya demanda y dependencia de empresas de la península es muy
grande y ofrecer una oportunidad al consultor que, habiendo desarrollado su carrera
fuera de las islas, quiera volver a ellas pero con el condicionante de encontrar una
empresa en la que pueda seguir evolucionando de forma profesional, y en unas
condiciones similares a las empresas en las que ha estado trabajando.
La experiencia de los socios actuales se ha desarrollado en empresas de gran prestigio
y experiencia dentro del sector de la consultoría a nivel nacional e internacional tales
como: CSC, Indra, Unisys, Realtech, SAP, etc.
Alguno de los clientes con los que se ha trabajado en diferentes proyectos han sido:
Repsol, Telefónica, Bayer, GlaxoWellcome, ICEX, Turespaña y un largo etcétera.
2.2 Filosofía
La integración horizontal que pretende ITOP con todos sus clientes hace que éstos
evolucionen hacia el concepto de socios-clientes. La empresa es consciente de que
tiene mucho que aportar en el crecimiento de sus clientes, al igual que ellos les facilitan
la energía necesaria para seguir creciendo e invirtiendo en ideas. La filosofía de la
empresa queda reflejada en el nombre ITOP —Información, Tecnología, Organización,
Procesos.
34
2.3 Alianzas
Las principales alianzas y áreas de experiencia del equipo de ITOP MC son:
• HP
• Microsoft
• SAP
SAP Business One
SAP R/3
35
36 Chapter I
Capítulo 3. Descripción del problema e integración de soluciones tecnológicas
Resumen:
En este capítulo se describe el estudio realizado a lo largo del proyecto para la elección de
las tecnologías por las que se iban a apostar para la construcción de una solución BI.
3.1 Introducción
Sap Business One (Sap BO) es una única aplicación de gestión empresarial integrada
integra todas las funciones empresariales básicas necesarias en cualquier empresa
(incluye gestión financiera, ventas, gestión de atención al cliente, e-commerce, gestión
de inventarios y operaciones).
El problema a abordar consiste en integrar SAP BO con una solución BI, de forma que
proporcione a las Pymes informes gráficos y cuadros de mando interactivos que
ofrezcan una mayor versatilidad, control de los ingresos, los márgenes y la liquidez.
Con esta aplicación de BI, se ofrece funcionalidades para la gestión del conocimiento
que ayudan a las empresas a poner en contacto a "aquellos que saben" con "aquellos
que necesitan saber".
3.2 Análisis funcional y elección
En este capítulo se describe el estudio realizado a lo largo del proyecto para la elección
de las tecnologías por las que se iban a apostar para la construcción de una solución
BI.
3.2.1 Análisis Inicial
La evolución del Business Intelligence (BI) durante los últimos 10 años ha sido muy
interesante, sobre todo en la manera en cómo se han simplificado el desarrollo e
implantación de proyectos de este tipo, gracias a las tecnologías que han sabido
adaptarse a las necesidades de los usuarios, tanto de perfil desarrollador como
usuarios finales.
En el año 1998 el esfuerzo era realmente muy grande para poder plasmar en un
informe las necesidades del usuario final, con el fin de que pudiera realizar un
monitoreo y análisis de la información. En aquel momento las herramientas eran algo
primitivas, en cuanto a la presentación de los datos y al desarrollo de las mismas,
36
teniendo muchas restricciones de formatos en los que se podía mostrar la información.
En consecuencia, se tenían que implementar desarrollos adicionales con el objetivo de
complementar las herramientas de BI existentes. El escenario típico era el desarrollo
en Visual Basic; con este lenguaje se creaba una aplicación de presentación enfocada
a un ambiente más ejecutivo, amigable, permitiéndoles a los usuarios finales de la
herramienta de BI realizar un análisis con el ya famoso término "Drill Down", que en
aquellos tiempos era lo último en tecnología14.
Con el tiempo la historia fue cambiando y ahora existen innumerables tecnologías para
llevar a cabo una solución BI, tanto con herramientas propietarias como con
OpenSource, cuyas dos vertientes también fueron analizadas en este proyecto.
I.3.2.1.1 Análisis de una solución BI con Software privativo.
Por la parte del Software privativo se encontró que existían muchas empresas
dedicadas a desarrollar software que facilita el desarrollo de una solución BI. Para
conocer cuáles de ellas eran las líderes se procedió al estudio del cuadrante de
Gartner del año 2010. Gartner es una empresa consultora, la cual realiza y publica una
serie de análisis, de las más fiables referencias, para conocer el estado y nivel de
madurez de los proveedores de BI más influyentes de la actualidad. En la Figura 21
muestra el análisis de Gartner del 2010:
En el eje X “completeness of visión” se representa el conocimiento de los
proveedores indicando cómo se puede aprovechar el momento actual del
mercado para generar valor, tanto para sus clientes como para ellos mismos.
En el eje Y “ability to execute” trata de querer medir la habilidad de los
proveedores para ejecutar con éxito su visión del mercado.
14 The Datawarehouse Toolkit de Ralph Kimball
37
38 Chapter I
Figura 21: Cuadrante de Gartner BI 2010
Estos dos baremos dividen al cuadrante en cuatro sectores en donde se clasifican los
proveedores estudiados.
Leaders: Esta categoría, en principio, es la mejor. Situarse aquí significa haber
puntuado alto en los dos ejes de medidas, por lo que se puede esperar de
estos proveedores una solución de productos amplia, completa y madura, que
evoluciona según demanda el mercado. Por otra parte también nos sugiere
que el proveedor goza de buena salud como empresa y que dispone de
medios suficientes para implantar con éxito su solución en variados escenarios.
Visionaries: En esta categoría entrarían aquellos proveedores con una buena
puntuación en “completeness of visión” pero peor puntuación en “ability to
execute”. Por lo tanto aquí estarán las empresas con una fuerte y acertada
visión del mercado actual en Business Intelligence. Sin embargo, a pesar de
sus buenas ideas, aún puede que no tengan la capacidad para llevar
implantaciones, bien sea por su tamaño o por otras circunstancias.
Challengers: Este es el caso contrario al de los Visionaries. Se trata de
proveedores bien posicionados y que ofrecen altas posibilidades de éxito a la
hora de implantar su solución. No obstante, suelen ofrecer poca variedad de
productos, o directamente centrarse en un único aspecto de lo que demanda el
mercado. También puede ocurrir que se trate de un déficit en su canal de
ventas o presencia geográfica.
Niche Players: La última categoría en principio es la más desfavorable. Son
proveedores que no llegan a puntuar lo suficiente en ninguna categoría como
para alcanzar uno de los otros cuadrantes. No obstante, no significa que por
ello sus soluciones no tengan calidad. Por otra parte, la falta de puntuación en
“completeness of visión” nos da una idea de que estos proveedores no están
38
evolucionando sus soluciones suficientemente rápido y de alguna manera
están perdiendo parte de la perspectiva.
Una vez visto que representan las diferentes áreas del cuadrante de Gartner, se
analiza como Oracle y Microsoft, consolidadas en el año 2010 como las empresas
líderes en producto BI, son las mejores por lo cual se decide apostar por Microsoft
como una opción muy interesante para desarrollar este proyecto —destacar además
que la empresa ITOP MC ya poseía una serie de licencias por lo que no habría que
realizar una nueva inversión a priori.
Para poder implantar una solución BI usando tecnologías de Microsoft es necesario los
requerimientos que se muestran en la Tabla 8, resumidos en la Figura 22.
Tabla 8: Requerimientos tecnológicos básicos para una solución BI con Microsoft
Requerimientos de Software ¿Qué solución necesitamos? ¿Qué nos aporta?
Sistema Operativo Windows 2008 R2 64bits
Conexiones remotas, trabajo
concurrente y Sistema Operativo
Windows convencional
Servidor de Integración dedatos
SQL Server 2008 R2 Integration
Services (SSIS)
Servidor para realizar y planificar el
proceso de Extracción,
Transformación y Carga de los
datos de origen
Servidor de Base de datosAnalista o OLAP
SQL Server 2008 R2 Analisys
Servicies (SSAS)
Análisis y optimización de los datos
almacenados en el DW
Sistema gestor de base dedatos SQL Server 2008 R2 64bits
Gestión y creación de almacén de
datos
Servidor de InformesSQL Server 2008 R2 Reporting
Services (SSRS)
Representación de informes
alimentados desde un Cubo OLAP
Cuadros de mando
Crystal Xcelsius 2008 (No
pertenece a Microsoft pero está
totalmente integrada, con
cualquier producto de esa
empresa)
Cuadros de mando dinámicos
basados en Flash, exportables a
Excel, PDF, etc.
SharePoint Foundation 2010 +
Performance Point
Diseñador de cuadro de mando
integrables en los portales Web
corporativos Share Point
Silverlight 4.0Cuadros de mando dinámicos y con
conexión directa al cubo OLAP
Microsoft Office Excel 2007 +
Power Pivot
Tablas y cuadros de mando
dinámicos con conexión directa a los
cubos OLAP
39
40 Chapter I
Figura 22: Solución tecnológica propuesta para una solución BI usando herramientas Microsoft
Se realizó además una comparación de las características que nos aporta cada una de
las herramientas de presentación y cuadros de mando, indicada en la Tabla 9. Con
respecto a la parte de Sistema Gestor de Bases de Datos y Sistema Operativo se parte
del punto que los clientes, a los que se les quieres implantar la solución BI, ya tienen
disponibles el software necesario derivado de la contratación ERP SAP BO, así como
el deseo por parte de ITOP MC de la importancia del uso de Share Point para tener
acceso, tanto externo como interno, a sus cuadros de mando por parte de sus clientes
desde cualquier parte y dispositivo.
Tabla 9: Tabla comparativa del Software de representación
SSRSCrystal
XcelsiusPerformance
PointSilverlight
MicrosoftExcel
PublicaciónSharePoint
Característicasinteractivas
Programables (SDK)
Interfaz Amigable
Integración conSAP
Publicables enWeb
40
Tabla 9: Tabla comparativa del Software de representación
SSRSCrystal
XcelsiusPerformance
PointSilverlight
MicrosoftExcel
Facilidad de uso
Costo de licenciaaceptable
Valoración final
En mayor o menor medida las cuatro herramientas se ajustan a las necesidades por
tanto se escogieron dos y el resto quedaron estudiadas para futuros proyectos:
Generación de informes: SSRS y Microsoft Excel
Creación de cuadros de mando: Microsoft Excel y Cristal Xcelsius
I.3.2.1.2 Análisis de una solución BI con Open Source.
En cuanto al estudio que se realizó por la vertiente del Open Source se escogió la
solución BI mejor valorada: Pentaho.
La plataforma Open Source Pentaho Business Intelligence cubre muy amplias
necesidades de Análisis de los Datos y de presentación de información empresarial.
Las soluciones de Pentaho están escritas en Java y tienen un ambiente de
implementación también basado en IDE Eclipse. Eso hace de Pentaho una solución
muy flexible para cubrir una amplia gama de necesidades empresariales —tanto las
típicas como las sofisticadas y especificas al negocio.
La Figura 23 muestra un esquema de la estructura de Pentaho.
Figura 23: Estructura de la solución de Pentaho
Los módulos de la plataforma Pentaho BI son:
41
42 Chapter I
Reporting.- Módulo de informes que ofrece la solución adecuada a las
necesidades de los usuarios. Pentaho Reporting es una solución basada en el
proyecto JFreeReport y permite generar informes ágil y de gran capacidad.
Pentaho Reporting permite la distribución de los resultados del análisis en
múltiples formatos —todos los informes incluyen la opción de imprimir o
exportar a formato PDF, XLS, HTML y texto—, además de admitir
programación de tareas y ejecución automática de informes con una
determinada periodicidad.
Análisis.- Pentaho Análisis suministra a los usuarios un sistema avanzado de
análisis de información, con uso de las tablas dinámicas —pivot tables,
crosstabs—, generadas por Mondrian y JPivot. El usuario puede navegar por
los datos, ajustando la visión de los mismos, los filtros de visualización,
añadiendo o quitando los campos de agregación. Los datos pueden ser
representados en una forma de SVG o Flash, los dashboards widgets, o
también integrados con los sistemas de Minería de Datos y los portales web o
portlets. Además, con Microsoft Excel Analysis Services, se puede analizar los
datos dinámicos en Microsoft Excel —usando la conexión a OLAP server
Mondrian.
Portal de BI: En este portal web se publica toda la información recolectada en
los procesos de análisis.
Dashboards.- Todos los componentes del módulo Pentaho Reporting y
Pentaho Análisis pueden formar parte de un Dashboard. En Pentaho
Dashboards es muy fácil incorporar una gran variedad en tipos de gráficos,
tablas y velocímetros —Dashboard widgets— e integrarlos con los Portlets
JSP, en donde podrá visualizar informes, gráficos y análisis OLAP. Así como
una librería de código abierto integrada en el Portal de BI que nos proporciona
Pentaho denominada CDF (Community Dashboard Framework).
Data Mining.- Minería de datos se realiza con una herramienta WeKa.
Integración de Datos.- Se realiza con una herramienta Kettle ETL (Pentaho
Data Integration) que permite implementar los procesos ETL. Últimamente
Pentaho lanzó una nueva versión PDI 3.0, que marcó un gran paso adelante
en OSBI ETL y que hizo Pentaho Data Integration una alternativa interesante
para las herramientas comerciales.
3.2.2 Conclusión
Una vez estudiada la vertiente del software privativo y Open Source se procedió a
comparar y decidir por cual se va optar para desarrollar el proyecto. Resaltar que
ambas herramientas fueron instaladas y testeadas antes de su selección. Para más
detalle mirar la Tabla 10.
42
Tabla 10: Tabla comparativa Pentaho vs Microsoft
Pentaho Microsoft
Documentación
Integración con otras herramientas Sólo especificas
Posibilidad de añadir funcionalidades
Integrables con SharePoint
Facilidad para implementar cuadros de
mando
con el uso de
herramientas externas
Coste de Licencias
Curva de aprendizaje
Multiplataforma. Múltiple sistema de
BBDD
Valoración final
Finalmente se decidió decantarse por la solución propuesta por Microsoft debido a los
siguientes motivos:
Documentación más homogénea, sólida y abundante.
Mayor bibliografía que Pentaho, quizás porque esta última utiliza herramientas
muy heterogéneas entre sí, no siguen un mismo patrón de desarrollo, están en
constante cambios y son desarrolladas por diferentes organizaciones15.
Menor curva de aprendizaje.
Mayor facilidad de desarrollo.
La versión libre de Pentaho tiene elementos muy básicos que conlleva un
esfuerzo adicional de instalación y configuración adicional
ITOP MC, así como sus clientes, ya poseían la licencia de Microsoft SQL
Server 2008 Standard y se quería aprovechar esta opción.
3.3 Descripción del problema
Finalmente, después de haber decidido cuál era la tecnología que se iba a usar para
implementar la solución BI con el fin de integrarla con SAP BO, se procede a definir el
problema al que en este trabajo se le da solución.
15 A fecha 07 de julio de 2011 en la búsqueda realiza de bibliografía sobre Pentaho fue escaso encontrar libros querealmente entren en profundidad en cómo llevar a cabo un desarrollo completo de BI con Pentaho, ya que lo normal fueencontrar bibliografía centrada en las herramientas de ETL y de Reporting.
43
44 Chapter I
Se quiere implantar una solución Business Intelligence en SAP BO de manera que el
cliente que posea esta aplicación pueda explotar y visualizar los datos, de tal forma que
sea una herramienta que recoja periódicamente los datos claves de su empresa,
convirtiéndose en un mecanismo para la ayuda en la toma de decisiones empresariales
y/o económicas acertadas que permitan mejorar su competitividad.
Se elaboran una serie de indicadores de estudios centrándose en unas áreas de
negocio específicas, concretamente en gestión de ventas, gestión financiera, gestión
de proyectos y gestión de incidencias. A continuación se valoraran cuáles son las
dimensiones y sus jerarquías por las cuales se analiza dichos indicadores, para acto
seguido elaborar los diferentes cubos.
Por último se implementa los cuadros de mandos e informes necesarios que le permite
al usuario final visualizar, medir y tomar decisiones con respecto a su empresa.
44
Parte II. Cuerpo principal. Descripción deltrabajo
45
46 Chapter I
Capítulo 1. Descripción de la metodología para resolver el problema
Resumen:
Desarrollo ágil de Software
Metodología de desarrollo Scrum
Planificación del proyecto
1.1 Metodología de desarrollo
Una metodología de desarrollo de software se refiere a un framework16 que se usa para
estructurar, planear y controlar el proceso de desarrollo en Sistemas de Información. El
objetivo es mejorar la productividad en el desarrollo y la calidad del producto software.
¿Qué tipo de metodología se podría utilizar?
Se entiende por metodología ágil de desarrollo de software a una colección de valores,
principios y prácticas para modelar software que pueden ser aplicados de manera
simple y ligera. La filosofía de las metodologías ágiles se basa en dar mayor valor al
individuo, a la colaboración con el cliente y al desarrollo incremental del software con
iteraciones muy cortas.
En este proyecto se ha apostado por una metodología ágil de desarrollo de software,
intentando evitar los tortuosos y burocráticos caminos de las metodologías
tradicionales, debido a que presentan los siguientes problemas a la hora de abordar
proyectos, como se muestra en la Tabla 11.
Tabla 11: Desventajas de las metodologías de desarrollo tradicionales
Existen unas costosas fases previas de especificación de requisitos, análisis y
diseño
La corrección de errores durante el desarrollo será costosa, es decir, se pierde
flexibilidad ante los cambios
El proceso de desarrollo está encorsetado por documentos firmados
El desarrollo es más lento y entender un sistema complejo en su globalidad
16 Un framework que se usa para estructurar, planear y controlar el proceso de desarrollo en Sistemas de Información asistir al proceso de desarrollo de software.
46
implica mayor dificultad
Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con
requisitos poco definidos y/o cambiantes o cuando se exige reducir drásticamente los
tiempos de desarrollo pero manteniendo una alta calidad. Además, se aplican bien en
equipos pequeños que resuelven problemas concretos, lo que no está reñido con su
aplicación en el desarrollo de grandes sistemas, ya que una correcta modularización de
los mismos es fundamental para su exitosa implantación. Dividir el trabajo en módulos
abordables minimiza los fallos y el coste, con lo cual las metodologías ágiles presentan
diversas ventajas, entre las que podemos destacar las indicadas en la Tabla 12.
Tabla 12: Ventajas de la metodologías de desarrollo ágiles
Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo
Entrega continua y en plazos breves de software funcional
Trabajo conjunto entre el cliente y el equipo de desarrollo
Importancia de la simplicidad, eliminado el trabajo innecesario
Atención continua a la excelencia técnica y al buen diseño
Mejora continua de los procesos y el equipo de desarrollo
En este proyecto se ha querido aportar más dinamismo y adaptabilidad frente a los
cambios, por lo que se ha decidido hacer uso de una metodóloga ágil, apostando,
dentro del abanico de posibilidades, por la metodología Scrum debido a que permite
maximizar la realimentación sobre el desarrollo —pudiendo corregir problemas y
mitigar riesgos de forma temprana—, a su creciente uso en los equipos de desarrollo
software a nivel internacional, así como otras ventajas que se adaptaban de forma
eficiente con la naturaleza del problema abordado, como se detallará a continuación.
1.1.1 Metodología SCRUM
Scrum es una metodología para la gestión y desarrollo de software basada en un
proceso iterativo e incremental utilizado, comúnmente, en entornos basados en el
desarrollo ágil de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se
emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y
flexibilidad —situaciones frecuentes en el desarrollo de determinados sistemas de
software.
47
48 Chapter I
Scrum es un modelo de referencia que define un conjunto de tareas —que se engloban
en trabajos— y roles, pudiéndose tomar como punto de partida para definir el proceso
de desarrollo que se ejecutará durante un proyecto software. A continuación en la Error:
No se encuentra la fuente de referencia se presenta una ilustración donde se puede
apreciar los elementos que lo integran —roles, artefactos, eventos— así como sus
conexiones.
Scrum estructura el desarrollo en ciclos de trabajo llamados Sprints, siendo de duración
fija —entre 1 y 4 semanas— y terminando en una fecha específica,
independientemente de haberse finalizado, o no, el trabajo. Cada Sprint se va
sucediendo uno detrás de otro. Dentro de Scrum se diferencian los siguientes roles
principales, presentes en los Sprints:
48
ScrumMaster es la persona que vela por el cumplimiento de las normas de
Scrum. Trabaja de forma similar a un director de proyecto, llevando a cabo la
gestión del Sprint, con seguimientos diario del Scrum Daily Meeting —
representa una reunión de avance diaria de no más de 15 minutos, cuyo
propósito es vigilar las tareas realizadas, los recursos necesarios y los
obstáculos que se presentan— en busca del objetivo fijado.
Dueño del producto (Product Owner) representa a los clientes externos o
internos
Equipo de desarrolladores (Team) es el grupo de personas encargadas de
implementar los requisitos del cliente, así como de elegir las tareas que se
comprometen hacer en cada Sprint.
Al comienzo de cada Sprint, un equipo Team selecciona las tareas del Product
Backlog17 o pila del producto —se trata de una lista, previamente priorizada por el
Product Owner—, y se comprometen a terminarlas al final del Sprint. Las tareas
elegidas por el Team serán introducidas en el Sprint Backlog18 o pila del Sprint. Todos
los días el equipo Team realiza un Scrum Daily Meeting, actualizando unas gráficas
orientativas que permiten hacer un seguimiento, de forma rápida y sencilla, de las
tareas que faltan para alcanzar su objetivo. Al final del Sprint, el Team hace una
revisión del mismo con los interesados en el proyecto, enseñándoles lo construido: se
obtienen comentarios y observaciones que pueden incorporar al siguiente Sprint.
Scrum pone énfasis en productos que funcionen al final del Sprint, es decir, que
realmente estén “hechos”19 —en el caso de software significa estar integrado,
completamente probado y potencialmente para entregar.
Un tema importante en Scrum es “inspeccionar y adaptar” (1). El desarrollo
inevitablemente implica aprender e innovar, haciendo hincapié en tiempos no muy
extensos de desarrollo y centrándose en analizar el producto resultante midiendo la
eficacia obtenida, ajustando el objetivo del producto iterativamente o en continuo
feedback.
II.1.1.1.1 Scrum en el proyecto
Dada la naturaleza y la magnitud del proyecto, se optó por aplicar esta metodología
modificándola para se ajustara a las necesidades puntuales de la solución BI aportada
en este documento.
17 El Product Backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todoslos requerimientos, funcionalidades deseables, etc. priorizadas. Contiene estimaciones a grosso modo, tanto del valorpara el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al Product Owner a ajustar la líneatemporal y la prioridad de las diferentes tareas.
18 El Sprint Backlog es un documento detallado donde se incluye la lista de tareas o elementos que el equipo va aimplementar durante el siguiente Sprint. Estas tareas son extraídas del Product Backlog por el Team, teniendo encuenta cuáles de ellas son más prioritarias.
19 Scrum y XP desde las Trincheras. Henrick Kniberg (1)
49
50 Chapter I
En primer lugar, los roles de los participantes no estaban bien definidos ya que se trata
de un Proyecto Final de Carrera en colaboración con la empresa ITOP MC y esta
desempeñaba el tanto el papel de Product Owner como el de Scrum Master.
Por otro lado no se consideró mantener reuniones diarias para el seguimiento de los
Sprint, ya que no serían efectivas puesto que no existirían cambios sustanciales que se
pudieran comentar para su valoración. En su lugar se mantuvieron, siempre que fue
posible, reuniones semanales.
II.1.1.1.2 Planificación de la solución BI
A continuación, en la Tabla 13, se muestra el Product Backlog tal y como se describe
en la metodología Scrum. Se especificaron en una columna las funcionalidades y al
lado las correspondiente estimación del tiempo que se dedicará para completar cada
ítem. Decir que, aunque tendrían que diferenciarse entre requisitos básicos, prioritarios
o no, todos los requisitos son prioritarios ya que en si son una secuencia de pasos para
construir una solución BI.
50
Tabla 13: Product Backlog de la solución BI
Ítem Descripción Estimación
1 Estado del arte 30 días
2 Búsqueda de una metodología 15 días
3 Estudio de las herramientas de desarrollo 15 días
4 Análisis de requerimientos
4.1 Identificar Preguntas 15 días
4.2 Identificar Indicadores y Perspectivas 30 días
4.3 Modelo Conceptual 7 días
5 Análisis de los OLTP
5.1 Conformar indicadores 30 días
5.2 Establecer correspondencias 7 días
5.3 Nivel de granularidad 7 días
5.4 Modelo conceptual ampliado 7 días
6 Modelo lógico del Data Warehouse
6.1 Tipo de modelo lógico del Data Warehouse 7 días
6.2 Tablas de dimensiones 15 días
6.3 Tablas de hechos 15 días
6.4 Uniones 15 días
7 Integración de datos
7.1 Carga inicial 15 días
7.2 Actualización 15 días
8 Implementación de ETL con el SSIS 15 días
9 Implementación de cubos OLAP con el SSAS 15 días
10 Representación 15 días
A partir del Product Backlog se ha elaborado el Sprint Backlog. Esta lista de tareas
permitirá organizar el trabajo del Team para optimizar el uso de los recursos
disponibles, obtener resultados en plazos de tiempo breves y controlar la ejecución de
cada punto para detectar “cuellos de botellas” y, en consecuencia, darles solución.
La estrategia que se ha seguido para definir los distintos Sprints ha sido tomar cada
ítem del Product Backlog como una etapa a completar. Cada una de estas etapas
contendrá tantos Sprints como tareas contenga la etapa, de manera que cada sprint
51
52 Chapter I
tenga como objetivo el desarrollo de una tarea. Como limitación a estos Sprints, se ha
impuesto que cada uno tenga como mínimo 6 días de ciclo de vida y, como máximo 7.
52
53
54 Chapter I
Tabla 14: Sprint Backlog de la solución BI
Backlog Sprint DescripciónDuración
Estimación Real
1
Estudio del estado del arte
1,2,3,4,5 Estado del arte 30 días 30 días
6 Documentación 3 días 3 días
2
Desarrollo de una metodología
7, 8 Búsqueda de una metodología 15 días 15 días
9 Documentación 3 días 3 días
3
Herramientas de desarrollo
10, 11Estudio de las herramientas de
desarrollo15 días 15 días
12 Documentación 3 días 3 días
13 Pruebas 7 días 7 días
4
Análisis de requerimientos
14, 15 Identificar Preguntas 7 días 10 días
16,17,18,19,2
0Identificar Indicadores y Perspectivas 7 días 10 días
21 Modelo Conceptual 7 días 7 días
22 Documentación 3 días 3 días
23 Pruebas 7 días 7 días
5
Análisis de los OLTP
24,25,26,27,2
8Conformar indicadores 7 días 15 días
29 Establecer correspondencias 7 días 15 días
30 Nivel de granularidad 7 días 15 días
31 Modelo conceptual ampliado 7 días 7 días
22 Documentación 3 días 3 días
23 Pruebas 7 días 7 días
Modelo lógico del Data Warehouse
Tipo de modelo lógico del Data
54
En la Tabla 14 se puede observar el tiempo estimado para cada tarea, de forma que se
cumpla con el requisito temporal impuesto para los Sprints y, en la última columna de la
derecha, el tiempo real dedicado a cada una de ellas. Se observa que en varios casos
el tiempo empleado ha sido mayor que el estimado, circunstancia que viene explicada
por el hecho de que, dichas tareas, presentaban una mayor complejidad de la
esperada, eran novedosas pues se acometían por primera vez, hubo cambios de
tecnologías y necesidad de nuevos equipos de trabajo debido a que los que existían no
soportaban la tecnología elegida, además no se parte de un caso ideal o teórico sino
que se trataba de explotar datos reales donde no se disponía, entre otros problemas,
de una base de datos totalmente depurada (o purificada).
II.1.1.1.3 Planificación temporal
Este proyecto viene delimitado temporalmente por la necesidad de no exceder las 150
horas de dedicación, equivalentes a los 15 créditos asignados a esta asignatura.
Respetar este límite es una tarea difícil, ya que siempre se dedican más horas en la
parte de desarrollo para intentar cumplir los objetivos fijados, sin contar con el tiempo
dedicado a las reuniones, a la formación o a incidencias tecnológicas.
Para la representación de las tareas y su asignación temporal, se ha seleccionado el
Diagrama de Gantt. Su objetivo es mostrar el tiempo de dedicación previsto para
diferentes tareas o actividades a lo largo de un tiempo total determinado. El diagrama
de Gantt de este proyecto se puede ver reflejado en la Figura 24.
55
56 Chapter I
Figura 24: Diagrama de Gantt
56
Capítulo 2. Metodología de Implementación de una solución BI
Resumen:
Metodología para construir de un Data Warehouse
Metodología propia para la construcción de un Data Warehouse
Como se mencionó en el Capítulo Fundamentos Business Intelligence, se denomina
Business Intelligence al conjunto de estrategias y herramientas enfocadas a la
administración y creación de conocimiento mediante el análisis de datos existentes en
una organización o empresa. Abarca la comprensión del funcionamiento actual de la
empresa, bien como la anticipación de acontecimientos futuros, con el objetivo de
ofrecer conocimientos para respaldar las decisiones empresariales. En Figura 25 se
representa el esquema de una solución BI, teniendo en cuenta que los componentes
básicos son: OLTP, herramientas ETL —Extracción, Transformación y Carga—, Data
Warehouse, Query Manager y las herramientas de consultas y análisis como los
cuadros de mandos o generados de informes.
Figura 25: Componentes principales de una solución BI
Una vez entendido en qué consiste una solución BI, se puede observar que uno de los
pilares es el Data Warehouse ya que contiene los datos que vamos a analizar, por eso
es importante como se diseña e implementa.
La construcción e implementación de un Data Warehouse puede adaptarse muy bien a
cualquier ciclo de vida de desarrollo de software, con la salvedad de que para algunas
fases las acciones que se han de realizar, en particular, serán diferentes. Lo que se
57
58 Chapter I
debe tener muy en cuenta, es no entrar en la utilización de metodologías que requieran
fases extensas de reunión de requerimientos y análisis, fases de desarrollo monolítica
que conlleve demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es
entregar una primera implementación que satisfaga una parte de las necesidades, para
demostrar las ventajas del Data Warehouse y motivar a los usuarios.
La metodología elegida para el diseño del Data Warehouse se ha elaborado a partir de
una metodología base existente, la cual se ha ampliado y adaptando a nuestro
problema. La ampliación ha consistido en la adición de algunos aspectos claves en el
diseño de un Data Warehouse y una metodología de implementación para una solución
de Business Intelligence. La metodología base de la que se parte fue propuesta por el
Ingeniero Argentino Bernabeu Ricardo “Investigación y Sistematización de Conceptos -
HEFESTO: Metodología propia para la Construcción de un Data Warehouse ”20 (2).
2.1.1 Metodologías para construir un Data Warehouse
En un principio se realizó una búsqueda con el fin de encontrar una metodología que
se adaptara lo mejor posible a nuestro problema. Se encontraron dos metodologías
interesantes: por un lado Hefesto, anteriormente nombrada, y por otro lado la
desarrollada por SAS, llamada The SAS Rapid Data Warehouse Methodology
(SRDWM). Dicha metodología es iterativa y desarrolla incrementalmente un proyecto
Data Warehouse dividiéndolo en cinco fases:
1. Definición de los objetivos
2. Definición de los requerimientos de información
3. Diseño y modelización
4. Implementación
5. Revisión
La razón por la que se desestimó el uso de la metodología SRDWM es debido a la
sencillez y eficacia con la que está elaborada la metodología Hefesto. Hefesto explica
de forma muy intuitiva los pasos que hay que tomar en cada momento, así como por
qué debemos tomarlos, acompañada siempre con ejemplos y comparaciones. Se toma
como punto de referencia para todas aquellas personas que estén dando sus primeros
pasos en el mundo del Data Warehousing y quizás en ese sentido SRDWM no
aportaba esa sencillez, resultando incluso más dificultoso. Otra ventaja es que encaja
perfectamente con la metodología Scrum frente a SRDWM, que al ser una metodología
iterativa incremental, tendría mayor dificultad de adaptarse a una metodología de
desarrollo ágil. En la Tabla 15 se muestra las principales características de Hefesto.
Tabla 15: Características principales en la metodología Hefesto
Los objetivos y resultados esperados en cada fase se distinguen fácilmente y son sencillos de
comprender
20 A partir de ahora utilizaremos Hefesto para referirnos a ella.
58
Tabla 15: Características principales en la metodología Hefesto
Se basa en los requerimientos de los usuarios, por lo cual su estructura es capaz de adaptarse
con facilidad y rapidez ante los cambios en el negocio
Cuando se culmina con una fase, los resultados obtenidos se convierten en el punto de partida
para llevar a cabo el paso siguiente
Utiliza modelos conceptuales y lógicos, los cuales son sencillos de interpretar y analizar
Se aplica tanto para Data Warehouse como para Data Mart
Es independiente del tipo de ciclo de vida que se emplee para contener la metodología
Es independiente de las herramientas que se utilicen para su implementación
Es independiente de las estructuras físicas que contengan el DW y de su respectiva distribución
Reduce la resistencia al cambio, ya que involucra a los usuarios finales en cada etapa para que
tome decisiones respecto al comportamiento y funciones del Data Warehouse
Durante el estudio de la metodología Hefesto nos dimos cuenta que habría que
adaptarla hacia una situación real de Data Warehouse más compleja, pero esto no
supuso ningún problema gracias a la flexibilidad que ofrece.
2.1.2 Metodología propia para la Construcción de un Data Warehouse con base en HEFESTO
La metodología Hefesto sigue las fases de construcción mostradas en la Figura 27.
Figura 26: Metodología propia de Hefesto para la construcción de un Data Warehouse
Las adaptaciones llevadas a cabo en la metodología propia de Hefesto, ha consistido en crear
una nueva sección dedicada a la implementación, ya que no lo tiene en cuenta por ser
independiente de las herramientas que se utilicen para su implementación. Además las fases
de análisis e integración también sufrieron modificaciones en diversos apartados.
Figura 27: Metodología propia para la construcción de un Data Warehouse
En la Figura 27 se muestra la metodología propia con base en Hefesto, donde se puede
apreciar en color rojo las adiciones o reestructuraciones de las fases. A continuación se van
analizando las fases resaltando los cambios realizados en cada una de ellas.
II.2.1.2.1 Fase 1: Análisis de Requerimientos
59
60 Chapter I
El primer paso a realizar es identificar los requerimientos de los usuarios a través de
preguntas que expliciten los objetivos de su organización. Luego, se analiza estas
preguntas a fin de identificar cuáles serán los indicadores y perspectivas que serán
tomadas en cuenta para la construcción del Data Warehouse. Finalmente se
confecciona un modelo conceptual en donde se puede visualizar el resultado obtenido
en este primer paso.
II.2.1.2.1.1 Identificar preguntas
El objetivo de este apartado consiste en recolectar las necesidades de información,
pudiéndose llevar a cabo a través de diversas técnicas como entrevistas, cuestionarios,
observaciones, entre otras.
El análisis de los requerimientos de los diferentes usuarios, es el punto de partida de
esta metodología, ya que nos deben, en cierto modo, guiar la investigación hacia un
desarrollo que refleje claramente lo que se espera del Data Warehouse, en relación a
sus funciones y capacidades.
Por todo lo anterior, el fin consiste en obtener e identificar las necesidades de
información clave de alto nivel, esencial para llevar a cabo las metas y estrategias de la
empresa, facilitando una toma de decisiones de forma eficaz y eficiente a través de los
KPI (Key Performance Indicators) o indicadores de rendimiento clave.
Debe tenerse en cuenta que dicha información, es la que proveerá el soporte para
desarrollar las fases sucesivas, por lo cual, es muy importante que se preste especial
atención al revelar los datos.
Una forma de asegurarse de que se ha realizado un buen análisis, es corroborar que el
resultado del mismo haga explícitos los objetivos estratégicos planteados por la
empresa que se está estudiando.
Otra forma de encaminar la relevancia, es enfocar las necesidades de información en
los procesos principales que desarrolle la empresa en cuestión.
La idea central es formular preguntas complejas sobre el negocio, que incluyan
variables de análisis que se consideren relevantes, ya que son estas las que permitirán
estudiar la información desde diferentes perspectivas.
Cabe destacar que la información debe estar soportada de alguna manera por algún
OLTP, ya que de otra forma, no se podrá elaborar el Data Warehouse.
Como aportación a la metodología Hefesto, en principio se ha seleccionado una serie
de cuestiones que pueden ayudar a identificar qué es lo que quiere medir, evaluar o
ver la empresa:
60
¿Cuáles son las metas que tenemos?
Antes que nada se debe definir la meta21 para poder ver los elementos más
importantes que influyen para llegar al resultado final. Aquí es donde está una de las
claves del éxito, hasta dónde quiero llegar y qué tengo que hacer.
¿Qué elementos influyen en las metas que me he propuesto?
¿Es posible medir este indicador?
¿Me ayuda a pensar en qué acciones puedo mejorar?
¿Tengo con qué comparar este indicador?
¿Por qué es este un buen indicador?
¿Qué es lo que estoy midiendo: €, tiempo, visitas, %?
Una vez que tengamos nuestro indicador vienen las siguientes preguntas:
¿Cada cuánto es bueno medir este indicador?
¿Quién debe conocer estos números?
¿Cómo presentaremos estos números para que se entiendan?
¿Cómo motivaremos al personal a alcanzar estas metas?
Una vez obtenido el indicador, faltaría analizar la perspectiva donde este valor aporta
un significado:
¿Cuál es la perspectiva de análisis?
¿Con qué otra medida lo comparo?
Se puede dar el caso que el usuario no tenga muy claro sus necesidades de
información o que estas sean demasiadas y, por lo tanto, imposible de abarcar. Es muy
importante centrarse en los puntos clave de información y eliminar aquellos que sean
secundarios. Cuando ocurre esto, como refuerzo a las cuestiones, se propone guiar al
usuario pidiéndole que indique cuáles son los procesos principales que desarrolla su
empresa, apoyándose en la Gestión de Procesos de Negocio (Business Process
Management o BPM) 22 ya que a través del modelado de las actividades y procesos se
puede lograr un mejor entendimiento del negocio y muchas veces esto presenta la
oportunidad de mejorarlos.
La automatización de los procesos reduce errores, asegurando que los mismos se
comporten siempre de la misma manera y dando elementos que permitan visualizar el
estado de los mismos. La administración de los procesos permite asegurar que los
mismos se ejecuten eficientemente, obteniendo información vital para futuras mejoras,
21 Tener en cuenta que una meta debe ser medible, por lo general, cuantitativamente.
22 Una Gestión de Procesos de Negocio es una metodología empresarial cuyo objetivo es mejorar la eficiencia através de la gestión sistemática de los procesos de negocio, que se deben modelar, automatizar y optimizar de formacontinua.
61
62 Chapter I
ya que a través de la ejecución diaria de los procesos, se puede identificar posibles
ineficiencias en los mismos, llevando a actuaciones para optimizarlos.
En el caso de estudio presente llevado a cabo para la empresa ITOP, se analizó su
mapa de Procesos de Negocio, pues al ser una empresa con los objetivos bien
marcados, las cuestiones se usaron en segundo lugar, se propone guiar al usuario
pidiéndole que indique cuáles son los procesos principales
¿Qué necesito ver, medir o evaluar?
¿Cómo necesito analizarlo?
Figura 28: Mapa de procesos ITOP
ITOP MC distinguen tres procesos importantes:
Procesos estratégicos orientados y dirigidos a los procesos clave y de apoyo.
Procesos claves objetivo principal de las actividades que se llevan a cabo en la
empresa o unidad siendo su razón de ser.
Procesos de apoyo soportan a uno o más de los procesos clave.
Después de haber analizados los procesos claves, se decidió centrarse en los
procesos Gestión de Proyectos, Soporte – a partir de ahora Gestión de Incidencias–,
Vender –Gestión de Ventas– y Dirección Financiera. A continuación, se procedió a
identificar las necesidades de información dentro de cada proceso, que a groso modo
se aprecia en la Tabla 16.
62
Tabla 16: Necesidades de información dentro de cada proceso
¿Qué quiero
medir?
¿En qué
unidad va a
ser medido?
¿Cómo
representaremos
estos números
para que se
entiendan?
¿Cuál es la
perspectiva de
análisis?
Gestión de
Ventas
Total de ventas que
han habidoEuros
Gráfico de Bala
Diagrama de
Barras
SparkLines
En qué momento
ocurrió
Quién
Donde ocurrió
Que compro
Quien lo vendió
Cuál fue el medio
donde se produjo
la venta
Total de beneficio
que se ha obtenido
Euros,
Porcentaje
Cuanto aumentó las
ventas
Euros,
Porcentaje
Cuanto aumentó el
beneficio
Euros,
Porcentaje
Dirección
Financiera
Relación entre el
capital ajeno y el
capital propio
Euros,
Porcentaje
Gráfico de Bala
Diagrama Barras
SparkLines
Gráfico de línea
En qué momento
ocurrió
Grado de
endeudamiento de
los activos
Euros,
Porcentaje
Rentabilidad de la
empresa
Euros,
Porcentaje
Eficiencia empresaEuros,
Porcentaje
Gestión de
Proyectos
Cómo va el
proyecto en cuanto
a costos
Euros
Gráfico de Bala
Diagrama Barras
SparkLines
Diagramas control
Líneas tendencias
En qué momento
ocurrió
Cómo va el
proyecto en cuanto
aspectos de calidad
se refiere
Porcentaje
Cómo va el
proyecto en
márgenes de tiempo
Tiempo
63
64 Chapter I
Tabla 16: Necesidades de información dentro de cada proceso
¿Qué quiero
medir?
¿En qué
unidad va a
ser medido?
¿Cómo
representaremos
estos números
para que se
entiendan?
¿Cuál es la
perspectiva de
análisis?
En qué nivel de
riesgo se encuentra
el proyecto
Porcentaje
Como se encuentra
el proyecto en
cuanto al alcance
fijado
Atributo23
Como se encuentra
el proyecto en
cuanto a
adquisiciones
Tiempo
Como se encuentra
el proyecto en
cuanto a recursos
humanos
Numérico
Gestión de
Incidencias
Número de
incidencias abiertas
frente a
Numérico
Gráfico de Bala
Diagrama de
Barras
SparkLines
Líneas de
tendencias
Gráfico de pila
En qué momento
ocurrió
Incidencias
cerradasPorcentaje
Tiempo que se tarda
en responder una
incidencia
Numérico
Tiempo que se tarda
en cerrar una
incidencia
Numérico
Fuente de
incidencias
Atributo
23 Entendemos como atributo una serie de valores definidos por el usuario que le ayuden a entender la medidaevaluada. Ej: Bueno, Malo
64
Tabla 16: Necesidades de información dentro de cada proceso
¿Qué quiero
medir?
¿En qué
unidad va a
ser medido?
¿Cómo
representaremos
estos números
para que se
entiendan?
¿Cuál es la
perspectiva de
análisis?
Gravedad de la
incidenciaAtributo
Número de
incidentes
asignados
incorrectamente
Porcentaje
Número de
incidencia
reabiertas
Porcentaje
II.2.1.2.1.2 Identificar indicadores y perspectivas
Una vez que se han establecido las preguntas de negocio, se debe proceder a su
descomposición para descubrir los indicadores que se utilizarán y las perspectivas de
análisis que intervendrán.
Para ello, se debe tener en cuenta que los indicadores KPI para que sean realmente
efectivos, toman, en general, valores numéricos y representan lo que se desea
concretamente analizar, como saldos, promedios, cantidades, sumatorias, fórmulas,
entre otros.
En cambio, las perspectivas o dimensiones se refieren a los objetos mediante los
cuales se quiere examinar los indicadores, con el fin de responder a las preguntas
planteadas, como clientes, proveedores, sucursales, países, productos, entre otros,
destacando al tiempo —la más común de las perspectivas24.
Llegados a este punto, en nuestro caso de estudio se ha elaborado una tabla de KPI´s
(ver Tabla 17) a partir de los procesos en lo que más estaban interesados la empresa.
Tabla 17: Indicadores
24 Las dimensiones o perspectivas, usualmente, se asocian en jerarquías para describir niveles de agrupamientoespecíficos —explícitos o implícitos— y, por lo tanto, las diferentes granularidades —nivel de detalle— en la visión delos datos
65
66 Chapter I
Ventas
Finanzas
Gestión de Proyectos
Gestión de Incidencias
Para el proceso de Ventas y Finanzas, la empresa ya tenía decidido cuales eran los
indicadores que querían medir; en cambio, los indicadores de Gestión de Proyectos e
Incidencias se hizo un estudio de cuáles eran los que más se adaptaban a sus
necesidades de información.
Se aprecia en la Tabla 18 los indicadores de Gestión de Ventas, indicando el nombre
del indicador y una breve descripción de los mismos.
Tabla 18: Gestión de Ventas
Indicadores Descripción Perspectiva
Variación de ventasMide el porcentaje de variación de ventas sobre elejercicio anterior Tiempo
ClienteGestión de VentasCanalProductoGeografía
Total de ventas Mide el total de ventas que se han realizado
% Beneficio Total Mide el beneficio total obtenido de las ventas
% Variación del
BeneficioMide la variación del beneficio respecto al histórico
Los indicadores de Dirección Financiera figuran en las Tabla 20, Tabla 21, Tabla 22,
Tabla 23 dividiéndose los ratios financieros en cuatro grandes grupos, como indica la
Tabla 19.
Tabla 19: Grupos de Indicadores de Dirección
Financiera
Ratios de liquidezRatios de endeudamiento o solvencia
Ratios de rentabilidadRatios de gestión u operativos
66
Tabla 20: Ratios de liquidez
Son los ratios que miden la disponibilidad o solvencia de dinero en efectivo, o la capacidad que tiene la
empresa para cancelar sus obligaciones de corto plazo.
Indicadores de
Dirección
Financiera
Descripción Perspectivas
Ratios de
liquidez severa o
Prueba ácida
Este ratio muestra una medida de liquidez más precisa que laanterior, ya que excluye a las existencias (mercaderías oinventarios) debido a que son activos destinados a la venta yno al pago de deudas, y, por lo tanto, menos líquidos;además de ser sujetas a pérdidas en caso de quiebra.
TiempoRatios de liquidez
absoluta o Ratio
de efectividad o
Prueba superácida
Es un índice más exacto de liquidez que el anterior, ya queconsidera solamente el efectivo o disponible, que es el dineroutilizado para pagar las deudas y, a diferencia del ratioanterior, no toma en cuenta las cuentas por cobrar (clientes)ya que es dinero que todavía no ha ingresado a la empresa.Si el resultado es menor que 0.5, no se cumple conobligaciones de corto plazo
Capital de trabajoSe obtiene de deducir el pasivo corriente al activo corriente.Lo ideal es que el activo corriente sea mayor que el pasivocorriente, ya que el excedente puede ser utilizado en lageneración de más utilidades.
Tabla 21: Ratios de endeudamiento, solvencia o de apalancamiento
Son aquellos ratios o índices que miden la relación entre el capital ajeno —fondos o recursos
aportados por los acreedores— y el capital propio —recursos aportados por los socios o accionistas y
lo que ha generado la propia empresa—, así como también el grado de endeudamiento de los activos.
Miden el respaldo patrimonial.
Indicadores de Dirección
Financiera
Descripción Perspectivas
Ratio de endeudamiento a
corto plazo
Mide la relación entre los fondos a corto plazoaportados por los acreedores y los recursosaportados por la propia empresa.
TiempoRatio de endeudamiento a
largo plazo
Mide la relación entre los fondos a largo plazoproporcionados por los acreedores, y losrecursos aportados por la propia empresa.
Ratio de endeudamiento totalMide la relación entre los fondos totales acorto y largo plazo aportados por losacreedores, y los aportados por la propiaempresa.
Ratio de endeudamiento de
activo
Mide cuánto del activo total se ha financiadocon recursos o capital ajeno, tanto a cortocomo largo plazo.
67
68 Chapter I
Tabla 22: Ratios de rentabilidad
Muestran la rentabilidad de la empresa en relación con las ventas, el patrimonio y la inversión,
indicando además la eficiencia operativa de la gestión empresarial.
Indicadores de Dirección
Financiera
Descripción Perspectivas
Ratio de rentabilidad de lainversión (ROA)
Es el ratio más representativo de la marchaglobal de la empresa, ya que permite apreciar sucapacidad para obtener utilidades en el uso deltotal activo.
Tiempo
Ratio de rentabilidad delpatrimonio (ROE)
Este ratio mide la capacidad para generarutilidades netas con la inversión de losaccionistas y lo que ha generado la propiaempresa (capital propio).
Ratio de rentabilidad brutasobre ventas
Llamado también margen bruto sobre ventas,muestra el margen o beneficio de la empresarespecto a sus ventas.
Ratio de rentabilidad netasobre ventas
Es un ratio más concreto ya que usa el beneficioneto luego de deducir los costos, gastos eimpuestos.
Ratio de rentabilidad poracción
Llamado también utilidad por acción, permitedeterminar la utilidad neta que le corresponde acada acción. Este ratio es el más importantepara los inversionistas, pues le permite compararcon acciones de otras empresas.
Ratio de dividendos poracción
El resultado de este ratio representa el monto oimporte que se pagará a cada accionista deacuerdo a la cantidad de acciones que éstetenga.
Tabla 23: Ratios de gestión, operativos o de rotación
Evalúan la eficiencia de la empresa en sus cobros, pagos, inventarios y activo.
Indicadores de Dirección
FinancieraDescripción
Perspectivas
Ratio de periodo de cobro Indica el número de días en que se recuperan lascuentas por cobrar a sus clientes.
Tiempo
Ratio de rotación por pagar Mide el plazo que la empresa cuenta paracancelar bonificaciones.
Ratio de periodo de pagosDetermina el número de días en que la empresase demora en pagar sus deudas a losproveedores.
Ratio de rotación deinventarios
Indica la rapidez en que los inventarios seconvierten en cuentas por cobrar mediante lasventas al determinar el número de veces que rotael stock en el almacén durante un ejercicio.
Por otro lado, para elaborar los indicadores de Gestión de Proyectos e Incidencias,
comentado anteriormente, se tuvo que llevar a cabo una investigación de cuáles
68
podrían ser los más que se ajustaban a las necesidades de la empresa y, después de
sucesivas reuniones con el cliente, se escogieron una serie de ellos.
Para la creación de los indicadores de Gestión de Proyectos se utilizó como
documentación el PMBOK25. Comprende dos grandes secciones: la primera sobre los
procesos y contextos de un proyecto, y la segunda sobre las áreas de conocimiento
específico para la gestión de un proyecto.
Las nueve áreas del conocimiento mencionadas en el PMBOK se detallan en la Tabla
24.
Tabla 24: Gestión de Proyectos
Gestión de la Integración delProyecto
Incluye los procesos y actividades necesarios paraidentificar, definir, combinar, unificar y coordinar losdiversos procesos y actividades de la dirección deproyectos dentro de los grupos de procesos de direcciónde proyectos.
Gestión del Alcance del ProyectoIncluye los procesos necesarios para garantizar que elproyecto incluya todo (y únicamente todo) el trabajorequerido para completarla con éxito.
Gestión del Tiempo del ProyectoIncluye los procesos requeridos para administrar lafinalización del proyecto a tiempo.
Gestión de los Costos del ProyectoIncluye los procesos involucrados en estimar,presupuestar y controlar los costos de modo que secomplete el proyecto dentro del presupuesto aprobado.
Gestión de la Calidad del Proyecto
Incluye los procesos y actividades de la organizaciónejecutante que determinan responsabilidades, objetivos ypolíticas de calidad a fin de que el proyecto satisfaga lasnecesidades por la cuales fue emprendido.
Gestión de los Recursos Humanosdel Proyecto
Incluye los procesos que organizan, gestionan y conducenel equipo del proyecto.
Gestión de las Comunicaciones delProyecto
Incluye los procesos requeridos para garantizar que lageneración, la recopilación, la distribución, elalmacenamiento, la recuperación y la disposición final dela información del proyecto sean adecuados, oportunos yentregada a quien corresponda (interesado del proyecto ostakeholders).
Gestión de los Riesgos delProyecto
Incluye los procesos relacionados con llevar a cabo laplanificación de la gestión, identificación, el análisis, laplanificación de respuesta a los riesgos, así como sumonitoreo y control en un proyecto.
Gestión de las Adquisiciones delProyecto
Incluye los procesos de compra o adquisición de losproductos, servicios o resultados que es necesario obtenerfuera del equipo del proyecto.
Una vez analizadas y comprendidas estas nueves áreas se crearon los siguientes
KPI’s correspondientes a dichas áreas, como se indica en la Tabla 25, Tabla 26, Tabla
27, Tabla 28, Tabla 29, Tabla 30 y la Tabla 31.
Tabla 25: Gestión de proyectos. Gestión de la Integración del Proyecto
Indicador Descripción Perspectivas
25 PMBOK es un estándar en la Administración de Proyectos desarrollado por el Project Management Institute (PMI)(37).
69
70 Chapter I
% de tiempo dedicado a lacoordinación del proyecto
Este indicador mide el porcentaje de tiempoinvertido en coordinar un proyecto enrelación con el tiempo que se tardó encoordinar e implementar el proyecto.
TiempoNúmero de proyectos
abiertos en relación con elnúmero de proyectos
cerrados
Este indicador mide el número deproyectos cerrados en relación con elnúmero de proyectos abiertos.
Número de hitos retrasadosUn hito es una tarea que representa unafecha importante en un proyecto, como lafinalización de una fase del proyecto.
Tabla 26: Gestión de proyectos. Gestión del tiempo
Indicador Descripción PerspectivaDesviación del
calendario previstopara el proyecto
La desviación del calendario previsto es ladiferencia en tiempo entre la línea base conrespecto al desarrollo actual
TiempoTasa de tareas
realizadas en losplazos deseados
Tasa de tareas realizadas en los plazos deseados
Tabla 27: Gestión de proyectos. Gestión de calidad
Indicador Descripción Perspectivas
Desviación delretorno de la
inversión prevista
La desviación del retorno prevista de la inversión(ROI) es la diferencia entre el retorno de lainversión prevista en la línea de base y el retornoreal de la inversión. Tiempo
Porcentaje del
proyecto terminado
--------------------------------------------------------
Tabla 28: Gestión de proyectos. Gestión de costo
Indicador Descripción Perspectiva
Valor Ganado (EV)
El valor ganado es el valor del trabajocompletado expresado en términos delpresupuesto aprobado asignado a dicho trabajopara una actividad del cronograma o uncomponente de la estructura de desglose deltrabajo.
Tiempo
Valor planificado (PV)El valor planificado es el presupuesto autorizadoasignado al trabajo que debe ejecutarse paracompletar una actividad o un componente de laestructura de desglose del trabajo.
Costo real (AC)
El costo real (AC) es el costo total en el que seha incurrido realmente y que se ha registradodurante la ejecución del trabajo realizado parauna actividad o componente de la estructura dedesglose del trabajo.
Variación delcronograma (SV)
La variación del cronograma es una medida deldesempeño del cronograma en un proyecto. Lavariación del cronograma, en la EVM, finalmenteserá igual a cero cuando se complete elproyecto, porque ya se habrán ganado todos losvalores planificados.
Variación de costo(CV)
La variación del costo es una medida deldesempeño del costo en un proyecto.En la EVM, la CV es particularmente crítica
70
Tabla 28: Gestión de proyectos. Gestión de costo
Indicador Descripción Perspectivaporque indica la relación entre el desempeñoreal y los costos gastados. En la EVM, una CVnegativa con frecuencia no es recuperable parael proyecto.
Índice de desempeñodel cronograma (SPI)
El índice de desempeño del cronograma es unamedida del avance logrado en un proyecto encomparación con el avance planificado.Puesto que el SPI mide todo el trabajo delproyecto, el desempeño en la ruta críticatambién debe analizase, para determinar si elproyecto terminará antes o después de la fechade finalización programada.
Índice del desempeñodel costo (CPI)
Es una medida del valor del trabajo completado,en comparación con el costo o avance reales delproyecto. Se considera la métrica másimportante de la gestión del valor ganado y midela eficacia de la gestión del costo para el trabajocompletado.
Estimación a laconclusión (EAC)
La EAC puede diferir del presupuesto hasta laconclusión (BAC).Si resulta evidente que el BAC ya no es viable,el director del proyecto debe proyectar una EAC.Las EAC se basan normalmente en los costosreales en los que se ha incurrido para completarel trabajo, más una estimación hasta laconclusión (ETC) para el trabajo restante.
Índice de Desempeñodel Trabajo por
Completar (TCPI)
El índice de desempeño del trabajo porcompletar es la proyección calculada deldesempeño del costo que debe lograrse para eltrabajo restante, con el propósito de cumplir conuna meta de gestión especificada, tal como elBAC o la EAC. Si resulta evidente que el BAC ya no es viable,el director del proyecto proyecta una estimacióna la conclusión EAC.
Tabla 29: Gestión de proyectos. Gestión de Riesgos
Indicador Descripción Perspectiva% de los proyectos que
consideran de riesgoPorcentaje de proyectos que seconsideran de riesgo
Tiempo
% de los proyectos con cambiosde alcance
Porcentaje de proyectos activos concambios de alcance durante elproyecto
% de los proyectos "en elcontrol"
Porcentaje de proyectos que está"bajo control", es decir, que sonsubjetivamente calificados como elcontrol basado en tiempo, presupuestoy calidad
Promedio del número demodificaciones realizadas alproyecto desde su definición
Promedio del número de cambiosrealizados en la definición del alcancedel proyecto, es decir, de los proyectosdurante su ciclo de vida
% de los proyectos a tiempo ydentro del presupuesto
Porcentaje de proyectos que seejecutan en el marco de tiempoprevisto y con el presupuesto (gastos)en función de su línea de base
71
72 Chapter I
Tabla 30: Gestión de proyectos. Gestión de recursos humanos
Indicador Descripción Perspectiva
Promedio del número depersonas asignadas al proyecto
---------------------------------------------------
----
Tiempo
Tabla 31: Gestión de proyectos. Gestión de adquisición
Indicador Descripción Perspectiva
Requisición de tiempo deemisión tema
Para medir el tiempo transcurridoentre el momento en que unasolicitud de contratación se inicia y elmomento en que la solicitud secumple (expresada en términos dedías).
Tiempo
A la hora de crear los indicadores de Gestión de Incidencias se ha optado por seguir la
guía de buenas prácticas de ITIL (Biblioteca de Infraestructura de Tecnologías de
Información o Information Technology Infrastructure Library) (3) que consiste en un
conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la
información, el desarrollo de tecnologías de la información y las operaciones
relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso
conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a
lograr calidad y eficiencia en las operaciones de TI (Tecnologías de la Información).
Los indicadores elaborados para el proceso de Gestión de Incidencias se muestran en
la Tabla 32.
Tabla 32: Gestión de Incidencias
Indicador Descripción Perspectiva Tiempo en cerrar la
incidenciaTiempo promedio que se tarda entre elregistro de la incidencia y su cierre.
Tiempo
Tiempo promedio que setarda en responder
incidentes
Tiempo promedio de tiempo (por ejemplo,en minutos) entre la detección de unincidente y la primera medida tomada parareparar el incidente.
Número total de incidentespor fuente
Número de incidentes que se originaron porrazones de telecomunicaciones, lainfraestructura física, operación, soporte,seguimiento, los socios externos deeventos, proveedores y otros
% de los incidentes deretraso
Número de incidentes de retraso (no secierra y no se resuelve dentro del plazoestablecido) en relación con el número deprocedimientos abiertos (no cerrados)incidentes.
Número de incidentesgraves
--------------------------------------------------------
% de los incidentesrepetidos
.
Porcentaje de incidentes que puedenclasificarse como un incidente derepetición, en relación con todos losincidentes reportados en el período de
72
Tabla 32: Gestión de Incidencias
Indicador Descripción Perspectivamedición. Un incidente se repite si ya ha ocurrido(varias veces) en el período de medición
Incidente tasa de colaEl número de casos cerrados, en relacióncon el número de casos abiertos en unperíodo de tiempo determinado.
% de incidentes resueltosdentro del plazo / destino
Número de incidentes cerrados en el plazofijado durante la duración del marco, enrelación con el número de todos losincidentes cerrados en un período detiempo determinado. Un tiempo de duración-marco se aplica acada incidente en el que se recibe, yestablece un límite en la cantidad de tiempodisponible para resolver el incidente. El tiempo de duración aplica-marco sederiva de los acuerdos alcanzados con elcliente sobre la resolución de incidentes.
Costo promedio pararesolver un incidente
Los costes medios para resolver unincidente se calculan a partir de los costosfijos y variables del proceso de gestión delincidente dividido por el número total deincidentes recibidos en el período demedición.
% de incidentesincorrectamente asignados
--------------------------------------------------------
Número de incidentescerrados en relación con el
número de incidentesabiertos
Se valora la eficacia a la hora de resolverincidentes
% de incidentes clasificadosincorrectamente
Un incidente puede ser clasificado comoprioridad alta, media y baja
II.2.1.2.1.3 Modelo Conceptual
A continuación se crea un modelo conceptual a partir de los indicadores y perspectivas
obtenidos en los pasos anteriores.
Con este modelo conceptual lo que se pretende es dar una visión del alcance del
proyecto, aportando una alta definición de datos lo que nos ayuda en la presentación,
difusión y entendimiento de los mismos de cara a los usuarios.
De cada proceso analizado anteriormente, se ha creado cuatro mapas conceptuales26.
A la izquierda se pueden ver las perspectivas que serán unidas a un óvalo central que
26 Se entiende por mapa conceptual a un método para organizar, de forma sencilla, cualquier tipo de información,ayudando a obtener una mejor comprensión e intercambio de la misma.
73
74 Chapter I
representa y lleva el nombre de la relación que existe entre ellas. La relación,
constituye el proceso o área de estudio elegida. De dicha relación y entrelazadas con
flechas, se desprenden los indicadores, estos se ubican a la derecha del esquema.
Figura 29: Diagrama conceptual de ventas
Como puede apreciarse en la Figura 29 el modelo conceptual permite de un solo
vistazo y sin poseer demasiados conocimientos previos, comprender cuáles serán los
resultados que se obtendrán, cuáles son las variables que se utiliza para analizarlos y
la relación que existe entre ellos.
74
Figura 30: Diagrama conceptual Finanzas
Figura 31: Diagrama conceptual Gestión de Proyectos
75
76 Chapter I
Figura 32: Diagrama conceptual Gestión de Proyectos
Figura 33: Diagrama conceptual Gestión de Incidencias
76
II.2.1.2.2 Fase 2: Análisis de los OLTP
El siguiente paso consiste en analizar las fuentes OLTP para determinar cómo serán calculados
los indicadores y poder establecer las respectivas correspondencias entre el modelo conceptual
creado en el paso anterior y las fuentes de datos. Luego, se define qué campos se incluirán en
cada perspectiva. Finalmente, se ampliará el modelo conceptual con la información obtenida en
este paso.
II.2.1.2.2.1 Conformar Indicadores
En este paso se debe indicar cómo calcular los indicadores definiendo las medidas que lo
componen y las funciones de sumarización que se utilizan para su agregación.
En adicción a la metodología de Hefesto, se ha creído conveniente definir un valor objetivo que
ayude al usuario a entender si el valor del KPI es bueno o malo, es decir, que el indicador total
del ventas nos dé un valor de 1000000 euros en el año 2010 no nos dice nada, pero si
sabemos que en el año 2009 las ventas fueron de 3000000, se puede concluir que en el año
2011 el total de ventas ha bajado con respecto al anterior. Otro ejemplo es el caso de proponer
llegar a un total de ventas de 2000000 en el año 2011 —este sería el valor objetivo y nuestro
KPI a día 9 de septiembre de 2011. Si se lleva un total de 1000000, eso quiere decir que si se
quiere conseguir el objetivo antes del nuevo año, quizás se deba hacer un cambio de estrategia
en las ventas para poder en tres meses llegar al objetivo.
Tabla 33: Indicadores
Gestión de VentasGestión Financiera
Gestión de Proyectos
Gestión de Incidencias
Tabla 34: Conformar Indicadores. Gestión de Ventas
Indicadores Medidas Función de sumarización Valor Objetivo
Variación de
ventas
Total de línea (TL)
Descuento pie de
documento (DPD)
Un aumento del 2%
con respecto al año
anterior
77
78 Chapter I
Tabla 34: Conformar Indicadores. Gestión de Ventas
Indicadores Medidas Función de sumarización Valor Objetivo
Unidades de
ventas
Total de línea (TL)
Descuento pie de
documento (DPD)
Un aumento del 2%
con respecto al año
anterior
% Beneficio
Total
Precio Venta Neto PVN
Coste artículo CA
Cantidad C
Un aumento del 2%
con respecto al año
anterior
% Variación
del Beneficio
Precio Venta Neto PVN
Coste artículo CA
Un aumento del 2%
con respecto al año
anterior
Tanto para los indicadores de Dirección Financiera, Gestión de Proyectos y Gestión de
Incidencias, no se va representar su función de sumarización ya que como ya se comentó
anteriormente, por motivos de tiempo no se llegaron a implementar.
Tabla 35: Conformar Indicadores. Grupos de
Indicadores de Finanzas
Ratios de liquidez
Ratios de endeudamiento o solvencia
Ratios de rentabilidad
Ratios de gestión u operativos
Tabla 36: Conformar indicadores Ratios de liquidez
Medida Indicador
Ratios de liquidez severa o prueba acida Activo Corriente
Pasivo Corriente
Ratios de liquidez severa o prueba ácida Activo Corriente
Existencias
Pasivo Corriente
Ratio de liquides absoluta o de efectividad o
Prueba superácida
Caja y banco
Pasivo Corriente
Capital de trabajo Activo Corriente
Pasivo Corriente
78
Tabla 37: Conformar indicadores Ratios de endeudamiento o solvencia
Indicador Medida
Ratio de endeudamiento a corto plazo Pasivo Corriente
Patrimonio
Ratio de endeudamiento a largo plazo Pasivo no Corriente
Patrimonio
Ratio de endeudamiento total Pasivo Corriente
Pasivo no Corriente
Patrimonio
Ratio de endeudamiento de activo Pasivo Corriente
Pasivo no Corriente
Activo Total
Tabla 38: Conformar indicadores Ratios de rentabilidad
Indicador Medida
Ratio de rentabilidad de la inversión (ROA) Utilidad neta
Activos
Ratio de rentabilidad del patrimonio (ROE) Utilidad neta
Patrimonio
Ratio de rentabilidad bruta sobre ventas Utilidad Bruta
Patrimonio
Ratio de rentabilidad neta sobre ventasUtilidad Bruta
Ventas netas
Ratio de rentabilidad neta sobre ventasUtilidad neta
Ventas netas
Ratio de rentabilidad por acción Utilidad neta
Número de acciones
Ratio de dividendos por acción Dividendos
Número de acciones
Tabla 39: Conformar indicadores Ratios de gestión u operativos
Indicador Medida
Ratio de rotación de cobro Ventas al crédito
Cuentas por cobrar comerciales
Ratio de periodo de cobro Cuentas por cobrar comerciales
Ventas al crédito
79
80 Chapter I
Tabla 39: Conformar indicadores Ratios de gestión u operativos
Indicador Medida
Ratio de rotación por pagar Compras al crédito
Cuentas por pagar comerciales
Ratio de periodo de pagos Cuentas por pagar comerciales
Compras al crédito
Ratio de rotación de inventarios Costo de ventas
Existencias
Tabla 40: Conformar Indicadores. Gestión de
proyectos
Gestión de la integración del proyecto
Gestión del tiempo
Gestión de la calidad
Gestión de costos
Gestión de riesgos
Gestión de recursos humanos
Gestión de adquisición
Tabla 41: Conformar Indicadores. Gestión de la integración del proyecto
Indicador Medida
% de tiempo dedicado a la coordinación del
proyecto
Tiempo de coordinación
Tiempo implementación
Número de proyectos abiertos en relación con
el número de proyectos cerrados
Proyectos cerrados
Proyectos abiertos
Número de hitos retrasados Hitos retrasados
Tabla 42: Gestión del tiempo
Indicador Medida
Desviación del calendario previsto para el
proyecto
Tiempo previsto
Tiempo real
80
Tasa de tareas realizadas en los plazos
deseados
Trabajo terminado
Línea base prevista
Tabla 43: Conformar Indicadores. Gestión de calidad
Indicador Medida
Desviación del retorno de la inversión previstaBeneficios
Coste iniciales
Porcentaje del proyecto terminadoTareas terminadas
Tareas incompletas
Tabla 44: Gestión de proyectos. Gestión de costo
Indicador Medida
Valor Ganado (EV)Presupuesto autorizado
Trabajo completado
Valor planificado (PV) Presupuesto asignado a cada actividad
Costo real (AC) Costo real de cada actividad
Variación del cronograma (SV)Valor Ganado
Valor Planificado
Variación de costo (CV)Valor Ganado
Costo Real
Índice de desempeño del cronograma (SPI)Valor Ganado
Valor Planificado
Índice del desempeño del costo (CPI)Valor Ganado
Costo real de la actividad
Estimación a la conclusión (EAC)
Costo real de la actividad
Estimación para concluir el trabajo restante
Índice de Desempeño del Trabajo por
Completar (TCPI)
Presupuesto hasta la conclusión
Valor Ganado
Costo Real
Estimación hasta la conclusión
Tabla 45: Gestión de proyectos. Gestión de riesgos
Indicador Medida
% de los proyectos que consideran de riesgoProyectos en riesgo
Total de proyectos
% de los proyectos con cambios de alcance Proyectos con cambios de alcance
Total de proyectos
% de los proyectos "en el control"Proyectos en control
Total de proyectos
81
82 Chapter I
Promedio del número de modificaciones
realizadas al proyecto desde su definición
Numero de modificaciones
Ciclo de vida del proyecto
% de los proyectos a tiempo y dentro del
presupuesto
Coste de todas las tareas
Calendario del proyecto
Tabla 46: Gestión de proyectos. Gestión de recursos humanos
Indicador Medida
Promedio del número de personas asignadas
al proyecto
Empleados asignados a un proyecto
Total de empleados
Tabla 47: Gestión de proyectos. Gestión de adquisición
Indicador Medida
Requisición de tiempo de emisión temaTiempo de inicio de la solicitud
Tiempo de fin de la solicitud
Tabla 48: Gestión de proyectos. Gestión de adquisición
Indicador Medida
Tiempo en cerrar la incidencia
Tiempo de resolución
Tiempo de detección
Tiempo total en resolver todas las incidencias
Tiempo promedio que se tarda en responder
incidentes
Tiempo de detección
Tiempo en el que se toma la primera medida
Tiempo total que se tardó en resolver tolas las
incidencias
Número total de incidentes por fuenteNúmero de incidencias
Fuente de inciden
% de incidente no resueltos dentro del plazo Incidentes retrasados
Procedimientos abiertos
Número de incidentes graves Incidentes graves
% de los incidentes repetidos
.Incidentes repetidos
Total de incidentes
% de incidentes tratados en los tiempos
de respuestas acordados
Número de casos cerrados
Número de casos abiertos
Tiempo en resolver un incidente
82
Tabla 48: Gestión de proyectos. Gestión de adquisición
Indicador Medida
Costo promedio para resolver un incidente
Costo fijos del incidentes
Costos variables del proceso de gestión
Total de incidentes
% de incidentes incorrectamente asignados
Incidentes incorrectamente asignados
Incidentes asignados
Total de incidentes
% de incidentes mal clasificadosIncidentes abiertos
Incidentes mal clasificados
Número de incidentes cerrados en relación con
el número de incidentes abiertos
Número de casos cerrados
Número de casos abiertos
83
84 Chapter I
II.2.1.2.2.2 Estudio de OLTP
En este punto se va a estudiar los OLTP disponibles que contengan la información
necesaria para poder establecer una correspondencias entre el modelo conceptual y
las fuentes de datos, y de esta manera crear el diagrama conceptual ampliado. La idea
es saber de dónde vamos a obtener los datos que vamos a explotar.
Este apartado ha sufrido una adaptación con respecto a Hefesto, ya que este propone
hacer una correspondencia entre el OLTP y el diagrama conceptual ya creado. Lo que
se ha hecho es mostrar esta correspondencia directamente en el diagrama conceptual
ampliado, esto es debido a que en el ejemplo que propone Hefesto el esquema de la
base de datos es mucho más sencillo que el que se realizó para ventas (Figura 34) y
se pueden apreciar las relaciones, pero en el caso que se abarca el resultado no sería
tan aclaratorio.
Para nuestro caso de estudio solo se dispones de una sola fuente de datos que es la
base de datos de que nos proporcionó ITOP MC.
Figura 34: Esquema de la base de datos de “Ventas”
Se analizaron los campos residentes en cada tabla a la que hace referencia la Figura 34
anterior a través de dos métodos. Primero se examinó la base de datos y el programa SAP BO
84
para hacernos una idea del significado de cada campo, y luego se consultó con la encargada
del sistema las dudas que no se pudieron resolver con el método anterior o las surgidas como
consecuencia del examen de la base de datos.
En la Tabla 49 se puede ver la correspondencia entre el modelo conceptual y el OLTP.
Tabla 49: Relación entre el OLTP y el modelo conceptual
Tabla SAP Perspectivas o Dimensiones
OITB Producto
OITM Familia
@ITOP_SUBF Subfamilia
OMRC Fabricantes
OCRD Cliente
CRD1 Cliente | Direcciones de los clientes27
OTER Cliente | Sector al que pertenece el Cliente
OOND Cliente | Subsector al que pertenece el Cliente
OCRG Cliente | Grupo al que pertenece el Cliente
OSLP Empleado de ventas
OWHS Unidad de Negocio | Almacén
OLCT Sucursal
OINV Tiempo, Total de ventas, Variación Ventas, Beneficio, Variación Beneficio
ORIN Tiempo, Total de ventas, Variación Ventas, Beneficio, Variación Beneficio
OCRY Geografía | País
OCST Geografía
En la Figura 35 se ha ilustrado un ejemplo de cómo sería esta correspondencia con la tabla
CLIENTE de SAP BO.
Figura 35: Correspondencia entre el modelo conceptual y el OLTP
27 La nomenclatura “X|Y” intenta especificar que la X es la perspectiva que se está analizando y la Y una perspectivahija de X, como por ejemplo: Año|Mes
85
86 Chapter I
Para crear el esquema de la base de datos de Gestión de Ventas se parte de una base de
datos ya existente; sin embargo, para crear la de Gestión de Proyectos e Incidencias se inicia
desde cero, apreciándose en la Figura 36 dicho esquema.
Figura 36: Esquema de la bases de datos de Gestión de Proyectos e Incidencias
II.2.1.2.2.3 Nivel de Granularidad
La selección de la granularidad implica decidir exactamente qué es lo que va a representar en
cada registro de la tabla de hechos. En el caso de estudio que se aborda, la granularidad de la
tabla de hechos de Ventas28 será la correspondiente a las ventas en cada línea de factura. La
28 La tabla hecho Ventas es la que contendrá las medidas para crear posteriormente los indicadores
86
decisión sobre la granularidad de las tablas de hechos también determinará la granularidad de
cada una de las tablas de dimensión. Por ejemplo, si la granularidad de la tabla de hechos
Ventas es la de las ventas realizadas en cada línea de factura, entonces la granularidad de la
dimensión producto será los detalles del producto correspondiente a una línea concreta. Para
que el lector entienda estos conceptos se ha definido la granularidad de la perspectiva
CLIENTE:
OCRD.- En esta tabla están todos los clientes o Business Partners como los identifica SAP. De
esta tabla nos interesan los siguientes campos:
CardCode.- Es la clave primaria de la tabla y representa un código único para
identificar a los clientes.
CardType.- En SAP un cliente puede tomar tres roles, Cliente, Proveedor o un
cliente potencial.
ShipToCode.- En esta tabla solo se guardan aquella dirección que el cliente
elige como principal, donde quiere que se le envié la mercancía o la factura. La
dirección marcada como principal se le asocia un nombre para identificarla y es la que
se almacena en este campo.
MailAddres.- Es la calle del destinatario de la mercancía. Esta calle pertenece a
la dirección elegida por el cliente como principal.
MailCity.- Es la ciudad del destinatario de la mercancía. Esta ciudad pertenece
a la dirección elegida por el cliente como principal.
MailCount.- Es el municipio del destinatario de la mercancía. Este municipio
pertenece a la dirección elegida por el cliente como principal.
MailCounttr.- Es el país del destinatario de la mercancía. Este país pertenece a
la dirección elegida por el cliente como principal.
State2.- Es la provincia del destinatario de la mercancía. Esta provincia
pertenece a la dirección elegida por el cliente como principal.
CRD1.- Un cliente puede tener más de una dirección, esto ocurre porque puede tener varias
tiendas. En esta tabla se almacena todas las direcciones del cliente.
CardCode.- Es la clave principal de la tabla y es el campo que vincula la tabla
CRD1 con la OCRD.
AdresType.- Indica si la dirección almacenada en esa fila hace referencia al
lugar donde se entrega la mercancía o por el contrario hacer referencia al lugar donde
se va a entregar.
Address.- Es el nombre de la dirección.
County.- Municipio al que pertenece el cliente.
Country.- País al que pertenece el cliente.
State.- Provincia a la que pertenece el cliente.
City.- Ciudad a la que pertenece el cliente.
U_Isla.- Isla a la que pertenece el cliente.
OTER.- Esta tabla almacena todos los territorios a los que pertenece un cliente.
TerritryID.- Es la clave primaria de la tabla e identifica unívocamente a un
territorio. Este campo relaciona la tabla OTER con la tabla OCRD.
87
88 Chapter I
Descript.- Es el Nombre del territorio.
OCRG.- Tabla que identifica el sector al que pertenece el cliente.
GroupCode.- Clave primaria que identifica unívocamente un sector. Este campo
relaciona la tabla OCRG con la tabla OCRD.
GroupType.- Tipo de sector.
GroupName.- Nombre del sector al que pertenece el cliente.
OOND.- Tabla que recoge los subsectores a los que pertenece un cliente.
IndName.- Nombre del subsector.
II.2.1.2.2.4 Modelo Conceptual Ampliado
En este paso se va a ampliar el modelo conceptual, esto va ayudar a tener una
referencia muy visual de que campos del OTLP conforman una perspectiva y cuáles
son los campos o medidas que se necesitan para crear el indicador. Con este fin se
adjunta debajo de cada perspectiva o dimensión los campos seleccionados y bajo
cada indicador su respectiva fórmula de cálculo.
Figura 37: Modelo conceptual ampliado Gestión de Ventas
88
II.2.1.2.3 Fase 3: Modelo Lógico del DW
Seguidamente, se diseña el modelo lógico de la estructura del Data Warehouse,
teniendo como punto de apoyo el modelo conceptual que ya ha sido creado. Lo primero
que se debe hacer es definir el tipo de modelo que se utiliza, en segundo lugar hacer
un estudio de cómo se van a diseñar las tablas correspondientes a las dimensiones y
hechos. Por último, se realiza las uniones oportunas entre dichas tablas.
II.2.1.2.3.1 Tipo de Modelo Lógico del DW
Es importante seleccionar el tipo de esquema que se utiliza para soportar la estructura
del Data Warehouse, que se adecue mejor a los requerimientos y necesidades de los
usuarios. Una decisión correcta entre un esquema en estrella, constelación o copo de
nieve es importante ya que afecta considerablemente la elaboración del modelo lógico.
En el caso de estudio se optó por un esquema en copo de nieve debido a que las
perspectivas o dimensión se van organizar jerárquicamente. Además este tipo de
esquema nos da la posibilidad de segregar los datos de las tablas de dimensiones y
proveer un esquema que sustente los requerimientos de diseño, hace una mejor
utilización del espacio y, al estar normalizadas las tablas dimensiones, requiere menos
esfuerzos de diseño.
II.2.1.2.3.2 Tablas dimensiones
Las dimensiones establecen el contexto para realizar preguntas acerca de los hechos
contenidos en la tabla de hechos. Un conjunto bien construido de dimensiones hace
que el Data Warehouse sea comprensible y fácil de utilizar. Un conjunto de
dimensiones incompleto o que no se presente adecuadamente reducirá la utilidad que
el Data Warehouse tiene para la organización. En este apartado se va a proceder a
diseñar las tablas dimensiones que forman parte del Data Warehouse.
Cada perspectiva definida en el mapa conceptual corresponde con una tabla
dimensión. Para el caso práctico que se está abordando se ha hecho lo siguiente:
Se elige un nombre que identifique la tabla dimensión
Se añade un campo que represente su clave principal
Se definen las jerarquías dentro de las dimensiones
Se redefinen los nombre de los campos si es que no son lo bastante intuitivo
Las jerarquías definidas que siguen las dimensiones se observa en la Figura 38.
89
90 Chapter I
Figura 38: Jerarquía dimensión
Al haber elegido un tipo de esquema en copo de nieve, aquellas tablas de dimensión
donde existen jerarquías, deberán ser normalizadas. Se toma como ejemplo la
siguiente tabla dimensión y sus respectivas relaciones “padre-hijo” entre sus campos:
Figura 39: Jerarquía Dimensión Geografía
Entonces, al normalizar se obtiene las siguientes dimensiones (ver Figura 40, Figura 41, Figura
42, Figura 43, Figura 44, Figura 45 y Figura 46) para cada jerarquía de dimensión.
Figura 40: Dimensión Unidad de Negocio
90
Figura 41: Dimensión Tiempo
Figura 42: Dimensión Cliente
Figura 43: Dimensión Gestión de Ventas
Figura 44: Dimensión Canal
Figura 45: Dimensión Geografía
91
92 Chapter I
Figura 46: Dimensión Producto
II.2.1.2.3.3 Tablas de hechos
Seguidamente de van a definir las tablas de hechos, que son las que almacenan las
medidas a través de las cuales se constituyen los indicadores de estudio.
Es importante destacar que las tablas de hechos deben contener solamente valores
numéricos y aditivos, esto es debido a que en muy pocas oportunidades se harán
consultas por un solo registro de la tabla de hechos, lo común es traer cientos o quizás
miles de registros a la vez, y en estos casos la única cosa útil por hacer es sumarlos.
En un esquema copo de nieve se deben realizar los siguientes pasos:
Se asigna un nombre a la tabla de hechos que represente la información
analizada, área de investigación, negocio enfocado. En el presente estudio es
la tabla de hechos de Ventas.
Se define su clave primaria, que se compone de la combinación de las claves
primarias de cada tabla de dimensión relacionada.
Se crean tantos campos de hechos como medidas seleccionadas en el mapa
conceptual necesarias para crear los indicadores definidos en el modelo
conceptual y se les asigna un nombre representativo, siendo los siguientes:
Tabla 50: Conversión de nombres de los campos (medidas)
seleccionadas en el OLTP
Nombre del campo (medida) real Nombre en la tabla hecho
Quantity Cantidad
GrossBuyPr Precio Coste
INVPrice Precio de Venta
DiscPrcnt DtoDocumento
LineTotal LíneaTotal
92
Figura 47: Esquema del diseño de la tabla de hechos
Una vez seleccionados los hechos, es necesario re-examinarlos para determinar si
existe la posibilidad de utilizar valores precalculados. Un ejemplo de la necesidad de
almacenar valores precalculados es el que surge en casos como el presente donde la
tabla de hecho está basada en facturación o ventas. En el caso de estudio, se ha
añadido como hecho precalculado los que se observan en la Tabla 51.
Tabla 51: Hechos precalculados
Nombre en la tabla hecho Fórmula
PrecioCosteXCantidad Cantidad * PrecioCoste
PrecioVentaXCantidad Cantidad * PrecioVenta
TotalVentaLinea LineaTotal –( (LineaTotal *DtoDocumento)/100)
La tabla de hechos resultante se muestra en la Figura 48.
Figura 48: Diseño de la tabla de Hechos de Venta
93
94 Chapter I
II.2.1.2.3.4 Uniones
A continuación se hacen las uniones pertinentes entre las tablas dimensiones y el
hecho, observándose el resultado en la Figura 49.
Figura 49: Primera aproximación al diseño lógico del Data Warehouse.
La Figura 49 muestra una primera aproximacion al diseño lógico del Data Warehouse y
es una “primera aproximación” porque hubieron varias hasta conseguir un diseño que
se ajustará a los requerimientos exigidos. Un ejemplo claro está en la Dimensión
Unidad de Negocio, ya que cuando se hizo la carga de los datos resulta que el cliente
no realiza distincion entre Sucursal y Delegación, por lo tanto, se decide eliminar la
Delegacion y solo almacenar la Sucursal a la que pertenece el cliente. Este cambio se
puede apreciar en la Tabla 52. Otro ejemplo se aprecia en la Tabla 53, con respecto la
dimensión geografía, finalmente solo se almacena el Pais y la Provincia del cliente
debido a que en la base de datos SAP los campos Isla estaban vacíos, y tanto el
campo municipio como ciudad eran campos que se rellenaban por los usuarios, lo que
significa que se encontraban casos de no-normalizada información al tener, por
ejemplo, S/C de Tenerife escrito de 3 formas distintas —S/C de Tenerife, Santa Cruz de
Tenerife, Sta. Cruz de Tenerife— aunque existía la solución de imputación de datos.
Finalmente se opta por almacenar solo el pais y la provincia.
La Figura 50 muestra el esquema lógico del Data Warehouse final.
94
Tabla 52: Comparación Dimensiones Unidad de Negocio
Primera aproximación ResultadoFinal
Tabla 53: Comparación Geografía
Primera aproximación ResultadoFinal
Figura 50: Esquema lógico del Data Warehouse
95
96 Chapter I
II.2.1.2.4 Fase 4: Integración de datos
Una vez construido el modelo lógico, se debe proceder a poblarlo con datos, utilizando
técnicas de extracción, transformación y carga (ETL). Posteriormente se procede a
definir las reglas y políticas para su respectiva actualización, así como también los
procesos que se lleven a cabo.
II.2.1.2.4.1 Extracción
Es aquí donde, basándose en las necesidades y requisitos de los usuarios, se exploran
las diversas fuentes OLTP que se tengan a disposición y se extrae la información que
se considere relevante al caso.
Si los datos operacionales residen en un SGBD Relacional, el proceso de extracción se
puede reducir a, por ejemplo, consultas en SQL o rutinas programadas. En cambio, si
se encuentran en un sistema no convencional o fuentes externas nos encontramos con
el inconveniente de que cada sistema separado puede usar una organización diferente
de los datos o formatos distintos. La extracción convierte los datos a un formato
preparado para iniciar el proceso de transformación.
Una vez que los datos son seleccionados y extraídos, se guardan en un
almacenamiento intermedio, de esta manera se podrán manipular los datos sin
interrumpir ni paralizar los procesos del OLTP, ni tampoco el DW.
Un requerimiento importante que se debe exigir a la tarea de extracción es que ésta
cause un impacto mínimo en el sistema origen. Si los datos a extraer son muchos, el
sistema de origen se podría ralentizar e incluso colapsar, provocando que éste no
pueda utilizarse con normalidad para su uso cotidiano. Por esta razón, en sistemas
grandes las operaciones de extracción suelen programarse en horarios o días donde
este impacto sea nulo o mínimo. A efectos de nuestro caso de estudio los datos residen
en un solo SGBD con lo cual este proceso resultó bastante sencillo.
En la Figura 51 se puede ver un ejemplo muy simple de extracción y carga de datos en
un Data Warehouse. En SAP la tabla OCRY contiene la información referente a Países,
extrayéndolos a través de una consulta SQL —ver Figura 52— y almacenándola en la
subdimensión País (SdPaís) en el Data Warehouse.
Figura 51: Ejemplo de extracción con SSIS
96
Figura 52: Consulta a la base de datos de SAP para extraer los países almacenados en la tabla OCRY
II.2.1.2.4.2 Transformación
La fase de transformación aplica una serie de reglas de negocio o funciones sobre los
datos extraídos para convertirlos en datos que serán cargados. Algunas fuentes de
datos requerirán alguna pequeña manipulación de los mismos. Los casos más
comunes en los que se debe realizar integración, son los siguientes:
Codificación
Medida de atributos.
Convenciones de nombramiento.
Fuentes múltiples.
Los procesos de Limpieza de Datos (Data Cleanning) y Calidad deDatos.
Hay que evitar que el DW sea cargado con valores faltantes o anómalos, al igual que
también se deben establecer condiciones y restricciones para asegurar que solo se
utilicen los datos de interés.
Para el caso de estudio, sólo se tuvo que centrar en el último punto “Procesos de
Limpieza de Datos” debido a que se parte de una única fuente de datos. Se llevaron a
cabo los siguientes procesos de limpieza de datos, como muestra la Tabla 54.
Tabla 54: Transformaciones llevadas a cabo en el proceso ETL
Acciones Descripción
Valores nulos Hubo la obligación de renombrarlos como “Sin valor”, debido a que el cliente quiso
contemplar ciertas perspectivas de análisis para las cuales no almacenaba valores.
Se tomó esta decisión en vez de omitirlos para que el cliente, al comprobar los
resultados, pudiera corregir el error y rellenar los campos que son objeto de interés
para su análisis y así poder llevar a cabo su objetivo.
Codificar
valores
Aquellos campos cuyo contenido no poseía una descripción lo suficientemente
significativa se sustituyó por una que si lo fuese, como fue el caso del tipo de
interlocutor comercial que posee SAP. Este campo en la base de datos original
puede tomar los siguientes valores: C, S, L y, como se puede observar, no aportan
97
98 Chapter I
Tabla 54: Transformaciones llevadas a cabo en el proceso ETL
Acciones Descripción
significado alguno, sustituyéndolos por Cliente, Proveedor y Leads.
Conversión tipo Se realizaron las conversiones de tipo de dato oportunas para poder almacenar los
datos en el Data Warehouse
Calcular totales
de múltiples
filas de datos
Se creó un nuevo campo TotalVentaLinea a partir de LineTotal y DiscPrcnt.
Se creó un nuevo campo PrecioCosteXCantidad a partir de Cantidad y PrecioCoste
Se creó un nuevo campo PrecioVentaXCantidad a partir de Cantidad y PrecioVenta
En la Figura 53 se puede ver una serie de transformaciones antes de cargar los datos
en el Data Warehouse. En SAP, la tabla OSLP almacena la información referente a los
empleados, pero hay campos como es el campo memo donde se guarda el
departamento al que pertenece dicho empleado, que permite valores nulos. En la
Figura 54 se puede observar como se ha programado la caja “Valores nulos” para
sustituirlos por la cadena “SinValor”.
Figura 53: Transformación de valores nulos de la tabla OSLP de SAP
98
Figura 54: Sustitución de nulos por la cadena “Sin Valor” del campo memo perteneciente a la tabla OSLP de SAP
II.2.1.2.4.3 Carga
Esta función se encarga, por un lado de realizar las tareas relacionadas con:
Carga Inicial
Actualización o mantenimiento periódico
La carga inicial, se refiere precisamente a la primera carga de datos que se realiza al
Almacén de Datos. Por lo general, esta tarea consume un tiempo bastante
considerable, ya que se deben insertar registros que han sido generados
aproximadamente y, en casos ideales, durante más de cinco años.
En el momento de realizarla, primero se cargan los datos de las dimensiones y luego
las tablas de hechos, teniendo en cuenta siempre, la correcta correspondencia entre
cada elemento. En el caso en que se esté utilizando un esquema copo de nieve, cada
vez que existan jerarquías de dimensiones, se comienza cargando las tablas de
dimensiones del nivel más general al más detallado.
99
100 Chapter I
Figura 55: Carga del almacén de datos
Antes de realizar una nueva actualización, es necesario identificar si se han producido
cambios en las fuentes originales de los datos recogidos, desde la fecha del último
mantenimiento, a fin de no atentar contra la consistencia del DW. Para efectuar esta
operación, se pueden realizar las siguientes acciones:
Cotejar las instancias de los OLTP involucrados.
Utilizar disparadores en los OLTP.
Recurrir a Marcas de Tiempo o Time Stamp en los registros de los OLTP.
Comparar los datos existentes en los dos ambientes (OLTP y DW).
Hacer uso de técnicas mixtas.
Las políticas de actualización que ha convenido con los usuarios son los siguientes:
La información se actualiza cada viernes por la noche, esto es así debido a que
cada lunes el cliente necesita saber cómo fueron sus ventas la semana pasada
y, en el caso de que fuera necesario, qué acciones correctivas debe aplicar.
Las dimensiones son todas lentamente cambiantes de Tipo1, cuando un
registro presente un cambio en alguno de los valores de sus campos, se debe
proceder simplemente a actualizar el dato en cuestión, sobrescribiendo el
antiguo, excepto la dimensión cliente que es de Tipo2 lo que requiere que se
agreguen algunas columnas adicionales a la tabla de dimensión, para que
almacenen el historial de cambios.
Los datos de la tabla dimensión tiempo se cargan de manera incremental
teniendo en cuenta la fecha de la última actualización.
II.2.1.2.5 Fase 5: Creación de Cubos Multidimensionales
100
Los cubos multidimensionales son una representación del Data Warehouse, este
representa o convierte los datos planos que se encuentran en filas y columnas, en una
matriz de N dimensiones. Los objetos más importantes que se pueden incluir en un
cubo multidimensional, son los indicadores, atributos y jerarquías. En nuestro caso de
estudio se crea el cubo de Ventas como se puede ver en la Figura 56.
Figura 56: Cubo de Ventas
Como se puede observar en la Figura 57 se ha resaltado en un cuadrado de color rojo
unos valores denominados miembros calculados que pertenecen a una dimensión o un
grupo de medida que se definen según una combinación de datos del cubo,
operadores aritméticos, números y funciones. Las definiciones de miembros calculados
se almacenan en cubos pero sus valores se calculan en el momento de la consulta.
Estos miembros nos van a facilitar crear los KPI de Beneficio total, Variación de Ventas
y Variación del Beneficio donde la Tabla 55 ayuda a aclarar estos conceptos.
Tabla 55: Miembro calculado con su fórmula y la relación con el cálculo de KPI
Nombre Miembro Calculo Miembro Calculo KPI
Measure.Beneficio
PrecioVentaXCantidad –[(PrecioCosteXCantidad*100)/PrecioVentaXCantidad]
Es una sumarización de
Measure.Beneficio
Measure.Variacion MeasureBeneficio periodo Es una sumarización de
101
102 Chapter I
Beneficioactual / MeasureBeneficio
periodo anteriorMeasure.VariaciónBeneficio
Measure.Variacion
Ventas
Measure.VariacionVentas
periodo actual /
Measure.VariacionVentas
periodo anterior
Es una sumarización de
Measure.VariacionVentas
II.2.1.2.6 Fase 6 Implementación: Sql Server 2008 R2 IntegrationServices
Microsoft Integration Services es una plataforma para la creación de soluciones
empresariales de transformaciones de datos e integración de datos. Integration
Services sirve para resolver complejos problemas empresariales mediante la copia o
descarga de archivos, el envío de mensajes de correo electrónico como respuesta a
eventos, la actualización de almacenamiento de datos, la limpieza y Minería de Datos y
la administración de objetos y datos de SQL Server.
Integration Services puede extraer y transformar datos de muchos orígenes distintos,
como archivos XML, archivos planos y orígenes de datos relacionales, y,
posteriormente, cargarlos en uno o varios destinos. Las herramientas gráficas de
Integration Services se pueden usar para crear soluciones sin escribir una sola línea de
código.
En los procesos ETL en estudio, se utiliza Integration Services para extraer los datos
de orígenes. Se transforman, limpian y se almacenan, posiblemente en un área
intermedia, y finalmente en el Data Warehouse, siendo ambas bases de datos
relacionales, alimentadas con datos de los orígenes citados anteriormente. También se
realiza tareas de procesamiento periódico de los cubos de Analisys Services, los cuales
tendrán como origen de datos el Data Warehouse.
Figura 57: Integration Services
102
Por último, destacar que este tipo de herramientas son muy potentes. Los desarrollos
son muy rápidos y permiten crear una gran cantidad de procesos en reducidos periodo
de tiempo de desarrollo e implementación. Es una herramienta muy intuitiva y muy fácil
de usar. Pero utilizarla sin un previo diseño puede hacer que su potencialidad y
rendimiento disminuya.
Integration Services es un servicio independiente que se instala y ejecuta en un
servidor, y será el encargado de almacenar y ejecutar los diversos procesos que se
hayan definidos. Estos procesos se almacenan en unos archivos XML que contienen
toda la información de ese proceso y que se llaman paquetes.
En la Tabla 56 se enumeran una serie de características destacables del producto.
Tabla 56: Características del Integration Services
Permite la integración con Sistemas de Bases de Datos y con ficheros
Obtiene un alto rendimiento al mantener los datos en memoria, además permite concurrencia y
paralelismo
Permite gestionar alertas y notificaciones
Tiene tareas de “data profiling”, limpieza y minería de texto y datos
Desde el punto de vista del desarrollador, dispone de un entorno de desarrollo con el que se
sentirá muy familiarizado.
Como principales inconvenientes indican los que figuran en la Tabla 57.
Tabla 57: Inconvenientes del Integration Services
Falta de documentación que explique en detalle la herramienta, es decir, que abarque problemas
reales y no solamente los ideales.
La necesidad de contar con una tecnología con altos requisitos.
Poca información de cómo optimizar el ETL, es decir, que componentes se deben usar solo en
caso necesario porque ralentizan el proceso, o como sustituirlos por otros.
A continuación la Figura 58 muestra la ejecución del Integration Services: las cajas,
marcadas con color verde, indican que ya han sido ejecutadas y han tenido éxito, las
amarrillas están en ejecución y las blancas están a las espera. En caso de que durante
el proceso falle alguna caja cambiará el color de amarillo a rojo y terminará la
ejecución.
103
104 Chapter I
Figura 58: Ejecución del SSIS
Como se puede ver en la Tabla 59 se han medido los tiempos de ejecución del proceso
ETL con el programa Interation Services y que ha sido ejecutado con dos máquinas
diferentes —la Tabla 58 muestra las características de cada máquina.
Tabla 58: Característica de las máquinas donde se ejecutó el ETL
Máquina A
Máquina B
Tabla 59: Estadísticas de ejecución
Tiempo máquina A Tiempo máquina B
Ejecución ETL 00:02:18.575 00:31:02:04
Una vez poblado el almacén de datos ocupó 46MB y contiene la información referente
a 4 años, al realizar actualizaciones semanales se estima que pueda crecer un 0,2%
semanal, por lo tanto es importante el lugar físico donde se almacene y que cuente con
escalabilidad.
II.2.1.2.7 Fase 7 Implementación del Modelo lógico del DW SQL SAS
Microsoft, incluye Analysis Services como un componente de SQL Server, que va a
permitir cubrir una serie de necesidades que tienen los usuarios de negocio a la hora
de obtener información de nuestros sistemas. Se ha sintetizado dichas necesidades en
la Tabla 60.
Tabla 60: Necesidades cubiertas por SSAS
104
Consultas ad-hoc Esto implica que el sistema permite al usuario personalizar una consulta en
tiempo real, en vez de estar atado a las consultas prediseñadas para informes.
Generalmente las consultas ad hoc permiten a los usuarios con poca
experiencia en SQL tener el mismo acceso a la información de la base de
datos, para esto los sistemas que soportan ad hoc poseen GUIs para
generarlas.
Autoservicio de
informes Permite a los usuarios realizar sus propios informes
Fuente de
información de gran
calidad
Se debe ofrecer al usuario una información limpia, amigable, elaborada y
confiable, que le permita obtener información analítica para reflejarla en sus
informes
Tiempo de respuesta
rápidos
Las consultas ad-hoc como los informes deben tener un tiempo de respuesta
rápido
Minería de datos Segmentar o hacer predicciones en base a grandes volúmenes de datos
La característica de datos multidimensionales de Microsoft SQL Server Analysis
Services le permite diseñar, crear y administrar estructuras multidimensionales que
contienen detalles y datos agregados de numerosos orígenes de datos, como bases de
datos relacionales, en un único modelo lógico unificado compatible con cálculos
integrados.
Los datos multidimensionales de Analysis Services proporcionan un análisis rápido,
intuitivo y descendente de grandes cantidades de datos basado en este modelo de
datos unificado, que puede llegar a los usuarios en múltiples idiomas y monedas. Esta
característica funciona con Data Warehouse, Data Marts, bases de datos de
producción y almacenes de datos operativos, y es compatible con el análisis de datos
históricos y en tiempo real.
La Tabla 61 describe las características clave de Analysis Services.
Tabla 61: Ventajas Analisys Services
Facilidad de uso
Extensa interfaz de usuario con asistentes
Modelo flexible de datos y eficaz para la definición y almacenamiento de cubos
Escalabilidad Arquitectura proporciona una gran variedad de escenarios de almacenamiento y
una solución automatizada para el síndrome de explosión de datos que existe en las tecnologías
OLAP tradicionales.
Integración de herramientas de administración, seguridad, orígenes de datos y caché de cliente-
servidor.
API ampliamente compatibles y arquitectura abierta
Compatibilidad con aplicaciones personalizadas
Los principales inconvenientes de dicha tecnología se muestran en la Tabla 62.
105
106 Chapter I
Tabla 62: Inconvenientes Analisys Services
Resulta muy difícil cruzar datos de varios Cubos Olap
Dificultad a la hora de explotar la información cuando no usamos Microsoft Excel
Falta de documentación que explique en detalle la herramienta, es decir, que abarque problemas
reales y no solamente los ideales.
La Figura 59 muestra una consulta sobre el Total de Ventas que han ocurrido desde
que se creó la empresa.
Figura 59: Consulta sobre el Total de Ventas al cubo
El cubo ocupa 23.74MB en almacenamiento físico, recordando que esto se realiza en
un vector multidimensional, ver apartado Data Warehouse Manager, al igual que en el
almacén de datos se deben tomar medidas de escalabilidad para prevenir posibles
problemas futuros de almacenamiento.
II.2.1.2.8 Representación
En este punto se va a estudiar como representar la información que se quiere analizar.
Para ello se van a usar dos herramientas: una de generación de informes y otra para la
creación de cuadros de mando.
106
En este proyecto no se llegó a generar informes debido a que no dio tiempo y el cliente
estaba más interesado en la creación de cuadros de mando, aun así, se estudia dos
herramientas para la generación de informes.
II.2.1.2.8.1 Creación de informes
A la hora de crear informes se estudiaron dos herramientas: Reporting Services y
Microsoft Excel.
Reporting Services (SSRS).- Es una plataforma de creación de informes
basada en servidos que ofrece una completa funcionalidad de creación de informes
para una gran variedad de orígenes de datos. Reporting Services contiene un
completo conjunto de herramientas para crear, administrar y entregar informes, así
como interfaces de programación de aplicaciones con las que los desarrolladores
pueden integrar o extender el procesamiento de los datos y los informes en
aplicaciones personalizadas.
En la Figura 60 se muestra un informe generado con dicha herramienta.
Figura 60: Informe generado con Reporting Services
Microsoft Excel 2007 y 2010. Viene con la posibilidad de generar informes
dinámicos, partiendo de tablas dinámicas que no son más que consultas a un cubo
OLAP. Esta conexión con el cubo generado por el Analysis Services va a permitir
realizar una gran variedad de consultas al sistema. Con un informe de tabla dinámica
puede resumir, analizar, explorar y presentar un resumen de los datos de la hoja de
cálculo o un origen de datos externos. Este tipo de informe es especialmente útil
cuando tiene una larga lista de cifras para sumar y los datos agregados o subtotales
107
108 Chapter I
podrían servir para mirar los datos desde perspectivas diferentes y comparar las cifras
de datos similares. A continuación en la Figura 61 se puede ver un informe de tabla
dinámica generado en Excel.
Figura 61: Informe generado con Microsoft Excel
Como se ha comentado, no se genera ningún informe con dicha herramientas, pero si
se hizo una labor de investigación, donde las conclusiones se reflejan en la Tabla 63.
Tabla 63: Comparación Reporting Services vs Excel
Reporting Services Microsoft Excel
En los esquemas permite hasta 7 niveles de
anidamiento
Más fácil de usar. Muy intuitivo
Si el elemento de informe que controla si la
visualización de otro elemento va activarse o
desactivarse no está en la fila o en la columna
anterior o siguiente al elemento controlado, el
esquema también se deshabilita.
Procesa millones de filas con casi el mismo
rendimiento que mil filas
Informes más elaborados con un aspecto visual
muy atractivo
Crear aplicaciones que se incrusten o vinculen
a un explorador Web para presentar y
manipular el informe mediante direcciones URL.
Crear otras extensiones para el procesamiento,
entrega y procesamiento de datos mediante
Microsoft .NET Framework
Crear aplicaciones para administrar uno o
varios servidores de informes mediante la
interfaz de servicios Web.
Otra de las grandes características de
Reporting Services, es que puede distribuir el
reporte en distintos formatos, como hojas de
108
Excel, documentos PDF, texto, XML, etc.
II.2.1.2.8.2 Creación de cuadros de mando
A la hora de llevar a cabo el desarrollo de un cuadro de mando integral para la solución
de BI, se han analizado 4 herramientas:
1. Crystal Xcelsius 2008 (SAP Business Objects)
2. Microsoft Performance Point
3. Silverlight 4.0
4. Microsoft Office Excel 2007
Crystal Xcelsius 2008
Es un software específico para la implementación de cuadros de mando. A través de
una interfaz gráfica sencilla permite convertir las hojas de cálculo Excel en cuadros de
mando interactivos basados en la tecnología Adobe Flash. Por iniciativa de la empresa
se llegó a implementar un cuadro de mandos como se puede ver en la Figura 62.
Figura 62: Cuadro de mando implementado en Xcelsius
Finalmente se descartó el uso de esta herramienta por las siguientes razones:
El coste de la licencia
Se observa bastante lentitud del software e incomodidad a la hora de trabajar conlas tablas de Excel incrustadas en el programa
109
110 Chapter I
Fallos en la importación de los datos desde hojas Excel externas
Imposibilidad de alimentar los gráficos directamente con consultas en MDX directascontra la base de datos analítica, con el fin de integrar el cuadro de mando en unaplataforma web y no como un informe dinámico
Microsoft Performance Point
Performance Point es un servicio, de Microsoft SharePoint 2010, de administración,
supervisión y análisis empresarial. Cuenta con herramientas para la creación de
paneles o Dashboards, cuadros de mando o Scorecards, informes e indicadores de
rendimiento KPIs. Se ha descartado también el uso de esta solución por las siguientes
razones:
Coste de las licencias
Aumento de tiempos en el desarrollo ya que conlleva la implantación de unaplataforma de SharePoint
Microsoft Silverlight 4.0
Silverlight 4.0 es un complemento gratuito para los navegadores de Internet basado en
la plataforma Windows que agrega nuevas funciones multimedia como la reproducción
de vídeos, gráficos vectoriales, animaciones,.. de forma similar a lo que hace Adobe
Flash. Para programar aplicaciones en esta tecnología se hace uso del IDE Visual
Studio 2010. Pero el tiempo de desarrollo y preparación necesario para la
implementación de un cuadro de mando desde cero, hicieron que se descartara el uso
de la misma.
Microsoft Office Excel 2007
Para llevar a cabo el desarrollo de los se ha decido elegir el programa de Microsoft
Office Excel 2007 por las siguientes razones:
Debido a su sencillez e interfaz de conexión bien definida con los cubos deSSAS
Por su potencia y gran usabilidad en el mundo empresarial
La curva de desarrollo y aprendizaje respecto a otras soluciones, disminuyeconsiderablemente permitiendo cumplir los plazos del proyecto
Una vez seleccionada la herramienta para implementar el cuadro de mandos se hizo
un estudio previo de cuál era la mejor la representación, para mostrar los indicadores
110
analizados. Para ello se ha seguido una serie de pautas recomendadas por
Stephen Few 29 con el fin de trasmitir la información de forma eficaz, siendo:
Se ha prestado especial atención en los colores utilizados para el diseño delcuadro de mandos, debido a que el 10% de los hombres y 1% de mujeres sondaltónicos, siendo una de las prácticas más habituales la representación demedidas de alertas a través de los colores rojo, amarillo y verde, pudiendo llevar alas personas que sufren este síndrome a la toma de decisiones empresarialesequivocadas.
Figura 63: percepción de los colores rojo, verde, amarillo por parte de las personas daltónicas
Por lo que se decidió utilizar colores que puedan permitir diferenciar tonalidades por
parte de las personas daltónicas o el uso tipo de gráfico donde se resalte la tendencia
positiva o negativa como se ve en la Figura 64.
Figura 64: se observa las representaciones adaptadas para personas daltónicas
Por otro lado se ha hecho una selección de todos aquellos gráficos que se adaptanmejor, para la representación de información de negocio atendiendo a lossiguientes criterios:
1. Gráfico de bala: Este grafico fue diseñado por Stephen Few, creadoespecíficamente para ser representado en cuadros de mando. Permite deforma rápida, eficaz y ocupando muy poco espacio identificar si el indicadorque se quiere medir es bueno o malo dentro de un determinado contexto. Estegráfico no se ha llegado a utilizar debido a que no venía como grafico nativo enExcel 2007, pero se considera que es un buen grafico a tomar en cuenta. Enla Figura 65 tenemos un ejemplo de gráfico de viñeta
Figura 65: Ejemplo de gráfico de bala
29 Stephen Few tiene más de 20 años trabajando como innovador en el mudo del IT, como educador y consultor. Hacentrado sus estudios en la visualización para el análisis de los datos y en la comunicación de información de negocio.
111
112 Chapter I
2. Gráfico de barras: Los gráficos de barra se han seleccionado ya que permitenla comparación de las medidas representadas, así como la rápida localizaciónde los datos más significativos al estar ordenados. Además son el tipo degráfico que predomina en Excel 2007
3. Gráfico de pila: Es una variación al gráfico de barras y es recomendable parauna única serie dividida en diferentes partes.
4. Gráfico de línea: Ideal para la representación de tendencias, fluctuaciones yciclos a lo largo del tiempo, así como un conjunto de datos varía en relación aotro.
5. SparkLines: Este grafico es idéntico a uno de línea pero en cambio serepresenta sin etiquetado ni escala, normalmente al lado de un indicador con elfin de representar la tendencia que ha seguido a través de un periodo detiempo.
Tabla 64: Ejemplo de gráfico Sparklines
6. Tabla: En una tabla simple muchas veces se puede representar la mismainformación que en un gráfico complejo y ocupando mucho menos espacio.
Se estudió cada uno de los indicadores y se realizó una clasificación atendiendo a los
criterios antes mencionados.
Tabla 65: Indicadores y su representación grafica
Indicadores Tipo de Grafico que se adapta mejor
Total de ventas
Gráfico de Bala (H - V)
Gráfico de Barras (H - V)
Gráfico de Líneas
SparkLines
Variación de ventasGráfico de Bala (H - V)
Gráfico de Líneas
Beneficio
Gráfico de Bala (H - V)
SparkLines
Gráfico de Barras (H - V)
Variación de BeneficioGráfico de Bala (H - V)
Gráfico de Líneas
El cuadro de mandos de Total de Ventas que se ha obtenido al final se muestra en la
Figura 66 y Figura 67.
112
Figura 66: Cuadro de mando de Total de Ventas
Figura 67: Cuadro de mando de Total de Ventas
La Figura 68 y Figura 69 muestra cuadro de mandos de Beneficio.
113
114 Chapter I
Figura 68: Cuadro de mando de Beneficio
Figura 69: Cuadro de mando de Beneficio
114
Capítulo 3. Análisis de los resultados
Resumen:
Análisis de los resultados obtenidos mediante los cuadros de mandos elaborados
3.1 Resultados
El resultado final de este proyecto queda resumido en los cuatro cuadros de mandos que se
implementaron, de esta manera se proporciona a los gerentes de una compañía una mirada
global de las prestaciones del negocio, con una sola ojeada se podrá saber cómo va la
empresa y en qué puntos de la misma se deben emprender medidas correctivas. Permite tanto
guiar el desempeño actual como apuntar al desempeño futuro.
Si analizamos uno de los cuadros de mando que se crearon para “Total de Ventas” se puede
deducir diversas conclusiones, observando de nuevo la Figura 70.
Figura 70: Cuadro de mando “Total de Ventas”
En la primera gráfica titulada “Total de ventas” se comparan las ventas de los años 2008, 2009
y 2010. Se puede observar que el año donde hubo una mayor cantidad de ventas fue en 2009.
Hay que aclarar que este cliente creo su empresa en el año 2008 y el 29 de Septiembre de ese
mismo año fue cuando comenzó a emitir facturas, por tanto es comprensible que desde Enero
a Septiembre exista esa diferencia de ventas del año 2008 con respecto al 2009; en cambio,
los meses de Octubre, Noviembre y Diciembre más o menos son similares.
115
116 Chapter I
En el año 2010 las ventas disminuyeron notablemente, sobre todo los meses de Julio a
Diciembre. Se averiguo que en esos meses hubo problemas técnicos con el programa de
facturación y no se recogieron datos.
La empresa se fijó como objetivo superar las ventas del año anterior un 2%, dando por sentado
que en el año 2008, como se acaba de crear, no se pudo comparar.
En el año 2009, si se observa la Figura 70 la gráfica con título “Objetivos 2009” indica como de
Enero a Septiembre se alcanza este objetivo, aunque este hecho no es representativo pues en
esos meses del 2008 la empresa aun no tenía ventas. En cambio sí podemos evaluar este
valor objetivo en los meses de Octubre, Noviembre y Diciembre donde se ve que es en
Noviembre del año 2009 donde supera ese 2% de objetivo con respecto al año anterior.
En el gráfico “Objetivos 2010” de la Figura 70 se puede observar como en los meses de Enero
a Junio se mantiene y, en menor o mayor medida, se cumplen los objetivos. Después del mes
de Junio, las ventas en el año 2010 bajan por la razón que ya se ha comentado y se hace
imposible alcanzar el objetivo fijado.
En la Figura 71 se observa el cuadro de mando de “Total de Ventas” pero ahora se analizan las
ventas por distintas dimensiones en el año 2009.
Figura 71: Cuadro de mando de “Total de Ventas”
En la Figura 71 en el gráfico “Total de ventas por familia de productos”, se puede observar cual
es la familia de productos que más ha vendido, familia “Productos cocidos” y la que menos es
la familia de “Productos mayoristas”. Este análisis es interesante porque quizás se debería
indagar en por qué los “Productos mayoristas” son unos de los menos vendidos ya que puede
116
interesar realizar una campaña de marketing para promocionarlos o simplemente dejar de
comercializarlos ya que no son rentables.
Si nos centramos ahora en el grafico “Total de ventas por provincia” de la Figura 71, indica que
la provincia donde ha habido un mayor número de ventas es la provincia “Sin Valor”,
¿Qué ha ocurrido? ¿Ha habido un error en el gráfico?
La respuesta es NO. Lo que ha pasado es que el usuario no ha rellenado en un gran número
de facturas del campo provincia del cliente, por tanto este caso sirve de referencia para que el
gerente, que vaya a analizar este gráfico, tome medidas para que se recojan estos valores en
el momento de la facturación, si es que le interesa estudiar el “Total de ventas por provincia”
117
118 Chapter I
Parte III. Conclusiones, Final
118
Capítulo 1. Conclusiones y posibles ampliaciones
Inicialmente, el propósito de este proyecto era implantar una solución BI integrada con
SAP BO que contemplara los procesos de Gestión de Ventas, Gestión de Finanzas,
Gestión de proyectos y Gestión de Incidencias. Sin embargo, solo se llegó a finalizar
para la Gestión de Ventas ya que el objetivo inicial quizás era muy ambicioso y el
tiempo limitado.
Se planteó, por tanto, realizar un estudio del arte inicial y una elaboración de una
metodología para el desarrollo de una solución BI.
Este proceso condujo a la consecución de los siguientes logros.
Estudio del Arte
Se realizó una labor bastante importante de consultoría para el estudio y análisis del
proyecto. Desatancando tres puntos muy importantes:
Estudio de aplicaciones existentes en el mercado y demanda de mercado
respecto a funcionalidades.
Tecnologías destacadas en el sector de BI
Demanda de mercado de soluciones BI
Entendemos que ésta es una de las partes más importantes y duras del proyecto, ya
que de aquí se construye la base de todas las funcionalidades y desarrollo del mismo.
Análisis y obtención de requisitos funcionales
Una vez realizado el análisis del estado del arte se obtienen una serie de requisitos
funcionales con ITOP MC y los miembros del equipo de trabajo, con el fin de satisfacer
la necesidad planteada en el proyecto.
Tras evaluar los requisitos obtenidos se pasa a desarrollarlos mediante la metodología
de desarrollo ágil SCRUM, obteniendo el Product Backlog del proyecto priorizándolo.
La dinámica de trabajo con esta metodología ha sido enriquecedora a la vez que nos
ha llevado a tener un buen ritmo de trabajo en colaboración con ITOP MC.
119
120 Chapter I
Elaboración de una metodología propia para la creación de unasolución BI
Esta metodología, elaborada con base a la metodología “HEFESTO”, fue de vital
importancia para dotar al proyecto de suficiente robustez a la hora de crear una
solución BI para el proceso de Gestión de Ventas. Una gran ventaja es que se adapta
muy bien a SCRUM, lo que agiliza el proceso de implementación y una rápida
adaptación a los cambios que iban surgiendo por motivos de errores de comprensión o
cambios de tecnologías.
Implementación de la solución.
Se creó una aplicación BI para la “Gestión de Ventas” implementada con herramientas
que Microsoft ha creado para llevar a cabo este tipo de proyectos y se dejó preparada
para que pueda ser publicada en una aplicación Web para que el gerente o
responsable de la empresa pueda consultar los resultados de sus ventas en cualquier
momento. No se realizan grandes cálculos y complejos algoritmos, sin embargo, se
han concentrado grandes esfuerzos en la validación de los datos, en formatearlos de
forma adecuada y crear una serie de cuadros de mandos interactivos y dinámicos.
Posibles ampliaciones
Como posible ampliación queda implementar una solución BI para los procesos de
Gestión de Finanzas, Gestión de Proyectos y Gestión de Incidencia, así como sería
interesante integrar un módulo de Data Mining que sirve de ayuda al gerente o
responsable de la empresa a la hora de tomar decisiones.
Capítulo 2.
120
Parte IV. Bibliografía
Parte V.1. Kniberg, Henrick. . http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-
y-xp-desde-las-trincheras.pdf. [En línea] 09 de 06 de 2011.
Parte VI. 2. Dario, Bernabeu R. Investigación y Sistematización de HEFESTO:
Metodología propia para la Construcción de un Data Warehouse. [En línea] 09 de 06 de 2011.
Parte VII. 3. Commerce, Office of Government. ITIL Gestión de Servicios TI. [En línea]
05 de 01 de 2011. http://itil.osiatis.es.
Parte VIII. 4. Alexander, Michael. Crystal Xcelsius for Dummies. 2007.
Parte IX. 5. Berndtsson, M., Hansson, J., Olsson, B., Lundell, B. A Guide for Students
in Computer Science and Information Systems, Springer. 2008.
Parte X. 6. Stephen Few. Information Dashboard Design, The Effective Visual
Communication of Data. s.l. : O'Reilly, 2006.
Parte XI. 7. Doug Harts, Jim Dugan, Tricia Wilcox Almas. Microsoft SQL Server 2008
R2 Analytics & Data Visualization. s.l. : Mac Graw Hill, 2008.
Parte XII. 8. Ramos, Salvador. Microsoft Business Intelligence vea el cubo medio lleno.
s.l. : SolidQ Press, 2011.
Parte XIII. 9. Sivakumar Harinath, Matt Carroll, Sethu Meenakshisundaram, Robert
Zare, Denny Guang-Yeu Lee. Professional Microsoft SQL Server Analysis Services 2008 with
MDX. s.l. : Wiley Publishing, Inc., 2009.
Parte XIV. 10. Xavier Hacking, David Lai. SAP BusinessObjects Dashboards 4.0
Cookbook. s.l. : Packt Publishing, 2011.
Parte XV. 11. Roland Bouman, Jos van Dongen. Pentaho Solutions - Business
Intelligence and Data Warehousing with Pentaho and MySQL. s.l. : WILEY.
Parte XVI. 12. Roldán, María Carina. Pentaho 3.2 Data Integration, Beginner's Guide.
s.l. : Packt Publishing, 2010.
121
122 Chapter I
Parte XVII. 13. Erik Veerman, Jessica M. Moss, Brian Knight, Brian Knight. Microsoft®
SQL Server® 2008 Integration Services Problem–Design–Solution. s.l. : Wiley Publishing, Inc,
2010.
Parte XVIII. 14. Nanda, Ashwani. Microsoft SQL Server 2008 Integration Servicies. s.l. :
Mac Graw Hill, 2010.
Parte XIX. 15. Haselden, Kirk. Microsoft® SQL Server 2008 Integration Services. s.l. :
UNLEASHED, 2009.
Parte XX. 16. Anónimo. The Official Introduction to the ITIL Service Lifecycle. s.l. :
Published by TSO (The Stationery Office).
Parte XXI. 17. Commerce, Office of Government. ITIL Serivce Transition. s.l. : Published
by TSO (The Stationery Office).
Parte XXII. 18. —. ITIL Continual Service Improvement. s.l. : Office Government Comerce,
2009.
Parte XXIII. 19. —. ITIL Service Design. s.l. : Published by TSO (The Stationery Office).
Parte XXIV. 20. —. ITIL Service Operation. s.l. : Published by TSO (The Stationery Office).
Parte XXV. 21. ZELAZNY, GENE. Say it whit Charts. s.l. : McGraw-Hill, 2001.
Parte XXVI. 22. PARMENTER, DAVID. Key Performance Indicators, Developing,
Implementing, and Using Winning KPIs. s.l. : John Wiley & Sons, Inc., 2010.
Parte XXVII. 23. John Wiley & Sons, Inc., Hoboken, New Jersey. Business Dashboards.
s.l. : John Wiley & Sons, Inc., 2009.
Parte XXVIII. 24. Withee, Ken. Microsoft Business Intelligence for Dummies. s.l. : Wiley
Publishing, Inc, 2010.
Parte XXIX. 25. Lynn Langit, Kevin S. Goff, Davide Mauri, Sahil Malik, and John Welch.
Smart Business Intelligence Solutions with Microsoft SQL Server2008. s.l. : Microsoft Press,
2009.
Parte XXX. 26. SQL SERVER INTEGRATION SERVICES 2008 LABORATORIOS . s.l. :
INTERMEZZO BUSINESS INTELLIGENCE , 2010.
Parte XXXI. 27. Inmon, W. H. Building the Data Warehouse. s.l. : Design & Composition,
2010.
Parte XXXII. 28. Viera, Robert. Professional Microsft SQL Server 2008 Programming. s.l. :
Wiley Publishing, I nc, 2009.
Parte XXXIII. 29. Ross MistRy, Stacia MisneR. Introduciong Microsoft SQL Server 2008 R2.
s.l. : Microsoft Press, 2010.
Parte XXXIV. 30. Philo Janus, Philo Janus. Pro SQL Server 2008 Analysis Services. s.l. :
Apress, 2010.
Parte XXXV. 31. Rainardi, Vincent. Building a Data Warehouse with Examples in SQL
Server. s.l. : Apress, 2010.
Parte XXXVI. 32. Scott Cameron, Hitachi Consulting. SQL Server 2008 Analysis Services.
s.l. : Vincent Rainardi, 2009.
122
Parte XXXVII. 33. Chris Webb, Alberto Ferrari and Marco Russo. Expert Cube
Development with Microsoft SQL Server 2008 Analysis Services. s.l. : Marco Russo, 2009.
Parte XXXVIII. 34. Langit, Guy Fouché and Lynn. Foundations of SQL Server 2008 R2
Business Intelligence. s.l. : Apress, 2009.
Parte XXXIX. 35. Kimball, Joy Mundy and Marren Thornthwaite with Ralph. The Microsft
Data Warehouse Toolkit whit SQL Server. s.l. : Kimball Group, 2011.
Parte XL. 36. Anónimo. Scrum. Definición de Scrum. [En línea] 23 de 06 de 2011.
http://es.wikipedia.org/wiki/Scrum.
Parte XLI. 37. Institute, Project Management. PMBOK.
Capítulo 1.
123
124 Chapter I
Glosario de términos
A
agregación...................................................................................................................................................................26
Analysis Services..................................................................................................................................43, 102, 103, 105
Atributo.......................................................................................................................................................................64
Atributos de dimensión...............................................................................................................................................26
B
Business Intelligence.................................................................................1, 2, 3, 14, 15, 17, 38, 40, 42, 45, 55, 56, 127
business key................................................................................................................................................................24
Business Models....................................................................................................................................................20, 32
C
claves subrogadas........................................................................................................................................................24
Community Dashboard Framework.............................................................................................................................44
Cuadros de mando................................................................................................................................................33, 41
Cuadros de Mando........................................................................................................................................................3
cubo multidimensional.............................................................................................................22, 23, 26, 27, 28, 32, 99
D
Dashboards.................................................................................................................................................................43
Data Integration..........................................................................................................................................................44
Data Mining.................................................................................................................................................................44
Data Warehouse.14, 17, 18, 19, 20, 21, 22, 26, 28, 29, 30, 31, 32, 33, 34, 51, 52, 55, 56, 57, 58, 60, 86, 87, 92, 93, 95,
96, 99, 101, 103, 127
Datamarts..............................................................................................................................................................17, 34
Decision Support Systems....................................................................................................................................14, 127
Diagrama de Gantt......................................................................................................................................................53
dimensiones........................................22, 23, 24, 25, 26, 27, 28, 29, 30, 34, 45, 51, 52, 65, 86, 87, 97, 98, 99, 114, 127
dimensiones lentamente cambiantes..................................................................................................................24, 127
Drill-acros....................................................................................................................................................................32
Drill-down....................................................................................................................................................................32
Drill-through................................................................................................................................................................32
Drill-up........................................................................................................................................................................32
Dueño del producto....................................................................................................................................................49
DW...................................................................................17, 18, 19, 22, 23, 26, 30, 32, 41, 86, 87, 94, 96, 98, 102, 127
E
Eclipse.........................................................................................................................................................................42
124
ERP......................................................................................................................................................................42, 127
Esquema constelación...........................................................................................................................................23, 29
Esquema en copo de nieve....................................................................................................................................23, 28
Esquema en estrella....................................................................................................................................................28
ETL.........................................................................................................17, 21, 44, 45, 51, 52, 55, 94, 96, 101, 102, 127
Excel............................................................................................................15, 41, 42, 43, 104, 105, 106, 107, 108, 109
Executive Information Systems............................................................................................................................16, 127
F
Finanzas.................................................................................................................................................66, 77, 117, 118
G
Gartner..................................................................................................................................................................39, 40
Gestión de Incidencias............................................................................................................64, 66, 71, 72, 76, 77, 117
Gestión de Proyectos........................................................................................................62, 63, 66, 68, 76, 77, 84, 118
Gestión de Ventas.......................................................................................................................63, 66, 76, 84, 117, 118
Gráfico de bala..........................................................................................................................................................109
Grafico de barras.......................................................................................................................................................109
Gráfico de línea....................................................................................................................................................63, 109
Gráfico de pila......................................................................................................................................................64, 109
H
Hechos básicos............................................................................................................................................................26
Hechos derivado..........................................................................................................................................................26
Hefesto.............................................................................................................................56, 57, 58, 59, 61, 76, 82, 117
HOLAP.........................................................................................................................................................................31
I
Indicadores............................................................................................3, 26, 27, 51, 52, 66, 67, 68, 76, 77, 79, 99, 110
Information Technology Infrastructure Library............................................................................................................71
Informes dinámicos.................................................................................................................................................3, 33
Informes estáticos.......................................................................................................................................................33
Integration Services...........................................................................................................................................100, 101
inteligencia de negocios................................................................................................................................................3
inteligencia empresarial................................................................................................................................................3
ITOP MC....................................................................................................................36, 37, 40, 42, 45, 50, 62, 117, 127
K
Kettle...........................................................................................................................................................................44
KPI........................................................................................................................................27, 60, 65, 66, 69, 100, 127
M
Minería de Datos.........................................................................................................................................................18
MOLAP........................................................................................................................................................................31
125
126 Chapter I
O
OLAP............................................................................................................17, 31, 32, 41, 43, 44, 51, 53, 103, 105, 127
OLTP...................................................................................17, 20, 21, 30, 34, 51, 52, 55, 61, 76, 82, 83, 90, 94, 98, 127
Open Source..........................................................................................................................................................42, 44
Operational Data Store........................................................................................................................................17, 127
P
Pentaho......................................................................................................................................................42, 43, 44, 45
Performance Point.................................................................................................................................41, 42, 107, 108
PMBOK........................................................................................................................................................................68
Product Backlog.......................................................................................................................................49, 50, 51, 117
Product Owner............................................................................................................................................................36
Q
Query Manager.....................................................................................................................................................32, 55
R
Ralph Kimball.........................................................................................................................................................25, 39
Reporting..................................................................................................................................41, 43, 45, 105, 106, 107
ROLAP..........................................................................................................................................................................31
Roll-across...................................................................................................................................................................32
S
SAP..........................................................................................................36, 37, 38, 42, 45, 83, 85, 92, 95, 96, 107, 117
Sap BO.........................................................................................................................................................................38
SCD................................................................................................................................................................24, 25, 127
SCRUM....................................................................................................................................................47, 48, 49, 50, 57
ScrumMaster...............................................................................................................................................................49
SharePoint................................................................................................................................................41, 42, 44, 108
Silverlight...............................................................................................................................................41, 42, 107, 108
Sistema de Información.......................................................................................................................................14, 127
Sistemas de Información Ejecutiva..............................................................................................................................16
Sistemas Transaccionales.............................................................................................................................................14
Slowly Changing Dimensions...............................................................................................................................24, 127
solución BI..............................................................................15, 16, 17, 19, 38, 39, 40, 42, 45, 50, 51, 55, 56, 117, 118
SparkLines..............................................................................................................................................63, 64, 109, 110
SPRINT................................................................................................................................................................49, 50, 51
SQL Server 2008 R2...............................................................................................................................................40, 41
SQL Server 2008 R2 Analisys Servicies.........................................................................................................................41
SQL Server 2008 R2 Integration Services.....................................................................................................................40
SRDWM.......................................................................................................................................................................57
subdimensión..............................................................................................................................................................95
subrogate key..............................................................................................................................................................24
126
T
tabla de hechos.................................................................................................24, 25, 26, 28, 30, 32, 84, 87, 89, 90, 91
Team............................................................................................................................................................................49
V
Ventas.........................................................................................................................66, 78, 83, 90, 100, 113, 114, 117
W
WeKa...........................................................................................................................................................................44
X
Xcelsius..........................................................................................................................................................41, 42, 107
127
128 Chapter I
Índice de siglas
SIGLAS DEFINICIÓN
BI Business Intelligence o Inteligencia de Negocios
BPM Business Process Management o Gestión de Proceso de Negocio
DSS Decision Support Systems o Soporte al sistema de decisiones
DW Data Warehouse o Almacén de Datos
EIS Executive Information Systems o Sistemas de Información Ejecutiva
ERP Enterprise Resource Planning
ETL Extracción Transform Load o Extracción Transformación y Carga
ITILInformation Technology Infrastructure o Biblioteca de Infraestructura de
Tecnologías de Información
ITOP MCInformación Tecnología Organización Proceso Management
Consulting
KPI Key Performance Indicators o indicadores de rendimiento clave
ODS Operational Data Store
OLAP On-Line Analytical Processing o Procesamiento Analítico en Línea
OLTP On-Line Transaction Processing o Bases de Datos Transaccionales
PMI Project Management Institute
SAPSystem, Applications and Products o Sistemas Aplicaciones y
Productos
SDC Slowly Changing Dimensions o Dimensiones Lentamente Cambiantes
SGBDR Sistema Gestor de Base de Datos Relacional
SI Sistema de Información
128
SRDWM The SAS Rapid Data Warehouse Methodology
TI Tecnología de la Información
Apéndices
I. Actas de las reuniones con la empresa ITOP MC
129
130 Chapter I
130