UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación DESARROLLAR PROTOTIPO DE INTELIGENCIA DE NEGOCIO CON INDICADORES DE DESEMPEÑO EN EL ÁREA DE VENTAS Por: Fabián Alberto Correa Matute INFORME FINAL DE CURSOS EN COOPERACIÓN Presentado ante la Ilustre Universidad Simón Bolívar como Requisito Parcial para Optar al título de Ingeniero en Computación Sartenejas, Marzo de 2007 ii DESARROLLAR PROTOTIPO DE INTELIGENCIA DE NEGOCIO CON INDICADORES DE DESEMPEÑO EN EL ÁREA DE VENTAS Por Fabián Alberto Correa Matute RESUMEN El objetivo del presente trabajo es registrar los resultados obtenidos durante el proceso de desarrollo del prototipo funcional de inteligencia de negocios (BI) con indicadores claves de desempeño en el área de ventas. El prototipo fue dirigido específicamente a los clientes con base instalada del ERP JD Edwards en su versión 8.11, quienes carecen de un aplicativo de inteligencia de negocios dentro del ERP. El aplicativo consistió en la construcción de un Data Warehouse con una estructura de almacenamiento adecuada con la finalidad de almacenar los datos históricos del área de ventas del ERP, para la realización de ad-hoc queries y creación de reportes para su futuro análisis. La metodología empleada para la construcción del aplicativo fue Rational Unified Process. Se prestó especial atención a las fases de inicio y elaboración para la creación de artefactos, dado que uno de los objetivos del proyecto de pasantía fue establecer lineamientos para la construcción de un aplicativo de BI. La intención fue facilitarle al Partner BFGP una guía de elaboración con la cual pudiesen ofrecerles a sus clientes de base instalada 8.11 un aplicativo de BI con las herramientas que contiene el paquete de JD Edwards. Un resultado preliminar fue utilizado para un evento del producto JD Edwards pudiendo presentarles a algunos clientes la solución presentada en el trabajo. Luego de la exposición se elaboraron más funcionalidades con la intención de instruir a un consultor de BFGP. iii ÍNDICE GENERAL 1.0 INTRODUCCIÓN .............................................................................................................................1 1.1 Situación actual ..............................................................................................................................2 1.2 Objetivo..........................................................................................................................................2 1.3 Estructuración del documento........................................................................................................3 2.0 ENTORNO EMPRESARIAL ............................................................................................................4 2.1 Oracle Corporation.........................................................................................................................5 2.2 Principios de la empresa.................................................................................................................5 2.3 Oracle de Venezuela.......................................................................................................................6 2.3.1 3.0 Estructura organizacional.....................................................................................................6 MARCO TEÓRICO...........................................................................................................................7 3.1 ¿Qué es inteligencia de negocio? ...................................................................................................8 3.1.1 Datos, Información y Conocimiento ....................................................................................8 3.1.2 Objetivo e importancia de Bussiness Intelligence (BI) ........................................................9 3.1.3 Indicadores Claves de Desempeño – Key Performance Indicators (KPI)..........................10 3.2 El proceso de inteligencia de negocio ..........................................................................................10 3.2.1 Consolidación y Estructuración de los Datos.....................................................................11 3.2.1.1 Fuentes de Datos. Online Transaction Processing (OLTP) ...........................................11 3.2.1.2 Estructura OLTP, Normalización y Tercera Forma Normal..........................................11 3.2.1.3 Construcción de un Data Warehouse.............................................................................13 3.2.1.4 Data Mart .......................................................................................................................18 3.2.1.5 Sistemas Analíticos – Online Analytical Processing (OLAP) .......................................19 3.2.1.6 Proceso de Extracción, Transformación y carga – ETL ................................................20 3.2.2 Análisis de los Datos, Creación y Publicación de Reportes...............................................21 3.2.2.1 Análisis de los datos y creación de reportes ..................................................................21 3.2.2.2 Publicación e interacción con reportes ..........................................................................21 iv 3.3 Herramientas utilizadas y breve descripción................................................................................22 3.3.1 Consolidación y Estructuración de los Datos.....................................................................22 3.3.2 Análisis de los datos creación de reportes..........................................................................22 3.3.3 Publicación e interacción con reportes...............................................................................22 4.0 PLANTEAMIENTO DEL PROBLEMA.........................................................................................23 4.1 Problema ......................................................................................................................................24 4.2 Objetivo........................................................................................................................................24 4.3 Objetivos específicos....................................................................................................................24 5.0 MARCO METODOLÓGICO ..........................................................................................................25 5.1 Rational Unified Process (RUP) ..................................................................................................26 5.1.1 6.0 Fases...................................................................................................................................26 5.1.1.1 Inicio ..............................................................................................................................27 5.1.1.2 Elaboración ....................................................................................................................28 5.1.1.3 Construcción ..................................................................................................................28 5.1.1.4 Transición ......................................................................................................................29 IMPLEMENTACIÓN......................................................................................................................30 6.1 Fase de inicio................................................................................................................................31 6.1.1 Alcance...............................................................................................................................31 6.1.2 Plan inicial..........................................................................................................................31 6.1.3 Arquitectura del sistema.....................................................................................................33 6.1.3.1 Nivel Gerencia ...............................................................................................................34 6.1.3.2 Nivel Análisis ................................................................................................................34 6.1.3.3 Nivel Bodega .................................................................................................................34 6.1.4 6.2 6.2.1 Requerimientos funcionales ...............................................................................................36 Fase de elaboración ......................................................................................................................38 Análisis y formulación de las métricas ..............................................................................38 v 6.2.1.1 Cálculo de métricas........................................................................................................38 6.2.2 Fuente de datos del ERP JD Edwards ................................................................................39 6.2.3 Diseño ETL primera etapa (Tablas Externas a Staging Area) ...........................................39 6.2.3.1 Tablas externas a Staging Area......................................................................................40 6.2.4 Diseño ETL segunda etapa (Creación de dimensiones).....................................................41 6.2.5 Diseño ETL tercera etapa (Data Marts) .............................................................................41 6.3 Fase de Construcción ...................................................................................................................42 6.3.1 6.3.1.1 Configuración del ambiente de trabajo..........................................................................42 6.3.1.2 Trabajando con los archivos planos. Datos transaccionales. .........................................43 6.3.1.3 Segunda Etapa ETL (Creación de Dimensiones)...........................................................50 6.3.1.4 Tercera Etapa ETL (Creación de data marts) ................................................................52 6.3.1.5 Creación de áreas de negocio.........................................................................................53 6.3.1.6 Creación de reportes. Discoverer Plus ...........................................................................54 6.4 7.0 Iteración #1 ........................................................................................................................42 Fase de Transición........................................................................................................................58 CONCLUSIONES Y RECOMENDACIONES ...............................................................................60 7.1 Conclusiones ................................................................................................................................61 7.2 Recomendaciones.........................................................................................................................61 7.2.1 Recomendaciones generales...............................................................................................61 7.2.2 Extensión de funcionalidades.............................................................................................62 8.0 BIBLIOGRAFÍA..............................................................................................................................63 9.0 APÉNDICE A EJEMPLOS FASE DE CONSTRUCCIÓN ............................................................66 9.1 Ejemplo de Tabla .........................................................................................................................66 9.2 Ejemplo de dimension..................................................................................................................67 9.3 Ejemplo de cubo...........................................................................................................................67 9.4 Ejemplo de correspondencias.......................................................................................................68 vi 9.5 10.0 Ejemplo de flujos de proceso .......................................................................................................69 APÉNDICE B ARTEFACTOS DE RUP.........................................................................................70 10.1 Documento de arquitectura ..........................................................................................................70 10.2 Diagrama de desarrollo ................................................................................................................70 10.3 Apéndice c matriz de requerimientos...........................................................................................71 11.0 APENdice C Visualización de Reportes ..........................................................................................72 11.1 R01 ...............................................................................................................................................72 11.2 R04 ...............................................................................................................................................73 11.3 R08 ...............................................................................................................................................74 11.4 R10 ...............................................................................................................................................75 vii ÍNDICE DE TABLAS Tabla 1 OLTP VS Sistema Analítico ...........................................................................................................12 Tabla 2 DM Dependiente vs DM Independiente..........................................................................................18 Tabla 3 Data Warehouse vs Data Mart ........................................................................................................19 Tabla 4 OLTP DB VS OLAP DB ................................................................................................................19 Tabla 5 Plan inicial alto nivel.......................................................................................................................32 Tabla 6 Requerimientos funcionales ............................................................................................................37 Tabla 7 Definición de métricas ....................................................................................................................38 Tabla 8 Tablas JD Edwards..........................................................................................................................39 Tabla 9 Matriz de requerimientos ................................................................................................................71 viii ÍNDICE DE FIGURAS Figura 1 Pirámide de datos, información y conocimiento..............................................................................9 Figura 2 Modelo estrella ..............................................................................................................................18 Figura 3 Ciclo de vida de RUP.....................................................................................................................27 Figura 4 Arquitectura del sistema ................................................................................................................33 Figura 5 Diagrama de desarrollo..................................................................................................................35 Figura 6 Modelo conceptual.........................................................................................................................37 Figura 7 Diseño ETL primera etapa.............................................................................................................40 Figura 8 Diseño ETL segunda etapa ............................................................................................................41 Figura 9 Diseño ETL tercera etapa ..............................................................................................................42 Figura 10 Oracle Warehouse builder ...........................................................................................................43 Figura 11 Usuarios de OWB ........................................................................................................................45 Figura 12 Objetos de bases de datos OWB ..................................................................................................45 Figura 13 Centro de control OWB ...............................................................................................................46 Figura 14 Editor de Objetos OWB...............................................................................................................47 Figura 15 Modelo estrella del DW...............................................................................................................48 Figura 16 Correspondencia del Fact de Ventas............................................................................................49 Figura 17 Flujo de proceso...........................................................................................................................50 Figura 18 Correspondencia de dimensión....................................................................................................51 Figura 19 Cubo de 5 dimensiones ................................................................................................................52 Figura 20 Correpondencia del cubo .............................................................................................................53 Figura 21 Área de negocio ...........................................................................................................................54 Figura 22 Discoverer....................................................................................................................................55 Figura 23 Indicador de discoverer plus ........................................................................................................56 Figura 24 Gráfico de discoverer plus ...........................................................................................................57 ix Figura 25 Discoverer viewer ........................................................................................................................58 Figura 26 Discoverer viewer worksheet solo tabla ......................................................................................59 Figura 27 Discoverer viewer worksheet tabla y gráfico...............................................................................59 Figura 28 Tabla Compañía...........................................................................................................................66 Figura 29 Fact de Ventas..............................................................................................................................66 Figura 30 Dimensión de Tiempo..................................................................................................................67 Figura 31 Cubo órdenes en demora..............................................................................................................67 Figura 32 Correspondencia de tabla producto..............................................................................................68 Figura 33 Correspondencia de Cubo de órdenes en demora ........................................................................68 Figura 34 Flujo de proceso Staging Area – Data Warehouse ......................................................................69 Figura 35 Documento de arquitectura..........................................................................................................70 Figura 36 Diagrama de desarrollo...............................................................................................................70 Figura 37 R01 Margen de ganancias por compañía y por un período dado.................................................72 Figura 38 R04 Tipo de cliente que le generó más ganancias a un almacén por compañía y por año ..........73 Figura 39 R08 Órdenes en demora y a tiempo por compañía, almacén en un período dado .......................74 Figura 40 R10 Total de órdenes en demora vs a tiempo ..............................................................................75 x LISTA DE SÍMBOLOS Y ABREVIACIONES BI – Business Intelligence (Inteligencia de Negocio) KPI – Key Performance Indicators (Indicadores claves de desempeño) OLTP – Online Transaction Processing (Procesamiento de transacciones en línea) SW – Software HW – Hardware DS – Data Source (Fuente de Datos) DW – Data Warehouse (Bodega de Datos) DM – Data Mart DB – Data Base (Base de Datos) 3NF – Third Normal Form (Tercera Forma Normal) OLAP – Online Analytical Processing (Procesamiento analítico en línea) LOB – Line of Business (Línea de negocio) ERP – Enterprise Resource Planning (Planificación de recursos empresariales) CRM – Customer Relationship Management (Gerencia de relaciones con clientes) SCM – Supply Chain Management (Gerencia de cadena de suministro) EUL – End User Layer (Capa de usuario final) RUP – Racional Unified Process (Proceso Unificado de Rational) OWB – Oracle Warehouse Builder xi 1.0 INTRODUCCIÓN Este capítulo tiene la finalidad de presentar la situación actual, el objetivo general del proyecto y la estructuración del documento. 1 2 1.1 Situación actual La inteligencia de negocios (BI) se ha convertido en la actualidad en un diferenciador de mercado para las empresas comerciales. Su asistencia en el proceso de toma de decisiones lo ha convertido en una necesidad para cualquier departamento que desee maximizar su desempeño. Actualmente existe una cartera de clientes considerable que poseen el ERP JD Edwards en su versión 8.11 como sistema principal de control de sus actividades comerciales. Esta versión no incluye los indicadores de negocio necesarios para el proceso de toma de decisiones. Oracle como empresa tecnológica tiene la responsabilidad de abastecer a sus clientes las nuevas tendencias tecnológicas que estén en el mercado. A su vez todas las empresas asociadas a Oracle que ofrezcan soluciones a partir de sus productos, están en la obligación de buscar soluciones tecnológicas (aplicaciones especializadas a las necesidades del cliente, adaptación de sistemas existentes, etc.) e implementarlas para cubrir esa carencia de tecnología. A estos clientes que poseen la versión 8.11 se les presentaron varias opciones, como la de migrar a la versión 8.12 del ERP o adquirir una herramienta analítica como Siebel. El problema de ambos ofrecimientos está relacionado con costos. A raíz de la adquisición de JD Edwards, Oracle ha ofrecido en su nuevo paquete de la aplicación (versión 8.11), herramientas para la construcción de aplicativos de BI con la finalidad de brindarles a sus clientes de base instalada la oportunidad de aplicar BI. 1.2 Objetivo El objetivo del presente trabajo es registrar los resultados obtenidos durante el proceso de desarrollo del prototipo funcional de inteligencia de negocios (BI) con indicadores claves de desempeño en el área de ventas. 3 Otro objetivo importante fue el de fijar lineamientos para la elaboración de un aplicativo de inteligencia de negocios que sirviera de guía para el Partner BFGP, para poder ofrecer trabajos de consultoría a partir de la necesidad planteada por los clientes de base instalada 8.11. 1.3 Estructuración del documento El trabajo se encuentra estructurado de la siguiente manera: El capítulo 2 presenta una breve descripción de la empresa en donde se realizó el proyecto de pasantía. El capítulo 3 explica la Inteligencia de negocios mediante la exposición de un marco teórico. El capítulo 4 presenta el planteamiento del problema. El capítulo 5 describe la metodología empleada para la construcción del aplicativo. El capítulo 6 presenta la implementación del aplicativo en base a las fases que constituyen la metodología empleada. El capítulo 7 presenta las conclusiones y recomendaciones del trabajo. El capítulo 8 presenta las referencias bibliográficas y finalmente presentaremos la sección de apéndices. 2.0 ENTORNO EMPRESARIAL En este capítulo se presenta una breve descripción de la empresa en donde se llevó a cabo el presente trabajo de pasantía, sus principios y la estructura organizacional de la subsidiaria en Venezuela. 4 5 2.1 Oracle Corporation Oracle es una de las compañías más grandes de Software, fundada en 1977 con una presencia en más de 145 países alrededor del mundo, empleando alrededor de 50.000 empleados en todo el mundo. Su desarrollo abarca productos como su manejador de base de datos, herramientas para el desarrollo en bases de datos, programas de capas intermedias (Servidor de aplicación, Directorios, etc.), aplicaciones como ERP, CRM, SCM, entre otras [16]. 2.2 Principios de la empresa Oracle aplicando estos tres principios ha ahorrado más de US$ 1.000 millones en costos operativos. Con estos principios, que están incorporados en el diseño de su software, han coordinado y perfeccionado sus procesos comerciales en todo el mundo [15]. Estos principios son [15]: • Simplificar: Acelerar la entrega de la información con sistemas integrados y una única base de datos. • Estandarizar: Reducir los costos y ciclos de mantenimiento con componentes abiertos y de fácil disponibilidad. • Automatizar: Mejorar la eficiencia operativa con tecnología y mejores prácticas. Consideran que sus clientes obtienen más de su información utilizando el software y los servicios de Oracle, y aplicando estos principios. Muchos ya han mejorado su capacidad para utilizar información de IT como activos estratégicos, y ahora están preparados para compartir datos y procesos, medir resultados de las mejoras continuas, alinear interesados y comunicar una sola verdad a todos los que formen parte de estas empresas [15]. 6 2.3 Oracle de Venezuela Tiene presencia en Venezuela desde 1989, empleado alrededor de 80 personas y prestando servicios en las áreas de ventas, soporte, consultoría y educación. 2.3.1 Estructura organizacional Oracle de Venezuela está constituida por 12 departamentos, los cuales son: Administración, Alianzas, Consultoría, Educación, Facilities, Finanzas, Global IT, Mercadeo, Oracle Direct, Preventas, Recursos Humanos, Soporte Técnico y Ventas. El equipo de Oracle Direct es el encargado de realizar el proceso de ventas indirectas o ventas por teléfono, la cual se apoya en la participación de Partners o socios de la compañía para la prestación de servicios. En este departamento se realizó la pasantía, trabajando conjuntamente con un Partner para establecer los lineamientos necesarios para la elaboración de un aplicativo de inteligencia de negocios específicamente para los clientes que tuviesen el ERP JD Edwards en su versión 8.11. 3.0 MARCO TEÓRICO En este se presentan los conceptos relacionados al área de desarrollo del proyecto. 7 8 3.1 ¿Qué es inteligencia de negocio? Es el proceso de recolección y análisis de gran cantidad de datos disponibles en el negocio para obtener información de gran utilidad que pueda asistir al proceso de toma de decisiones [1, 2, 3]. Pero, ¿qué significa recolectar y analizar en términos comerciales?: Consiste en observar tendencias, comportamientos, tener claros los objetivos y metas que se deben establecer para lograr un mejor desempeño y poder hacer predicciones que permitan determinar las acciones a ejecutar, con la intención de adaptarse a los posibles cambios del futuro. En conclusión, podríamos considerar al proceso de inteligencia de negocio como la transformación de datos en información y luego la utilización de esta información para la toma de decisiones inteligentes. La ejecución reiterada de este proceso generará el conocimiento necesario para la gerencia inteligente del negocio. 3.1.1 Datos, Información y Conocimiento Es importante entender los conceptos básicos mencionados porque la transición entre ellos define el proceso de inteligencia de negocios. Un dato es un hecho o hechos, valores o conjunto de valores, que por si solos no le dan un significado al negocio o a si mismos [4,5] . La Información, son los datos procesados e interpretados; es un conjunto de datos en contexto y con significado [4,5]. Finalmente, el conocimiento podemos definirlo como el conjunto de decisiones inteligentes generadas a partir de la utilización de información en el proceso de toma de decisiones. Cada transición ocurrida entre los conceptos requiere de un trabajo sustancial, el cual debe ser preciso, eficiente y confiable ya que la toma de decisiones depende del resultado de este proceso (Figura 1). 9 Figura 1 Pirámide de datos, información y conocimiento 3.1.2 Objetivo e importancia de Bussiness Intelligence (BI) El objetivo principal de BI es ayudar a los ejecutivos de negocio a tomar decisiones inteligentes basadas en reportes analíticos del comportamiento del mercado, del negocio y de los clientes generados a partir de la información acumulada por las actividades diarias de la empresa. BI nos permite hacer predicciones acerca de las nuevas tendencias de los sectores comerciales y de los clientes, permitiendo adaptarse mas rápido a los cambios [3]. Considerando el desempeño de la empresa encontramos que éste promueve la comunicación entre departamentos; mejora la coordinación de las actividades [3] , ya que permite el acercamiento entre ejecutivos y empleados en base a decisiones orientadas a la adaptación que sugieren los cambios observados en los análisis del negocio. Si tomamos en cuenta el aspecto competitivo, las empresas necesitan tener información actualizada y precisa acerca del comportamiento del cliente de manera de poder adaptarse y atender a las necesidades de la demanda [3]. 10 3.1.3 Indicadores Claves de Desempeño – Key Performance Indicators (KPI) La pregunta inicial que nos formulamos ante esta definición de BI es ¿Cómo podemos calificar o medir este tipo de actividades? En los negocios, actualmente, existe un monitoreo de actividades mediante el uso de KPI, los cuales se traducen en métricas financieras o no financieras cuya finalidad es cuantificar objetivos para reflejar el desempeño estratégico de una empresa. Son generalmente utilizados para darle valor a actividades difíciles de valorizar tales como servicios, satisfacción, compromiso, entre otras. Estos indicadores difieren dependiendo de la naturaleza de la organización y su estrategia [11]. Para identificar un indicador debemos tomar en cuanta lo siguiente [11]: • Tener definidos procesos de negocio para poder medir su desempeño • Tener definidas las metas y requerimientos de desempeño para los procesos de negocio • Tener medidas cualitativas y cuantitativas para los resultados y comparación con los objetivos • Investigar los diferentes procesos de optimización para mejorar el desempeño de actividades Es importante tener datos consistentes y correctos al construir los KPI. Estos indicadores deben crearse y estar disponibles para las organizaciones en el menor tiempo posible ya que a partir de esta información es que se toman decisiones del negocio [11]. 3.2 El proceso de inteligencia de negocio Para entender el concepto de BI, debemos definir las fases y conceptos involucrados en el proceso de construcción de un aplicativo. Podríamos sintetizar el proceso de BI en 3 fases: Consolidación y Estructuración de los Datos, Análisis de los Datos, Creación y Publicación de Reportes. 11 3.2.1 Consolidación y Estructuración de los Datos Para poder tener conocimiento acerca de tendencias, comportamientos y desempeño, debemos tener varias fuentes de datos (Data Source), que nos provean con las características de las transacciones que diariamente se llevan a cabo. Cuando hablamos de transacciones nos referimos a las operaciones que describen las actividades realizadas y que a su vez definen los departamentos de una empresa. 3.2.1.1 Fuentes de Datos. Online Transaction Processing (OLTP) En la actualidad las empresas necesitan de tecnología para llevar a cabo sus actividades. Una tecnología común es la utilización de sistemas transaccionales o sistemas de procesamiento de transacciones en línea (OLTP) los cuales pueden definirse como aplicativos que facilitan el almacenamiento, obtención y administración de las operaciones (transacciones) diarias de la empresa [7]. Existen diversas fuentes de datos para el almacenamiento de las operaciones diarias de la empresa, por ej.: Sistemas Legacy, Aplicaciones, Servicios Web, entre otras. En el trabajo de pasantía solo se utilizó un sistema transaccional. La naturaleza de estas transacciones, requieren que nuestro sistema OLTP permita que las operaciones de inserción, actualización y eliminación de datos sea acelerado, es decir, debemos maximizar el desempeño de las operaciones DML (insert, delete y update) de la Base de Datos. 3.2.1.2 Estructura OLTP, Normalización y Tercera Forma Normal La estructura de los datos operacionales (datos de las transacciones) en sistemas OLTP, generalmente es muy compleja y rígida, ya que este tipo de sistemas fue diseñado para maximizar el desempeño de las operaciones en línea construye? [4] . Lo primero que nos preguntamos es: ¿cómo es ésta estructura y cómo se 12 Un sistema operacional maneja gran cantidad de transacciones lo cual genera una abundancia de datos, que necesita de gran estructuración y organización para no comprometer la eficiente realización de las operaciones básicas de inserción, eliminación y actualización de datos. Para esto, al construir una estructura de almacenamiento nos basamos en el concepto de normalización el cual se define como el diseño de estructuras de almacenamiento para la información digital [9] . Su objetivo principal es mejorar la calidad de los datos almacenados mediante la eliminación de la redundancia [8] . Este proceso tiene un puesto importante en el proceso de desarrollo ya que mejora el entendimiento de los datos a almacenar [9]. En la práctica, las aplicaciones cuyas unidades de datos son implementadas en la Tercera forma normal (3NF) son consideradas totalmente normalizadas. Esta forma normal plantea que todas las tablas de datos sólo deben depender de su clave primaria [9] . No profundizaremos en este concepto ya que el objetivo de estas definiciones es recalcar ¿porqué un sistema OLTP no es el sugerido para el proceso de BI? OLTP Sistema Analítico Información para el apoyo del servicio diario Información histórica para analizar Datos almacenados en un nivel transaccional Necesidad de integrar los datos Diseño de DB: Normalización Diseño de DB: No normalizado, Modelo Estrella Tabla 1 OLTP VS Sistema Analítico En la Tabla 1 podemos ver las características de un sistema OLTP en comparación con las necesarias para un sistema de análisis requerido por BI [4]. Como mencionamos anteriormente el volumen de datos generados en un sistema OLTP es abundante. Con el pasar del tiempo estos datos se convierten en históricos y de gran valor para las empresas, e incluso los necesarios para el análisis requerido en el proceso de toma de decisiones. 13 El apoyo a la toma de decisiones, proceso analítico complicado, es muy diferente a un sistema OLTP. La mayoría de las transacciones manejadas por estos sistemas requieren a lo sumo un registro en la base de datos para las operaciones de inserción, eliminación y actualización de datos. En cambio, las consultas analíticas requieren de la localización de múltiples registros y raramente son actualizadas [4]. Como observamos en la Tabla 1, el sistema OLTP requiere de estructuras normalizadas a diferencia de los sistemas analíticos los cuales manejan estructuras no normalizadas y/o dimensionales para optimizar las consultas analíticas necesarias para la recopilación de datos. 3.2.1.3 Construcción de un Data Warehouse Como un aplicativo de BI pretende optimizar las consultas relacionadas a la recopilación de datos y debe contener datos históricos necesarios para el análisis, debemos tener un aplicativo con una estructura de DB adecuada que nos permita atender este requerimiento. 3.2.1.3.1 Data Warehousing Consiste en el diseño e implementación de procesos y herramientas para manejar y entregar información completa, precisa, actualizada y de gran entendimiento para la toma de decisiones [1]. Maneja el desarrollo, implementación y operación de un Data Warehouse (Bodega de Datos) o Data Mart. Incluye el manejo de los metadatos, adquisición, depuración e integración de los datos, administración del almacenamiento, distribución de los datos, reportes analíticos, operacionales y muchas características necesarias para la administración de los datos de valor para la empresa conceptos involucrados en este proceso. [8] . A continuación precisaremos un poco más los 14 3.2.1.3.2 Data Warehouse (DW) Un DW es una forma de almacenamiento de datos para su recuperación futura [8]. Consiste en una base de datos centralizada (integra varios Data Stores), con datos generalmente históricos, diseñada para consultas de recopilación y análisis [8, 2] . Generalmente están orientadas a temas específicos (Ventas, Mercadeo, Finanzas, etc.) y se ven influenciadas en el tiempo [8]. 3.2.1.3.2.1 Tipos de DW A continuación los tipos de DW [4]: • Orientado a un tema: Los datos almacenados en un DW, son almacenados en base al área o a temas comunes (Ej.: Cliente, Producto, etc.) de manera de facilitar el acceso. Las consultas generadas a partir de las preguntas que generalmente hace una persona que toma decisiones, suelen ampliarse cada vez que son respondidas. • Variables con el tiempo: Los datos que contiene un DW pertenecen a diferentes períodos de tiempo, de esta manera los usuarios podrán responder preguntas tanto actuales como en el pasado. • Históricos: Los datos generalmente son de varios años pasados. Estos datos son importantes para el estudio de tendencias, la formulación predicciones, informes de desempeño en el tiempo, etc. • Recopilación de información y ayuda a la toma de decisiones: Utilizada para obtener información con la finalidad de responder preguntas. • Datos atómicos y resumidos: Dependiendo del propósito del DW, puede contener datos atómicos de manera de describir hechos hasta el nivel transaccional, o datos resumidos. 3.2.1.3.2.2 Propiedades de un DW A continuación las propiedades de un DW [4]: 15 • Orientado a un tema: Los datos en un DW son almacenados en base al área o a temas comunes (Ej.: Cliente, Producto, etc.) de manera de facilitar el acceso. Las consultas generadas a partir de las preguntas que generalmente hace una persona que toma decisiones suelen ampliarse cada vez que son respondidas. • Integrada: En la mayoría de las empresas, los datos están repartidos en diferentes sistemas, lo cual hace difícil para las empresas el poder recopilar información para el futuro análisis. En un DW los datos están almacenados de manera centralizada y comprensible. Este proceso de transformación e integración puede ser costoso y requiere de compromiso. Debe existir consistencia en los datos que son cargados en un DW, por lo cual se deben definir convenciones, medidas, estructuras claves para mantener la consistencia. • Variables con el tiempo: Los datos que contiene un DW pertenecen a diferentes períodos de tiempo, de esta manera los usuarios podrán responderse preguntas tanto actuales como en el pasado. • No volátil: Generalmente los datos en un DW son sólo de lectura. Los datos son cargados por primera vez y luego son actualizados cada cierto tiempo. 3.2.1.3.2.3 Componentes de un DW A continuación los componentes de un DW [4]: • Fuentes de datos: Pueden ser definidos como sistemas de producción, archivos, archivos internos no relacionados directamente con el sistema de producción, datos externos a la compañía, etc. • Staging area: Puede definirse como el área de construcción. En este lugar es donde se depuran los datos, se transforman antes de ser almacenados en el DW. Este proceso de depuración y transformación es el conocido como el proceso ETL (Extracción, transformación y carga). 16 • Almacén de datos operacionales: Contiene una copia de los datos que provienen del sistema operacional (transaccional), la cual es la continuamente actualizada. Es un paso intermedio antes de la carga de los datos en el DW. • Presentación de los datos: Es el lugar de almacenamiento de los datos que van a ser consultados para futuro análisis. Consiste en un DW y varios DM. • Herramientas de Acceso a los datos: Herramientas para realizar las consultas en el DW. Pueden ser herramientas para consultas personalizadas (ad-hoc), aplicaciones, herramientas para hacer minería de datos, etc. Las herramientas elegidas dependen de los requerimientos del usuario y es fundamental que sean intuitivas y de fácil uso. • Metadatos: Los metadatos es información acerca de la misma información. Viene en diferentes formas, formularios, etc. 3.2.1.3.3 Modelo y estructura de un DW 3.2.1.3.3.1 Modelo Dimensional Este modelo está diseñado para recolectar datos de manera significativa. Su objetivo es hacer que los datos sean comprensibles para el usuario de negocio. Los usuarios tienen una forma dimensional de ver los datos, Ej.: se quiere ver el margen de ganancias por período y por región. Este modelo lo que sugiere es imitar la forma dimensional en que piensan los usuarios, colocando como dimensión las condiciones propuestas por sus necesidades [14]. Los datos dimensionales pueden ser almacenados en tablas relacionales o en cubos multidimensionales como serán descritos en la estructura de datos más adelante [14]. 17 Para entender la forma en que se clasificarán las cosas que desea ver el usuario, es importante definir los siguientes términos [14]: • Hechos y/o Métricas: representarán los datos que el usuario quiere ver o examinar, como las ventas, costos, ganancias, etc. Generalmente estos datos son numéricos. • Dimensiones: representan la forma en que los datos están categorizados. También podemos definirlos como las condiciones “por”. Ej.: Margen de ganancias por compañía. • Jerarquías: es como están compuestas estructuralmente las dimensiones. Representa la forma en que se encuentran agregados los datos, la forma como los usuarios navegarán por las dimensiones. • Agregaciones: es la agrupación de datos para definir alguna entidad. Ej.: El indicador de margen de ganancias por compañía está constituido por la dimensión compañía y la métrica de margen [8]. • Niveles: representan las categorías por las cuales se rige la jerarquía de las dimensiones. Ej.: la jerarquía de la dimensión “Región” puede estar categorizada en país y estado. • Cubos: Almacena tanto la información de las métricas como las referencias a las dimensiones por las cuales se desean ver las métricas. 3.2.1.3.3.2 Estructura de datos – Modelo estrella Es la implementación relacional de un modelo multidimensional [14]. Esta implementación contempla [14]: • Las dimensiones, que poseen los valores dimensionales en cada columna de la tabla. • Las “Fact Tables”, poseen las claves foráneas de cada dimensión y un campo adicional que representa la métrica que se desea estudiar o analizar. 18 Figura 2 Modelo estrella En la Figura 2 podemos observar las características mencionadas. 3.2.1.4 Data Mart Es un subconjunto de los datos calculados de un DW que provee a los usuarios información específica de un departamento [4]. Existen 2 tipos dependientes e independientes [4], ver Tabla 2. Propiedad Fuente de datos Proceso ETL DM Dependiente DW (Extracción, Fácil DM Independiente Operacional y externa Difícil transformación y carga) Propósito Mejorar desempeño, Satisfacer necesidades analíticas. disponibilidad, control y Son construidos para solucionar disminuir costos de problemas que necesiten una telecomunicación rápida solución Tabla 2 DM Dependiente vs DM Independiente 19 Es muy frecuente encontrarnos con la pregunta, ¿cuál es la diferencia entre un DW y un DM? En la siguiente tabla (Tabla 3) le ayudaremos a entender las diferencias entre estos conceptos [4]: Propiedad Data Warehouse Data Mart Alcance Empresarial Departamental Área Múltiple Orientado a un área. LOB Fuentes de datos Muchos Pocos Tiempo de implementación Meses a años Meses Tabla 3 Data Warehouse vs Data Mart 3.2.1.5 Sistemas Analíticos – Online Analytical Processing (OLAP) Un sistema OLAP es un acercamiento para proveer rápidamente la respuesta a consultas analíticas [12]. El sistema OLAP es muy parecido al OLTP pero agrega diferencias de estructura por su funcionalidad. En la Tabla 4 se pueden observar las diferencias entre un sistema OLAP y un sistema OLTP [4]: Propiedad OLTP – DB OLAP – DB Tiempo de respuesta Milisegundos a segundos Segundos a horas Operaciones DML Sólo de lectura Naturaleza de los datos 30 a 60 días Histórica Organización de los datos Aplicación Área o materia, tiempo Tamaño Pequeño a grande Grande a abundante Fuentes de datos Operacional, interna Operacional, interna, externa Actividades Procesos, transacciones Análisis, multidimensional Tabla 4 OLTP DB VS OLAP DB 20 3.2.1.5.1 Tipos de sistemas OLAP A continuación los tipos de sistemas OLAP en base a su almacenamiento [12]: • Multidimensional – MOLAP: Es la forma clásica de almacenamiento. Utiliza estructuras en la DB óptimas para el almacenamiento de atributos como el tiempo, producto, ubicación, etc. • Relacional – ROLAP: Trabaja con estructuras relacionales. Los componentes son almacenados en tablas relacionales. Dependen de una modelo de almacenamiento. • Híbrido – HOLAP: No están muy bien definidos, pero consisten en una mezcla de MOLAP con ROLAP. 3.2.1.6 Proceso de Extracción, Transformación y carga – ETL Estos procesos son fundamentales para la creación de información de calidad en el DW. Puedes tomar los datos de las diferentes fuentes de datos; depurar, verificar, validar, y convertirla a un estado consistente; luego la almacenas en el DW [4]. Podemos definir los procesos por separado de la siguiente manera [4]: • Extracción: Es el proceso de seleccionar las características operacionales específicas de las diferentes fuentes de datos. • Transformación: Es el proceso de integración, verificación, validación, depuración, y ubicación en el tiempo de los datos seleccionados para dejarlos en un estado consistente y en un formato uniforme para luego almacenarlos en las bases de datos correspondientes. • Carga: Es el proceso de movilización de los datos desde un almacén intermedio al DW. 21 3.2.2 Análisis de los Datos, Creación y Publicación de Reportes 3.2.2.1 Análisis de los datos y creación de reportes Al utilizar una herramienta analítica, se necesita de metadatos relacionales para acceder a los datos que están almacenados en un modelo estrella, tablas relacionales o tablas en 3NF. Para crear estos metadatos es necesaria la creación de una capa que aísle a los usuarios de la complejidad de la base de datos. Esta capa la conocemos como Capa del usuario final (EUL - End User Layer). Esta capa se encarga de la creación de áreas de negocio, las cuales, agrupan en carpetas, información para distintos usuarios. Cada una de estas carpetas corresponde a un resultado de la ejecución de consultas para la construcción de reportes [14]. En estas capas podemos encontrar [14]: • Jerarquías para navegación en profundidad, • Joins que conecten tablas o vistas, • Condiciones que filtren los datos para los reportes y, • Cálculos creados para los usuarios de negocio. 3.2.2.2 Publicación e interacción con reportes Finalmente, una vez analizados los datos, se deben entregar reportes a los usuarios finales de manera de poder finalizar con el proceso de ayuda a la toma de decisiones. Existen diversas herramientas en las cuales podemos basarnos para la creación de reportes y visualización pero en general estas deben poder facilitar la generación de gráficas y tablas en base a los metadatos creados anteriormente. 22 3.3 Herramientas utilizadas y breve descripción En base a las fases mencionadas anteriormente para el proceso de construcción de un aplicativo de BI, definiremos las herramientas necesarias para cada una de las fases. Las herramientas que mencionaremos a continuación son las utilizadas para la pasantía, mas no todas las que integran el repertorio completo de Oracle para BI. La base de datos de Oracle no será nombrada ya que es un aplicativo necesario solo para el almacenamiento. 3.3.1 Consolidación y Estructuración de los Datos • Fuente de datos OLTP: ERP JD Edwards. Sistema transaccional para la planificación de recursos empresariales. No se profundizará mucho acerca de este producto ya que solo se utilizaron las tablas del módulo de ventas embebido. • Construcción de Data Warehouse: Oracle Warehouse Builder. Utilizada para el diseño, implementación y mantenimiento de un Data Warehouse y los Metadatos para la construcción de reportes. 3.3.2 Análisis de los datos creación de reportes • Construcción de los Metadatos: Oracle Business Intelligence Discoverer Administrator para la creación y mantenimiento de las áreas de negocio de los datos relacionales. • Creación de reportes: Oracle Business Intelligence Discoverer Plus para la creación de reportes estándar y consultas personalizadas. 3.3.3 Publicación e interacción con reportes • Visualización de reportes: Oracle Business Intelligence Discoverer Viewer, el cual asiste en la visualización de reportes y análisis de datos por medio de un explorador Web. 4.0 PLANTEAMIENTO DEL PROBLEMA 23 24 4.1 Problema Actualmente existe una cartera de clientes considerable que poseen el ERP JD Edwards en su versión 8.11 como sistema principal de control de sus actividades comerciales. Esta versión no posee incluido el cálculo de indicadores de negocios necesarios para el proceso de toma de decisiones. A los clientes que poseen esta versión se les presentaron varias opciones como las de migrar a la versión 8.12 del ERP, la cual posee incluida una aplicación de BI con indicadores de negocio en varias áreas o departamentos de la empresa, o adquirir una herramienta analítica como Siebel. El problema de ambos ofrecimientos está relacionado con costos. A raíz de la adquisición de JD Edwards, Oracle ha ofrecido en su nuevo paquete de la aplicación (versión 8.11), herramientas para la construcción de aplicativos de BI con la finalidad de brindarles a sus clientes de base instalada la oportunidad de aplicar BI. 4.2 Objetivo Desarrollar un prototipo de inteligencia de negocio que muestre indicadores de desempeño en el área de ventas mediante la utilización de las herramientas de BI embebidas en el ERP JD Edwards. 4.3 Objetivos específicos • Levantamiento de información junto a un Partner sobre el ERP JD Edwards, específicamente el área de ventas embebida en la aplicación. • Modelar e implementar la Base de Datos del modelo de negocios utilizando el Oracle Database 10g y Oracle Warehouse Builder 10g. Consolidar, estructurar y suministrar datos a la DB. • Integrar las soluciones de la herramienta de Business Intelligence de Oracle para la creación y visualización de reportes. • Establecer un lineamiento para el desarrollo de un aplicativo de BI para JD Edwards. 5.0 MARCO METODOLÓGICO Este capítulo pretende describir la metodología empleada para el desarrollo del aplicativo. Consiste en una revisión general de la metodología a través de fuentes teóricas. 25 5.1 Rational Unified Process (RUP) Es un proceso iterativo para el desarrollo de software creado por la Corporación Racional (división de IBM desde el 2002) [18]. Es un proceso adaptable, cuya intención es que se amolde a las organizaciones y equipos de desarrollo de proyectos de software, quienes seleccionan los elementos apropiados según sus necesidades [18]. ¿Porqué un enfoque RUP para DW? La respuesta a esa pregunta se argumenta en los siguientes puntos [1]: • El alcance de RUP cubre los riesgos técnicos y financieros • RUP va mas allá de los datos (ver Figura 1) • RUP cubre los riegos técnicos desde sus fases tempranas. • RUP cubre los riegos financieros. • Promueve la agilidad y la disciplina en el desarrollo de actividades. 5.1.1 Fases El ciclo de vida de RUP es una implementación del modelo espiral. Ha sido creado para ensamblar el contenido de los elementos en una secuencia semi-ordenada. Por consecuencia, el ciclo de vida se puede visualizar como una estructura de interrupción de trabajo, el cual puede ser editado para satisfacer las necesidades específicas de un proyecto. Para RUP un proyecto se divide en fases e iteraciones. Un proyecto tiene cuatro fases: Inicio, Elaboración, Construcción y Transición ciclo de vida de este proceso, vea la Figura 3. [18] . Para entender un poco el Figura 3 Ciclo de vida de RUP 5.1.1.1 Inicio El objetivo principal de esta fase es tratar los riegos de alcance del proyecto. Se establece el alcance inicial, un plan inicial a alto nivel, una visión del negocio que establezca los objetivos y la justificación del proyecto, y finalmente el apoyo del cliente. Se definen los requerimientos que describen en alto nivel las funcionalidades, características y actores del proyecto a desarrollar [1]. Es importante definir la arquitectura del sistema desde el punto de vista del negocio como también el punto de vista técnico. Es recomendable la construcción de un modelo conceptual y un diagrama de desarrollo para explicar mejor el contexto del proyecto. Se debe tomar en cuenta que la metodología no obliga a elaborar todos los artefactos sino que se elaboren sólo los necesarios para el desarrollo del proyecto [1]. 5.1.1.2 Elaboración El objetivo principal de esta fase es revisar los riesgos técnicos del proyecto. Esto se hace mediante la identificación de los requerimientos que reflejan los riesgos técnicos prioritarios, de manera de poder asegurar que la arquitectura provista funciona. Sólo se deben tomar en cuenta algunos requerimientos ya que la finalidad es cubrir los riesgos mas no implementar todo un requerimiento [17]. Errores que se deben evitar durante la fase de elaboración [17]: • Requerimientos muy detallados • Diseño muy detallado • Documentos detallados de las fuentes de datos • Mapeos entre fuentes de datos y las base de datos del Warehouse muy detallado • No involucrar operaciones ni a personas. 5.1.1.3 Construcción Se desarrolla el aplicativo de manera evolutiva, colocando poco a poco los componentes que conforman nuestra arquitectura inicial (Elaboración). El sistema se construye en iteraciones. Estas iteraciones oscilan entre dos a cuatro semanas de trabajo. Siempre se deben construir los requerimientos de mayor prioridad primero y esperar una retroalimentación del cliente [17]. Técnicas para el desarrollo evolutivo [17]: • Gerencia de la configuración • Integración continua • Refactoring • Pruebas de regresión Errores que se deben evitar durante la fase de construcción [17]: • Tomar un acercamiento intensivo a los datos • Organizar el trabajo por fuentes de datos • Escribir reportes muy detallados • Herramientas inadecuadas • Poca interacción con el cliente • Poca interacción con los dueños de los datos 5.1.1.4 Transición El objetivo de esta fase es lograr poner en producción el proyecto desarrollado. Se debe mantener la comunicación constante con el cliente para saber que es lo que se puede poner en producción. Una vez que el sistema es aceptado y puesto a producción, el entrenamiento necesario para el proyecto es mínimo ya que solo se debe especificar de donde vienen los datos, las nuevas fuentes de datos [17] 6.0 IMPLEMENTACIÓN Este capítulo muestra la implementación del aplicativo de inteligencia de negocios en base a las fases de la metodología. 31 6.1 Fase de inicio El levantamiento de información tuvo una duración de 2 semanas, en la cual se llevó a cabo un estudio de la situación actual frente al problema planteado. El levantamiento de información se hizo junto a la Ing. Rosa Dos Santos perteneciente al departamento de Ventas y los Ing. Jorge Tomioka y José Alirio Peña pertenecientes al departamento de consultoría del Partner de Oracle llamado BFGP el cual está certificado en el ERP JD Edwards. Los puntos principales discutidos fueron el alcance del proyecto, el área al cual iba a atender el aplicativo y los indicadores adjuntos al área necesarios para justificar el prototipo. 6.1.1 Alcance Son muchas las áreas que pueden beneficiarse adjuntando la inteligencia de negocio a su proceso de toma de decisiones. El prototipo irá destinado al área de ventas, considerando algunos indicadores de negocio que serán definidos en los requerimientos funcionales. Estos indicadores serán construidos a partir de la fuente de datos del ERP JD Edwards. 6.1.2 Plan inicial Conjuntamente con la persona de ventas de BFGP y los consultores se planteó el siguiente plan de trabajo el cual se ve reflejado en la Tabla 5. Este plan de trabajo se elaboró para una primera entrega destinada a la exposición de algunos resultados en un evento del aplicativo de Oracle JD Edwards. 32 Pasos. Descripción 1. Levantamiento de información Semanas 1 a. Identificar las necesidades del departamento de ventas b. Definir los objetivos y limitaciones del sistema 2. Especificación de los requerimientos 1 a. Identificar las métricas e indicadores del área de ventas. Requerimientos funcionales. b. Identificar e instalar los productos de Oracle BI c. Aprendizaje y manipulación de los productos de Oracle BI 3. Elaboración 2 a. Análisis y formulación de las métricas b. Identificar las tablas y los campos del la BD de JD Edwards relacionados a las métricas de estudio. c. Diseño ETL primera etapa (Tablas Externas a Staging Area) d. Diseño ETL segunda etapa (Creación de dimensiones) e. Diseño ETL tercera etapa (Data Marts) 4. Construcción 3 a. Implementación del DW b. Creación de reportes 5. Documentación Siempre a. Técnica b. Usuario 6. Pruebas 1 7. Presentación Final Tabla 5 Plan inicial alto nivel 33 6.1.3 Arquitectura del sistema Para la construcción del aplicativo, se necesitó de la definición de las siguientes fases: Consolidación y Estructuración de los Datos, Análisis de los Datos, Creación y Publicación de Reportes. Éstas las podemos ver reflejadas en la Figura 4 en lo correspondiente a los niveles de la arquitectura. COMPONENTES NIVEL G E R E N C I A PRODUCTO USUARIO BI_USER Visualización de reportes Oracle Discoverer Viewer EUL_FROM_OWB A N Á L I S I S Análisis de datos Creación de reportes Oracle Discoverer Plus REP_USER B O D E G A Metadatos TXT Datos OLTP Oracle Warehouse Builder / Oracle Database REP_OWNER Figura 4 Arquitectura del sistema Cada nivel (Gerencia, Análisis y Bodega) refiere a un componente específico el cual está definido por su función en el aplicativo de BI. A su vez se muestra explícitamente qué herramienta de Oracle está involucrada y qué usuarios pertenecen a cada nivel. 34 6.1.3.1 Nivel Gerencia Este nivel corresponde al estudio de los reportes generados para tener mejor basamento en la toma de decisiones. Esta visualización es posible gracias a la herramienta Oracle Discoverer Viewer, componente de Oracle Business Intelligence SE que permite revisar los reportes generados por la capa analítica. El usuario BI_USER hace referencia al cliente de inteligencia de negocios que tiene permiso para visualizar la información y con esta tomar decisiones. 6.1.3.2 Nivel Análisis Este nivel corresponde al análisis de los datos y la creación de reportes. Esta función se hace mediante Oracle Discoverer Plus, componente de Oracle Business Intelligence SE, que permite la realización de consultas personalizadas (ad-hoc queries) y su presentación en tablas y gráficos. La herramienta permite hacer operaciones de filtro, cálculos y porcentajes para la claridad de la información. Toda esta información es guardada en el DW en los denominados Workbooks, los cuales almacenan los metadatos correspondientes al Discoverer Plus. El usuario EUL_FROM_OWB representa al analítico que crea los reportes para la gerencia. No sólo tiene acceso a la herramienta analítica sino también la herramienta que permite la visualización. En este demo se utilizó este usuario para ambas capas por comodidad de presentación, aunque de igual forma se crearon todos los usuarios. 6.1.3.3 Nivel Bodega Este nivel corresponde al concepto de Data Warehouse. Contempla la extracción, transformación y carga de los datos y la consolidación de fuentes de datos necesarias. La Base de Datos de Oracle representa digitalmente el Warehouse y la herramienta Oracle Warehouse Builder es la creadora del DW. Esta 35 herramienta es la responsable de realizar el proceso ETL conjunto a la DB y la creadora de las áreas de negocio necesarias para tener los metadatos. El usuario REP_USER es el usuario de la bodega que sólo podrá consultar los objetos creados. El usuario REP_OWNER es el dueño del DW; éste usuario podrá modificar y consultar los objetos creados en la bodega de datos. 6.1.3.3.1 Diagrama de desarrollo del DW En la Figura 5 se presenta un esquema del funcionamiento del proceso del nivel bodega. Incluye los conceptos mencionados con una abstracción en alto nivel para dar una visión inicial de lo que queremos elaborar. Figura 5 Diagrama de desarrollo En la Figura 5 podemos observar la transición que inicia desde la fuente de datos del ERP JD Edwards hasta nuestro DW. 36 La primera transición exporta las tablas del ERP a unos archivos planos. La razón por la cual no se pudo acceder directamente el repositorio fue por problemas de acceso Web al servidor en donde estaba instalado el demo del aplicativo. El demo era del Partner BFGP quien ayudó a determinar las tablas de la DB necesarias para desarrollar los requerimientos establecidos. La segunda y tercera transición describe el proceso de extracción, transformación y carga de los archivos planos al staging area (área intermedia) en donde se realizará un proceso de depuración y transformación para tener los datos con el formato adecuado. La última transición corresponde a la carga de los datos en el Warehouse. Esto significa que ya los datos se encuentran almacenados con la estructura adecuada dentro del DW, listos para la creación de los metadatos necesarios para la capa de análisis. 6.1.4 Requerimientos funcionales Una vez establecida la visión general de la arquitectura del sistema debemos definir los indicadores del área de ventas que se van a trabajar para entender específicamente qué funcionalidades deben ser elaboradas para el prototipo. En la Tabla 6 podemos encontrar los requerimientos funcionales a implementar. De la tabla de requerimientos nos damos cuenta de 5 conceptos importantes que debemos revisar al diseñar la estructura del DW: cliente, producto, almacén, compañía y tiempo. En la Figura 6 podemos revisar el modelo conceptual del DW. 37 Requerimiento Descripción R-01 Analizar margen de ganancias por compañía en un período dado. R-02 Analizar margen de una compañía por almacén en un período dado. R-03 Analizar el cliente que le generó mayor ganancias a un almacén de una compañía en un período dado. R-04 Analizar el tipo de cliente que le generó mayor ganancias a un almacén de una compañía en un período dado. R-05 Analizar el tipo de productos mas vendido por un almacén de una compañía en un período dado. R-06 Analizar el producto mas vendido por un almacén de una compañía en un período dado. R-07 Analizar el producto que compró el cliente que le generó más ganancias a un almacén de una compañía. R-08 Analizar los almacenes que poseen pedidos pendientes en un período dado. R-09 Analizar el tipo de productos que tiene más pedidos pendientes en un período dado. R-10 Analizar el total de pedidos entregado contra los no entregados. Tabla 6 Requerimientos funcionales Figura 6 Modelo conceptual 38 6.2 Fase de elaboración Esta fase tuvo como duración 2 semanas y su objetivo es probar el funcionamiento de la arquitectura planteada. Por esta razón se eligieron los requerimientos necesarios para abarcar todo el contexto de la aplicación. La intención es diseñar soluciones para cada uno de los niveles en base a los indicadores de ventas definidos en los requerimientos. Deben tomarse en cuenta los siguientes riesgos antes de la elaboración del diseño de la solución: acceso a las fuentes de datos, volumen de datos, y calidad de los datos. 6.2.1 Análisis y formulación de las métricas Cuando hablamos de métricas nos referimos a la forma en que está definido el indicador, es decir, básicamente se refiere al valor calculado del indicador utilizado para describir la operación que lleva implícita. 6.2.1.1 Cálculo de métricas En la Tabla 7 podemos observar el nombre de las métricas implementadas así como su descripción y su forma de cálculo. Métrica Descripción Margen sobre órdenes totales Se refiere a la ganancia generada por todas las órdenes de compra entregadas. Puede calcularse con la resta del precio extendido por orden de compra menos el costo extendido por orden de compra. Número de órdenes tardías Cuenta el número de órdenes consideradas como demoradas. Se define comparando si la fecha actual de entrega de la orden es mayor a fecha prometida de entrega. Tabla 7 Definición de métricas 39 6.2.2 Fuente de datos del ERP JD Edwards Tomando en cuenta las entidades resaltadas en los requerimientos (cliente, producto, compañía, almacén y tiempo) se seleccionaron varias tablas del ERP JD Edwards las cuales podemos verlas en la Tabla 8. Tablas Customer Master LOB (Cliente) Item Master (Producto) User Defined Codes (Definidos por el usuario) Address By Date (País y Estado) Address Book Master (Nombres y descripción) Company Constants (Compañía) Business Unit Master (Almacén) Sales Order Detailed File (Ventas) Tabla 8 Tablas JD Edwards 6.2.3 Diseño ETL primera etapa (Tablas Externas a Staging Area) Una vez seleccionadas las tablas, se manifestó el primer riesgo, el acceso a la fuente de datos. Durante el levantamiento de información se estableció que el demo de JD Edwards sobre el cual se iban a extraer los datos iba a tener como manejador de DB el de Oracle. Finalmente por disponibilidad, el demo utilizado tuvo como manejador SQL Server. El problema entre las conexiones entre diferentes manejadores y el problema de conexión entre la computadora utilizada y el servidor del Partner donde estaba instalado el demo, se dio principalmente por protocolos de ambas empresas. La solución propuesta, consistía en exportar las tablas a archivos planos de texto para luego cargarlos como tablas externas en la base de datos de Oracle donde se iba a crear el DW. 40 6.2.3.1 Tablas externas a Staging Area El primer pasó a realizar involucraba un proceso de depuración de los datos debido a los diferentes tipos de datos entre el manejador SQL Server y Oracle Database. Una vez depurados los archivos, se deben cargar en la base de datos como tablas externas (Figura 7) las cuales pueden ser definidas como aquellas provenientes de fuentes alternas (Archivos planos o conexiones a otras bases de datos). Figura 7 Diseño ETL primera etapa Finalmente luego de un proceso de transformación y estructuración, se almacenan las tablas externas en tablas relacionales en el staging area tomando como referencia el modelo conceptual presentado en la fase de inicio (Figura 6). El proceso de estructuración debe incluir la denormalización de las tablas externas. En el proceso de transformación se cubre el riesgo de calidad de los datos ya que se incluye una revisión que verifica que los datos a cargar sean consistentes y de calidad para el usuario final. En este punto se debe asegurar que los datos no sean nulos, que haya suficientes datos y además que el valor de los datos sea significativo y acorde a lo necesario para la fase de análisis. 41 6.2.4 Diseño ETL segunda etapa (Creación de dimensiones) Una vez obtenida la estructura de nuestro DW, se crearon los componentes dimensionales referentes a las condiciones de evaluación de las métricas. Para realizar esta tarea se realizó un mapeo de los datos de cada una de las tablas del DW a su dimensión correspondiente (Ej.:Figura 8). Figura 8 Diseño ETL segunda etapa 6.2.5 Diseño ETL tercera etapa (Data Marts) El motivo principal de la creación de un Data Mart es representar sólo una porción de DW. En nuestro caso queremos implementar una visión que nos muestre las métricas de margen y órdenes en demora con cada una de sus condiciones. A partir de los Data Marts dependientes se construirán las diferentes áreas de negocio utilizadas por la herramienta analítica. La estructura de los Data Marts van a seguir las pautas del modelo estrella y el Fact Table de cada uno va a ser llenado a partir del Fact Table del DW, específicamente los datos correspondientes al cálculo de la métrica y los datos de las dimensiones (Figura 9). Para contemplar el riesgo de volumen de datos se propuso una estructura ROLAP (Relational Online Analytical Processing) para la construcción de los Data Marts, promoviendo el almacenamiento en tablas relacionales para minimizar el espacio utilizado en la base de datos. 42 Figura 9 Diseño ETL tercera etapa 6.3 Fase de Construcción 6.3.1 Iteración #1 En esta iteración se trabajó con los requerimientos pautados en la fase de inicio. Cada etapa de diseño se verá reflejada a lo largo de la explicación de la construcción del aplicativo. 6.3.1.1 Configuración del ambiente de trabajo El primer paso fue la creación de una base de datos llamada ORCL. La Base de Datos fue creada durante la instalación del producto el cual poseía la siguiente versión: Oracle Database 10g Release 2 EE. La herramienta Warehouse Builder fue instalada en la misma máquina donde iba a residir el DW. En seguida se crearon los usuarios de las diferentes capas del sistema: REP_USER, REP_OWNER, EUL_FROM_OWB y BI _USER como lo establece el documento de arquitectura. Los usuarios REP_USER, REP_OWNER fueron creados a partir de la herramienta Repository Assistant de Oracle Warehouse Builder. Al crear estos usuarios, la herramienta les concede los permisos de acuerdo a su perfil (Usuario o Dueño). Los usuarios restantes se crearon directamente en la DB mediante la Herramienta SQL Plus. 43 Al arrancar OWB se crea un proyecto automáticamente. De igual manera se creó otro proyecto denominado BFGP_DEMO (ver Figura 10). Figura 10 Oracle Warehouse builder 6.3.1.2 Trabajando con los archivos planos. Datos transaccionales. Una vez creados los usuarios se deben crear los módulos de archivos planos los cuales refieren a las carpetas donde estarán almacenados los archivos planos de la fuente de datos. 44 Utilizando el asistente de creación de archivos (Figura 10, en la sección de Archivos) se creó un módulo llamado BFGP_SOURCE que representó la ubicación de los archivos planos en el sistema operativo (El nombre de la ubicación fue BFGP_SOURCE_LOCATION). Para la importación de archivos se utilizó el asistente de importación, que al proporcionarle la ubicación nos facilitó una interfaz para el identificar el formato de cada archivo. Al obtener el control de la ubicación y la estructura de las tablas que contiene cada archivo, pudimos editar los tipos de datos de las tablas. El control sobre los archivos no implica la visualización de su contenido, por lo que el siguiente paso correspondió a su traslado a una forma que nos permitió realizar el proceso de depuración para asegurarnos del contenido y la calidad de los datos. 6.3.1.2.1 Creación de esquema relacional del Warehouse Constituye el proceso de modelar de forma relacional (Tercera Forma Norma (3FN) a dimensional – Modelo estrella) los esquemas que conforman el DW. Corresponde al módulo de Bases de Datos, el cual nos permite la definición de objetos relacionales como tablas, vistas, secuencias, tablas externas y la definición de objetos dimensionales como dimensiones y cubos. Estos módulos deben tener un mapeo directo a un esquema de la base de datos para poder almacenar los objetos mencionados. La intención de la herramienta es separar el diseño de la implementación física. Ofrece opciones de diseño multidimensionales como relacionales (MOLAP, ROLAP). Para el diseño relacional tomaremos la implementación del modelo estrella. Como primer paso, se creó en la base de datos un esquema llamado BFGP_WH el cual tuvo un usuario con el mismo nombre del esquema (ver Figura 11). 45 Figura 11 Usuarios de OWB Finalmente se creó un módulo de base de datos llamado BFGP_STG_WH, el cual generó una ubicación llamada BFGP_WH_LOCATION que almacenó los datos de la conexión al esquema. Este módulo introdujo diferentes objetos para la creación del DW (ver Figura 12). Figura 12 Objetos de bases de datos OWB 46 6.3.1.2.2 De archivos planos a tablas externas Dentro de los objetos que podemos crear en el módulo de bases de datos, encontramos las tablas externas. Éstas nos permiten transformar los datos de un archivo plano en objetos relacionales o dimensionales y de esta forma ofrecernos la posibilidad de consultar los archivos directamente desde la base de datos. Para la construcción de las tablas externas se utilizó el asistente de creación de tablas externas. Este nos permitió crear la tabla externa a partir de un archivo plano, los cuales en nuestro caso residen en la ubicación BFGP_SOURCE_LOCATION. A partir de las tablas externas, se crean los “data files” correspondientes, y los archivos de log, los cuales son útiles para revisar las inconsistencias de los tipos de datos del archivo plano con respecto a las tablas relacionales en la base de datos Oracle. Para poder revisar estas inconsistencias, debemos desplegar las tablas externas de manera de poderlas crear en la base de datos. El gestor de centro de control tiene la funcionalidad de desplegar los objetos creados dentro de la base de datos. Como podemos observar en la Figura 13 tenemos en la parte izquierda las ubicaciones del proyecto las cuales contienen los objetos creados. Para desplegar, eliminar o actualizar algún objeto en la base de datos, debemos seleccionarlo e indicar la acción que debe ejecutar el gestor de centro de control. Figura 13 Centro de control OWB 47 Luego de revisar las inconsistencias, se consultaron los datos de las tablas externas conjunto al Partner BFGP para asegurarnos que la calidad de los datos fuese óptima para el análisis. 6.3.1.2.3 De tablas externas a staging area Utilizaremos como referencia el documento de despliegue de la Figura 7 y el modelo conceptual de la Figura 6. Con el módulo de creación de tablas dentro del modulo de base de datos, se crearon las tablas correspondientes a los conceptos importantes: cliente, producto, almacén, compañía y ventas. Esta creación lleva implícita la participación del editor de objetos, el cual define un espacio de trabajo en donde podemos crear una tabla y editarla (Figura 14). Figura 14 Editor de Objetos OWB 48 Figura 15 Modelo estrella del DW La Figura 15 refiere a la implementación del modelo estrella del DW. Dentro de los conceptos mencionados incluimos el tiempo el cual no fue incluido en el modelo conceptual como en esta implementación ya que lo vamos a considerar como una dimensión en los Data Marts que se elaborarán. El gestor de centro de control es el que nos permite tanto la creación como el llenado de los objetos. Para el llenado se deben definir las correspondencias las cuales son diseños que definen la forma en que se van a llenar las tablas. Tomemos como ejemplo la correspondencia de la Figura 16 para ver en que consisten. Utiliza como fuente (lado izquierdo) las tablas externas y como destino tenemos una de las tablas creadas para definir la estructura del warehouse. Estas correspondencias definen operadores los cuales nos permiten hacer cálculos u operaciones con los datos de la fuente antes de insertarlos en la tabla. 49 Figura 16 Correspondencia del Fact de Ventas En el gestor de centro de control, se despliegan las correspondencias y se corren de manera de que se active un trabajo en la base de datos para llenar las tablas según lo establece la correspondencia. Todos los objetos creados en los módulos de base de datos requieren de una correspondencia para ser llenados con datos a excepción de las tablas externas cuyos datos corresponden a los archivos planos. Para automatizar el proceso de llenado se definen los flujos de procesos (Figura 17). Estos permiten establecer una secuencia de llenado entre las correspondencias organizadas por prioridad y dependencia. 50 Figura 17 Flujo de proceso 6.3.1.3 Segunda Etapa ETL (Creación de Dimensiones) 6.3.1.3.1 Creación del esquema relacional del Warehouse Para modularizar un poco el proceso se decidió crear otro o módulo de base de datos pero de igual forma se hizo bajo el mismo esquema y utilizando el mismo usuario. La razón fue la de representar la transición del staging area al DW. En este módulo se crearán los objetos dimensionales. 6.3.1.3.2 Diseño de dimensiones Son las formas organizacionales primarias de los datos en un modelo estrella. Representan las condiciones por la cual se desean visualizar los indicadores de negocio. Consisten un una serie de niveles y jerarquías. Cada nivel posee atributos y cada uno debe tener un identificador de la dimensión a la cual pertenece y un identificador de negocio. 51 Para la creación de dimensiones se utilizó el asistente de creación de dimensiones el cual nos permitió definir las características mencionadas en el párrafo anterior. Al igual que las tablas creadas para el staging area, las dimensiones también necesitan de correspondencias para ser llenadas de datos. Un ejemplo de una dimensión y su correspondencia la podemos observar en la Figura 18. Vale la pena recalcar que se creó tantas dimensiones como condiciones (conceptos: cliente, producto, compañía y almacén) y además se incluyó la dimensión de tiempo la cual es fundamental para cualquier análisis de inteligencia de negocios. Figura 18 Correspondencia de dimensión Para la correspondencia mostrada en la ilustración anterior, tenemos como fuente las tablas que se encuentran depuradas del staging area. De esta forma estamos seguros que la fuente de datos ya paso por un proceso de depuración y control de calidad antes de llegar a los objetos dimensionales. Finalmente en el gestor del centro de control se desplegaron todas las dimensiones y se ejecutaron sus correspondencias. 52 6.3.1.4 Tercera Etapa ETL (Creación de data marts) Una vez creadas las dimensiones se crearon los data marts. Para la implementación de los DM se crearon cubos, los que podemos definirlos como los contenedores de las métricas y los enlaces a las dimensiones por las que se evaluarán las métricas. Para la creación de los cubos se utilizó el asistente de creación de cubos en los que se especificó el tipo de dato de la métrica, su forma de cálculo y las dimensiones que los van a constituir. Para visualizar mejor la explicación nos valdremos de la Figura 19. Figura 19 Cubo de 5 dimensiones 53 Para los cubos también se crearon correspondencias las cuales llenaron al cubo a partir del Fact table de ventas del staging area (Figura 20). Dentro de la correspondencia se definieron las operaciones necesarias para el cálculo de la métrica como se ve en la ilustración. Figura 20 Correpondencia del cubo Al igual que en el staging area, en este caso también se definió un flujo de proceso para el llenado de los data marts para optimizar el proceso. 6.3.1.5 Creación de áreas de negocio Finalmente se utilizó el módulo de Business Intelligence, dentro del cual se encuentran las áreas de negocio. El primer paso fue crear, utilizando la herramienta Discoverer administrator, una capa de usuario final. El usuario creado fue denominado EUL_FROM_OWB. Se le concedieron los permisos de acceso y manipulación de todos los objetos en el esquema BFGP_WH de manera de poder acceder desde la herramienta analítica el área de negocio. 54 Una vez creado el usuario, nos dirigimos al módulo de BI en OWB para crear el área de negocio el cual iba a contener los objetos dimensionales del DW. El asistente de creación del área de negocio sólo pidió referenciar los objetos dimensionales que se debían integrar (ver Figura 21). Al igual que todos los componentes creados las áreas de negocio fueron desplegadas en la base de datos mediante la utilización del gestor del centro de control. Figura 21 Área de negocio 6.3.1.6 Creación de reportes. Discoverer Plus Una vez creadas las áreas de negocio, metadatos de la herramienta analítica, se crearon los reportes correspondientes a los indicadores de negocio planteados en los requerimientos. Para poder acceder los metadatos, se creó una conexión al esquema del Warehouse (BFGP_WH) con la herramienta Discoverer Administrator. En este caso utilizamos el usuario EUL_FROM_OWB para el acceso a Discoverer Plus. 55 Para entender la herramienta Discoverer Plus debemos ver los componentes participantes en la elaboración de reportes: • Workbook: Es el contenedor de los Worksheet • Worksheet: Son los objetos que contienen el reporte. Está compuesto por una tabla o una gráfica o ambos. En el caso de elegir ambos se debe tomar en consideración que la consulta mostrada por cada una es la misma. Al acceder a Discoverer Plus aparecerá la ventana de creación de Workbooks y a su vez la configuración del primer Worksheet (Figura 22 Discoverer). Figura 22 Discoverer 56 Este asistente nos permitió agregar tanto los cubos como las dimensiones provenientes del área de negocio definida en OWB. Al finalizar el asistente dependiendo del layout seleccionado (Tabla, gráfico, o tabla y gráfico). Cada vez que agregamos un elemento del área de negocio estamos incluyendo una tabla en la consulta realizada por la herramienta analítica. En la Figura 23 podemos visualizar la implementación de uno de los indicadores. La tabla que aparece en el centro de la figura representa la tabla generada por la consulta de discoverer. Cada columna representa una característica diferente. La columna izquierda representa uno de los niveles de la dimensión de compañía. La columna central representa la métrica del cubo el cual describe el comportamiento del indicador utilizando el margen. La última columna representa el cálculo de porcentaje de cada margen de las diferentes compañías a partir del cálculo del total representado en la última línea con el color rojo. Figura 23 Indicador de discoverer plus 57 En la parte izquierda de la ventana podemos observar cada elemento del área de negocio. Está compuesto por los cubos, las dimensiones y cada atributo correspondiente a los niveles de éstas. En la parte superior están la herramientas para hacer lo cálculos, los porcentajes y los filtros. En la parte inferior observamos varias pestañas que representan diferentes Worksheet correspondientes a indicadores de negocio, es decir, cada Worksheet representa un indicador. Para ofrecer una mejor explicación de los indicadores se generaron por cada uno un gráfico que como mencionamos corresponde a la misma consulta de la tabla. La Figura 24 representa el gráfico correspondiente a la tabla de la Figura 23. Figura 24 Gráfico de discoverer plus 58 6.4 Fase de Transición El prototipo funcional necesitó la herramienta Discoverer Viewer para la visualización de reportes. Esta herramienta forma parte del paquete de JD Edwards y es la utilizada por las personas que participan en la toma de decisiones para el análisis de la información creada por los analíticos. La primera pantalla de la aplicación Discoverer Viewer nos ofrece el listado de Workbooks generados por el Discoverer Plus (Figura 25). Al expandir la rama de Workbooks, se ofrecerán todos los Worksheets creados. Figura 25 Discoverer viewer La pantalla de visualización de Worksheet ofrece diferentes acciones a ejecutar para manipular el objeto mostrado. A su vez nos permite seleccionar los diferentes Worksheets creados y configurar el layout. Para entender mejor esta explicación vea la Figura 26 y Figura 27. 59 Figura 26 Discoverer viewer worksheet solo tabla Figura 27 Discoverer viewer worksheet tabla y gráfico 7.0 CONCLUSIONES Y RECOMENDACIONES Este capítulo presenta las conclusiones del proyecto elaborado en base a los objetivos cumplidos y futuras recomendaciones para la elaboración de aplicativos de inteligencia de negocios sobre el ERP JD Edwards. 60 61 7.1 Conclusiones Si nos referimos al objetivo general podemos concluir que con las herramientas provistas en el paquete del ERP JD Edwards en su versión 8.11 se puede hacer inteligencia de negocios. Para esto, los clientes que poseen el ERP deben elaborar un aplicativo el cual debe incluir la construcción de un Data Warehouse. Es importante incluir que si muy bien el repositorio puede implicar costos por la adquisición de nuevo Hardware, el retorno a la inversión por la aplicación de inteligencia de negocios es muy rápido. Además que el proceso de elaboración solo requiere de 6 meses. Finalmente podemos concluir que el trabajo realizado establecerá lineamientos de elaboración de aplicativos de inteligencia de negocios para los consultores de BFGP, quienes ofrecerán a sus clientes de base instalada 8.11 la garantía de poder aplicar BI en sus procesos diarios de aplicación. 7.2 Recomendaciones El aplicativo construido cumplió con las expectativas de ofrecerles a los clientes de base instalada 8.11 la posibilidad de construir un aplicativo de inteligencia de negocios con las herramientas que trae el paquete del ERP. Es importante recordar que actualmente en el mercado, existen herramientas de BI mucho más avanzadas las cuales pueden proveer mayor información en menor tiempo y con mayor especificidad. No queremos con esto presionar a la adquisición de nuevas herramientas sino la elaboración de nuevos artefactos de requerimientos. 7.2.1 Recomendaciones generales • Centralización de la información mediante la elaboración de un portal (Dashboard). • Establecer correlaciones entre los diferentes indicadores • Elaborar nuevas áreas de negocio en base a los diferentes departamentos de la empresa. • Automatizar los procesos ETL para generar información diaria para la toma de decisiones. 62 7.2.2 Extensión de funcionalidades • Implementación de nuevas métricas para el área de ventas. • Implementación de seguridad de datos para el repositorio. • Implementar mayor dinamismo entre indicadores. 8.0 BIBLIOGRAFÍA . 63 64 [1] A RUP-based approach to developing a data warehouse -- Part 1: Setting the stage, IBM 2006. http://www-128.ibm.com/developerworks/rational/library/nov06/ambler/ [2] The Oracle Business Intelligence Solution, Oracle 2006. http://download-east.oracle.com/docs/html/B16378_01/introbi.htm [3] Business intelligence, Wikipedia 2006. http://en.wikipedia.org/wiki/Business_intelligence [4] Psomas, N., Kolachalam, P. M. (2002). Data Warehousing. Fundamentals. Edición 1.0. Oracle Corporation. U.S [5] Guide S35: Purpose, Ministry of forest and rage. http://www.for.gov.bc.ca/his/datadmin/s35_1.htm [7] Online transaction processing, Wikipedia 2007. http://en.wikipedia.org/wiki/OLTP [8] Designing the Star Schema Database, CIO Briefings. http://www.ciobriefings.com/whitepapers/StarSchema.asp [9] Database normalization, Wikipedia 2006. http://en.wikipedia.org/wiki/Database_normalization [10] Data warehouse, Wikipedia 2006. http://en.wikipedia.org/wiki/Data_warehouse 65 [11] Key performance indicators, Wikipedia 2006. http://en.wikipedia.org/wiki/Key_performance_indicators [12] OLAP, Wikipedia 2006. http://en.wikipedia.org/wiki/OLAP [13] Star schema, Wikipedia 2006. http://en.wikipedia.org/wiki/Star_schema [14] Technical Fundamentals for Implementation, Oracle 2006. http://download-east.oracle.com/docs/html/B16378_01/implementbi.htm [15] Principios de las empresas que se basan en la información, Oracle 2007. http://www.oracle.com/global/lad/corporate/corpoverview1.html [16] Oracle Corporation, Wikipedia 2007. http://en.wikipedia.org/wiki/Oracle_Corporation [17] A RUP-based approach to developing a data warehouse -- Part 2: Building the data warehouse, one iteration at a time, IBM 2007. http://www-128.ibm.com/developerworks/rational/library/dec06/ambler/ [18] IBM Rational Unified Process, Wikipedia 2007. http://en.wikipedia.org/wiki/RUP 9.0 APÉNDICE A EJEMPLOS FASE DE CONSTRUCCIÓN 9.1 Ejemplo de Tabla Figura 28 Tabla Compañía Figura 29 Fact de Ventas 66 67 9.2 Ejemplo de dimension Figura 30 Dimensión de Tiempo 9.3 Ejemplo de cubo Figura 31 Cubo órdenes en demora 68 9.4 Ejemplo de correspondencias Figura 32 Correspondencia de tabla producto Figura 33 Correspondencia de Cubo de órdenes en demora 69 9.5 Ejemplo de flujos de proceso Figura 34 Flujo de proceso Staging Area – Data Warehouse 10.0 APÉNDICE B ARTEFACTOS DE RUP 10.1 Documento de arquitectura Figura 35 Documento de arquitectura 10.2 Diagrama de desarrollo ERP JD Edwards 8.11 Demo DB SQL Server TABLAS ETL FACT TABLE Staging Area TABLAS Data Warehouse ARCHIVOS PLANOS Figura 36 Diagrama de desarrollo 70 10.3 Apéndice c matriz de requerimientos Requerimiento Descripción R-01 Analizar margen de ganancias por compañía en un período dado. R-02 Analizar margen de una compañía por almacén en un período dado. R-03 Analizar el cliente que le generó mayor ganancias a un almacén de una compañía en un período dado. R-04 Analizar el tipo de cliente que le generó mayor ganancias a un almacén de una compañía en un período dado. R-05 Analizar el tipo de productos mas vendido por un almacén de una compañía en un período dado. R-06 Analizar el producto mas vendido por un almacén de una compañía en un período dado. R-07 Analizar el producto que compró el cliente que le generó más ganancias a un almacén de una compañía. R-08 Analizar los almacenes que poseen pedidos pendientes en un período dado. R-09 Analizar el tipo de productos que tiene más pedidos pendientes en un período dado. R-10 Analizar el total de pedidos entregado contra los no entregados. Tabla 9 Matriz de requerimientos 71 11.0 APENDICE C VISUALIZACIÓN DE REPORTES 11.1 R01 Figura 37 R01 Margen de ganancias por compañía y por un período dado 72 73 11.2 R04 Figura 38 R04 Tipo de cliente que le generó más ganancias a un almacén por compañía y por año 74 11.3 R08 Figura 39 R08 Órdenes en demora y a tiempo por compañía, almacén en un período dado 75 11.4 R10 Figura 40 R10 Total de órdenes en demora vs a tiempo