UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación

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