UNIVERSIDAD TECNOLÓGICA EQUINOCCIAL

Transcripción

1 UNIVERSIDAD TECNOLÓGICA EQUINOCCIAL FACULTAD DE CIENCIAS DE LA INGENIERÍA CARRERA DE INGENIERÍA INFORMÁTICA Y CIENCIAS DE LA COMPUTACIÓN DESARROLLO DE UNA SOLUCIÓN BUSINESS INTELLIGENCE EN LA PYME COMERCIALIZADORA DE CALZADO STEFY RALL TRABAJO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN INFORMÁTICA Y CIENCIAS DE LA COMPUTACIÓN JUAN PABLO CASTAÑEDA SÁNCHEZ DIRECTORA: ING. PATRICIA AUZ Quito, febrero 2013

2 Universidad Tecnológica Equinoccial Reservados todos los derechos de reproducción

3 DECLARACIÓN Yo JUAN PABLO CASTAÑEDA SÁNCHEZ, declaro que el trabajo aquí descrito es de mi autoría; que no ha sido previamente presentado para ningún grado o calificación profesional; y, que he consultado las referencias bibliográficas que se incluyen en este documento. La Universidad Tecnológica Equinoccial puede hacer uso de los derechos correspondientes a este trabajo, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normativa institucional vigente. Juan Pablo Castañeda Sánchez

4 CERTIFICACIÓN Certifico que el presente trabajo que lleva por título Desarrollo de una solución Business Intelligence en la pyme comercializadora de calzado STEFY RALL, que, para aspirar al título de Ingeniero en Informática y Ciencias de la Computación fue desarrollado por Juan Pablo Castañeda Sánchez, bajo mi dirección y supervisión, en la Facultad de Ciencias de la Ingeniería; y cumple con las condiciones requeridas por el reglamento de Trabajos de Titulación artículos 18 y 25. Ing. Patricia Auz DIRECTORA DEL TRABAJO

5 DEDICATORIA Dedico el esfuerzo de este trabajo de titulación principalmente a mis queridos padres Guillermo y Maggy, por brindarme su apoyo durante toda mi vida y en especial durante la realización de esta tesis. Estoy seguro que sin ellos todo hubiese sido mucho más difícil. También se lo dedico a mis pequeños sobrinos y a las personas que siempre estuvieron pendientes del avance del trabajo como mis hermanas y amigos. Finalmente a DIOS, por guiar mi camino y por darme la suerte y el privilegio de pasar por la universidad.

6 AGRADECIMIENTO En primer lugar quiero agradecer a la familia Parra Cabrera y en especial a mi estimado amigo Raúl Fernando por abrirme las puertas de su empresa y facilitarme toda la información necesaria para la realización de esta tesis. Al Ing. Carlos Rojas Dousdebes por su invaluable ayuda durante el desarrollo de la parte práctica de este trabajo. A mi directora de tesis la Ing. Patricia Auz por su asesoría en la elaboración del documento y supervisión en la parte práctica. A todos ellos mi eterno agradecimiento por su tiempo y por su buena voluntad.

7 ÍNDICE DE CONTENIDOS PÁGINA RESUMEN ABSTRACT vii viii 1. INTRODUCCIÓN 1 2. MARCO TEÓRICO DATAWAREHOUSING MODELO RELACIONAL MODELO MULTIDIMENSIONAL ADMINISTRACIÓN DEL DATAWAREHOUSE OLAP SQL STRUCTURED QUERY LANGUAJE Data Mining TAREAS TÉCNICAS APLICACIÓN A LA TOMA DE DECISIONES HERRAMIENTAS Y SUITES DE BUSINESS INTELLIGENCE HERRAMIENTAS SIMPLES SUITES CLASIFICACIÓN DE SUITES EN EL MERCADO DISCUSIÓN FINAL METODOLOGÍA CASO DE ESTUDIO MODELO DE DATOS DE LA EMPRESA SITUACIÓN ACTUAL 43 i

8 3.1.3 RECURSOS TECNOLÓGICOS CON LOS QUE CUENTA RECURSOS TECNOLÓGICOS NECESARIOS IDEA SOBRE VENTAJAS COMPETITIVAS ARQUITECTURA DE LA SOLUCIÓN BI MODELO DE DATOS MULTIDIMENSIONAL LIMPIEZA E INTEGRACIÓN DE DATOS DISCUSIÓN FINAL ANÁLISIS DE RESULTADOS CREACIÓN CAPA DE INTEGRACIÓN CREACIÓN CAPA DE ANÁLISIS OLAP DATA MINING CAPA DE VISUALIZACIÓN DISCUSIÓN FINAL CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES 65 BIBLIOGRAFÍA 67 ii

9 ÍNDICE DE TABLAS PÁGINA Tabla 1 Diferencias entre una base de datos transaccional y un datawarehouse 6 Tabla 2 Operadores de OLAP 18 Tabla 3 Tareas de data mining 21 Tabla 4 Áreas de aplicación de apoyo a la toma de decisiones 24 Tabla 5 Clasificación de sistemas de inteligencia empresarial 24 Tabla 6 Atributos del Modelo Multidimensional 52 Tabla 7 Monto IVA en el Tabla 8 Monto IVA por Categoría 63 Tabla 9 Resultados del modelo clasificar 94 iii

10 ÍNDICE DE FIGURAS PÁGINA Figura 1 Arquitectura general de un datawarehouse 5 Figura 2 Ejemplo de tablas hecho y dimensión 9 Figura 3 Ejemplo de esquema estrella 10 Figura 4 Ejemplo de esquema copo de nieve 11 Figura 5 Ejemplo de esquema constelación 11 Figura 6 Diferencia entre los modelos relacional y multidimensional 12 Figura 7 Cubo de OLAP 15 Figura 8 Ejemplos de reportes de OLAP 15 Figura 9 Técnicas de almacenamiento de cubos ROLAP y MOLAP 16 Figura 10 Operadores de OLAP 18 Figura 11 Consulta en lenguaje SQL 19 Figura 12 Resultado de la consulta SQL 19 Figura 13 Ejemplo de árbol con nodos 22 Figura 14 Herramientas de integración de datos (ETL) 25 Figura 15 Herramientas de OLAP 29 Figura 16 Herramientas de data mining 31 Figura 17 Suites de Business Intelligence 34 Figura 18 Clasificación de suites comerciales 38 Figura 19 Local principal de la pyme 42 Figura 20 Sistema administrativo SIC Figura 21 Arquitectura de la Solución BI 48 Figura 22 Entidades principales de la pyme 50 Figura 23 Modelo multidimensional 51 iv

11 Figura 24 Flujo de datos de la solución BI 56 Figura 25 Migración de MS Access a MS SQL Server 57 Figura 26 SQL Server BI Development Studio 58 Figura 27 Browser del cubo de datos 59 Figura 28 Monto IVA en el Figura 29 Data Mining para MS Excel 60 Figura 30 Modelo de datos CLASIFICAR 61 Figura 31 Resultados del Modelo Clasificar 61 Figura 32 Conexión al cubo de datos 62 Figura 33 Recursos generados por MS Excel 63 Figura 34 Monto IVA por Categoría 64 Figura 35 Diagrama E-R de la base de datos 71 Figura 36 Conexiones existentes de datos 97 Figura 37 Opciones de importación de datos 98 Figura 38 Recursos estadísticos generados 98 Figura 39 Medidas y dimensiones del cubo 99 Figura 40 Número de ventas por clase de cliente 100 Figura 41 Número de ventas por clase de cliente y por sucursal 101 v

12 ÍNDICE DE ANEXOS PÁGINA ANEXO I 71 DIAGRAMA ENTIDAD RELACIÓN DE LA BASE DE DATOS USADA POR LA PYME 71 ANEXO II 72 ENTREVISTAS AL GERENTE GENERAL DE LA PYME 72 ANEXO III 83 CÓDIGO FUENTE DEL PROCESO ETL 83 ANEXO IV 94 EXPLICACIÓN A LA FIGURA ANEXO V 97 MANUAL DE USUARIO 97 vi

13 RESUMEN Este documento presenta el desarrollo de una solución Business Intelligence para una pyme, el cual apoya a la toma de decisiones mediante el análisis de información integrando las técnicas de datawarehousing, OLAP y data mining. En este trabajo se expone una solución Business Intelligence factible para empresas que no manejan grandes volúmenes de datos y que tampoco requieren de personal experto en el área para poder tener acceso a las técnicas mencionadas y entender la información que se entrega como resultado. Hoy en día estas técnicas no se aplican comúnmente en una pyme, porque se piensa que es un proceso muy costoso, no solo para su creación, sino también para su mantenimiento. Se describe de la manera más clara posible las técnicas de Business Intelligence y cómo implementarlas, esto con el fin de comprender qué son y qué se realizó en este trabajo. Además se mencionan algunas herramientas de software disponibles para desarrollar cada una de las técnicas de este tipo de proyectos, esto con motivo de dar a conocer alternativas de software diferentes a las que se abordaron en esta tesis. También se justificó las razones de las herramientas seleccionadas. Esta tesis se realizó con base en los requerimientos del caso de estudio: STEFY RALL, una pyme de tipo comercial con necesidades de análisis de información para mejorar su administración. Se pretende que este documento sirva como guía referencial para poder aplicar este tipo de soluciones en pymes de características similares. Finalmente se muestra en el documento los resultados obtenidos con la implementación de la solución y las conclusiones / recomendaciones respectivas. vii

14 ABSTRACT This document presents the development of a Business Intelligence solution for a Small and Medium Enterprise (SME), which supports take decisions through information analysis, integrating Data Warehousing, OLAP and Data Mining techniques. In this work propose a feasible solution Business Intelligence for companies that handle medium volumes of data and not require of expert staff in the area to have access to the above techniques and understand the information given as a result. Today these techniques are not commonly applied in an SME because it is thought to be an expensive process, not only for its creation, but also for maintenance. Is described as clearly as possible the techniques of Business Intelligence and how to implement, this in order to understand what are and what was done in this work. Besides are some software tools available to develop each of the techniques in this type of projects, this to know different software alternatives to those discussed in this work. Also are justified the reasons for the selected tools. This work was made based on the requirements of the study case: STEFY RALL, an SME of commercial type with information analysis needs to improve its management. This document is intended to serve as a reference guide to apply this type of solutions in SMEs with similar characteristics. Finally the document shown the results obtained with the implementation of the solution and the conclusions / recommendations thereon. viii

15 INTRODUCCIÓN

16 1. INTRODUCCIÓN El desarrollo de una solución Business Intelligence en la pyme comercializadora de calzado STEFY RALL permite afianzar los conocimientos en este tema, además de facilitar la solución BI a la pyme que actualmente no dispone de una tecnología informática que le ayude en la toma de decisiones. Las pymes (pequeñas y medianas empresas), son organizaciones que se caracterizan por tener un número reducido de empleados (hasta 100) y una facturación media o baja. En el último censo económico realizado por el Instituto Nacional de Estadísticas y Censos (INEC) en el 2010, se establece que en el Ecuador existen alrededor de pequeñas y medianas empresas. (Instituto Nacional de Estadísticas y Censos, 2011) El crecimiento de las pymes ocurre actualmente entre una fuerte competencia, contracción económica, clientela más inteligente, reducción de márgenes de utilidad y constantes innovaciones tecnológicas. De ahí lo valioso de que las medianas empresas tomen decisiones acertadas en el momento que se requieran y antes que su competencia lo haga. (Revista Líderes, 2012) La información es un factor crítico en los negocios. Por esto, las empresas requieren de soluciones que permitan la exploración de la información, donde sus propios datos sean procesados para apoyar la toma de decisiones estratégicas, justificadas con información esencial para ellas. El mantenerse al tanto de la situación de la empresa, les permite establecer o mejorar estrategias que generen ventajas ante su competencia, con mayor seguridad. De ahí la importancia de que una pyme pueda contar con soluciones inteligentes en su infraestructura informática, considerando que en la actualidad existen varias herramientas de software que facilitan la implementación de este tipo de soluciones y dejando de pensar que solo las 1

17 empresas grandes pueden contar con tecnologías que faciliten la toma de decisiones. Los objetivos principales de este trabajo son: Entender las definiciones necesarias de lo que es o comprende una solución Business Intelligence. Conocer de manera general las funcionalidades de algunas herramientas existentes en el mercado para cada una de las técnicas: datawarehousing, OLAP, data mining. Diseñar un ambiente integral que facilite el uso de las herramientas seleccionadas para la implementación de la solución Business Intelligence. Desarrollar una solución Business Intelligence en la pyme comercializadora de calzado STEFY RALL, integrando las técnicas de datawarehousing, OLAP y data mining. 2

18 MARCO TEÓRICO

19 2. MARCO TEÓRICO El objetivo de este capítulo es explicar detalladamente cada una de las tecnologías de Business Intelligence y cómo encajan dentro del proyecto desarrollado. El capítulo se encuentra organizado de la siguiente manera: la sección 2.1 corresponde a los conceptos de datawarehousing, la sección 2.2 a la parte de OLAP, la sección 2.3 a los conceptos de data mining, en la sección 2.4 se describen las áreas de aplicación de apoyo a la toma de decisiones, en la sección 2.5 se describe una clasificación de algunas herramientas que existen en el mercado relacionadas con el área de Business Intelligence y por último, en la sección 2.6 las conclusiones del capítulo. 2.1 DATAWAREHOUSING William Inmon quien es considerado padre del datawarehouse, lo define como una colección de datos diseñada para apoyar la toma de decisiones. Los datawarehouses integran datos que han sido seleccionados y organizados de manera histórica, sobre los que se realizan análisis que ayuden a justificar las decisiones estratégicas tomadas en las empresas. (Inmon, 2005) Las características principales de un datawarehouse según (Inmon, 2005) son las siguientes: El datawarehouse está orientado a un contexto, organiza y orienta los datos desde la perspectiva del usuario final. Administra grandes cantidades de información. La mayoría de los datawarehouses contienen información histórica que se retira con frecuencia de las bases de datos operacionales. Comprende múltiples versiones de esquemas de datos, debido a que el datawarehouse tiene que guardar información histórica, y como esta ha sido manejada en distintos momentos por diferentes 3

20 versiones de esquemas, debe poder administrar información originada en diferentes bases de datos. Condensa y agrega información. Con frecuencia, es muy alto el nivel de detalle de la información guardada. Un datawarehouse condensa y agrega la información para presentarla en forma comprensible a las personas. Un datawarehouse se compone de los siguientes elementos (Kimball, 2008): Fuentes de datos de sistemas operacionales: se refieren a las bases de datos operacionales que contienen información recopilada de las aplicaciones operacionales, que pueden venir en diversos esquemas tales como modelos relacionales, no relacionales o basados en archivos, y pueden ser tanto internas como externas a la organización. Área mediación de datos: en esta área se realiza un conjunto de procesos conocidos como de extracción, transformación y carga (ETL por sus siglas en inglés). Esta área comprende todo aquello que se encuentra entre la fuente de datos operacionales y el área de presentación de datos. Área de presentación de datos: es el lugar en donde los datos son organizados, almacenados y están disponibles para las consultas, reportes y resúmenes que realicen los usuarios. Herramientas de acceso a los datos: todas las herramientas de acceso a los datos realizarán consultas a partir del área de presentación de datos. Una herramienta de acceso puede consistir desde una simple consulta, hasta minería de datos. Para mostrar de manera gráfica los aspectos comunes mencionados anteriormente, se propone la figura 1, que representa en sí la arquitectura general de un datawarehouse. 4

21 Figura 1 Arquitectura general de un datawarehouse Como podemos observar en la figura 1 existe un proceso intermedio entre las fuentes de datos y el datawarehouse. A este proceso se lo conoce como ETL por sus siglas en ingles que significan Extract Transformation Load. Este proceso es muy importante para la construcción de un datawarehouse, ya que aquí es donde se van a limpiar y estandarizar los datos para su posterior almacenamiento. En un datawarehouse nunca se debe almacenar datos sucios o inconsistentes, considerando que de aquí se tomaran los datos para realizar el posterior análisis de información. De manera muy simplificada el proceso ETL consiste en (Caserta, 2004): Extraer convierte los datos a un formato preparado para iniciar el proceso de transformación. Se analiza los datos extraídos, de lo que resulta un chequeo para verificar si los datos cumplen la estructura que se esperaba. De no ser así los datos son rechazados. 5

22 Transformación se aplica reglas de negocio sobre los datos extraídos para convertirlos en datos que serán cargados. Por ejemplo, se selecciona solo ciertas columnas para su carga y las con valores nulos se descartan. Carga los datos son cargados en el datawarehouse de destino. Consiste en realizar un resumen de todas las transacciones comprendidas en el período de tiempo seleccionado y transportar el resultado como una única transacción hacia el datawarehouse. A pesar de que se puede pensar que un datawarehouse es semejante a un OLTP, la verdad es que existen diferencias muy significativas entre ellos como podemos ver en la tabla 1 (Inmon, 2005) Tabla 1 Diferencias entre una base de datos transaccional y un datawarehouse Propósito Tipo de datos Características de los datos Modelo de datos Número y tipo de usuarios Acceso Base de datos transaccional Operaciones diarias. Soporte a las aplicaciones. Datos de funcionamiento de la organización. Datos de funcionamiento, cambiantes, internos, incompletos, Datos normalizados. Cientos/miles: aplicaciones, operarios, administrador de la base de datos. SQL. Lectura y escritura Datawarehouse Recuperación de información, informes, análisis y minería de datos. Datos útiles para el análisis, la totalización, etc. Datos históricos, datos internos y externos, datos descriptivos Datos en estrella, copo de nieve, parcialmente desnormalizados, multidimensionales. Decenas: directores, ejecutivos, analistas. SQL y herramientas propias, entre muchas otras. Lectura. Una vez comprendida la definición de un datawarehouse, se puede comenzar a diseñarlo e implementarlo. Para construir un datawarehouse existen 2 tipos de modelado de datos los cuales son (Hernandez, 2004) (SAP, 2006) (Inmon, 2005): MODELO RELACIONAL El modelo relacional se puede usar para implementar un datawarehouse aplicando sobre el modelo de datos de la empresa, un proceso de 6

23 transformación de datos de 8 pasos, Los 8 pasos a considerarse son los siguientes: 1. Selección de los datos de interés. El modelo de datos de la empresa es una de las entradas en este paso, además existen otras como reportes, prototipos, consultas y requerimientos de información. Se debe tener cuidado en la selección de los datos para no sobresaturar la información que se almacene en el datawarehouse. 2. Añadir la dimensión de tiempo a las llaves. Debido a que el modelo del datawarehouse representa la información a lo largo del tiempo, se debe agregar el tiempo o fecha a la llave de cada entidad de interés. 3. Añadir datos derivados. Los datos derivados se obtienen como resultado de aplicar operaciones matemáticas a otros datos. Es necesario incluirlos en el datawarehouse por razones de optimización y para asegurar la consistencia de los datos. 4. Determinar el nivel de granularidad. El nivel de detalle que se almacenará en el datawarehouse puede variar dependiendo la perspectiva del negocio, técnica o del proyecto. Antes de determinar el nivel de granularidad, es necesario considerar varios factores tales como las necesidades del negocio, de los procesos de data mining, el costo de almacenamiento y el desempeño. 5. Totalizar los datos. Se utiliza con fines de rendimiento en la entrega de los resultados. Comúnmente se totalizan los datos por periodos de tiempo. 6. Mezclar entidades. Combinar 2 o más entidades en una sola, es decir, se desnormalizan los datos, para esto deben tener una llave en común. 7. Crear arreglos. Se utiliza poco, pero si es necesario, puede mejorar considerablemente la población de los datawarehouses. 7

24 8. Separar los datos. Se separan tablas con base en su estabilidad y uso. Estos 8 pasos pueden dividirse en 2 categorías. Los primeros 4 pertenecen a la etapa de creación del datawarehouse y los 4 siguientes pasos sirven para mejorar el rendimiento y optimizar el tiempo de respuesta. Sobre el modelo relacional se pueden aplicar las técnicas de reporteo general y permite almacenar el histórico de la información MODELO MULTIDIMENSIONAL El modelo multidimensional, permite tener datos organizados entorno a hechos, que tienen unos atributos o medidas, que pueden verse con mayor o menor detalle según ciertas dimensiones. Los conceptos importantes que se manejan dentro del modelo multidimensional son: Hecho: corresponde a la actividad de la empresa que se desea representar, por ejemplo, las ventas. Medidas: son el conjunto de indicadores del hecho que se escogió para representar. Generalmente responden a la pregunta Cuánto? Retomando el ejemplo anterior, las medidas para el hecho de las ventas podrían ser: Cuántos productos se vendieron?, Cuánto fue el total de la venta? Cuánto costaron esos productos vendidos? Dimensiones: son las que van a caracterizar al hecho y responden a las preguntas Dónde? Cuándo? Qué? Siguiendo con el ejemplo, las dimensiones para el hecho de las ventas podrían ser: la fecha de la venta, la hora, o el lugar. Granularidad: corresponde al nivel de detalle que será almacenado en las dimensiones. Por ejemplo: para la dimensión de tiempo podemos tener: año, semestre, trimestre, mes, semana, día, hora. 8

25 Una vez comprendidos estos conceptos, podemos definir los elementos de los que se compone el modelo multidimensional para su implementación: las tablas y los esquemas (Kimball, 2008). Existen dos tipos de tablas, que se muestran gráficamente en la figura 2. Tabla hecho: en ella se almacenan las medidas y las claves de las tablas de dimensión u otras medidas derivadas, conocidas como funciones de agregación. Tabla de dimensión: contiene los datos descriptivos de cada dimensión, también conocidos como atributos de la dimensión. Figura 2 Ejemplo de tablas hecho y dimensión Los esquemas son colecciones de tablas y pueden ser de dos tipos (Kimball, 2008): Esquema Estrella: el centro de la estrella consiste en una tabla hecho y las puntas de la estrella son las tablas de dimensión, las cuales tienen una sola conexión a la tabla hecho a través de su llave primaria, que debe ser un atributo único, y no hay caminos alternativos en las dimensiones, es decir no existen jerarquías. Como vemos en la figura 3. Este esquema es una representación sencilla de los datos que agiliza el tiempo de respuesta en las consultas multidimensionales, sin embargo, dificulta el proceso de actualización de datos, porque usualmente está desnormalizado, lo que provoca 9

26 duplicación de datos o sustitución de llaves por valores de registros y esto ocupa más espacio de almacenamiento. Figura 3 Ejemplo de esquema estrella Esquema Copo de Nieve: La diferencia con el esquema estrella es que sí existen caminos alternativos en las dimensiones, es decir jerarquías en las dimensiones. Una de las ventajas de este esquema es que facilita la actualización de los datos del datawarehouse y ahorra espacio de almacenamiento. Sin embargo, es una representación de datos más compleja que disminuye el tiempo de respuesta en las consultas multidimensionales. La figura 4 es un ejemplo del esquema copo de nieve. 10

27 Figura 4 Ejemplo de esquema copo de nieve Constelación: es un conjunto de esquemas estrella o copos de nieve que comparten dimensiones, como podemos ver en la figura 5. Figura 5 Ejemplo de esquema constelación Existen 4 pasos importantes que se deben considerar para la elaboración de un modelo multidimensional (Universidad de Concepción Chile, 2008): 1. Selección del proceso a modelar. 11

28 2. Seleccionar el hecho central y el gránulo máximo que se va a necesitar sobre él. 3. Identificar las dimensiones que caracterizarán el dominio. 4. Determinar y refinar las medidas y atributos a almacenar sobre el proceso. El modelo multidimensional también permite almacenar el histórico de la información, una ventaja importante es que los esquemas estrella ayudan a enfocarse en hechos particulares y permiten crecer tanto como se quiera. La figura 6 presenta gráficamente las diferencias entre ambos modelos (Inmon, 2005) (Kimball, 2008). Figura 6 Diferencia entre los modelos relacional y multidimensional A diferencia del modelo relacional, sobre el modelo multidimensional se pueden construir cubos de OLAP, que serán explicados en la siguiente sección. 12

29 2.1.3 ADMINISTRACIÓN DEL DATAWAREHOUSE Una de las razones principales por las que se construye el datawarehouse separado de la base de datos operacional, es para conseguir que se realice el análisis de datos de una manera eficiente. La carga y el mantenimiento de un datawarehouse son los aspectos más delicados y que más esfuerzo requieren. Como se mencionó anteriormente el proceso ETL, es el encargado de realizar estas tareas. La extracción, transformación y carga, comprende las siguientes tareas (Harjinder, 1996): Lectura de datos transaccionales: se trata de obtener, mediante consultas SQL, la información que se necesita de la base de datos transaccional. La primera carga de datos, suele ser la más difícil ya que los datos pueden encontrarse en distintos formatos. Creación de claves: es recomendable hacer una distinción entre las claves de las bases de datos transaccionales y las del datawarehouse para evitar confusiones. Integración de datos: consiste en la unión de datos de distintas fuentes, detectar cuándo representan los mismos objetos y generar las referencias y restricciones adecuadas para conectar la información y proporcionar la integridad referencial. Limpieza y transformación de datos: en esta tarea se trata de evitar datos redundantes, inconsistentes, estandarizar medidas, formatos, fechas, tratar valores nulos, etc. Creación y mantenimiento de metadatos: para que todo el proceso de ETL pueda funcionar, es necesario crear y mantener metadatos sobre el propio proceso de ETL, los pasos realizados y por realizar. 13

30 Identificación de cambios: se puede realizar de distintas maneras, una carga total cada vez que haya un cambio, comparaciones entre instancias, marcas de tiempo o técnicas mixtas. Planificación de la carga y mantenimiento: consiste en definir las fases de carga y el orden de las migraciones para evitar violar las restricciones de integridad. El objetivo es poder hacer la carga sin saturar la base de datos transaccional, así como el mantenimiento sin paralizar el almacén de datos. Indización: se deben crear índices en las claves y atributos del datawarehouse que se consideren relevantes. Una vez que se ha implementado de manera exitosa el datawarehouse se puede proceder a la aplicación de técnicas que exploten y manipulen la información almacenada, las cuales se verán en las siguientes secciones. 2.2 OLAP On Line Analytical Processing (OLAP) permite analizar grandes cantidades de datos a través del modelo multidimensional, explicado en la sección 2.1. Esta representación permite mostrar los datos al usuario final de una manera más sencilla y tiene la flexibilidad necesaria para cambiar las perspectivas de visión de la información. OLAP permite realizar análisis históricos complejos con amplia manipulación de los datos (Ponniah, 2007). El análisis de la información se realiza mediante cubos, que son colecciones de dimensiones y medidas, alrededor de un hecho particular, sobre los cuales se aplican distintos operadores para dar los resultados a las consultas que se ejecuten. En la figura 7 se puede observar que un cubo se compone de ejes, representados por las dimensiones y celdas que son las medidas que se quieren analizar. 14

31 Figura 7 Cubo de OLAP En la figura 8 podemos observar ejemplos de reportes obtenidos con los cubos de OLAP. Figura 8 Ejemplos de reportes de OLAP Existen 2 técnicas de almacenamiento o implementación de cubos de OLAP, como se muestra en la figura 9, que son (Harjinder, 1996): 15

32 ROLAP: físicamente el datawarehouse se construye sobre una base de datos relacional. Una ventaja de este tipo de esquema es que se pueden utilizar los sistemas de administración de bases de datos relacionales, que son muy populares para el OLTP, y sus herramientas asociadas, además de que el costo necesario para la implementación es mucho menor. MOLAP: físicamente el datawarehouse se construye sobre estructuras basadas en matrices multidimensionales. Las ventajas de este esquema son la especialización y la correspondencia entre el nivel lógico y el nivel físico. Por esto generalmente MOLAP es más eficiente, debido a que es una solución ad-hoc. Figura 9 Técnicas de almacenamiento de cubos ROLAP y MOLAP La diferencia entre ambas técnicas radica en la implementación física y no en la manera en que las herramientas muestren los resultados de las consultas (Hernandez, 2004). 16

33 Entre las características principales de OLAP se encuentran las siguientes: Presenta una visión multidimensional lógica de los datos en el datawarehouse. La visión es independiente de cómo se almacenan los datos. Incluye siempre la consulta interactiva y el análisis de los datos. Por lo regular la interacción es de varias pasadas, lo cual comprende la profundización en niveles cada vez más detallados o el ascenso a niveles superiores de resumen y adición. Ofrece opciones de modelado analítico, incluyendo un motor de cálculo para obtener proporciones, desviaciones, etc., que comprende mediciones de datos numéricos a través de muchas dimensiones. Crea resúmenes, adiciones, jerarquías y cuestiona todos los niveles de adición y resumen en cada intersección de las dimensiones. Maneja modelos funcionales de pronóstico, análisis de tendencias y análisis estadísticos. Recupera y exhibe datos tabulares en dos o tres dimensiones, cuadros y gráficas. Esto permite analizar los datos desde diferentes perspectivas. Para explotar la información almacenada en el datawarehouse una vez definido el cubo, se pueden aplicar distintos operadores que se muestran en la tabla 2 (Stackowiak, 2007). 17

34 Tabla 2 Operadores de OLAP Operador Drill Roll Slice & Dice Pívot Drill-down/Roll-up Drill-across/Roll-across Significado Ofrece mayor nivel de detalle y menos agregación. Lo contrario a Drill, se tiene mayor agregación y menor nivel de detalle. Se proyectan datos de áreas específicas por selección, no por agregación. Se reorientan las dimensiones, es decir, las columnas ocupan el lugar de las filas y las filas el de las columnas. Se aumentan o disminuyen agregaciones dentro de una consulta ya predefinida. Se obtienen agregaciones en otras dimensiones que no hayan sido comprendidas inicialmente, o se desaparecen dimensiones. En la figura 10 podemos ver un ejemplo de la aplicación de un operador de OLAP. Figura 10 Operadores de OLAP Una vez que hemos visto la definición de OLAP y los operadores de manipulación de datos que existen, podemos pasar a la realización de consultas, las cuales se definen en lenguaje SQL que se explicará en la siguiente sección SQL STRUCTURED QUERY LANGUAJE El lenguaje de consulta estructurado o SQL, es un lenguaje de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones. Una de sus características es el cálculo relacional, permitiendo 18

35 efectuar consultas con el fin de recuperar información de interés de una base de datos, así como también hacer cambios sobre ella (Microsoft, 2010). Un ejemplo sencillo de consulta en lenguaje SQL luce como se muestra en la figura 11 y cuyo resultado se muestra en la figura 12. (Usando la base de datos Northwind) /*cuantas ordenes ha hecho cada cliente*/ select c.companyname as [Cliente], count(o.orderid) as [Numero de Ordenes] from customers c join orders o on c.customerid = o.customerid group by c.companyname Figura 11 Consulta en lenguaje SQL Figura 12 Resultado de la consulta SQL 19

36 En conclusión, el objetivo de OLAP es ayudar al usuario final a entender lo que está sucediendo en la empresa, ya que permite mostrar un análisis concentrado de los datos de la empresa. Esto ayuda a los administradores a mantenerse informados de la situación actual de la organización. Otro tipo de análisis es la técnica de data mining, que también utiliza los datos almacenados en el datawarehouse y que veremos con más detalle en la siguiente sección. 2.3 Data Mining Es el proceso de extraer información útil y comprensible, previamente desconocida, desde grandes cantidades de datos almacenados en distintos formatos (University of California, 2010). Para que este proceso sea efectivo debería ser automático o semiautomático y el uso de los patrones descubiertos debería ayudar a tomar decisiones más seguras. Por lo tanto, el objetivo de data mining es descubrir patrones válidos, novedosos, interesantes y comprensibles, que reporten algún beneficio a la organización (Fayyad, 1996). Dos conceptos importantes en data mining son las tareas y los métodos. En las secciones siguientes se explican con más detalle los tipos de tareas y métodos que existen para resolverlas TAREAS Una tarea es un tipo de problema de data mining. Por ejemplo: clasificar productos en defectuosos, no defectuosos, defectuosos reparables y defectuosos no reparables es una tarea (Hernandez, 2004). Existen dos grandes grupos en los que se pueden dividir las tareas, como se pueden ver en la tabla 3 (Larose, 2007). 20

37 Tabla 3 Tareas de data mining Tipo de Tareas Descripción Ejemplos Predictivas Descriptivas Se trata de problemas en los que hay que predecir uno o más valores para uno o más ejemplos Los ejemplos se presentan como un conjunto de datos sin ordenar ni etiquetar de ninguna manera. Por lo tanto, el objetivo, no es predecir nuevos datos sino describir los existentes Clasificación. Clasificación suave. Estimación de probabilidad de clasificación. Categorización. Preferencias o priorización. Regresión Clustering. Correlación y factorizaciones Reglas de asociación. Arboles de desición de MS Detección de valores e instancias anómalas. De todas estas, la tarea que se aborda en esta tesis es descriptiva, específicamente Árboles de Decisión de Microsoft. Tomando en cuenta que la herramienta que usamos para minería de datos es Microsoft Excel, ya que Excel posee un complemento exclusivo para tareas de minería de datos, que permite utilizar la tarea mencionada. Árboles de Decisión de Microsoft Es un algoritmo de clasificación que proporciona Microsoft SQL Server Analysis Services para el modelado de predicción principalmente de atributos discretos. El algoritmo hace predicciones basándose en las relaciones entre las columnas de entrada de un conjunto de datos. Utiliza los valores o estados de estas columnas para predecir los estados de una columna que se designa como elemento de predicción. Específicamente, el algoritmo identifica las columnas de entrada que se correlacionan con la columna de predicción. Por ejemplo, en un escenario para predecir qué clientes van a adquirir probablemente una bicicleta, si nueve de diez clientes jóvenes compran una bicicleta, pero sólo lo hacen dos de diez clientes de edad mayor, el algoritmo infiere que la edad es un buen elemento de predicción en 21

38 la compra de bicicletas. El árbol de decisión realiza predicciones basándose en la tendencia hacia un resultado concreto. (Microsoft, 2012) El algoritmo genera un modelo de minería de datos mediante la creación de una serie de divisiones en el árbol. Estas divisiones se representan como nodos, apreciados en el ejemplo de la figura 13. El algoritmo agrega un nodo al modelo cada vez que una columna de entrada tiene una correlación significativa con la columna de predicción. Figura 13 Ejemplo de árbol con nodos TÉCNICAS Cada una de las tareas mencionadas en la sección 2.3.1, requiere de técnicas o métodos para resolverlas. Entre las técnicas más importantes se encuentran: Técnicas algebraicas y estadísticas. Técnicas basadas en conteo de frecuencias. Técnicas basadas en árboles de decisión y sistemas de aprendizaje de reglas. Técnicas basadas en redes neuronales artificiales. Como se puede observar, existen algunas técnicas que pueden aplicarse a la solución de distintas tareas, en ocasiones una misma tarea puede ser 22

39 resuelta por diferentes técnicas, sin embargo, algunas de ellas entregan resultados más pertinentes que otras. 2.4 APLICACIÓN A LA TOMA DE DECISIONES El área de apoyo a la toma de decisiones constituye un área multidisciplinar cuyo objetivo es la introducción de métodos y/o herramientas que ayuden a las personas en la toma de decisiones clave. La fase de toma de decisiones usualmente se refiere al proceso necesario para realizar la selección de una opción o alternativa. Este proceso incluye: conocer el problema, recoger información sobre el problema, identificar alternativas, anticipar consecuencias de posibles decisiones, realizar la selección utilizando juicios lógicos y coherentes basados en la información disponible. Entonces se puede definir el área del apoyo a la toma de decisiones en 2 partes: la primera que concierne a la toma de decisiones por parte del personal involucrado y la segunda que corresponde al estudio de técnicas que asistan a las personas a mejorar las decisiones tomadas (Sprague, 1995). Entre esas técnicas podemos ubicar a: datawarehousing, OLAP y data mining, que nos ayudan a formar un sistema completo de inteligencia empresarial. Existen diversas áreas de aplicación en las que ya se han incorporado estas técnicas para apoyar la toma de decisiones, las más importantes se muestran en la tabla 4 (Hernandez, 2004). 23

40 Tabla 4 Áreas de aplicación de apoyo a la toma de decisiones Area de aplicación Aplicaciones financieras Análisis de mercado, distribución y comercio Seguros y salud privada Educación Procesos industriales Medicina, biología, bioingeniería y otras ciencias Telecomunicaciones Ejemplos Obtención de patrones de uso fraudulento de tarjetas de crédito, determinación del gasto en tarjeta de crédito por grupos, cálculo de correlaciones entre indicadores financieros, análisis de riesgo en créditos. Análisis de la canasta básica de mercado, evaluación de campañas publicitarias, análisis de la fidelidad de los clientes, estimación de inventarios, costos y ventas. Determinación de clientes potencialmente caros, identificación de patrones de comportamiento para clientes con riesgo, identificación de comportamiento fraudulento, prediccion de clients que podrian ampliar su poliza. Selección o captación de estudiantes, detección de abandonos y fracasos, estimación de tiempo de estancia en la institución. Extracción de modelos sobre comportamiento de compuestos, detección de piezas con defectos, predicción de fallos y accidentes, estimación de composiciones óptimas en mezclas, extracción de modelos de costos, extracción de modelos de producción. Diagnóstico de enfermedades, detección de pacientes con riesgo de sufrir una enfermedad concreta, recomendación priorizada de fármacos para una misma enfermedad, predecir si un compuesto químico causa cáncer, clasificación de cuerpos celestes, predicción del recorrido y distribución de inundaciones, modelos de calidad de aguas. Establecimiento de patrones de llamadas, modelos de carga en redes, detección de fraude. 2.5 HERRAMIENTAS Y SUITES DE BUSINESS INTELLIGENCE En la actualidad se han desarrollado diversas herramientas que ofrecen soluciones a los problemas de Business Intelligence y que implementan todas o alguna de sus tecnologías. Para poder entender mejor el conjunto de herramientas para Business Intelligence, en esta tesis se ha realizado una clasificación de dichas herramientas, las cuales se muestran en la tabla 5 en donde los sistemas se dividen en 2 clases: Tabla 5 Clasificación de sistemas de inteligencia empresarial Clasificación Herramientas simples Suites Definición Herramientas especializadas en una sola técnica de inteligencia empresarial Ambientes completos que ofrecen la implementación de las 3 técnicas de inteligencia empresarial: datawarehousing, OLAP y data mining. A continuación veremos las herramientas simples y las suites más populares que existen en el mercado para cada una de las clasificaciones propuestas, junto con sus características principales. 24

41 2.5.1 HERRAMIENTAS SIMPLES Las herramientas simples son aquellas que dan soporte a las tecnologías de la inteligencia empresarial individualmente. Estas herramientas han sido clasificadas a su vez de acuerdo a la tecnología de inteligencia empresarial a la que dan soporte, en seguida mencionaremos las más importantes y populares para cada una. Herramientas de integración de datos En la figura 14 vemos algunas de las herramientas más populares que apoyan la integración de datos, las cuales se describirán con más detalle en seguida. Figura 14 Herramientas de integración de datos (ETL) Clover ETL Es un ambiente de transformación de datos de código abierto basado en Java, para datos estructurados, capaz de funcionar como aplicación independiente (standalone) o estar incluida en otra aplicación (Clover ETL, 2010). Características principales: Maneja todas las bases de datos con conexión JDBC disponible para ellas. 25

42 Realiza transformaciones gráficas basadas en XML para la descripción de los metadatos de los registros. Soporta valores nulos. Puede ejecutarse en múltiples CPU utilizando una estrategia llamada pipeline- parallelism. Se distribuye bajo la licencia LGPL. Clover ETL soporta 4 diferentes tipos de datos: string, numeric, date, bytes. EnhydraOctopus Conocida también como Octopus, es una herramienta de ETL para transformaciones de datos por conexión JDBC. Octopus solo soporta fuentes de datos que vengan con el manejador JDBC, incluye también drivers especiales que permiten la conectividad con archivos CSV, XML, MS- SQL. Octopus utiliza archivos XML para cargar los trabajos, así como para definir los parámetros de las transformaciones dadas (Dutina, 2007). Características principales: La característica principal de Octopus es el requerimiento de que para acceder a las fuentes de datos que lo utilicen, debe existir un manejador JDBC disponible. Herramienta poderosa capaz de: normalizar datos, crear llaves artificiales, tablas y llaves primarias. Todos los trabajos que corren en Octopus son independientes de los proveedores de bases de datos. 26

43 Kettle Conocido actualmente como Pentaho Data Integration, es un proyecto belga de código abierto, ahora adoptado por Pentaho BI, (del cual hablaremos con más detalle en la sección de suites), que incluye un conjunto de herramientas para realizar ETL. Uno de sus objetivos es que el proceso de ETL sea fácil de generar, mantener y desplegar (Pentaho, 2009). Se compone de 4 herramientas: - Spoon: permite diseñar de forma gráfica la transformación ETL. - Pan: ejecuta un conjunto de transformaciones diseñadas con SPOON, conocidas como trabajos (Jobs), creando dependencias entre dichas transformaciones. - Chef: permite mediante una interfaz gráfica, diseñar la carga de datos incluyendo un control de estado de los trabajos. - Kitchen: permite ejecutar los trabajos batch diseñados con Chef. Características principales: Funciona en Windows, UNIX and Linux. Tiene una interfaz visual con indicadores de las transformaciones. Es una aplicación escrita en Java con algunas características avanzadas escritas en JavaScript. Ofrece una licencia pública GPL. Soporta Oracle, DB2, SQL Server y Sybase así como MySQL, Postgres, Hypersonic, FireBird SQL e Ingres. También soporta la conectividad con SAP con una tarifa de licencia. Con respecto a escalabilidad, soporta la arquitectura de procesamiento en paralelo para distribuir las tareas de ETL a través de múltiples servidores. 27

44 Talend Talend Data Integration, es una herramienta de ETL de código abierto, que efectúa operaciones tales como alimentación de un datawarehouse, sincronización de bases de datos, transformación y verificación de la integridad de datos. Su interfaz gráfica de usuario está basada completamente en Eclipse RCP (Rich Client Platform) e incluye numerosos componentes para procesos de modelado de negocios, así como implementaciones técnicas para extracción de información, transformación y mapeo del flujo de datos. Las funciones generales de Talend incluyen modelador de negocios, diseñador del trabajo y administrador de metadatos (Talend, 2007). Características principales: Compatible con Microsoft SQL Server Integration Services (SSIS). Funciona en Windows, Unix y Linux. Interfaz de diseño drag and drop para componentes, conectores y relaciones. Genera componentes en Perl, Java o SQL para ETL o transformaciones ETL. Tiene una comunidad de soporte en Talend wiki, Talend Forum y un rastreador de errores. Conectividad con Oracle, DB2, MySQL, Sybase y Postgres y conectividad ODBC para otras bases de datos. 28

45 Herramientas para OLAP En la figura 15 se muestran algunos de los proveedores de OLAP más populares que se describen más detalladamente a continuación. Figura 15 Herramientas de OLAP Mondrian Es un motor de ROLAP desarrollado en Java, que permite analizar grandes conjuntos de datos que se encuentran almacenados en el datawarehouse. Mondrian se considera un motor, porque se encarga de recibir consultas dimensionales en lenguaje MDX y devolver los datos del cubo que correspondan a la consulta. El cubo se representa como un conjunto de metadatos que definen cómo se han de mapear estas consultas dimensionales a sentencias SQL para obtener de la base de datos la información necesaria para satisfacer la consulta dimensional. Utiliza una memoria caché para almacenar los resultados de las consultas que se acceden múltiples veces (Pentaho, 2010). Mondrian es usado para: Alto desempeño, análisis interactivo de grandes o pequeños volúmenes de información. 29

46 Exploración dimensional de los datos, por ejemplo analizando ventas por marcas de productos, región o periodo de tiempo. Parseo de expresiones en lenguaje MDX a expresiones en SQL para recuperar respuestas a consultas dimensionales. Cálculos avanzados utilizando las expresiones de cálculo del lenguaje MDX. Para definir el esquema que utilizará Mondrian existe una herramienta denominada Cube Designer, que está basada en un ambiente gráfico que permite diseñar un documento XML que representa un cubo o hipercubo para analizar la información almacenada de forma multidimensional. Este esquema será interpretado por Mondrian para obtener la información de las consultas de MDX ejecutadas. Palo Es un servidor de base de datos multidimensional capaz de centralizar y administrar casi un número infinito de hojas de cálculo. El sistema opera en tiempo real, soporta la consolidación de jerarquías así como numerosas funciones de inteligencia empresarial y es un servidor de código abierto. Palo es un servidor de datos multidimensional (MOLAP) orientado a celdas, específicamente desarrollado para almacenamiento y análisis de datos en hojas de cálculo (Palo, 2009). Olap4j Es una interfaz de aplicación para el ambiente Java 2 Platform, Enterprise Edition, que soporta la creación, almacenamiento y administración de datos para una aplicación OLAP. Hyperion, IBM, y Oracle iniciaron el desarrollo de OLAP4J con la intención de que fuera un equivalente a la conexión JDBC pero específica para OLAP, que se liberó en 2009 y es compatible con Mondrian (Hyde, 2006). 30

47 Herramientas para data mining En la figura 16 vemos algunos de los proveedores más populares para data mining. Estos y otros más se describen con más detalle enseguida. Figura 16 Herramientas de data mining Clementine La empresa SPSS, además de su conocido paquete estadístico, distribuye Clementine, uno de los sistemas de data mining más populares del mercado. Se trata de una herramienta visual inicialmente desarrollada por ISL (Integral Solutions Limited). En la actualidad esta herramienta, comercializada por SPSS, posee una arquitectura distribuida cliente / servidor (Robert Gordon University, 2010). Sus características principales son: Acceso a datos: fuentes de datos ODBC, tablas Excel, archivos planos ASCII y archivos SPSS. 31

48 Pre procesado de datos: pick & mix, muestreo, particiones, reordenación de campos, nuevas estrategias para la fusión de tablas, etc. Técnicas de aprendizaje: árboles de decisión, redes neuronales, agrupamiento, reglas de asociación, regresión lineal y logística, combinación de modelos. Técnicas para la evaluación de modelos guiadas por las condiciones especificadas por el experto. Visualización de resultados: ofrece un potente soporte gráfico que permite al usuario tener una visión global de todo el proceso, que comprende desde el análisis del problema hasta la imagen final del modelo aprendido. Exportación: generación automática de informes (HTML y texto), volcado de los resultados del ejercicio de data mining en bases de datos, exportación de los modelos a distintos lenguajes (C, SPSS, HTML, estándar PMML, SQL para árboles de decisión y reglas). Rapid Miner Es un entorno para la realización de experimentos de aprendizaje automático implementado en Java por la Universidad de Dortmund. Las operaciones elementales se encapsulan en los llamados operadores, los cuales son configurables mediante archivos XML. Estos archivos a su vez, pueden ser especificados gráficamente (Rapid-I, 2011). El sistema incluye operadores para: Importación y pre-procesamiento de datos. Aprendizaje automático: máquinas de vectores de soporte, árboles de decisión, agrupamiento y algoritmos genéticos. Validación de modelos. 32

49 Weka Es una herramienta de código abierto desarrollada por un equipo de investigadores de la Universidad de Waikato en Nueva Zelanda, implementada en Java (University of Waikato, 2011). Sus características principales son: Acceso a datos: los datos son cargados desde un archivo en formato ARFF (archivo plano organizado en filas y columnas). El usuario puede observar en sus diferentes componentes gráficos, información de interés sobre el conjunto de muestras. Pre procesado de datos: existe una gran cantidad de filtros disponibles tales como: selección de atributos, discretización, tratamiento de valores desconocidos, transformación de atributos numéricos. Métodos y técnicas: árboles de decisión, tablas de decisión, vecinos más próximos, máquinas de vectores de soporte, reglas de asociación, métodos de agrupamiento y modelos combinados. Puede utilizarse como aplicación independiente o dentro de otra aplicación. Xelopes Xelopes es una librería con licencia pública GNU para el desarrollo de aplicaciones de data mining, implementada por Proudsys AG en colaboración con Russian MDA specialist Zsoft Ltd. La librería implementa de una manera eficiente la mayoría de los algoritmos de aprendizaje, para desarrollar aplicaciones particulares de data mining. Además Xelopes es extensible, es decir, el usuario puede incorporar sus propios métodos a la propia librería (Prudsys, 2011). Sus características principales son: 33

50 Acceso a datos: existe una clase especial que permite dar uniformidad a todos los modos de accesos de datos permitidos. Así, el usuario puede acceder a archivos.log, archivos de bases de datos o implementar su propio formato de datos. Modelos: árboles de decisión lineales y no lineales, máquinas de vectores de soporte, redes neuronales, métodos de agrupamiento, métodos de reglas de asociación. Exportación de datos: existen métodos para exportar los modelos y sus resultados a otros entornos de data mining, soportando el estándar PMML SUITES Las suites, son sistemas que ofrecen la implementación de todas las tecnologías de Business Intelligence. En la figura 17 podemos ver algunas de las más populares que se describen a continuación. Figura 17 Suites de Business Intelligence Pentaho BI Pentaho BI es la única suite que existe de código abierto, ya que ha adoptado las herramientas de Kettle, Mondrian y WEKA para conformar una 34

51 sola plataforma de Business Intelligence. Tiene las funcionalidades de reportes, análisis, data mining e integración de datos (Pentaho, 2011). Los proyectos involucrados en Pentaho BI son: Mondrian: servidor de OLAP. JFreeReport: reporteador. Kettle: integración de datos (ETL). Pentaho: plataforma de inteligencia empresarial. WEKA: data mining. Permite a los desarrolladores de Java diseñar componentes que pueden ser rápidamente ensamblados en soluciones de inteligencia empresarial y a los usuarios finales desplegar rápidamente las soluciones existentes de Business Intelligence. A pesar de que Pentaho BI se conforma ya como una suite que satisface las necesidades de inteligencia empresarial, sus componentes no se integran perfectamente ya que surgieron de manera individual. Sin embargo la compañía Pentaho ofrece soporte comercial para todas ellas como conjunto, por eso se considera una suite. Oracle Oracle BI es la plataforma más completa para Business Intelligence, cubre un amplio rango de necesidades, incluidos los tableros interactivos, el análisis ad-hoc, alertas e inteligencia proactivas, publicación e informes avanzados, análisis predictivo en tiempo real, y análisis de tecnología móvil (Oracle, 2012). Existen varias versiones de las plataformas: Oracle BI Suite Enterprise Edition (EE): es una plataforma completa e innovadora que ofrece bases para crear soluciones empresariales desde fuentes de datos heterogéneas para la 35

52 distribución de datos, con sistemas Oracle y que no son de Oracle. Oracle BI Standard Edition (SE): incluye Oracle Discoverer, está optimizado para trabajar con los datos y las aplicaciones Oracle, y ofrecer análisis e inteligencia avanzados al menor costo. Oracle BI Publisher: también denominado Oracle XML Publisher, ofrece la solución más eficiente y escalable para informes y publicaciones, disponible para entornos complejos y distribuidos. Disponible con Oracle BI Suite EE o como solución independiente. Oracle Real-Time Decision: combina los requerimientos comerciales y de información del cliente para hacer la mejor recomendación en cada interacción con el cliente y en cada decisión operacional al adaptarse de manera inteligente, la información en constante cambio. La versión Enterprise cuenta con las herramientas Oracle Data Integrator con las capacidades de ETL para la creación de datawarehouses, Oracle OLAP para el análisis de datos multidimensional y Oracle Data mining para el análisis y aplicación de algoritmos de data mining. Actualmente estas 3 herramientas se distribuyen también por separado. SAS SAS Business Intelligence integra los datos de la empresa y tiene un servicio de análisis y reportes, posee amplias capacidades de inteligencia empresarial y la aplicación de análisis e integración de datos para crear una solución completa y de fácil interacción (SAS, 2011). SAS BI ofrece: Reportes: wizards intuitivos, reportes ilimitados, reportes ad-hoc, integración de resultados y procesos analíticos. 36

53 Consultas y análisis: consultas para todos los niveles de usuarios basados en sus necesidades y habilidades, y se pueden realizar sobre múltiples fuentes de datos utilizando datos relacionales o multidimensionales. OLAP: interfaces fáciles de utilizar para construir y mantener los cubos de OLAP. Los cubos pueden ser creados con base en datos almacenados en cualquier base de datos. Visualización: sumatorias y presentación de datos usando una gran variedad de gráficos. Data mining con Enterprise Miner. SQL Server 2008 Constituye la alternativa de Microsoft a otros potentes gestores de bases de datos como son Oracle o MySQL. Generalmente no se lo asocia como una suite de BI, sin embargo, posee potentes herramientas de productos integrados que ofrecen cobertura en la toma de decisiones. Estos productos son: Integration Services, Analysis Services y Reporting Services, que junto al alcance de SQL Server se convierten en el motor de potentes aplicaciones de inteligencia de negocios para empresas, manteniendo los costos bajo control (Microsoft, 2010). Entre sus principales características tenemos: Integra bases de datos en almacenes de datos (datawarehouses) y aumenta la capacidad de gestión de grandes tablas. Permite la construcción de soluciones Business Intelligence robustas y de alto rendimiento para el análisis de datos. Posee el módulo SQL Server Business Intelligence Development Studio para desarrollar, probar, implementar y mantener segura, escalable la integración de datos. Además de generar reportes y análisis optimizado de soluciones. 37

54 SQL Server Analysis Services permite el diseño de cubos de datos y facilita el diseño de dimensiones. SQL Server Integration Services proporciona las características y el rendimiento necesario para construir aplicaciones de clase empresarial de integración de datos desde diversas fuentes de datos. SQL Server Reporting Services extiende la plataforma de almacenes de datos para llevar la información que el trabajador necesita y tener acceso a los datos del negocio. Genera directamente reportes a herramientas familiares como Microsoft Excel y Microsoft Word. Soporta código en transact-sql y ansi-sql CLASIFICACIÓN DE SUITES EN EL MERCADO La figura 18 muestra una clasificación general de las suites comerciales de acuerdo a la opinión de los principales proveedores de software de Business Intelligence a nivel mundial. La figura muestra 4 cuadrantes: los líderes, retadores, visionarios y aplicaciones de nichos de oportunidad. Figura 18 Clasificación de suites comerciales 38

55 Líderes son los proveedores razonablemente fuertes en las capacidades de sus plataformas de inteligencia empresarial, y aquellos que pueden ofrecer a las empresas, extensas implementaciones que soportan amplias estrategias de negocios. Generan soluciones interesantes de negocio, basadas en la viabilidad y capacidad operacional de una plataforma global. Retadores ofrecen una amplia funcionalidad en sus plataformas de inteligencia empresarial y están bien posicionados en el mercado. Sin embargo, pueden estar limitados a ambientes específicos o dominios de aplicación y su visión puede estar obstaculizada por la falta de estrategias coordinadas a través de varios productos de sus plataformas de inteligencia empresarial. O puede faltarles el canal de ventas, presencia geográfica y contenido específico de la industria ofrecido por los proveedores en el cuadrante de los líderes. Visionarios son proveedores que tienen una fuerte visión para distribuir sus plataformas de inteligencia empresarial. Son distinguidos por su apertura y flexibilidad en las arquitecturas de sus aplicaciones, y ofrecen profundidad en la funcionalidad de las áreas que dirigen, pero puede faltarles cierta funcionalidad de requerimientos. Nichos de oportunidad son aquellas aplicaciones que están enfocadas en dominios específicos o ciertos puntos de la inteligencia empresarial, sin embargo les falta profundizar en la funcionalidad de otros aspectos y tienen capacidades limitadas para innovar y superar a otros proveedores en el mercado. 2.6 DISCUSIÓN FINAL En este capítulo se han mencionado los conceptos esenciales en los que se basa Business Intelligence: datawarehousing, OLAP y data mining. Estos conceptos ayudarán y facilitarán la comprensión de los siguientes capítulos, en donde se explican algunas herramientas, el análisis, diseño e implementación de la solución BI. Además, se mostró una diversidad de herramientas que ayudan a la implementación del proceso de Business 39

56 Intelligence. Sin embargo, debido a esta gran diversidad existe la complejidad de seleccionar una herramienta o herramientas que nos sean útiles. En el siguiente capítulo tomaremos el caso de aplicación para nuestra solución. 40

57 METODOLOGÍA

58 3. METODOLOGÍA El objetivo de este capítulo es describir la pyme que fue nuestro caso de estudio, así como el diseño de la solución BI, las consideraciones y requerimientos tomados en cuenta para su implementación y el modelo de datos definido. El capítulo se encuentra organizado de la siguiente manera: en la sección 3.1 se describe la empresa que sirvió como caso de estudio, su situación actual, los recursos tecnológicos con los que cuenta y los que hacían falta, en la sección 3.2 se describe la arquitectura de la solución BI, en la sección 3.3 se describe el modelo de datos para el datawarehouse, en la sección 3.4 se describe las consideraciones del proceso de ETL y por último, las conclusiones del capítulo en la sección CASO DE ESTUDIO La comercializadora de calzado STEFY RALL, la cual sirvió como caso de estudio, cuenta aproximadamente con veinte empleados y maneja un promedio de 300 transacciones de ventas mensuales en cada sucursal. Consta de un local principal con dos sucursales y una bodega central, los cuales se encuentran ubicados en la ciudad de Quito en las siguientes direcciones: a) Local principal: Av. De la Prensa y Av. Mariscal Sucre, en el Centro Comercial Condado Shopping local 258 segundo piso. b) Sucursal 1: Av. Amazonas y Av. Naciones Unidas, en el Centro Comercial Iñaquito (CCI) local 10 planta baja. c) Sucursal 2: Av. De la Prensa y Av. Carlos V, en los comisariatos COSSFA local 6. d) Bodega central: Urbanización El Condado, calle W #

59 Figura 19 Local principal de la pyme Hace 6 años la empresa adquirió un sistema de administración llamado SIC 3000, el cual ha sido instalado en todos los locales comerciales y se lo utiliza hasta el día de hoy, sin embargo, cabe señalar que este sistema siempre ha sido sub-utilizado, debido a que la empresa no lo explota en su totalidad, solamente lo utiliza para ciertas tareas. El sistema SIC 3000, que vemos en la figura 20, está diseñado para controlar las operaciones administrativas de los negocios. Algunas de sus principales características son: Figura 20 Sistema administrativo SIC

60 a) Aplicación de control de negocios para plataforma WINDOWS desarrollado en java. b) Multi-usuario. (con opción a operación en red) c) Control de inventarios. d) Módulo de punto de venta. e) Control de artículo con código de barras. (la empresa no lo utiliza) f) Control de clientes. g) Facturación para ventas por medio del punto de venta. h) Reportes para control del negocio. Este sistema le permite a la pyme mantener el control de su negocio y tener un panorama general de la situación de la empresa, lo que ayuda a tomar decisiones justificadas con la información reciente y de determinados procesos. Sin embargo no tiene la flexibilidad para realizar análisis de la información más específica. Por ejemplo: a lo largo del tiempo, historial de ventas por local MODELO DE DATOS DE LA EMPRESA En el anexo I se puede observar el diagrama entidad-relación de los datos que maneja la empresa. Este diagrama representa un componente importante del datawarehouse, el esquema de las fuentes de datos operacionales que se mencionó en el capítulo II. El diagrama fue utilizado para definir y seleccionar la información que se requirió almacenar en el datawarehouse SITUACIÓN ACTUAL Dado que se buscó el análisis de toda la información relevante de la empresa STEFY RALL, y el sistema de administración que maneja la 43

61 empresa ofrece resultados limitados, se requirió implementar las técnicas mencionadas en el capítulo II, para poder realizar un análisis con mayor profundidad que otorgue resultados con base en toda la información histórica de la empresa y no solo de algunos segmentos de la información. Se necesitó implementar un datawarehouse para almacenar datos que mediante la aplicación de las técnicas de OLAP y explotación con las técnicas de data mining, otorguen información adicional y relevante a la que brinda el sistema de administración actual. También se requirió la posibilidad de visualizar la información en diferentes dimensiones para tener más argumentos que justifiquen las decisiones que sean tomadas en la empresa. Fue necesario además, la realización de entrevistas con el Gerente para conocer comportamientos particulares del negocio, y así tomar decisiones que comprueben las ventajas competitivas existentes o que proporcionen datos necesarios para generar nuevas y que ayuden a mejorar la administración de la empresa RECURSOS TECNOLÓGICOS CON LOS QUE CUENTA La empresa cuenta con una terminal de punto de venta en cada uno de sus locales, 4 en total, y un computador utilizado como servidor de uso exclusivo para respaldos de las bases de datos y de cualquier otra información de importancia para el negocio. Las características de las terminales de punto de venta son las siguientes: Sistema operativo WINDOWS XP PROFESIONAL Procesador Intel Dual Core 3.2 GHz 2 Gb en memoria RAM (DDR2) Disco duro de 250 Gb Las características del servidor son las siguientes: Sistema operativo WINDOWS SERVER 2008 STANDARD EDITION 44

62 Procesador Intel Core I5 2.8 GHz 6 Gb en memoria RAM (DDR3) Disco duro de 500 Gb RECURSOS TECNOLÓGICOS NECESARIOS Se necesitó una nueva terminal, donde se alojó la solución Business Intelligence para realizar el análisis de la información, cuyas características se detallan: Sistema operativo WINDOWS 7 PROFESIONAL Procesador Intel Core 2 Dúo 2.0 GHz 4 Gb en memoria RAM (DDR2) Disco duro de 320 GB No era conveniente designar al servidor también como terminal para el análisis de datos, ya que es una buena política de la empresa tenerlo para uso exclusivo de respaldos en caso de presentarse algún daño en las terminales de punto de venta IDEA SOBRE VENTAJAS COMPETITIVAS El sistema que utiliza la empresa para control de la misma (SIC 300), les ha ayudado a responder ciertas preguntas básicas que todo sistema de este tipo proporciona. Por ejemplo: Cuáles son los 5 productos más vendidos? Mencionemos que el producto principal de comercialización de la empresa es el calzado, sin embargo también se comercializa otro tipo de productos de cuero como cinturones, billeteras, carteras, etc. Mediante la información y experiencia en el negocio, el gerente de la empresa, tiene algunas ideas con respecto a los productos que tienen mayor venta y ha formulado algunas estrategias que adopta como ventajas competitivas con respecto a su competencia. 45

63 Una de esas ideas es: Los productos más vendidos sirven como productos gancho, es decir, se venden a un precio reducido para que los clientes identifiquen a la tienda, como la tienda tiene mejores precios en esos productos prefieren comprarlos aquí y se compensa con el aumento de precios a otros productos que los clientes compran de paso (Parra, 2012). Como ejemplo: al comprar cierto par de zapatos que normalmente cuesta $95 en cualquier tienda del centro comercial, se lo reduce a $80, y al cinturón que combina con los zapatos se lo cambia de precio de $20 a $40. Según el gerente la probabilidad es bastante alta de que el cliente compre los 2 artículos, y en este caso incluso de obtiene una pequeña ganancia adicional de $5. Con la aplicación de la solución Business Intelligence, debemos poder comprobar la teoría del gerente o descartarla. Esto se llevará a cabo a partir del análisis de las compras de los clientes. 3.2 ARQUITECTURA DE LA SOLUCIÓN BI La arquitectura de nuestra solución estuvo conformada por tres grandes capas que son: integración, análisis y visualización. En la figura 21 se puede observar de manera gráfica la arquitectura diseñada para nuestra solución. Capa de Integración Se extrajeron los datos de las bases de datos operacionales y se seleccionaron los campos necesarios conforme al modelo de datos. Posteriormente los datos pasan por un proceso de transformación y carga en donde se limpian y estandarizan, esto con el fin de eliminar inconsistencias y posibles errores que llegaran a existir. Después son almacenados en estructuras (tablas) relacionales y de esta manera queda implementado el datawarehouse. 46

64 Capa de Análisis Se aplicaron las técnicas de OLAP y de data mining. Para OLAP, desde la capa de visualización, el usuario solicita cierta información, que es ejecutada en las tablas donde reside el datawarehouse. La información resultante es regresada al motor de OLAP y éste se encarga de enviarla nuevamente a la capa de visualización. Para data mining, se utilizó el modelado de datos clasificar facilitado por Microsoft Excel. Posteriormente, el mismo Excel entrega los resultados. Capa de Visualización Es la que permite mostrar al usuario final los resultados que se obtienen de la aplicación de las técnicas de OLAP y de data mining, de una manera que el usuario los pueda interpretar más fácilmente. Los resultados pueden visualizarse a través de gráficos. Esto facilita la comprensión e interpretación de los mismos. De esta manera, el usuario puede interactuar y manipular la información para poder analizarla de mejor manera. Esto permite obtener información relevante que le ayudará a crear estrategias justificadas que traigan beneficios a la pyme. Se definió una arquitectura de tres capas porque de esta manera cada procedimiento se encuentra bien definido e independiente de los demás. Para la implementación de la solución Business Intelligence, se escogieron las herramientas: MICROSOFT SQL SERVER 2008 para la parte de integración de datos (ETL y posterior datawarehouse) y OLAP. Mientras que para data mining y para la visualización de resultados utilizaremos MICROSOFT EXCEL 2010, dichas herramientas las explicaremos con más detalle en el Capítulo IV. 47

65 Figura 21 Arquitectura de la Solución BI Para la arquitectura propuesta se contempló que cumpliera con los siguientes aspectos: La integración de los datos debe realizarse de manera transparente para el usuario. La solución debe realizar el procesamiento de la información en poco tiempo, es decir, que los resultados se entreguen en un tiempo considerable, directamente proporcional al tamaño de los resultados a entregar. (el sistema actual es demoroso) Debe ofrecer distintos tipos de diagramas que muestren información relevante. Los resultados que entregue deben ser comprensibles y fáciles de interpretar. Los resultados mostrados a través de gráficos facilitan al usuario la comprensión de los mismos. Sencilla y de fácil interacción, debido a que las pymes no cuentan con personal experto en el área de informática y peor aún con expertos en 48

66 Business Intelligence, la solución debe ser sencilla, intuitiva y fácil de utilizar por el usuario final, en este caso, el Gerente. Debe ser económica, como hemos mencionado anteriormente, las pymes cuentan con recursos limitados, tanto económicos como tecnológicos, por lo mismo la solución debe ser accesible económicamente y debe ser capaz de trabajar con recursos tecnológicos limitados, sin que por estas dos razones se vea afectado el desempeño de la misma. Una vez que se definió la arquitectura de la solución, en las siguientes secciones se explicará cada componente más detalladamente. 3.3 MODELO DE DATOS MULTIDIMENSIONAL El primer componente de nuestra solución fue el datawarehouse, como se mencionó en el capítulo II para implementar un datawarehouse se requiere primero hacer el modelado de los datos que se van a almacenar. De los 2 tipos de modelos de datos que existen, mencionados en el capítulo II (relacional y multidimensional), se eligió el modelo de datos multidimensional para la representación de los datos de la pyme, porque se tiene una estructura general y homogénea de los datos, además de que nos da la opción de agregar información de otras fuentes de datos ya sean internas o externas a la pyme, en caso de requerirse. Otra razón por la que se escogió el modelo multidimensional, fue por su escalabilidad, es decir, se pueden agregar más hechos y dimensiones conforme se requieran en un futuro para colocar información que se genere posteriormente y que sea importante para el apoyo a la toma de decisiones en la pyme. Los hechos agregados, pueden compartir dimensiones con los hechos existentes y formar así constelaciones. A diferencia del modelo relacional, el modelo multidimensional permite analizar la información mediante cubos de OLAP. Otra de las razones por las que preferimos este tipo de modelado, es que resulta adecuado para el 49

67 estudio de los datos de la pyme, además de las técnicas de reporteo general. El modelo multidimensional también contempla el histórico de la información, el cual se va almacenando cada vez que hacen actualizaciones al datawarehouse. La información almacenada se encuentra agregada, lo que permite analizar grandes volúmenes de datos en espacios menores de almacenamiento. Esta característica facilita visualizar la información de manera gráfica, en reportes, mapas o gráficos, que a su vez simplifica la comprensión de los resultados que se entreguen. Para la elaboración del modelo multidimensional, se escogió, del diagrama entidad-relación de los datos operacionales de la pyme, visto en el anexo I, las tablas que tienen mayor importancia para el negocio, basándonos en las entrevistas realizadas al Gerente de la empresa, vistas en el anexo II. En la figura 22 podemos observar las tablas mencionadas, que contienen una versión más definida de los datos necesarios que nos interesa analizar. El diagrama muestra procesos importantes que se llevan a cabo en la pyme, representados cada uno en una entidad. Este diagrama fue útil como base para definir el modelo de datos multidimensional que fue usado para la implementación del datawarehouse, el cual explicaremos enseguida. Figura 22 Entidades principales de la pyme 50

68 El modelo de datos multidimensional definido para la implementación del datawarehouse, es un esquema estrella, con el cual se analizó la información de la pyme del caso de estudio. En la figura 23 se muestra nuestro modelo multidimensional, con cada una de sus dimensiones. Figura 23 Modelo multidimensional En la tabla 6 se detallan de mejor manera los atributos del modelo multidimensional. 51

69 Tabla 6 Atributos del Modelo Multidimensional Dimensión - Atributo Tipo de Dato Fecha_hora datetime Dia_Semana varchar (10) Dim_Epoca Semana_Anio varchar (15) Epoca_Anio varchar (15) Anio int Dim_ProductoXCategoria Producto varchar (50) Categoria varchar (15) Fecha_hora datetime Mes varchar (25) Dim_Tiempo Trimestre varchar (25) Semestre varchar (25) Anio int Dim_Vendedor Vendedor varchar (40) Categoria varchar (25) Producto varchar (50) Dim_ProductoXPrecio Precio money Grupo_Precio varchar (15) Dim_Cliente Cliente varchar (70) Clase varchar (50) Dim_Forma_Pago Forma_Pago varchar (10) Tipo varchar (25) Dim_Lugar Sucursal varchar (10) Ciudad varchar (10) La tabla de hechos o FACT únicamente contiene atributos calculados de tipo money e int, además de las llaves foráneas de cada una de las dimensiones. Sobre el modelo multidimensional que se definió, se construyó el cubo de datos de OLAP y se aplicó el algoritmo de árboles de decisión de Microsoft para data mining. En las siguientes secciones se verán las consideraciones para el proceso ETL y la implementación de OLAP, data mining para la solución Business Intelligence. 3.4 LIMPIEZA E INTEGRACIÓN DE DATOS Los datos almacenados en las bases de datos operacionales no siempre se encuentran homogéneos y estandarizados. Esto se debe a que los datos hayan sido ingresados por diferentes personas, que no se haya definido con anterioridad un estándar para la captura de los datos o simples errores humanos. 52

70 Para realizar un buen análisis tanto de OLAP como de data mining, fue necesario que la información almacenada en el datawarehouse se encuentre homogénea y estandarizada. Para esto se requiere pasar los datos por un proceso ETL, que se mencionó en el capítulo II, que permita la integración de los datos. Para integrar los datos de la pyme del caso de estudio se tomó en cuenta las siguientes consideraciones: Se verificó las inconsistencias que existen en los datos, que pueden deberse a errores de escritura en el ingreso de datos en el sistema o por eliminación de registros. Se eliminó duplicaciones en valores que hayan sido escritos incorrectamente, o que signifiquen lo mismo pero hayan sido escritos de formas diferentes. Como resultado de estas consideraciones se encontró ciertas inconsistencias en los datos de la pyme tales como: Clientes con número de cédula erróneo, ya sean con menos de 10 dígitos, números alfa numéricos, números basura ( ) o campos vacíos. Nombres de clientes basura o nombres antecedidos por puntos. Columnas totalmente vacías, como la de de clientes. Números de teléfono alfa numéricos. Facturas sin el nombre del cliente, CI o RUC. En la tabla de kardex en el campo tipo de documento, siempre se usa factura, sin embargo en algunos casos se encuentra números. En la tabla stocks, algunas filas con campos incompletos. 53

71 Para observar el código fuente del proceso ETL utilizado en este caso de estudio, dirigirse al Anexo III de este documento. Después de aplicar este proceso, los datos quedaron homogéneos, limpios y estandarizados, por lo que se pudo proceder al análisis de información. 3.5 DISCUSIÓN FINAL En este capítulo se describió el estudio que se realizó de los procesos de negocio que se llevan a cabo en la pyme, sus necesidades tecnológicas y las implementaciones que se llevaron a cabo para aplicar la solución Business Intelligence, así como el análisis de los datos de la pyme y la selección de los atributos necesarios para diseñar el modelo de datos. También se definió todas la consideraciones que se tomaron en cuenta para la implementación de las capas de actividades: ETL y OLAP. Se definió la arquitectura de la solución, el modelo de datos y la limpieza de datos. Resta por cumplir la fase de implementación de la solución BI que veremos en el siguiente capítulo, así como la justificación de las herramientas seleccionadas. 54

72 ANÁLISIS DE RESULTADOS

73 4. ANÁLISIS DE RESULTADOS En este capítulo se muestra la integración de las herramientas seleccionadas para nuestra solución Business Intelligence, la justificación de su selección y detalles sobre la implementación de la solución. El capítulo IV se encuentra organizado de acuerdo a la arquitectura propuesta en el capítulo III, en la sección 4.1 se describe la implementación de la capa de integración, en la sección 4.2 se describe la implementación de la capa de análisis, en la sección 4.3 se describe la capa de visualización y por último, en la sección 4.4 las conclusiones del capítulo. La figura 24 muestra el flujo de datos a través de las 3 capas: integración, análisis y visualización que integran la solución BI. Los datos son extraídos de la base de datos transaccional y pasan por el proceso de ETL para poder ser almacenados en el datawarehouse. Posteriormente los datos almacenados en el datawarehouse son explotados por la capa de análisis en donde se encuentran las técnicas de OLAP y data mining, por medio de las cuales se manipuló la información para ofrecer los resultados requeridos por el usuario final. Por último los datos son desplegados en la capa de visualización en donde el usuario puede manipular gráficamente los resultados que se le hayan entregado, esta información le servirá como base y justificación para el apoyo a la toma de decisiones dentro de la empresa. 55

74 Figura 24 Flujo de datos de la solución BI En las siguientes secciones veremos la implementación de cada una de las capas más detalladamente. 4.1 CREACIÓN CAPA DE INTEGRACIÓN Para la creación de la capa de integración, se migró las bases de datos de la pyme (Sic y Sic2) que se encontraban en Microsoft Access (.mdb) a Microsoft SQL Server (.mdf) usando la herramienta Microsoft SQL Server Migration Assistant for Access, observada en la figura 25. Posteriormente se sometió la base de datos al proceso ETL mencionado en el capítulo III y visto en el anexo III, para finalmente almacenar los datos en el datawarehouse (SIC_OLAP). Se decidió utilizar Microsoft SQL Server por ser una herramienta que satisface todas las necesidades para este tipo de proyectos como se mencionó en el capítulo II, además por ser la herramienta de uso principal durante la carrera universitaria y por esta razón se la conoce bien. 56

75 Figura 25 Migración de MS Access a MS SQL Server 4.2 CREACIÓN CAPA DE ANÁLISIS OLAP Para la creación de la capa de análisis OLAP, se utilizó la herramienta SQL Server Business Intelligence Development Studio, observada en la figura 26. Esta aplicación viene incluida en la instalación de SQL Server En SQL Server BI, se procedió a realizar las actividades que a continuación se detallan: 1. Se creó un nuevo proyecto y se agregó un nuevo Data Source en el que se seleccionó el datawarehouse (SIC_OLAP), creando así la Connection String (Sic Olap.ds). 2. Se creó una nueva Vista en la que se seleccionó nuestro Data Source creado en el paso 1. Realizado este paso ya se tuvo disponible las tablas y su contenido del datawarehouse. (DS_SIC_OLAP.dsv) 57

76 3. Se agregó las dimensiones contenidas en la Vista del paso Se creó un nuevo cubo, usando nuestro Data Source y solo seleccionando la tabla FACT. Figura 26 SQL Server BI Development Studio Realizadas las actividades anteriores se obtuvo el cubo de datos, con el cual se procedió a realizar consultas en el mismo SQL Server BI. Para esto se abre la vista diseño del cubo de datos y se marca la pestaña Browser (navegador), como se aprecia en la figura 27. Finalmente se escogió y arrastró las medidas y dimensiones de interés al Browser para obtener la información requerida. 58

77 Figura 27 Browser del cubo de datos Como ejemplo se realizó la siguiente consulta: Cuál es el monto de IVA pagado durante el año 2010 en cada uno de los locales comerciales? Los resultados pueden verse en la tabla 7 y en la figura 28 respectivamente. Tabla 7 Monto IVA en el 2010 Sucursal Monto IVA 2010 ($) CCI El Condado Total Los resultados obtenidos con esta consulta, entre otras, fueron verificados con el contador de la empresa quien confirmó que los resultados encontrados mediante el cubo de datos eran correctos. Figura 28 Monto IVA en el

78 Cabe indicar que la manipulación del cubo de datos con SQL Server BI se realizó con fines de prueba y puede ser utilizado como segunda opción, ya que para usos de la pyme se utilizó Microsoft Excel, tanto para manipular el cubo como para data mining. Dichos casos los veremos en las siguientes secciones de este capítulo DATA MINING Para utilizar la herramienta Data Mining de Microsoft Excel se necesitó instalar un complemento (add-in) que proporciona las funcionalidades para este tipo de tareas como se observa en la figura 29. Figura 29 Data Mining para MS Excel Una vez instalado el complemento, se realizaron las siguientes tareas: 1. En el menú MINERÍA DE DATOS se procedió a seleccionar el modelo de datos Clasificar que utiliza el algoritmo de Arboles de Decisión de Microsoft (Microsoft Decision Trees), revisado en el capítulo II, para analizar los datos del Datawarehouse (Sic_Olap) como se observa en la figura

79 Figura 30 Modelo de datos CLASIFICAR 2. Se procedió a analizar el lugar (CCI o Condado), considerando el número de ventas y el tiempo (fechas), obteniendo los resultados vistos en la figura 31 y explicados detalladamente en el Anexo IV de este documento. Figura 31 Resultados del Modelo Clasificar 61

80 La técnica de data mining proporcionada por Microsoft Excel para este trabajo fue útil e interesante, sin embargo, la minería de datos está orientada a bases de datos o datawarehouses de tamaño mucho más grande al utilizado en esta tesis. 4.3 CAPA DE VISUALIZACIÓN Para la capa de visualización, se decidió utilizar Microsoft Excel como aplicativo para manipular la información del cubo de datos por ser una herramienta conocida por los usuarios de la pyme, además considerando que no cuentan con personal informático para recibir soporte en caso de necesitar ayuda en otra aplicación exclusiva para Business Intelligence. Para manipular el cubo de datos se realizaron las siguientes tareas: 1. En el menú DATOS de Excel se procedió a realizar la conexión con el cubo, seleccionando la opción desde analisis services, como se observa en la figura 32. Figura 32 Conexión al cubo de datos 62

81 2. En la figura 33 se muestra como Excel generó automáticamente una tabla dinámica y un gráfico dinámico en blanco cuando se usó la conexión del punto 1, además incluyó la información del cubo para manipularla y así presentar los resultados de las consultas requeridas en los recursos estadísticos mencionados. Figura 33 Recursos generados por MS Excel Ya con la conexión al cubo de datos disponible, se pudo realizar cualquier tipo de consulta. Como ejemplo se realizó la siguiente: Cuál es el monto total de IVA pagado a lo largo del tiempo según la categoría de los productos? Los resultados pueden verse en la tabla 8 y en la figura 34 respectivamente. Tabla 8 Monto IVA por Categoría Categoría Monto IVA ($) Accesorios Botas Calzado casual Calzado hombre Calzado mujer Calzado Niños Otros Total

82 Figura 34 Monto IVA por Categoría Como se pudo apreciar, el calzado de mujer es el que más IVA ha pagado durante el tiempo. Estos resultados están acorde a la realidad del negocio, ya que en los pedidos de productos que realiza la pyme trimestralmente, mínimo el 50% de la mercadería es calzado de mujer, esto debido a que es el calzado que más se vende. 4.4 DISCUSIÓN FINAL A lo largo del capítulo se mencionó como se implementó cada una de las capas que conformaron esta solución Business Intelligence, así como los resultados obtenidos y algunos detalles que se tomaron en cuenta. También se agregó algunas capturas de pantalla para facilitar la comprensión del capítulo. Finalmente en el siguiente capítulo se expondrán las conclusiones y recomendaciones que dejó el desarrollo de este trabajo. 64

83 CONCLUSIONES Y RECOMENDACIONES

84 5. CONCLUSIONES Y RECOMENDACIONES En este capítulo se detallan los logros más importantes que se cumplieron durante la elaboración del presente trabajo y las consideraciones para el desarrollo de un posible trabajo futuro. 5.1 CONCLUSIONES Se entendió las definiciones necesarias de lo que es o comprende una solución Business Intelligence. Se conoció de manera general las funcionalidades de algunas herramientas existentes en el mercado para cada una de las técnicas: datawarehousing, OLAP, data mining. Se diseñó un ambiente integral que facilitó el uso de las herramientas seleccionadas para la implementación de la solución Business Intelligence. Se desarrolló una solución Business Intelligence en la pyme comercializadora de calzado STEFY-RALL, integrando las técnicas de datawarehousing, OLAP y data mining. 5.2 RECOMENDACIONES Con el pasar del tiempo en caso de que la base de datos de la pyme se vuelva demasiado grande, se debería pensar en utilizar otras herramientas especializadas en Business Intelligence como PENTAHO u ORACLE. Considerando que la base de datos de la pyme es relativamente pequeña, no fue necesario utilizar una herramienta especializada en minería de datos, sin embargo a futuro se podría considerar el uso de una. Con la activación del código de barras que actualmente no utiliza la pyme y con encuestas de atención al cliente, se mejoraría la alimentación del datawarehouse con información mucho más específica sobre el stock de productos y sobre la satisfacción del cliente, con esto se podría 65

85 implementar dimensiones adicionales al cubo de datos o perfeccionar las existes. El datawarehouse siempre será alimentado con la información cargada por el proceso ETL, por lo que en caso de necesitarse modificaciones a las reglas de negocio contempladas en dicho proceso, se estaría hablando de una nueva versión de la solución BI. La pyme podría considerar el desarrollo de una pequeña aplicación complementaria para esta solución BI, la misma que facilitaría el manejo de información estructurada por el usuario. Se debería manejar de manera más formal ciertos procesos, como la movilización de mercadería de un local a otro, ya que por este motivo se encuentran inconsistencias de productos en las bases de datos al momento de realizar inventarios. La pyme debería llevar un registro histórico de precios que permita conocer si el producto en verdad fue comercializado con el valor que constaba en el sistema o con otro valor. Esto con el fin de conocer la utilidad real que obtiene de la venta. 66

86 BIBLIOGRAFÍA Caserta, K. (2004). The datawarehouse ETL toolkit. Usa: Wiley. Clover ETL. (1 de Julio 14 de 2010). CloverETL. Recuperado el 30 de Mayo de 2012, de CloverETL: Dutina, R. (23 de Marzo de 2007). Octopus. Recuperado el 31 de Mayo de 2012, de Octopus: Fayyad, U. (1 de Febrero de 1996). Ebookee. Recuperado el 26 de Abril de 2012, de Ebookee: Discovery-and-Data-Mining_ html Harjinder, G. (1996). La integración de información para la mejor toma de desiciones. Mexico: Prentice Hall. Hernandez, J. (2004). Introducción a la minería de datos. Madrid: Pearson. Hyde, J. (19 de Agosto de 2006). Olap4j. Recuperado el 7 de Junio de 2012, de Olap4j: Inmon, W. (2005). Building the Datawarehouse. Usa: Wiley. Instituto Nacional de Estadísticas y Censos. (1 de Diciembre de 2011). INEC. Recuperado el 28 de Abril de 2012, de INEC: Kimball, R. (2008). The datawarehouse lifecycle. Usa: Wiley. Larose, D. (28 de enero de 2007). CSE. Recuperado el 30 de Abril de 2012, de CSE: %202006%20Data%20Mining%20Methods%20and%20Models.pdf 67

87 Microsoft. (7 de Octubre de 2010). Microsoft. Recuperado el 26 de Junio de 2012, de Microsoft: Microsoft. (14 de enero de 2010). MSDN. Recuperado el 5 de Abril de 2012, de MSDN: Oracle. (13 de Enero de 2012). Oracle. Recuperado el 20 de Junio de 2012, de Oracle: Palo. (24 de Octubre de 2009). Palo by Jedox. Recuperado el 6 de Junio de 2012, de Palo by Jedox: Parra, F. (22 de Junio de 2012). Cómo funciona la pyme. (J. P. Castañeda, Entrevistador) Pentaho. (10 de Noviembre de 2009). Kettle. Recuperado el 31 de Mayo de 2012, de Kettle: Pentaho. (17 de Marzo de 2010). Recuperado el 5 de Junio de 2012, de Pentaho. (30 de Noviembre de 2011). Pentaho. Recuperado el 18 de Junio de 2012, de Pentaho: Ponniah, P. (2007). Data modeling fundamentals. Usa: Wiley. Prudsys. (8 de Marzo de 2011). Prudsys. Recuperado el 14 de Junio de 2012, de Prudsys: Rapid-I. (15 de Julio de 2011). Rapid-I. Recuperado el 9 de Junio de 2012, de Rapid-I: 68

88 Revista Líderes. (1 de Mayo de 2012). Revista Lideres. Recuperado el 8 de Junio de 2012, de Revista Lideres: Robert Gordon University. (9 de Octubre de 2010). RGU. Recuperado el 8 de Junio de 2012, de RGU: _handout.pdf SAP. (16 de Mayo de 2006). SAP Business Magement. Recuperado el 26 de Febrero de 2012, de SAP Business Magement: eling.pdf SAS. (29 de Agosto de 2011). SAS. Recuperado el 24 de Junio de 2012, de SAS: erver/index.html#section=3 Sprague, R. (1995). Decision support for management. Usa: Prentice Hall. Stackowiak, R. (10 de Enero de 2007). Myopera. Recuperado el 29 de Marzo de 2012, de Myopera: Talend. (20 de Abril de 2007). Talend. Recuperado el 4 de Junio de 2012, de Talend: Universidad de Concepción Chile. (2 de Febrero de 2008). Departamento de Ingeniería Informática. Recuperado el 12 de Marzo de 2012, de Departamento de Ingeniería Informática: 69

89 Universidad Francisco José de Caldas. (27 de Agosto de 2003). Udistrital. Recuperado el 6 de Mayo de 2012, de Udistrital: University of California. (17 de noviembre de 2010). UCLA. Recuperado el 19 de abril de 2012, de UCLA: /palace/datamining.htm University of Waikato. (25 de Julio de 2011). Weka. Recuperado el 12 de Junio de 2012, de Weka: Vieira, L. (20 de octubre de 2009). Books google. Recuperado el 15 de Junio de 2012, de Books google: =PA115&dq=reglas+de+asociacion+mineria+de+datos&source=bl&ot s=rahdewrhaj&sig=4qw48qdra9gnrycx2o3zicxzxew&sa=x&ei=- NYyUJydM- TV6QGc24GgBQ&ved=0CAYQ6AEwADgK#v=onepage&q=reglas%2 0de%20asociacion%20m 70

90 ANEXOS

91 ANEXO I DIAGRAMA ENTIDAD - RELACIÓN DE LA BASE DE DATOS USADA POR LA PYME

92 ANEXO I DIAGRAMA ENTIDAD RELACIÓN DE LA BASE DE DATOS USADA POR LA PYME Figura 35 Diagrama E-R de la base de datos 71

93 ANEXO II ENTREVISTAS AL GERENTE GENERAL DE LA PYME

94 ANEXO II ENTREVISTAS AL GERENTE GENERAL DE LA PYME ENTREVISTA #1 y #2 Las preguntas y respuestas con letra cursiva corresponden a la segunda entrevista que se generó por motivo de dudas con base a las respuestas obtenidas en la primera entrevista. 1. Cuáles son las decisiones comunes o frecuentes que por lo general se toman en el negocio? i. En fechas especiales como san Valentín, día de la madre, navidad, etc. Se cambian a códigos de descuento ciertos productos. Los precios con descuentos vuelven a ser cambiados? Si se pone en descuento 10 o más pares se cambia a código de descuento, que son 1005 hombre y 2005 mujer. Si son 5 pares o menos se hace directamente el descuento al momento de facturar, sin cambiar de código, ya que el sistema permite hacer descuentos directamente de 5%, 10%, 15%, etc. ii. Del precio que se tiene registrado un producto en el sistema, se puede hacer un descuento adicional de hasta $4 con el fin de no perder el cliente. Y al hacer esto se procede a cambiar el precio del producto en el sistema. Los códigos son independientes, así sea el mismo modelo y color? No son independientes así sean el mismo modelo y color. Los códigos de manejan por un rango de precios. Como ejemplo el 1008 son todos los zapatos más caros para hombre ($95), sin importar que sean de modelo y talla diferente. Por motivo de pedidos nuevos o ventas, internamente se maneja un número de referencia que no consta en el sistema, esto para especificar qué modelo y talla se necesita. 72

95 iii. iv. Cada 3 meses se hace un nuevo pedido para actualizar los modelos. En algunos modelos si tuvieron buena aceptación se los vuelve a pedir. Por qué siempre se hace un pedido cada 3 meses? Normalmente se hace 2 pedidos grandes en el año, en febrero y agosto, dichos pedidos llegan en abril y octubre respectivamente, finalmente en noviembre se hace una reposición para tener bastante mercadería en diciembre. Y así se tenga todavía mercadería, estos pedidos se hacen obligatoriamente por actualizar modelos y aprovechar las ferias de zapatos en Colombia que son en esos meses. Al mes se hace aproximadamente 3 cambios de mercadería a clientes por diferentes motivos. v. A diario se anulan facturas por estar con errores de datos. Errores cometidos por parte de los vendedores. Las facturas anuladas se ven en la BDD? Si, están en la tabla KARDEX en el campo descripción factura y aquí mismo también se puede ver las devoluciones o cambios de mercadería. Las facturas anuladas son un tema crítico, más que todo por lo arriesgado que es emitir una factura con errores. Por cuestiones de multas o clausura por parte del SRI que en ocasiones hace compras ficticias para ver cómo trabaja el local con las facturas. Por factura anulada el vendedor recibe una multa. vi. vii. viii. En el cierre de caja si este no cuadra, se descuenta a los empleados. A no ser que adjunten los recibos respectivos para justificar egresos. Se cambia los precios de acuerdo a los impuestos de importación. Se coloca en liquidación ciertos zapatos, por ser los últimos pares o por fallas en el zapato. Se cambia el precio o también el código de zapato en liquidaciones? Ya fue contestada anteriormente. 73

96 ix. Inventarios cada semana de 3 modelos o códigos. Códigos: 10 hombre, 20 mujer, 50 niños, 30 botas. De los inventarios que se realiza, con qué frecuencia se encuentra inconsistencias y por qué se hace inventarios? Es común encontrar inconsistencias en los inventarios totales semestrales que se los hacen en todos los locales y en bodega. En los inventarios semanales por lo general no hay inconsistencias. Los inventarios se los hace para saber la rotación de la mercadería y también para saber que se pierde y que se necesitaría pedir en caso de una reposición de mercadería. 2. Cuáles cree usted que son las áreas o actividades críticas de su negocio? i. La venta de los productos, que depende mucho de que haya clientes. ii. iii. iv. El stock es muy importante, ya que sin stock no hay ventas, por eso los pedidos son obligatoriamente cada 3 meses. Existen pedidos especiales por algo muy vendido? Si, se hace la reposición por algún modelo muy vendido pero no es común. Por lo general las reposiciones son en noviembre y agosto por motivo de la navidad y la entrada a clases. Se controla mucho las comisiones de los empleados. Los inventarios, para saber que hay y que no, para según eso hacer el pedido. 3. Cómo manejan su información actualmente y como le gustaría o preferiría? Actualmente se maneja todo solo con reportes. Me gustaría también manejarla con diagramas de barras o pasteles para que sea más visual la información pero manteniendo también los reportes. 74

97 4. Qué factores positivos o negativos puede mencionar del negocio desde el punto de vista del sistema que utilizan? i. Mejoramiento notable de la contabilidad. ii. iii. iv. Mejoramiento en la búsqueda de productos, clientes, facturas, etc. Mejora en el ordenamiento y codificación de la mercadería. Como negativo, al no tener código de barras el personal nuevo tiene confusiones al vender ciertos productos al momento de registrarlos en el sistema. 5. Qué le gustaría saber de su negocio? i. Las ventas por periodo. Mensual, trimestral, semestral, anual. ii. iii. iv. Si he ganado o perdido clientes comparando el mismo periodo en años diferentes o poder comparar meses diferentes del mismo año. Cuanto he vendido y cuanto he tenido que cambiar. Los productos más vendidos o aceptados por los clientes de acuerdo al tipo de zapato (hombre, mujer, niño) v. Las ventas por vendedor, por local. Se guarda el nombre del vendedor que realizó alguna venta en el sistema? El sistema tiene la opción de que los vendedores entren con su usuario y contraseña pero no se la utiliza, los vendedores ingresan al sistema con el usuario VENDEDOR y una contraseña conocida por todos ellos. En el sistema el responsable aparece como vendedor. vi. Las ventas por periodo de tiempo, considerando solo zapatos de hombre vs mujer. 6. Podría más o menos definir cuáles son los factores críticos de éxito (KPIs) por los que se rige su negocio? 1) Las ventas mensuales en enero > $

98 2) Las ventas mensuales en febrero > $9000 3) Las ventas mensuales en marzo > $9000 4) Las ventas mensuales en abril > $ ) Las ventas mensuales en mayo > $ ) Las ventas mensuales en junio > $9000 7) Las ventas mensuales en julio > ) Las ventas mensuales en agosto > ) Las ventas mensuales en septiembre > ) Las ventas mensuales en octubre > $ ) Las ventas mensuales en noviembre > $ ) Las ventas mensuales en diciembre > $ ) El stock en agosto del código 50 > 100 (tener mínimo 100 pares de zapatos de niño por motivo del inicio de clases) 14) El stock en noviembre del código 30 > 100 (tener mínimo 100 pares de botas por motivo de fiestas de Quito) 15) El stock en julio del código 20 > 100 (tener mínimo 100 pares de zapatos de mujer por motivo de graduaciones en colegios, universidades) 16) Clientes nuevos en el año > 60% (comparando con el año anterior, para saber si las promociones atraen clientes nuevos) 17) Los cambios de mercadería en los meses de mayo, agosto, diciembre < 10 18) Clientes fidelidad: 100 clientes en el año que compren de 2 a 3 veces. 19) Stock, inventario se maneja mucho por un numero de referencia interno que no consta en el sistema. 20) Ventas Las ventas por empleado no se podrían saber por lo expuesto anteriormente. 21) Facturas anuladas las facturas anuladas diarias < 3 22) Monto de ventas mensual por local > $ ) Cantidad de productos vendidos en época por día de la madre > ) Cantidad de productos vendidos en época por entrada a clases >

99 25) Cantidad de productos vendidos en época navideña > ) Número de ventas semanales por local > 50 27) Ventas por cliente por año > 2 28) Monto promedio por factura > $70 ENTREVISTA #3 1. Los productos tienen una utilidad fija, es decir, existe un porcentaje definido fijo de ganancia por productos? La utilidad depende mucho de en cuanto se compre la mercadería, ya que si se consigue la mercadería a un buen precio (barato) la utilidad va a ser mayor, y va a ser menor si se compra a un precio caro. En cualquiera de los 2 casos la intención del local es ganar mínimo el 40%, ya que ganando menos no alcanzaría para pagar arriendos ni sueldos y peor aún pensar en ganancias. 1.1) La utilidad es variable de acuerdo a la temporada? La utilidad durante todo el año en general es fija, tal vez en navidad se la bajaría exagerando un 10% pero solo en casos especiales como compras de 2-3 artículos de precios altos, esto con el fin de aprovechar la temporada y no perder la venta. 2. Cuál es la comisión definida para vendedores? La comisión para vendedores en locales comerciales de prendas de vestir es del 3%. 77

100 3. Los descuentos pre definidos para pagos con efectivo y con tarjeta de crédito son? En efectivo el 10% de descuento y con tarjetas de crédito el 5%, siempre y cuando las ventas pasen los $60. Recordar que en el sistema se puede hacer descuentos automáticos en múltiplos de 5%, pero solamente bajo autorización administrativa para no perder la venta y dependiendo del producto a vender. 4. En algún lugar se almacena la forma de pago? Si, existe una tabla llamada FORMA_PAGO donde están las diversas formas de pago (efectivo, diners, visa pichincha, etc.). Aparte existe la tabla FACTURAPAGO en donde se almacena la forma de pago con el código de cliente que también consta en la tabla FACTURA. 5. En la tabla KARDEX se registra las compras a proveedor o ingresos? Se registra los ingresos, claro que podríamos decir que los ingresos también fueron compras a proveedores, sin embargo en esta tabla no se almacena ninguna información acerca de proveedores. En la tabla KARDEX existe el campo descripción, donde existen 7 tipos de transacciones como: venta, ingreso, egreso, etc. En esta tabla también existen algunos campos calculados. 6. Rotación de inventario o veces comprado un producto Está en la tabla KARDEX considerando los campos codpro y descripción = ingreso de productos a bodega, se puede mirar las veces comprado un producto. 78

101 7. Definir más específicamente los códigos de productos y también definir algunos códigos internos (los que definen el modelo exacto del zapato). Todos los códigos están en la tabla PRODUCTOS y se puede ver su movimiento en la tabla KARDEX según el código de producto codpro. HOMBRE 1008 zapatos hombre formales más de $95 Cng41 zapato negro cordón ginos talla 41 Bco40 botín café orpar talla zapatos hombre formales menos de $95 Mnm40 mocasín negro mims talla 40 Cnm39 zapato cordón modas talla zapatos hombre casuales más de $95 Gmcs42 gamuza mocasín café stefy talla 42 Gmgn40 gamuza mocasín negro ginos talla zapatos hombre casuales menos de $75 Bnp40 bolichero negro pielin 41 Ghp41 gamuza habano pielin zapatos hombre en descuento - $60 Cno36 zapato cordón negro orpar talla 36 Bbp44 bolichero blanco pielin talla 44 79

102 MUJER zapatos mujer más de $105 Tsrn36 zapato de taco stefy rall negro talla 36 Tsa37 zapato de taco salom azul oscuro talla zapatos mujer de $105 a $80 Ttn35 zapato taco tauros negro talla 35 Tfv36 zapato taco farinos vino talla zapatos mujer menos de $80 Scp38 sandalia colombiana plateada talla 38 Spmb36 sandalia perfect magnolia blanca talla zapatos mujer en descuento -$50 Sen37 sandalia ecuatoriana negra talla 37 Tpc35 zapato taco pequeño colombiana talla 35 BOTAS botas mujer más de $120 Bsgn38 botas shivago gamuza negra talla 38 Bscb39 botas shivago cuero beige talla botas mujer menos de $120 Bzcn36 bota zandra cuero negro talla 36 Bfcb37 bota farinos cuero beige talla botas mujer en descuento -$70 Ben39 bota ecuatoriana negra talla 39 Beng38 bota ecuatoriana negra gamuza talla 38 80

103 MUJER BOLICHEROS 4001 zapatos mujer bolicheros casuales más de $70 Bbv38 bolichero blanco victoria talla 38 Bnv38 bolichero negro victoria talla zapatos mujer bolicheros casuales menos de $70 Bza38 zapato zandra bailarina azul talla 38 Btzn37 zapato bailarina taco mini zandra negro talla zapatos mujer bolicheros casuales en descuento -$50 Bcr36 zapato bailarina conde rojo talla 36 Bem37 zapato bailarina ecuador morado talla 37 NIÑOS 5050 zapatos niños más de $50 Cng34 zapato cordón negro ginos talla 34 Cng32 zapato cordón negro guiffer talla zapatos niños menos de $50 Cnm34 zapato cordón negro mishel talla 34 Cbm33 zapato cordón blanco mishel talla 33 ACCESORIOS DE CUERO (correas, cinturones, bolsos, carteras, billeteras) 9015 bolsos y carteras Bbgc bolso blanco gigante Colombia Canpb cartera negra pequeña balestra 81

104 9018 correas y cinturones Chnc correa hombre negra capelli Cbv cinturón blanco victoria 9045 billeteras Bng billetera negra ginos Bcg billetera café ginos Existen otros códigos que no se contemplan en esta lista, esto debido a que no se volvió a comprar los modelos pertenecientes a esos códigos. Esta lista contiene los códigos que se manejan actualmente y frecuentemente. 82

105 ANEXO III CÓDIGO FUENTE DEL PROCESO ETL

106 ANEXO III CÓDIGO FUENTE DEL PROCESO ETL --ProcesoETL versión Descripción: Función que categoriza al cliente --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: septiembre Última modificación: n/a USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER function [dbo].[categoriza_cliente] float ) returns varchar(50) begin return (select case when count(*) then 'Muy Frecuente (>'+convert(varchar(10),@medio)+' vts.)' when count(*) and count(*) then 'Frecuente (entre '+convert(varchar(10),@menor)+' y '+convert(varchar(10),@menor)+' vts.)' else 'Poco Frecuente (<'+convert(varchar(10),@medio)+' vts.)' end from tmp_factura where codcli end --ProcesoETL versión Descripción: Carga dimensión cliente --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: septiembre Última modificación: noviembre 2012 USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as Begin int int int = (select top 1 COUNT(*) from tmp_factura where codcli <> 1 group by codcli order by 1 desc) - (@mayor / 3) 83

107 / 3 = 0 begin delete from Fact delete from Dim_Cliente insert into dim_cliente select distinct nomcli +' - from Sic.dbo.Cliente where nomcli +' - '+codcli in (select cliente from tmp_factura) insert into dim_cliente select distinct nomcli +' - from Sic2.dbo.Cliente where nomcli +' - '+codcli in (select cliente from tmp_factura) and nomcli +' - '+codcli not in (select cliente from dim_cliente) end 1 begin insert into dim_cliente select distinct nomcli +' - from Sic.dbo.Cliente where nomcli +' - '+codcli in (select cliente from tmp_factura) and nomcli +' - '+codcli not in (select cliente from dim_cliente) insert into dim_cliente select distinct nomcli +' - from Sic2.dbo.Cliente where nomcli +' - '+codcli in (select cliente from tmp_factura) and nomcli +' - '+codcli not in (select cliente from dim_cliente) end End --ProcesoETL versión Descripción: Carga dimensión época --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: septiembre Última modificación: octubre 2012 USE [SIC_OLAP] GO 84

108 SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as begin insert into Dim_Epoca select distinct convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)), DATENAME(WEEKDAY,fecfac), DATENAME(WEEK,fecfac), case when MONTH(fecfac) = 5 and DAY(fecfac)<=15 then 'Dia Madre' when MONTH(fecfac) = 12 and DAY(fecfac)<=25 then 'Navidad' when MONTH(fecfac) = 9 and DAY(fecfac)<=15 then 'Entr.Clases' else 'Normal' end, year(fecfac) from sic.dbo.factura where convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)) not in (select Fecha_Hora from Dim_Epoca) insert into Dim_Epoca select distinct convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)), DATENAME(WEEKDAY,fecfac), DATENAME(WEEK,fecfac), case when MONTH(fecfac) = 5 and DAY(fecfac)<=15 then 'Dia Madre' when MONTH(fecfac) = 12 and DAY(fecfac)<=25 then 'Navidad' when MONTH(fecfac) = 9 and DAY(fecfac)<=15 then 'Entr.Clases' else 'Normal' end, year(fecfac) from sic2.dbo.factura where convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)) not in (select Fecha_Hora from Dim_Epoca) end --ProcesoETL versión Descripción: Carga dimensión forma de pago --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: octubre Última modificación: noviembre 2012 USE [SIC_OLAP] GO SET ANSI_NULLS ON 85

109 GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as begin delete from Dim_Forma_Pago = 1 -- actualizacion insert into Dim_Forma_Pago select despag +' - '+ forpag, case when tarjeta = 1 then 'Tarj.Cred.' when despag = 'Efectivo' then 'Efectivo' when despag like 'Cheque%' then 'Cheque' else 'Documento' end from Sic.dbo.Forma_Pago where despag +' - '+ forpag not in (select Forma_Pago from Dim_Forma_Pago) insert into Dim_Forma_Pago select despag +' - '+ forpag, case when tarjeta = 1 then 'Tarj.Cred.' when despag = 'Efectivo' then 'Efectivo' when despag like 'Cheque%' then 'Cheque' else 'Documento' end from Sic2.dbo.Forma_Pago where despag +' - '+ forpag not in (select Forma_Pago from Dim_Forma_Pago) insert into Dim_Forma_Pago values ('No Definido - 0','No Definido') end --ProcesoETL versión Descripción: Carga dimensión producto por categoría --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: septiembre Última modificación: n/a USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as begin insert into Dim_ProductoXCategoria select distinct despro +'-'+codpro, case SUBSTRING(codpro,1,2) 86

110 when 10 then 'De Hombre' when 20 then 'De Mujer' when 30 then 'Botas' when 40 then 'Bolichero' when 50 then 'De Niño' else 'Accesorio' end from Sic.dbo.producto where despro +'-'+codpro not in (select Producto from Dim_ProductoXCategoria) insert into Dim_ProductoXCategoria select distinct despro +'-'+codpro, case SUBSTRING(codpro,1,2) when 10 then 'De Hombre' when 20 then 'De Mujer' when 30 then 'Botas' when 40 then 'Bolichero' when 50 then 'De Niño' else 'Accesorio' end from Sic2.dbo.producto where despro +'-'+codpro not in (select Producto from Dim_ProductoXCategoria) end --ProcesoETL versión Descripción: Carga dimensión producto por precio --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: septiembre Última modificación: octubre 2012 USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as begin insert into Dim_ProductoXPrecio select distinct despro +'-'+codpro, preven, case when preven < 40 then 'Precio Bajo' when preven between 40 and then 'Precio Medio' when preven between 80 and then 'Precio Alto' else 'Precio Muy Alto' end from Sic.dbo.producto where despro +'-'+codpro not in (select Producto from Dim_ProductoXPrecio) insert into Dim_ProductoXPrecio 87

111 select distinct despro +'-'+codpro, preven, case when preven < 40 then 'Precio Bajo' when preven between 40 and then 'Precio Medio' when preven between 80 and then 'Precio Alto' else 'Precio Muy Alto' end from Sic2.dbo.producto where despro +'-'+codpro not in (select Producto from Dim_ProductoXPrecio) end --ProcesoETL versión Descripción: Carga dimensión tiempo --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: septiembre Última modificación: octubre 2012 USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as begin insert into Dim_Tiempo select distinct convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)), DATENAME(mm, fecfac) + '-'+convert(char(4),year(fecfac)), DATENAME(qq, fecfac) + ' Trimes.-'+convert(char(4),year(fecfac)), case when MONTH(fecfac)<=6 then '1er.Semestre- '+convert(char(4),year(fecfac)) else '2do.Semestre-'+convert(char(4),year(fecfac)) end, year(fecfac) from sic.dbo.factura where convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)) not in (select fecha_hora from Dim_Tiempo) order by 1 insert into Dim_Tiempo select distinct convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)), DATENAME(mm, fecfac) + '-'+convert(char(4),year(fecfac)), DATENAME(qq, fecfac) + ' Trimes.-'+convert(char(4),year(fecfac)), case when MONTH(fecfac)<=6 then '1er.Semestre- '+convert(char(4),year(fecfac)) 88

112 else '2do.Semestre-'+convert(char(4),year(fecfac)) end, year(fecfac) from sic2.dbo.factura where convert(char(10),fecfac)+' '+convert(char(2),datepart(hh,hora))+ ':' +convert(char(2),datepart(mi,hora)) not in (select fecha_hora from Dim_Tiempo) order by 1 end --ProcesoETL versión Descripción: Función que categoriza al vendedor --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: noviembre Última modificación: n/a USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER function [dbo].[categoriza_vendedor] (@codven varchar(5)) returns varchar(50) begin return (select case when count(*) >= 1000 then 'Senior (>=1000 vts)' else 'Junior (<1000 vts)' end from tmp_factura where convert(varchar(5),codven) group by codven) end --ProcesoETL versión Descripción: Carga dimension vendedor --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: noviembre Última modificación: n/a USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as Begin = 0 begin delete from Fact delete from Dim_Vendedor insert into dim_vendedor select distinct 89

113 nomven +' - '+convert(varchar(10),codven), dbo.categoriza_vendedor(codven) from Sic.dbo.Vendedor where codven in (select codven from tmp_factura) and codven in (select codven from Sic.dbo.Factura) insert into dim_vendedor select distinct nomven +' - '+convert(varchar(10),codven), dbo.categoriza_vendedor(codven) from Sic2.dbo.Vendedor where codven in (select codven from tmp_factura) and codven in (select codven from Sic2.dbo.Factura) insert into Dim_Vendedor select distinct vendedor,'no_definido' from tmp_factura where SUBSTRING(vendedor,1,3)='No_' end 1 begin insert into dim_vendedor select distinct nomven +' - '+convert(varchar(10),codven), dbo.categoriza_vendedor(codven) from Sic.dbo.Vendedor where nomven +' - '+convert(varchar(10),codven) not in (select vendedor from Dim_vendedor) and codven in (select codven from tmp_factura) and codven in (select codven from Sic.dbo.Factura) insert into dim_vendedor select distinct nomven +' - '+convert(varchar(10),codven), dbo.categoriza_vendedor(codven) from Sic2.dbo.Vendedor where nomven +' - '+convert(varchar(10),codven) not in (select vendedor from Dim_vendedor) and codven in (select codven from tmp_factura) and codven in (select codven from Sic2.dbo.Factura) end End --ProcesoETL versión Descripción: Carga copia factura (tmp_factura) --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: octubre Última modificación: noviembre 2012 USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int 90

114 as begin drop table tmp_factura select f.numfac, f.codcli, c.nomcli +' - '+c.codcli Cliente, f.codloc, f.codven, isnull(v.nomven +' - '+convert(varchar(10),v.codven),'no_defin.- '+convert(varchar(10),f.codven)) Vendedor, isnull(g.forpag,0) forpag, isnull(g2.despag +' - '+ g.forpag,'no Definido - 0') FormaPago, f.fecfac, f.hora, convert(char(10),f.fecfac)+' '+convert(char(2),datepart(hh,f.hora))+ ':' +convert(char(2),datepart(mi,f.hora)) FechaHora, f.subtotal, f.pordes, f.totciva, f.iva, f.total, p.codpro, p.despro, isnull(p.despro +'-'+p.codpro,'no_defin.-'+k.codpro) Producto, p.preven, p.cospro, k.numdoc, k.fecha, k.tipdoc, k.descrip, k.coddep into tmp_factura from sic.dbo.factura f left join Sic.dbo.Kardex k on f.numfac = k.numdoc left join Sic.dbo.Producto p on k.codpro = p.codpro left join Sic.dbo.Cliente c on f.codcli=c.codcli left join Sic.dbo.Vendedor v on f.codven=convert(char(10),v.codven) left join Sic.dbo.FacturaPago g on f.numfac = g.numdoc left join Sic.dbo.Forma_Pago g2 on g.forpag = g2.forpag where k.tipdoc = 'fac' union select f.numfac, f.codcli, c.nomcli +' - '+c.codcli Cliente, f.codloc, f.codven, 91

115 isnull(v.nomven +' - '+convert(varchar(10),v.codven),'no_defin.- '+convert(varchar(10),f.codven)) Vendedor, isnull(g.forpag,0) forpag, isnull(g2.despag +' - '+ g.forpag,'no Definido - 0') FormaPago, f.fecfac, f.hora, convert(char(10),f.fecfac)+' '+convert(char(2),datepart(hh,f.hora))+ ':' +convert(char(2),datepart(mi,f.hora)) FechaHora, f.subtotal, f.pordes, f.totciva, f.iva, f.total, p.codpro, p.despro, isnull(p.despro +'-'+p.codpro,'no_defin.-'+k.codpro) Producto, p.preven, p.cospro, k.numdoc, k.fecha, k.tipdoc, k.descrip, k.coddep from sic2.dbo.factura f left join Sic2.dbo.Kardex k on f.numfac = k.numdoc left join Sic2.dbo.Producto p on k.codpro = p.codpro left join Sic2.dbo.Cliente c on f.codcli=c.codcli left join Sic2.dbo.Vendedor v on f.codven=convert(char(10),v.codven) left join Sic2.dbo.FacturaPago g on f.numfac = g.numdoc left join Sic2.dbo.Forma_Pago g2 on g.forpag = g2.forpag where k.tipdoc = 'fac' end create index ix_cli on tmp_factura (codcli) create index ix_ven on tmp_factura (codven) --ProcesoETL versión Descripción: Carga fact --Lenguaje: SQL --Desarrollado por: Juan Pablo Castañeda --Creado: noviembre Última modificación: n/a USE [SIC_OLAP] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure int as Begin truncate table Fact 92

116 End insert into Fact select sum(convert(float,totciva)) Monto_ventas, sum(convert(float,iva)) [Monto_IVA], sum(convert(float,totciva) * 0.3) [Monto_Utilidad], sum(convert(float,totciva) * 0.05) [Monto_Comisiones], count(distinct numfac) [Numero_Ventas], sum(1) [Cantidad_Productos], max(convert(float,totciva)) [Mayor_Venta], f.fechahora Tiempo, f.fechahora Epoca, case codloc when 1 then 'CCI' else 'El Condado' end Lugar, null Vendedor, f.producto ProductoPrecio, f.producto ProductoCategoria, f.cliente Cliente, null FormaPago from tmp_factura f group by f.cliente, f.fechahora, f.codloc, f.producto Nota: la carga de la dimension lugar (Dim_Lugar) no consta en este anexo debido a que la carga se la realizó manualmente, esto por ser una dimension que consta solo de dos valores: CCI y Condado. 93

117 ANEXO IV EXPLICACIÓN A LA FIGURA 31

118 ANEXO IV EXPLICACIÓN A LA FIGURA 31 Figura 31 Resultados del modelo clasificar Como se mencionó en el capítulo IV, esta imagen muestra los resultados del modelo de datos clasificar que utiliza el algoritmo de árboles de decisión de Microsoft. Con el cual se realizó el ejemplo: analizar el lugar (CCI o Condado), considerando el número de ventas y el tiempo (fechas). Los resultados se interpretan de la siguiente manera: Como se observa en la esquina superior derecha de la imagen, se asigna el color celeste al CCI y el color rosa al Condado. Además detalla la siguiente información: Tabla 9 Resultados del modelo clasificar Lugar Escenarios Probabilidad (%) CCI El Condado El modelo indica que la probabilidad de venta en el CCI es más alta con relación al Condado, esto por lógica es correcto, ya que este fue el primer local de la pyme, por lo tanto se tiene muchos más registros de ventas. 94

119 El nodo 1 muestra que en total existen escenarios de los cuales pertenecen al CCI y 6708 al Condado, es decir, proporciona la misma información que posee la tabla IV.1. Adicionalmente de este nodo nacen los nodos 2, 3, 4 y 5. El nodo 2 señala como intervalo de tiempo las fechas mayores al 8 de febrero del 2012, e indica 480 escenarios que pertenecen únicamente al Condado. Con esta información se interpreta que en los meses de febrero de años venideros se podría considerar algunas promociones de mercadería en este local para que las ventas mejoren aún más. El nodo 3 marca como intervalo de tiempo las fechas comprendidas entre el 22 de abril del 2010 y el 17 de marzo del 2011, e indica un total de 5083 escenarios totales, los cuales se dividen en 3076 para el Condado y 2007 para el CCI. Con esta información se interpreta que en este intervalo de tiempo en años venideros el número de ventas debe ser parecido en los 2 locales. El nodo 4 advierte como intervalo de tiempo las fechas comprendidas entre el 16 de marzo del 2011 y el 8 de febrero del 2012, e indica un total de 3387 escenarios totales, los cuales se dividen en 3148 para el Condado y 739 para el CCI. Con esta información se confirma lo interpretado en el nodo 2. El nodo 5 indica como intervalo de tiempo las fechas menores al 22 de abril del 2010, e indica escenarios totales, los cuales pertenecen al CCI y 4 para el Condado. Demostrando que el local ubicado en CCI también tiene una alta transaccionalidad en ventas, lo cual no se evidenciaba en los nodos revisados anteriormente. El nodo 3 se divide en los nodos 6 y 7. El nodo 6 señala como intervalo de tiempo las fechas mayores al 24 de mayo del 2012, e indica un total de 4846 escenarios totales, los cuales 3076 pertenecen al Condado y 1770 al CCI. A diferencia del nodo 3, este nuevo nodo indica que para finales de mayo de años venideros las ventas en el local del Condado deben ser superiores. 95

120 El nodo 7 marca como intervalo de tiempo las fechas menores al 24 de mayo del 2012, e indica un total de 237 escenarios que pertenecen únicamente al CCI. Con esta información se interpreta que si bien las ventas van a ser superiores en el CCI en este intervalo de tiempo, no va a ser un volumen de ventas considerable. El nodo 4 se divide en los nodos 8 y 9. El nodo 8 advierte como intervalo de tiempo las fechas menores al 25 de julio del 2011, e indica un total de 1977 escenarios, los cuales 1239 pertenecen al Condado y 738 al CCI. Con esta información se interpreta que en este intervalo de tiempo en años venideros el Condado va a tener más transaccionalidad de ventas que el CCI. El nodo 9 señala como intervalo de tiempo las fechas mayores al 26 de julio del 2011, e indica un total de 1909 escenarios que pertenecen únicamente al Condado. Con esta información se interpreta que en este intervalo de tiempo en años venideros las ventas en el condado deben ser mucho mejores a las del CCI. 96

121 ANEXO V MANUAL DE USUARIO

122 ANEXO V MANUAL DE USUARIO Este manual pretende facilitar el uso de la solución Business Intelligence mediante Excel 2010, esto con el fin de que los usuarios tengan una guía detallada para manipular la solución. Los pasos a considerar son: 1. En el menú DATOS de Excel, clic en Conexiones existentes y abrir Sic Cubo Ventas, como se observa en la figura 36. Figura 36 Conexiones existentes de datos Cabe señalar que la conexión al cubo de datos desde Excel ya fue creada anteriormente como se mostró en el Capítulo 4 sección 4.3. En este caso lo único que se hace es retomar esa conexión. 97

123 2. Ya abierta la conexión, Excel automáticamente preguntará cómo se desea importar los datos, como se aprecia en la figura 37, a lo cual se debe seleccionar informe de tabla dinámica o informe de gráfico y tabla dinámicos según lo que se requiera y clic en aceptar. Figura 37 Opciones de importación de datos 3. Hecho esto, Excel genera automáticamente los recursos estadísticos que se seleccionó, como se ve en la figura 38, además de importar todas las medidas y dimensiones contenidas en el cubo de datos para ser presentados en la tabla y gráfico dinámicos de acuerdo a los requerimientos del usuario, como se observa en la figura 39. Figura 38 Recursos estadísticos generados 98

124 Figura 39 Medidas y dimensiones del cubo Como se puede apreciar en la figura 39, la lista de campos de tabla dinámica es un reflejo de toda la información contenida en el cubo de datos. Esta información es la que el usuario manipula a su gusto, ya que solo debe marcar las medidas (monto IVA, mayor venta, etc.), los atributos de las dimensiones (cliente: clase nombre, lugar: sucursal, etc.) y la información se verá reflejada de forma automática en la tabla y gráfico dinámicos. Pudiendo también seleccionar los campos de eje (filas) y campos de leyenda (columnas) con solo arrastrar los atributos al lugar deseado. 99

125 En la figura 40 se pude mirar el resultado de la figura 39 en la tabla y grafico respectivos, en los que se consideró el número de ventas de acuerdo a la clase de cliente (poco frecuente, frecuente, muy frecuente). Figura 40 Número de ventas por clase de cliente Como un segundo ejemplo, se considera el número de ventas por clase de cliente y por sucursal. Para esto hay que dirigirse a la lista de campos de tabla dinámica y desplegar la dimensión lugar para también marcar la opción sucursal. El resultado se observa en la figura

126 Figura 41 Número de ventas por clase de cliente y por sucursal Adicionalmente, para obtener la tabla y gráfico como el de la figura 40, se debe arrastrar el atributo Sucursal de campos de eje (fila) a campos de leyenda (columna). Realizados todos los pasos y ejemplos detallados en este manual, el usuario debería sentirse familiarizado con el uso de la solución Business Intelligence, tomando en cuenta que la interfaz de usuario (Excel) es bastante amigable, intuitiva y conocida por la mayoría de personas hoy en día. 101