Upload
dangduong
View
221
Download
0
Embed Size (px)
Citation preview
1
FACULTAD DE INGENIERÍA
Ingeniería Empresarial y de Sistemas
IMPLEMENTACIÓN DE INTELIGENCIA DE
NEGOCIOS PARA EL ÁREA COMERCIAL DE LA
EMPRESA AZALEIA - BASADO EN METODOLOGÍA
ÁGIL SCRUM
Tesis para optar el Título Profesional de Ingeniero
Empresarial y de Sistemas
JUBITZA LISBETH SALAZAR TATAJE
Asesor:
Aures García, Álvaro Antonio
Lima – Perú
2017
2
DEDICATORIA
A Dios, por permitirme llegar a este momento tan importante en mi carrera profesional. A la
vida que a pesar de todos los momentos difíciles me ha enseñado que con esfuerzo,
dedicación y fe, se puede conseguir los objetivos trazados. A mis padres que con su
inmenso amor incondicional me han apoyado en cada etapa de mi vida y en especial a mi
abuela Mela Povis Matos, quien es y será el gran pilar de mi vida, que desde el cielo sigue
mis triunfos y es el ángel que siempre me acompaña.
3
AGRADECIMIENTO
Agradezco a mi asesor de tesis el Ing. Alvaro Aures, por haber invertido tiempo y
dedicación durante todo el proceso y desarrollo de la tesis.
Sus conocimientos y orientaciones basados en la experiencia, inculcando el sentido de la
seriedad, el compromiso, y responsabilidad que un profesional debe de tener.
Más que un asesor, es un amigo que ha sido capaz de ganarse mi confianza y admiración
a nivel profesional y como persona.
4
ÍNDICE
ÍNDICE DE TABLAS ............................................................................................... 7
Resumen ................................................................................................................. 8
Abstract .................................................................................................................. 9
Capítulo 1: Introducción ...................................................................................... 10
1.1. Problema de Investigación ........................................................................... 10
1.1.1. Planteamiento del problema. ............................................................... 10
1.2. Formulación del problema ............................................................................ 12
1.2.1. Justificación de la investigación ........................................................... 12
1.3. Marco referencial .......................................................................................... 14
1.3.1. Antecedentes ....................................................................................... 14
1.3.2. Marco teórico ....................................................................................... 17
1.3.2.1. Plataforma de Inteligencia de Negocios ............................... 17
1.3.2.2. Beneficios ............................................................................ 20
1.3.2.3. Componentes de la inteligencia de negocio ......................... 21
1.3.2.4. Repositorio de información................................................... 23
1.3.2.5. Metodología de Inteligencia de Negocios ............................. 24
1.3.2.5.1. Metodología Ralph Kimball .................................................. 25
1.3.2.5.2. Metodología Bill Inmon ......................................................... 26
1.3.2.5.3. Metodología Hefestos .......................................................... 27
1.3.2.5.4. Metodología Ágil .................................................................. 27
1.3.2.5.5. Scrum .................................................................................. 28
1.3.2.6. Repositorio Data Mart .......................................................... 30
1.3.2.7. Crecimiento de los Data Marts ............................................. 31
1.3.2.8. Data Marts Virtuales y Meta Vistas ...................................... 33
1.3.2.9. Administración de los Data Marts ......................................... 34
1.3.2.10. Paquetes Data Marts ........................................................... 35
1.3.2.11. Cubo Olap de estructura dimensional .................................. 36
1.3.2.12. Tableros de control .............................................................. 39
1.3.2.13. Software de explotación de información ............................... 40
1.3.2.14. Extracción, transformación y carga (ETL) ............................ 41
1.4. Objetivo e Hipótesis ...................................................................................... 42
1.4.1. Objetivo general ................................................................................... 42
1.4.2. Objetivos específicos ........................................................................... 42
1.4.3. Operacionalización de las variables e hipótesis ................................... 43
1.4.3.1. Hipótesis general ................................................................. 43
1.4.3.2. Hipótesis secundarias .......................................................... 43
1.4.3.3. Variables .............................................................................. 44
1.5.1. Alcance ................................................................................................ 45
1.5.2. Limitaciones ......................................................................................... 46
1.6. Breve resumen de las fases ......................................................................... 46
Capítulo 2: Marco Contextual .............................................................................. 47
2.1. Descripción de la Empresa ........................................................................... 47
2.2. Presentación del área funcional ................................................................... 51
2.3. Cadena de Valor ............................................................................................ 51
2.4. Cadena de Valor – Macro Procesos Misionales .......................................... 52
2.5. Procesos de venta e importaciones Nivel 0 ................................................ 53
5
Capítulo 3: Marco Metodológico ......................................................................... 55
3.1. Modelo de negocio ........................................................................................ 55
3.3. Metodología de desarrollo ............................................................................ 55
3.3.1. EDT Implementación de Inteligencia de Negocios ............................... 56
3.3.2. Tablero Kanban ................................................................................... 57
3.4. Dimensionamiento del Proyecto .................................................................. 57
3.5. Roles y responsabilidades ........................................................................... 57
3.6. Sprint Backlog ............................................................................................... 58
3.7. Desarrollo Sprint I ......................................................................................... 60
3.7.1. Entregables .......................................................................................... 60
3.7.2. Diseño de Arquitectura Azaleia ............................................................ 60
3.7.3. Indicadores de gestión ......................................................................... 61
3.7.4. Historias de Usuarios ........................................................................... 66
3.7.5. Diseño de Prototipos ............................................................................ 68
3.7.5.1. Tablero Gerencial ................................................................ 68
3.7.5.2. Ventas por Mayor ................................................................. 69
3.7.5.3. Ventas por Tienda ................................................................ 70
3.7.5.4. Ventas por Catálogo ............................................................ 71
3.8. Desarrollo Sprint II ........................................................................................ 72
3.8.1. Entregables .......................................................................................... 72
3.8.1.2. Modelo Dimensional ............................................................ 73
3.8.1.3. Diseño físico de la base de datos ........................................ 73
3.8.1.4. Diseño físico de la base de datos intermedia ....................... 74
3.8.1.5. Diseño de la arquitectura técnica ......................................... 74
3.8.1.6. Selección e instalación de productos ................................... 74
3.8.1.7. Especificación de la aplicación de usuarios ......................... 75
3.8.1.8. Implementación .................................................................... 75
3.8.1.9. Diseño de Extracción Transformación y Limpieza (ETL) ...... 75
3.8.1.10. Tablas identificadas ............................................................. 77
3.8.1.11. Tabla de extracción – Esquema SSIS .................................. 79
3.8.1.12. Modelo entidad relación / Diagrama E-R .............................. 79
3.9. Desarrollo Sprint III ....................................................................................... 81
3.9.1. Entregables .......................................................................................... 81
3.9.2. Implementación de interfaz de usuario ................................................. 81
3.9.2.1. Pruebas integrales ............................................................... 87
3.9.2.2. Carga de Datos .................................................................... 87
3.9.2.3. Afinamiento de rendimiento.................................................. 87
3.9.2.4. Estabilización y pase a producción ...................................... 87
3.9.2.5. Criterios de aceptación ........................................................ 88
3.10. Pruebas y resultados ............................................................................. 90
3.10.1 Contrastación de Hipótesis ................................................................... 90
3.11. Retorno de Inversión ............................................................................. 92
Conclusiones ....................................................................................................... 93
Recomendaciones ............................................................................................... 94
Referencias Bibliografía ...................................................................................... 95
Anexos .................................................................................................................. 98
6
INDICE DE FIGURAS
FIGURA 1 USO DE HERRAMIENTAS BI ....................................................................................11
FIGURA 2 NIVELES DE ANÁLISIS DE INTELIGENCIA DE NEGOCIO ................................................18
FIGURA 3. MODELO INTEGRAL SOLUCIÓN BI ..........................................................................22
FIGURA 4. COMPONENTES DE LA INTELIGENCIA DE NEGOCIO ..................................................23
FIGURA 5. ESQUEMA TRANSACCIONAL ERP ..........................................................................23
FIGURA 6. THE KIMBALL DATA LIFECYCLE .............................................................................26
FIGURA 7. THE INMON WAREHOUSE ......................................................................................26
FIGURA 8. FASES DE LA METODOLOGÍA HEFESTO...................................................................27
FIGURA 9. SCRUM FRAMEWORK ...........................................................................................29
FIGURA 10. INTEGRACIÓN DE DATA MARTS ...........................................................................34
FIGURA 11. DATA WAREHOUSE CENTRALIZADO .....................................................................35
FIGURA 12. ESQUEMA OLAP ................................................................................................36
FIGURA 13. ESQUEMA M-OLAP............................................................................................37
FIGURA 14. ESQUEMA R-OLAP ............................................................................................38
FIGURA 15. ESQUEMA H-OLAP ............................................................................................38
FIGURA 16. CUADRO DE MANDO MICROSTRATEGY ................................................................40
FIGURA 17. CUADRANTE GARTNER 2015 ..............................................................................41
FIGURA 18. PROCESO ETL ...................................................................................................42
FIGURA 19. ORGANIGRAMA AZALEIA PERÚ ............................................................................51
FIGURA 20. CADENA DE VALOR AZALEIA PERÚ.......................................................................52
FIGURA 21. MACRO PROCESOS MISIONALES .........................................................................53
FIGURA 22. PEDIDO VENTA AZALEIA ......................................................................................53
FIGURA 23. PEDIDO BRASIL ..................................................................................................54
FIGURA 24. PEDIDO ASIA .....................................................................................................54
FIGURA 25. TABLERO KANBAN ..............................................................................................57
FIGURA 26. ARQUITECTURA AZALEIA PERÚ ...........................................................................61
FIGURA 27. PROTOTIPO TABLERO GERENCIAL ........................................................................69
FIGURA 28. PROTOTIPO VENTA POR MAYOR ..........................................................................70
FIGURA 29. PROTOTIPO VENTA POR TIENDA ..........................................................................71
FIGURA 30. PROTOTIPO VENTA POR CATALOGO .....................................................................72
FIGURA 31. MODELO DIMENSIONAL DATA MART .....................................................................80
FIGURA 32. MODELO DIMENSIONAL QLIKVIEW ........................................................................80
FIGURA 33. TABLERO GERENCIAL .........................................................................................82
FIGURA 34. TABLERO CANAL DE VENTAS POR TIENDA .............................................................83
FIGURA 35. TABLERO CANAL DE VENTAS POR TIENDA .............................................................84
FIGURA 36. TABLERO VENTAS POR MAYOR ............................................................................85
FIGURA 37. TABLERO DE VENTAS POR CATALOGO ..................................................................86
FIGURA 38. EVALUACIÓN CALIDAD DE INFORMACIÓN ..............................................................90
FIGURA 39. EVALUACIÓN EFICIENCIA Y EFECTIVIDAD ..............................................................90
FIGURA 40. EVALUACIÓN AUMENTO DE PRODUCTIVIDAD DE VENTAS .......................................91
FIGURA 41. CRECIMIENTO DE VENTAS ANUAL ........................................................................91
FIGURA 42. CRECIMIENTO DE PUNTOS DE VENTA ...................................................................91
7
ÍNDICE DE TABLAS
TABLA 1. ACCIONES E INDICADORES SEGÚN METODOLOGÍA ....................................................20
TABLA 2. OPERALIZACIÓN DE VARIABLES ...............................................................................43
TABLA 3.INDICADORES DE LAS VARIABLES INDEPENDIENTES ...................................................44
TABLA 4. INDICADORES DE LAS VARIABLES DEPENDIENTES .....................................................45
TABLA 5. VENTAS ANUAL AZALEIA PERÚ ................................................................................49
TABLA 6. SPRINT BACKLOG ..................................................................................................59
TABLA 7. INDICADOR TOTAL DE VENTAS NETAS ......................................................................62
TABLA 8.INDICADOR COSTO PROMEDIO .................................................................................63
TABLA 9. INDICADOR DESCUENTO .........................................................................................64
TABLA 10. INDICADOR ÍNDICE DE ROTACIÓN ...........................................................................64
TABLA 11. INDICADOR METAS POR COBRANZA .......................................................................65
TABLA 12. CONTROL DE ACCESO A USUARIOS .......................................................................66
TABLA 13. DIMENSIONES DEL TIEMPO Y LUGAR ......................................................................66
TABLA 14. VISUALIZACIÓN DE ANÁLISIS DE LAS VENTAS ..........................................................67
TABLA 15. INDICADORES DE VENTAS .....................................................................................67
TABLA 16. VISUALIZACIÓN POR CATEGORÍAS .........................................................................68
TABLA 17. FUENTE DE DATOS TRANSACCIONALES_AZALEIA ....................................................78
TABLA 18.DIMENSIONES Y MÉTRICAS ....................................................................................79
8
Resumen
El principal objetivo de este trabajo, ha sido la implementación de un Datamart enfocado
para el área comercial – Ventas de la empresa Azaleia del Perú, que permita apoyar la
toma de decisiones y crecimiento de ventas en el mercado bajo los lineamientos
estratégicos de la empresa.
La implementación parte desde el análisis realizado al proceso del área de ventas de la
empresa Azaleia del Perú, dónde se pudo evidenciar varios puntos importantes de los
cuales resaltan tres. Como primer punto, el manejo de diferentes sistemas que contienen
información del área, genera para el usuario carga operativa en la obtención y
consolidación de esta. Como segundo punto, se encuentra la dependencia generada con el
área de sistemas, debido al mantenimiento que realizan en la estructura de la base de
datos para poder obtener la información solicitada por los diferentes usuarios generando
un cuello de botella lo cual impacta en tiempo de respuesta en las ventas. Y como tercer
punto, la integridad en la información como soporte a la toma de decisiones de la gerencia
general.
Como resultado de la investigación se tendrá el diagnóstico y solución a implementar en la
empresa Azaleia del Perú, la cual se enfoca en dos puntos relevantes: mejora en la
obtención de la información por parte de los usuarios, reduciendo la carga operativa y
dependencia al área de tecnología de información y un mejor monitoreo de los indicadores,
que permita a la gerencia general identificar patrones en el comportamiento de las ventas,
permitiendo obtener respuestas más acertadas basado en la demanda del mercado, para
la toma de decisiones.
Palabras clave: inteligencia de negocios, metodología ágil, data marts, scrum, olap,
dashboard.
9
Abstract
The main objective of this work has been the implementation of a Datamart focused to the
commercial area of the company Azaleia of Peru, which allows support decision making
and sales growth in the market under the strategic guidelines of the company.
The implementation part from the analysis process the business area of the company
Azaleia of Peru, where it was evident several important points, which stand 3. As a first
point, handling different information systems containing commercial area generated for the
user an operational burden in obtaining and consolidating this. As according point is, the
dependence generated by the systems area due to maintenance performed on the
structure of the database to obtain the information requested by different users creating a
bottleneck, which affects the time response to decision making in sales. Moreover, the third
point, the integrity of the information to support the decision of the general management.
Because of research the diagnosis and solution to be implemented in the company Azaleia
of Peru, which focuses on two important points, shall be improvement in obtaining
information from users, reducing dependence on technology area information and improved
decision -making, allowing the general management have more right answers depending
on market demand.
Key words: Business Intelligence, agile methodology, data marts, scrum, olap, dashboard.
10
Capítulo 1: Introducción
1.1. Problema de Investigación
1.1.1. Planteamiento del problema.
Según Ponjuán Dante, Gloria. Gestión de la información en las organizaciones:
Principios, conceptos y aplicaciones. (1998). Se evidencia que algunas
organizaciones carecen de conocimiento y tecnológicas que ayuden a absorber la
superabundancia de información contenida en la ingente cantidad de datos 1que
disponen y que son generadoras de conocimiento para la toma de decisiones.
Según Peña (2006). En la actualidad las organizaciones tienen la posibilidad de
recopilar y almacenar grandes volúmenes de información con datos operativos y de
clientes, el reto es como emplearla para que la información fluya en el momento
preciso, a cada uno de los niveles que constituyen la organización, ampliando la
visión estratégica, reduciendo los riesgos e incertidumbre y dando un mejor soporte
en el proceso para la toma de decisiones.
En ese sentido, Peña (2003) señala que la inteligencia de negocios es más que una
actitud empresarial o una tecnología, es un marco de referencia para la gestión del
rendimiento empresarial que ayuda a los gerentes a tomar mejores decisiones en los
niveles estratégicos y operativos.
Según la Consultora Gartner2 (2014), más del 60% de los compradores de
herramientas de inteligencia de negocios no son necesariamente profesionales del
área de sistemas, sin embargo buscan herramientas que les permita obtener y
1 Representación simbólica de un atributo o variable cuantitativa
2 Empresa consultora y de investigación de las tecnologías de información
11
visualizar mejor la información siendo lo más solicitado los tableros de control 3para el
análisis (véase Gráfico N° 01)
Figura 1 Uso de herramientas BI
Fuente: Adaptado de Gartnet, 2014.
La empresa Azaleia Perú, cuenta con más de 20 años en el mercado
comercializando calzados, sin embargo presenta sistemas poco integrados que son
manejados por aplicaciones independientes las cuales están alimentadas por
diferentes fuentes de información, no permitiendo tener la capacidad para monitorear,
entender y administrar de manera eficiente el comportamiento de los sus indicadores
de ventas, limitando a la empresa a tomar decisiones importantes sin tener todos los
elementos imprescindibles a la mano.
Además existe una carencia en la optimización para el análisis de la información y
la toma de decisiones de manera proactiva debido a la falta en la centralización de los
datos que permitan a los usuarios obtener información de forma fluida sin necesidad
de invertir mucho tiempo en la elaboración de estos.
3 Herramienta de diagnóstico y control permanente de indicadores
12
La poca visibilidad, la carencia de análisis y la falta de gestión en la información del
área de ventas, convierte a la empresa Azaleia Perú, en un tomador de decisiones
reactivo y no proactivo, debido a que no lleva un control de los problemas que
normalmente aborda el área comercial como: posibilidad de segmentar correctamente
a los clientes, saber por qué los clientes dejan de comprar, saber que marca es la más
vendida, cuales son los clientes más rentables y pérdida de oportunidades por falta de
control.
1.2. Formulación del problema
¿Cuál es el efecto que se obtendrá con la implementación de una plataforma de
inteligencia de negocios para el área de ventas de la empresa Azaleia Perú que se
encuentra focalizada en el crecimiento de sus puntos de venta y que maneja grandes
volúmenes de información?
1.2.1. Justificación de la investigación
El comportamiento de las importaciones de calzados en el Perú para el año 2014
y 2015 representó una variación de crecimiento de 73% en el caso de China y 7% para
Brasil. Posicionándose estos dos países como líderes en el sector de calzados
peruano.
La tecnología en el mercado Peruano, viene creciendo constantemente en las
empresas, las cuales usan de soporte para los objetivos estratégicos, destinando parte
del presupuesto anual, en inversión de herramientas que apoyen en el negocio a la
toma de decisiones.
El mercado de calzados en el Perú se caracteriza por ser bastante competitivo,
debido a la incursión de varias marcas tanto nacionales como internacionales, razón
13
por la cual se han visto en la necesidad de administrar de manera eficiente la
información, a efecto de mantener su posicionamiento en el mercado con estrategias y
tecnologías que sirvan de apoyo para obtener mayores beneficios económicos.
La empresa Azaleia Perú, en los últimos 3 años se ha expandido de manera
agresiva en el mercado Peruano, posicionándose como una de las marcas líderes de
calzados, teniendo un crecimiento del 10% anual a través de sus tiendas propias,
ventas por catálogo, ventas por internet y su canal de mayorista. Este último es el que
concentra la mayor parte de los ingresos (50%) de la empresa, Azaleia Perú. (2014).
Reporte de crecimiento por canal.
Tomando en consideración las premisas expuestas, la presente investigación se
focaliza en la implementación de una plataforma de inteligencia de negocios para el
área comercial, con alcance en las ventas de la empresa Azaleia Perú, que le permita
apoyar en la toma de decisiones de manera proactiva, para que se mantenga
competitivamente en el mercado.
Se pretende mediante la implementación, brindar al usuario una plataforma que
tenga acceso a un solo repositorio de datos centralizado y tableros de control con el fin
de optimizar, analizar, compartir y monitorear la información en línea y a nivel de
detalle, identificando de manera proactiva el comportamiento de las ventas mediante
visualizaciones gráficas que sean de apoyo en las funciones operativas para
anticiparse ante cambios y sucesos producidos por la demanda del mercado.
14
1.3. Marco referencial
1.3.1. Antecedentes
La inteligencia de negocios data desde los años 60, en donde se establecieron los
primeros sistemas de información.
En la década de los 70 aparecieron las primeras bases de datos 4como las primeras
aplicaciones empresariales. Estas estaban enfocadas en la introducción de los datos
para un mayor control de estos.
Hoy en día las empresas han visto la necesidad de implementar la inteligencia de
negocios a nivel corporativo o por áreas funcionales con el fin de mejorar el análisis de
la información para obtener ventajas competitivas en el mercado y anticiparse ante los
cambios de la demanda, teniendo un mejor control y seguimiento de los indicadores y
haciendo de estos la mejor arma para identificar anomalías en el negocio.
En base a estas premisas se viene realizando investigaciones en torno a la
inteligencia de negocios tal es el caso de:
Rafael Matamoros Zapata. (2010). En la Investigación titulada. “Implantación en
una empresa de un sistema Business Intelligence SaaS / On Demand a través de la
plataforma LITEBI5”, caracterizó técnicas de una adecuada gestión de soporte y
análisis de datos a una determinada empresa. Para alcanzar tales fines, propuso
realizar el análisis, diseño e implementación de una solución de BI sobre la plataforma
Business Intelligence SaaS6 / On Demand LITEBI. Asimismo, dicho estudio realizó el
análisis de las diferentes técnicas, herramientas y conceptos sobre el Business
4 Conjunto de datos pertenecientes a un mismo contexto almacenados sistemáticamente para su
posterior uso. 5 Empresa española dedicada a desarrollo y distribución de plataformas de inteligencia de negocio.
6 Software como servicio
15
Intelligence para su posterior aplicación en el planteamiento y diseño de una solución
tecnológica.
La investigación hace denotar que el autor realizó un estudio de la plataforma de
Business Intelligence SaaS / On Demand Litebi a partir de la realización de otros
pequeños proyectos, ya que no existía en su día documentación asociada a la
plataforma ni manual de usuario, al tratarse de una aplicación en desarrollo constante
y con poco tiempo en el mercado. Debido a esto, se planteó estudiar la aplicación de
forma práctica y adjuntar en este proyecto la documentación pertinente con sus
principales características. También hizo un desarrollo de una solución de Business
Intelligence destinada a cubrir las necesidades demandadas por el cliente,
implementando, a partir de una arquitectura previamente diseñada, los procesos,
extracción, transformación y limpieza que alimenten de forma actualizada la
información contenida en el Data Warehouse7, así como el diseño de una capa de
metadatos8 capaz de albergar las estructuras que permitan la comunicación entre el
usuario y la información necesaria con el fin de poder analizarla de forma rápida y
sencilla.
Como resultado de la investigación, la implantación de la solución se hizo efectiva
cubriendo todas las necesidades de información demandadas por el cliente tales
como: mantener actualizada la información a diario de la empresa y la presentación de
sus resultados. En este último punto, el autor procedió analizar aquellos informes que
la empresa estaba realizando anteriormente a la implantación de la solución de
Business Intelligence BI, encontrando brechas de información en los indicadores de
gestión de la empresa.
7 Almacén de datos organizacional, integrado, no volátil y variable en el tiempo de apoyo a la toma
de decisiones 8 Datos que describen otros datos
16
Como conclusión, se determinó que gracias a esta solución se eliminó
completamente la dependencia de los anteriores sistemas heterogéneos de reporte,
integrando toda la información de los análisis de los laboratorios de la organización en
un único lugar de una manera rápida, sencilla y fiable. Además cabe destacar en la
investigación la escalabilidad de la solución, que permitirá en un futuro de una forma
sencilla, desplegar el uso del sistema a otros departamentos, si se diera el caso, así
como a otras áreas de la empresa (finanzas, producción, administración, etc.).
Otro de los estudios que podemos mencionar es de Jonathan Narvaez y Otros
(2013) titulado “Business intelligence solution for managing educational resources and
physical spaces in Magdalena University”, la cual caracteriza una solución de
inteligencia de negocios para la gestión de recursos educativos y espacios físicos en la
Universidad del Magdalena de Colombia. Con esta solución se pueden obtener
informes históricos y actuales de los procesos, gestionar el rendimiento, tomar
decisiones de compra, prever la ocupación y mejorar la disponibilidad de los recursos,
etc. Para el desarrollo e implementación de la solución, se usó la plataforma Business
Intelligence, de Microsoft SQL Server 92008 R2.
Para ello y en procura de aumentar el rendimiento de las consultas, facilitar el auto
suministro de datos y permitir monitorear el rendimiento de los procesos en base a
indicadores, la solución de inteligencia de negocios desarrollada por Narvaez & Otros,
incluye los Cubos OLAP10 e Indicadores de Rendimiento.
Como resultado de la investigación, se determinó que los avances en tecnologías
de información y la reducción de sus costos, hacen posible que las soluciones de
inteligencia de negocios, que solían ser exclusividad de las grandes compañías, sean
9 Sistema de manejo de base de datos
10 On-Line Analytical Processing
17
utilizadas por pequeñas empresas. No obstante a la creciente crítica de las soluciones
de Inteligencia de negocios Stand – Alone dentro de la comunidad de académicos, ha
permitido que este tipo de solución se oriente también a unidades funcionales
específicos dentro de una organización a efectos de disponer sus beneficios
inmediatos, sin esperar una inversión empresarial que pueda nunca llegar.
1.3.2. Marco teórico
1.3.2.1. Plataforma de Inteligencia de Negocios
La mayor parte de las empresas existentes generan, almacenan y
modifican una enorme cantidad de datos de cualquier actividad que se registre en la
empresa a través de aplicaciones de gestión de datos, cada vez más complicadas de
utilizar y más obsoletas. A causa de esta necesidad, sobre los años 80 comenzaron
aparecer sistemas que ofrecían soluciones de apoyo para la toma de decisiones que
actualmente se conoce como el término Business Intelligence, acuñado por Howard
Dresner del grupo Gartner en 1989. Este término pretende ser la base para reunir todo
tipo de tecnologías capaces de extraer los datos corporativos almacenados por los
diferentes sistemas de gestión y tratarlos de manera que, al presentarlos a cualquier
persona o usuario, pueda obtener un conocimiento intelectual para así llevar a cabo
las tareas necesarias de la consecución exitosa de las metas propuestas en su
negocio.
El enfoque metodológico de Business Intelligence es también conocido
como modelo de inteligencia de negocio, el cual tiene diferentes niveles en cuanto al
tipo y tratamiento de información. Está basado en tres acciones: Procesos/actividades,
Gestión y Estrategia, cada una de ellas asociada al Cuadro de Mando Operativo,
Cuadro de Mando de Gestión y Cuadro de Mando Integral (véase Figura N° 2):
18
Figura 2 Niveles de análisis de inteligencia de negocio
Fuente: Elaboración propia
El objetivo básico es apoyar de forma sostenible y continuada a las
organizaciones para mejorar su competitividad, facilitando la información necesaria
para la toma de decisiones. El primero que acuñó el término fue Howard Dresner
que, cuando era consultor de Gartner, popularizó la inteligencia de negocio (Business
Intelligence o BI) como un término paraguas para describir un conjunto de conceptos
y métodos que mejoraran la toma de decisiones, utilizando información sobre qué
había sucedido (hechos).
Para definir la inteligencia de negocio utilizamos la definición de Gartner11:
“BI es un proceso interactivo para explorar y analizar información estructurada
sobre un área (normalmente almacenada en un Data Warehouse), para descubrir
tendencias o patrones, a partir de los cuales derivar ideas y extraer conclusiones”.
Por ejemplo:
11
Gartner es una consultora internacional especializada en Tecnologías de Información y Comunicación. www.gartner.com
19
- Proceso interactivo: al hablar de inteligencia de negocio estamos suponiendo
que se trata de un análisis de información continuado en el tiempo.
- Explorar: En todo proyecto de inteligencia de negocio hay un momento inicial
en el que por primera vez accedemos a información que nos facilita su
interpretación. En esta primera fase lo que hacemos es “explorar” para
comprender qué sucede en nuestro negocio.
- Analizar: Pretendemos descubrir relaciones entre variables, tendencias, es
decir, cuál puede ser la evolución de la variable, o patrones.
- Información estructurada y Data Warehouse: La información que utilizamos en
inteligencia de negocio está almacenada en tablas relacionadas entre ellas. Las
tablas tienen registros y cada uno de los registros tiene distintos valores para
cada uno de los atributos. Estas tablas están almacenadas en lo que
conocemos como Data Warehouse, datamart12 o almacén de datos.
- Área de análisis: Todo proyecto de inteligencia de negocio debe tener un objeto
de análisis concreto.
- Comunicar los resultados y efectuar los cambios: Un objetivo fundamental de la
inteligencia de negocio es que, una vez descubierto algo, sea comunicado a
aquellas personas que tengan que realizar los cambios pertinentes en la
organización para mejorar nuestra competitividad.
12
Subconjunto de datos que apoyo a un área específica dentro de una organización.
20
Tabla 1. Acciones e indicadores según metodología
¿Qué es y para qué sirve? ¿Qué tipo de indicadores son?
Modelo orientado a la implantación y gestión de la estrategia de la organización
Indicadores orientados al seguimiento de los objetivos estratégicos de las unidades estratégicas de la empresa.
ES
TR
AT
EG
IA
Objetivos estratégicos
No solamente son financieros sino, balanceados en la perspectiva del cliente, procesos internos, personas, etc.
Iniciativa orientadas al cumplimiento de los objetivos
Indicadores de gestión y desempeño
Indicadores clave y metas que definen el grado de cumplimiento
Actualizado de forma mensual
Modelo orientado al análisis de la gestión del negocio
Mayor número de indicadores que pueden ser analizados
GE
ST
IÓN
La información puede ser analizada a un nivel agregado o desglosado de detalle deseado
Fundamentalmente indicadores de resultados y estructurados
Se caracteriza por la flexibilidad para realizar una amplia variedad de análisis por tipo de usuario
Actualizado de forma mensual
Unifica en una misma aplicación la información de diferentes sistemas fuentes
Sistema y control orientado a la gestión operativa y de procesos específicos claves
Refleja el nivel de actividad
PR
OC
ES
OS
Y
AC
TIV
IDA
DE
S
Diseñado e implementado para determinadas unidades o áreas de la organización
Indicadores de resultados, actualizado diariamente
Fuente: Adaptado de Navarro, 2013.
1.3.2.2. Beneficios
Uno de los objetivos básicos de los sistemas de información es que nos
ayuden a la toma de decisiones. Sin embargo, aunque todos la utilicen, no todos los
responsables recogen la misma información. Depende de muchos factores, como
pueden ser su experiencia, formación, disponibilidad, etc. Acuñado por Braulio Arturo
Macedo, 2012
21
Del mismo modo, el autor menciona que los responsables pueden necesitar
recoger más o menos información dependiendo de su mayor o menor aversión al
riesgo. A partir de los datos que nos proporciona el sistema de inteligencia de
negocio podemos descubrir conocimiento. Como hemos visto, la inteligencia de
negocio nos servirá como ayuda para la toma de decisiones y, posteriormente, para
descubrir cosas que hasta ahora desconocíamos.
Los beneficios que se pueden obtener a través del uso de la inteligencia de
negocio pueden ser de distintos tipos:
- Beneficios tangibles, como por ejemplo: reducción de costes, generación de
ingresos o reducción de tiempos para las distintas actividades del negocio.
- Beneficios intangibles: el hecho de que tengamos disponible la información para la
toma de decisiones hará que más usuarios utilicen dicha información y por ende
mejoren la posición competitiva.
- Beneficios estratégicos: Todos aquellos que nos facilitan la formulación de la
estrategia, es decir, a qué clientes, mercados o con qué productos dirigirnos.
1.3.2.3. Componentes de la inteligencia de negocio
Según Roberto Espinoza (2010). En un proyecto real debemos definir
primero cuáles son los objetivos y el alcance de la solución, qué modelos de negocio
queremos analizar. Con esta información es mucho más fácil tomar las decisiones
necesarias en cada uno de los componentes.
Estos componentes los podemos ver visualmente en la siguiente (véase figura N° 3):
22
Figura 3. Modelo integral solución BI
Fuente: Adaptado de Navarro, 2013.
Los componentes son:
- Fuentes de información, de las cuales partiremos para alimentar de contenidos el
Data Warehouse.
- Proceso ETL13 de extracción, transformación y carga de los datos en el Data
Warehouse. Antes de almacenar los datos en un Data Warehouse, éstos deben
ser transformados, limpiados, filtrados y redefinidos.
- El motor OLAP14 , que nos debe proveer capacidad de cálculo, consultas,
funciones de planeamiento, pronóstico y análisis de escenarios en grandes
volúmenes de datos.
- Las herramientas de visualización, que nos permitirán el análisis y la navegación a
través de los mismos.
13
ETL corresponde a las siglas del inglés Extract, Transform and Load (Extracción, transformación y carga)
14 OLAP corresponde a las siglas de inglés Online Analytical Processing.
23
Figura 4. Componentes de la inteligencia de negocio Fuente: Navarro, 2013.
1.3.2.4. Repositorio de información
Vamos analizar las distintas fuentes de información con las que podemos
alimentar un Data Warehouse o un Datamart.
Las fuentes de información a las que podemos acceder son:
- Básicamente, de los sistemas operacionales o transaccionales, que
incluyen aplicaciones desarrolladas a medida, ERP, CRM, SCM, etc.
- Sistemas de información departamentales: previsiones, presupuestos,
hojas de cálculo, etc.
- Fuentes de información externa, en algunos casos comprada a terceros,
como por ejemplo estudios de mercado. (Navarro, 2013).
Figura 5. Esquema transaccional ERP
Fuente: Navarro, 2013
24
Existen muchos factores que contribuyen a la complejidad de cargar la
información en un Data Warehouse. Uno de los principales es el número de
diferentes fuentes de información que es cargado a un repositorio centralizado
(Navarro, 2013).
Según Bernabeu, R., (2007). El Data Warehouse, posibilita la extracción de
datos de sistemas operacionales y fuentes externas, permitiendo la integración y
homogenización de los datos de toda empresa.
Acceder a distintas bases de datos requiere distintas habilidades y el
conocimiento de distintas sintaxis de SQL15. Si el número de bases de datos a las
que debemos acceder es elevado, puede provocar que tanto las definiciones como
las codificaciones en los distintos entornos sean diferentes, lo que añadirá dificultad a
nuestro proyecto.
La información que cargamos en un Data Warehouse o Data mart
normalmente es estructurada, es decir, aquella que se puede almacenar en tablas:
en la mayoría de los casos es información numérica. Tendremos que analizar si la
información que disponemos es la que necesitamos para alimentar los modelos de
negocio que hemos definido anteriormente. Una vez decididas las fuentes de
información debemos verificar la calidad de los datos. (Navarro, 2013).
1.3.2.5. Metodología de Inteligencia de Negocios
Existen diversas metodologías para el desarrollo de un proyecto
de inteligencia de negocios, lo mejor es evaluar la que más se ajusta a cada proyecto
y para cada organización.
15
Por sus siglas, Structured Query Language, en español lenguaje de consulta estructurada
25
Según los especialistas L.T. Moss, las metodologías de BI deben
de cumplir con las siguientes carteristas:
1. Debe orientarse al cambio y no a conseguir un producto final
2. El proyecto debe ser gestionado en forma global y
transversal a toda la empresa
3. Debe tener la posibilidad de manejar múltiples proyectos.
4. Debe considerar todas las tareas y procesos de la empresa,
seas o no críticos
5. Se debe de basar en la gestión de cambios críticos del
workflow empresarial.
6. Debe orientarse a las personas y a las relaciones entre ellas.
7. Debe alinearse con la necesidad de negocio de la
organización.
1.3.2.5.1. Metodología Ralph Kimball
El enfoque de Ralph kimball hace referencia al Bottom –up.
El cual indica que la forma más flexible y sencilla de trabajar un Data Warehouse es
armando primero los Data marts como primer elemento del sistema de análisis y
luego ir añadiendo otros Data marts que compartan las dimensiones ya definida o
añadan nuevas.
Esta metodología incluye cuatro fases: Selección del proceso de negocio, definición
de la granularidad de la información, elección de las dimensiones de análisis e
identificación de los hechos y métricas y dimensiones lentamente cambiantes
(SCD).
26
Figura 6. The Kimball Data Lifecycle
Fuente: Ian Abramson, 2010
1.3.2.5.2. Metodología Bill Inmon
El enfoque de Bill Inmon hace referencia al Top –down. El
cual indica que la forma de construir un Data Warehouse es teniendo el enfoque
global “todo” para luego manejar el detalle. El Data Warehouse no está modelado
dimensionalmente sino en tercera forma normal.
Una vez generado el Data warehouse, se puede proceder
a crear los data marts para las áreas de negocio que se necesite.
Figura 7. The Inmon Warehouse
Fuente: Ian Abramson, 2010
27
1.3.2.5.3. Metodología Hefestos
HEFESTOS, es una metodología propia que permite la
construcción de un Data warehouse de forma sencilla, ordenada e intuitiva.
Es una investigación basada en metodologías existentes,
experiencias propias de confección de almacén de datos. Busca entregar una
primera implementación que satisfaga una parte de la necesidad, con el objetivo de
mostrar las ventajas y beneficios del Data Warehouse.
Está dividido en 5 fases, que muestra en como los datos
serán transformados, para posteriormente ser explotados para la toma de decisiones.
Figura 8. Fases de la metodología Hefesto
Fuente: Dario, 2013
1.3.2.5.4. Metodología Ágil
Según Scientia et Technica Año 384 XIII. (2007). “Principios de las
metodologías ágiles”. Se basa en garantizar una mayor productividad e interrelación
con el equipo, que permita mayor dinamismo y adaptación al cambio, con el objetivo
de entregar un producto de acuerdo a las expectativas y exigencias del cliente.
- Individuos e interacciones sobre procesos y herramientas.
- Software funcionando sobre documentación extensiva.
- Colaboración con el cliente sobre negociación contractual.
28
- Respuesta ante el cambio sobre seguir un plan.
En estos 4 valores se resumen los 12 principios del manifiesto ágil.
La intención es detallar las partes más prioritarias sobre las que son menos
prioritarias cuando tratamos con un proyecto ágil16. Hay que proporcionar una
motivación en los individuos y confiarles la ejecución del proyecto. Aunque se utilicen
herramientas para la gestión del proyecto, el método más efectivo y eficiente de
comunicación es cara a cara.
En las metodologías ágiles podemos encontrar una serie de prácticas
o técnicas habituales a la hora de afrontar la ejecución de un proyecto. Por ejemplo,
a la hora de hacer reuniones tienen que ser rápidas y frecuentes, lo suficientemente
rápidas (ágiles) como para no perder el tiempo pero con una frecuencia suficiente
para que los integrantes del equipo estén informados de todo. Suelen ser reuniones
diarias. Cuando se trata de una reunión de planificación de iteración en la que hay
una parte del producto para entregar se re-planifica la siguiente iteración a partir del
feedback obtenido del cliente. El intervalo de tiempo entre entregas se denomina
iteración. Como se puede deducir en este tipo de reuniones participa el cliente, al
que se considera uno más del equipo.
1.3.2.5.5. Scrum
Scrum parte de la esencia del desarrollo ágil. Se centra en las
funcionalidades con más prioridad y que pueden ser ejecutadas en un periodo corto
de tiempo. Los ciclos de desarrollo, llamados sprints, producen un incremento de
funcionalidad terminado y operativo.
16
Manifesto for Agile Software Development. http://agilemanifesto.org/
29
En Scrum la evolución de una iteración se revisa con reuniones de
seguimiento diarias, en las que se reúne todo el equipo de desarrollo, comenta el
trabajo que ha terminado, el trabajo que tiene por terminar y los impedimentos que
hayan podido surgir.
Scrum toma la inestabilidad como premisa. No se considera que la
definición detallada del producto, ni la arquitectura software tengan que estar en una
primera fase del proyecto. Como metodología ágil que es, no será un desarrollo por
fases.
Es decir, en cada iteración se van añadiendo las nuevas funcionalidades y
se hace necesario modificar la estructura de las funcionalidades implementadas para
adoptar las nuevas sin modificar el resultado que ya teníamos. Mientras que en una
metodología predictiva la responsabilidad de las circunstancias no planificadas las
tendrá el gestor de proyectos, en Scrum se parte de equipos auto-organizados con
suficiente margen para tomar las decisiones oportunas.
Figura 9. Scrum Framework
Fuente: Scrum.Org, 2014
30
1.3.2.6. Repositorio Data Mart
Un Data Mart es una aplicación de un Data Warehouse construida
rápidamente para soportar una línea de negocio simple. Los Data Marts, tienen las
mismas características de integración, no volatilidad y orientación temática que el
DW. Representan una estrategia de “divide y vencerás” para ámbitos muy genéricos
de un Data Warehouse. (Vitt, 2013).
Esta estrategia es particularmente apropiada cuando el DW central crece
muy rápido y los distintos departamentos requieren sólo una pequeña porción de los
datos contenidos en él. (Inmon, 2012)
La creación de los Data Mart requiere de algo más que una simple réplica
de datos: se necesitarán tanto la segmentación como algunos métodos adicionales
de consolidación.
Dado que un Data Mart soporta menos usuarios que un Data Warehouse
se puede optimizar para recuperar más rápidamente los datos que necesitan los
usuarios. La arquitectura de un Data Mart es aconsejable porque:
- Menores cantidades de datos implican que se procesan, tanto las cargas de datos
como las consultas.
- Las peticiones pueden acotarse al área o red que sirve esos datos, sin afectar al
resto de los usuarios.
- La aplicación cliente, que pide la consulta es independiente del servidor que la
procesa y del servidor de bases de datos que almacenan la información. (Vitt,
2013).
31
El uso efectivo de los Data Marts en un ambiente de Data Warehousing, es
un factor importante para la efectividad del Warehouse, y puede también ser
determinante en el éxito del proyecto de desarrollo. Los Data Marts son diseñados
para satisfacer las necesidades específicas de grupos comunes de usuarios
(divisiones geográficas, divisiones organizacionales, etc.). Los Data Marts son
generalmente, subconjuntos del Data Warehouse, pero pueden también integrar un
número de fuentes heterogéneas, e inclusive ser más grandes, en volumen de datos,
que el propio Warehouse central. Como los Data Marts son un factor crítico para el
éxito proyecto de Data Warehousing de mayor escala, también lo son su creación y
mantenimiento. (Vitt, 2013).
Actualmente, las organizaciones se están convenciendo de que los Data
Warehouse corporativos, son complejos tanto para construir como para usar.
Implementar un Data Warehouse, requiere de un considerable equipo de
desarrolladores, hardware, software, tiempo y dinero. Las necesidades de diferentes
áreas de la empresa, a veces conflictivas, deben ser sobrellevadas en su conjunto.
Los usuarios los encuentran difíciles de construir, y por lo tanto de navegar. En
consecuencia, las empresas están construyendo Data Marts, en lugar de los Data
Warehouse. (Inmon, 2012).
1.3.2.7. Crecimiento de los Data Marts
Existe un número de sólidas razones detrás del aumento en popularidad
de los Data Marts, en comparación con los sistemas de Data Warehouse a nivel de
empresa.
Los Data Marts han reducido drásticamente el costo implícito en la
creación y operación de un sistema de soporte a las decisiones. El concepto del Data
32
Mart ha logrado situar la instalación de la tecnología de soporte a las decisiones
dentro del rango de posibilidades económicas de un número mucho mayor de
usuarios. Mientras que los presupuestos de instalación de Data Warehouse
típicamente oscilan entre los $2-5 millones de dólares, los Data Marts típicamente
cuestan entre $100.000 y 1 millón de dólares al presupuesto total del proyecto. (Vitt,
2013).
Los Data Marts son los preferidos por los departamentos autónomos y las
pequeñas unidades comerciales que los emplean para crear sus propios sistemas de
soporte a decisiones. Pero los Data Marts también se han convertido en los favoritos
de la mayoría de los departamentos de Sistemas de Información (IS), para crear
grandes almacenes centrales de datos. La idea consiste en crear un Data
Warehouse paso a paso, añadiendo un Data Mart o área de estudio a la vez,
adquiriendo gradualmente la experiencia y el soporte de administradores comerciales
clave, quienes ven beneficios concretos cada 3-6 meses. (Vitt, 2013).
Con los Data Marts, resulta mucho más fácil identificar un cliente o
patrocinador comprometido dentro de una organización. En comparación con los
Data Warehouse, los Data Marts son más limitados en cuanto a alcance, y se
concentran más en un grupo específico de necesidades del usuario. La clave aquí
radica en concentrarse en un reto y enfrentarlo con un grupo específicamente
dedicado a esa tarea.
Los Data Marts permiten una prototificación más rápida para la captura de
los requisitos del sistema de soporte a decisiones. Las encuestas realizadas entre los
consumidores indican que los pilotos de los Data Marts se montan en 30-120 días.
33
La completa instalación del sistema se logra en un período que oscila de 3 a 6
meses. (Vitt, 2013).
En conclusión los Data Marts son:
- Más pequeños con tiempo de respuesta más rápido.
- Acceso menos complejo para los usuarios a los Data Marts.
- Data Marts diseñados para grupos de usuarios específicos.
1.3.2.8. Data Marts Virtuales y Meta Vistas
Los vendedores están desarrollando el concepto de Data Marts Virtuales
para satisfacer la necesidad de los usuarios de acceder a muchos Data Marts, sin
necesidad de excesivas replicaciones entre ellos. Los Datamarts Virtuales son vistas
de varios Data Marts Físicos, o del Data Warehouse corporativo, brindadas a grupos
específicos de usuarios. (Inmon, 2012)
Una Meta Vista es una representación gráfica de una base de datos que
incluye tablas, columnas y joins17. Una vez que una Vista Básica es creada, múltiples
Meta Vistas se pueden derivar de ella. Una Meta Vista es una representación lógica
de partes, de una o más Vistas Básicas. Inicialmente las tablas son desplegadas
como categorías, y los campos como partes. Se pueden renombrar o remover
categorías o partes de una Meta Vista. (Vitt, 2013).
Esos cambios no afectan a las Vistas Básicas que la soportan. La Meta
Vistas permite usar una única Vista Básica para presentar diferentes partes de la
información a diferentes grupos de usuarios. (Vitt, 2013).
17
Sentencia SQL, que permite combinar registros de dos o más tablas en una base de datos relacional
34
1.3.2.9. Administración de los Data Marts
Dentro de una empresa se hace latente la administración y coordinación a
medida que el número de Data Marts crece. Se hace necesario asegurar
consistencia e integridad de datos, controlar la seguridad y mantener el rendimiento
(performance) global.
La administración de estos tiene recientes requerimientos como
coordinación, extracción de datos, lectura, procedimientos de replicación,
procedimientos de respaldo, manejo de metadatos y performance18. (Inmon, 2012)
La administración de los Data Marts, pasa a convertirse en un
rompecabezas donde la gestión para obtener la información se ha complicado. No
obstante, lo que ha fallado no es la integración de Data Marts, sino su forma de
integración como se muestra (véase figura N° 6):
Figura 10. Integración de Data Marts Fuente: Vitt, 2013.
18
Desempeño con respecto al rendimiento del hardware
35
El enfoque más adecuado sería la coordinación de la gestión de
información de todos los Data Marts en una Data Warehouse centralizado
(corporativo) como se muestra en la siguiente figura:
Figura 11. Data Warehouse centralizado
Fuente: Vitt, 2013.
1.3.2.10. Paquetes Data Marts
Muchos vendedores han reconocido la necesidad de hacer que los Data
Marts sean más fáciles de instalar e implementar que un Data Warehouse
corporativo. Los paquetes de Data Marts pueden proveer herramientas convenientes,
y de relativamente bajo costo, que pueden ser el puntapié inicial para el desarrollo de
los Data Marts. Aunque un Data Mart es relativamente fácil de instalar, hay que tener
en cuenta otros aspectos como la lógica de los datos operacionales extraídos, la
consistencia en la definición de los datos, y el diseño del Data Mart, para lograr un
óptimo performance (rendimiento). (Inmon, 2012)
36
1.3.2.11. Cubo Olap de estructura dimensional
Estas herramientas manejan una serie de consultas de forma interactiva
sobre estructuras multidimensionales19 (Cubos OLAP) cargadas previamente con los
datos almacenados en las bases de datos corporativas tradicionales. Permiten
realizar informes y obtener grandes cantidades de información a partir de lo que
resultaría ser a modo rutinario una serie de complejas consultas sobre una base de
datos de forma sencilla. Con estos sistemas es posible analizar la información
almacenada en un Data Warehouse, pero no es estrictamente necesario, ya que la
información puede provenir de diferentes bases de datos. El objetivo de estas
herramientas es obtener una mejor comprensión de lo almacenado en las bases de
datos. (Navarro, 2013)
Figura 12. Esquema OLAP Fuente: Tomado de Oyarce, 2012
19
Usado principalmente para crear aplicaciones OLAP, almacena registros dimensionales y métricas para el estudio o análisis.
37
Existe una categorización para estas herramientas según su arquitectura:
M-OLAP (Multidimensional OLAP): Sistema OLAP que posee los datos almacenados
en una base de datos multidimensional. Esta implementación mejora los tiempos de
acceso a los datos ya que están pre calculados a costa de necesitar mayor espacio
de almacenamiento, aunque algunos sistemas utilizan la compresión. Es un sistema
OLAP compuesto por Cubos. (Navarro, 2013)
Figura 13. Esquema M-OLAP
Fuente: Tomado de Sinnexus, 2007
R-OLAP (Relational OLAP): Sistema OLAP que mantiene los datos
almacenados en una base de datos relacional. Para esta implementación se realiza
un Cubo virtual o tablas en forma de estrella20 con lo que se consigue una mayor
capacidad de almacenamiento sacrificando tiempo de respuesta. (Navarro, 2013)
20
Modelo dimensional que contiene una tabla de métricas que contiene los datos para el análisis y
está rodeada de tablas dimensionales.
38
Figura 14. Esquema R-OLAP
Fuente: Tomado de Sinnexus, 2007
H-OLAP (Hybrid OLAP): Combinación de los dos sistemas anteriores
donde los datos se almacenan repartidos en implementaciones M-OLAP y R-OLAP.
Esta combinación permite obtener ventajas de ambas implementaciones según
donde se almacene el dato y las operaciones que se vayan a realizar sobre él.
(Navarro, 2013)
Figura 15. Esquema H-OLAP
Fuente: Tomado de Sinnexus, 2007
39
En cualquier herramienta OLAP encontramos dos tipos de variables
características, independientemente del modo en que estén almacenados los datos y
Dimensiones, estas variables nos indican los diferentes puntos de vista con los que
podemos analizar la información. Las dimensiones son usadas para seleccionar y
agregar datos a un cierto nivel deseado de detalle. (Navarro, 2013)
Las dimensiones se relacionan en jerarquías o niveles, esto es, un
conjunto de niveles cada uno expresando un nivel de profundidad en la información,
indicadores o métricas: Es el dato que está siendo analizado, aquello que es
cuantificable en lo que se desea analizar, suelen ser valores numéricos. Ejemplo:
Número de productos vendidos en el mes de Mayo.
La forma de exploración de los datos en análisis OLAP suele ser en forma
de matriz, donde sobre cada uno de los ejes se sitúa una dimensión y sobre las
celdas se sitúan las métricas, conteniendo el valor en función de las dimensiones
escogidas. (Navarro, 2013)
1.3.2.12. Tableros de control
Los cuadros de mando, es una herramienta de dirección que permite
realizar el seguimiento y monitorear los procesos operativos para detectar y
diagnosticar estados de desempeño de los indicadores. Integra la información
resaltante el cual sirve de consumo para los tomadores de decisiones.
Su estructura o desarrollo se basa en gráficas, semaforizaciones y alertas que
permitan al usuario detectar desviaciones en función a umbrales pre definidos por el
negocio.
40
Figura 16. Cuadro de mando MicroStrategy
Fuente: Tomado de MicroStrategy, 2015
1.3.2.13. Software de explotación de información
El software de inteligencia de negocio son aplicaciones diseñadas para
colaborar con la implementación de una plataforma de BI, para el proceso de análisis
y visualización de la información.
El cuadrante de Gartner, muestra un informe de las herramientas líderes
en el mercado que básicamente tiene una potente capacidad de visualización, fáciles
de usar y proporcionan auto servicio a los usuarios.
41
Figura 17. Cuadrante Gartner 2015
Fuente: Gartner, 2015
1.3.2.14. Extracción, transformación y carga (ETL)
Este proceso permite extraer los datos de diferentes fuentes de
información, procesarlos y transformarlos, de tal manera que la data procesada, esté
limpia para ser depositada a otra base de datos la cual es denominada un Data Mart
o Data Warehouse, con el objetivo de posteriormente ser analizados.
42
Figura 18. Proceso ETL
Fuente: Adaptada de dfernang, 2013
1.4. Objetivo e Hipótesis
1.4.1. Objetivo general
Implementar una plataforma de Inteligencia de negocios que permita a la empresa
Azaleia Perú, tener un repositorio de información centralizado a efectos de acceder a
los datos en línea, optimizar el tiempo en la obtención de los datos y mejorar el análisis
de la información para el área de ventas, sirviendo como soporte a la toma de
decisiones de manera oportuna a las necesidades del negocio.
1.4.2. Objetivos específicos
- Realizar un diagnóstico de la situación actual del proceso del área de venta
que permita identificar la problemática.
- Definir indicadores y métricas del área para la explotación de los datos.
- Elaborar un repositorio centralizado focalizado en un modelo dimensional que
permita la resolución de consultas analíticas.
43
- Elaborar un cubo OLAP de estructura dimensional que permita el
procesamiento en Línea, para el análisis de los usuarios de negocio.
- Analizar los efectos de la implementación de inteligencia de negocios en la
empresa Azaleia Perú.
1.4.3. Operacionalización de las variables e hipótesis
1.4.3.1. Hipótesis general
La implementación de una plataforma de BI, optimiza el proceso de
análisis, monitoreo y toma de decisiones para fortalecer la comercialización de la
empresa Azaleia Perú.
1.4.3.2. Hipótesis secundarias
Las hipótesis secundarias que se van a evaluar serán las siguientes:
a) El aumento de la calidad de información, ayuda a los usuarios de
negocio a identificar y comercializar mejor los productos de la empresa
Azaleia.
b) La continuidad de la eficiencia y efectividad en la comercialización
genera una mayor rotación de productos
c) El aumento en la productividad de las ventas de la empresa Azaleia,
incrementa el número de puntos de venta.
Tabla 2. Operacionalización de variables
Variable Definición Indicador
Calidad de información Enfocado en la
calidad y
obtención de
información, para
un mejor
consumo y toma
de decisiones.
Reducción en el tiempo de procesamiento de la información
Eficiencia y efectividad en Enfocado en la Reducción en el Índice
44
la comercialización reducción de
tiempos de
respuesta de los
usuarios de
negocio, que dan
soporte al área
de ventas y
gerencia.
de fallas reportadas
Aumento en el % de rotación de productos
Aumento en la
productividad de ventas
Enfocado en el
incremento de las
ventas, reducción
de los costos y
mejor
posicionamiento
en el mercado
Incremento en las ventas
Reducción en los costos
Fuente: Propia, 2015
1.4.3.3. Variables
a) Variable Independiente.- Plataforma de inteligencia de negocio para la
explotación eficiente de la información. Para la definición de esta
variable se ha establecido 3 indicadores diferentes los cuales se
muestran en la tabla 2.
Tabla 3.Indicadores de las variables independientes
Nombre del indicador
Variable independiente
X1 Calidad de información
X2 Eficiencia y efectividad en la comercialización
Fuente: Propia, 2015
b) Variable dependiente.- En el presente trabajo la variable dependiente
general es: explotación de la información para la toma de decisiones a
través del análisis de los indicadores de gestión de las ventas en el
45
mercado. Para explicar la misma se han utilizado los siguientes
indicadores, ver tabla 3.
Tabla 4. Indicadores de las variables dependientes
Nombre del indicador
Variable dependientes
Y1 Aumento en la productividad de ventas
Fuente: Propia, 2015
1.5. Alcance y limitaciones
1.5.1. Alcance
- Implementación basado en la metodología Ágil Scrum y manejo de gestión de
proyectos basado en las buenas practicas del PMBOK v5.
- Identificación y análisis de procesos relacionados en el área de ventas.
- Identificar indicadores y métricas a implementar el área de ventas.
- El proceso de la extracción de la información serán de 2 fuentes de datos
(AzaleiaPeru y DBBusiness) transaccionales que se encuentran en SQL 2012.
- Los prototipos de los dashboard serán desarrollados en Storyboards, de
Microsoft Power Point.
- El desarrollo de ETL, se trabajará con SQL integration Services y será
trabajado únicamente para las tablas referida para el área de ventas.
- La elaboración de un (1) cubo OLAP en SQL Analysis Services, que contendrá
indicadores y métricas del área de ventas.
- Elaboración de tableros dinámicos y reportes en el software de explotación
QlikView.21
- Transferencia de conocimiento y capacitación a usuarios técnicos y de negocio.
21
Software de inteligencia de negocios, para explotación y descubrimiento de datos.
46
1.5.2. Limitaciones
- La implementación está basada para el área de ventas, cualquier otro
requerimiento fuera del proceso no está considerado.
- El trabajo de extracción, transformación y limpieza solo será efectuado para la
base de datos AzaleiaPeru y DBBusiness.
1.6. Breve resumen de las fases
La metodología que se propone trabajar en la implementación de inteligencia de
negocios es ágil y tiene como marco referencial Scrum22, que consiste en trabajar a
base de Sprint, de una duración de un (1) mes por Sprint, la cual se itera y revisa
constantemente con los usuarios de Azaleia Perú, para verificar que la implementación
se esté ejecutando de acuerdo al alcance y necesidad del cliente.
La implementación consta de 3 Sprint:
- Sprint 1: Abarca el levantamiento de información, especificaciones de
requerimientos de negocio y diseño de la solución.
- Sprint 2: Modelo dimensional, desarrollo ETL y creación de cubo OLAP
- Sprint 3: Explotación de Data Mart mediante herramienta Qlikview y
capacitaciones a usuarios finales
22
Marco de trabajo que adopta estrategias de desarrollo incremental e iterativo, bajo un enfoque ágil
47
Capítulo 2: Marco Contextual
2.1. Descripción de la Empresa
Azaleia Perú es filial de la empresa Vulcabras Azaleia. Fue fundada en 1958 en la
ciudad de Parobé, Brasil. Actualmente es el grupo más grande de América Latina
exportando cerca de 20% de su producción para más de 50 países.
Azaleia, maneja todo un proceso para realizar la venta propia de los productos de
las diferentes marcas que ofrece. Desde el requerimiento de la necesidad del
producto, la solicitud de importación del mismo y la distribución.
Cuenta con dos almacenes, de donde se distribuyen todos los pedidos realizados.
Además estos almacenes alimentan a las diferentes tiendas, ya que estas funcionan a
su vez como pequeños almacenes para abastecer a la demanda de los clientes.
Actualmente cuenta con 4 canales de venta los cuales son: Venta al por mayor, venta
por tienda, venta por catálogo y venta por internet (Netstore).
Canales de Venta
- Canal de Venta al por Mayor:
Maneja el mayor ingreso de las ventas, con un 70% de porcentaje de todas las
ventas realizadas en el año fiscal.
Las ventas mayoristas son manejadas a crédito, por ende cada vendedor
responsable de la cuenta, mantiene el seguimiento constante de la fecha de
pagos a ser efectuados por cada establecimiento.
48
Cada vendedor maneja una cartera de clientes de los grandes centros
comerciales a los cuales mantienen actualizados con las nuevas tendencias y
productos de Azaleia Perú.
- Canal de Venta al por Tienda:
Este canal genera el segundo ingreso en ventas para la empresa Azaleia Perú,
cuenta con 28 tiendas que están distribuidas en lima y provincias. Cada tienda
ingresa la información de las ventas del día en un sistema, el cual está
integrado con la sede principal.
La forma de pago que maneja es en efectivo o por medio de tarjeta de crédito.
- Canal de Venta al por Catalogo:
Maneja una venta más consultiva a través de promotoras que ofrecen los
productos por medio de catálogos.
Cada promotora cuenta con una supervisora, la cual hace seguimiento y
registra las ventas realizadas en el día.
- Canal de Venta al por Internet:
Tiene un ingreso de solo el 20% de las ventas totales en el año fiscal y está
siendo impulsada, para tener un mayor impacto en los próximos años debido a
la incursión en las redes sociales.
Volúmenes de facturación Anual
Para el año 2014 la empresa Azaleia Perú, tuvo ventas netas en dólares por un
monto de: USD 22’065,549.82 y un total de pares vendidos de: 877,444. Para el
año 2015 se proyecta crecer un 20% en ventas, para lo cual se estima abrir unas
10 tiendas más distribuidas a nivel nacional.
49
Tabla 5. Ventas anual Azaleia Perú
Marca Venta Neta Pares
AZALEIA 12,390,614.78 492,992
OLYMPIKUS 5,659,116.20 200,078
DIJEAN 3,831,955.60 178,406
ORTOPE 171,787.80 5,488
BOOM 6,704.36 301
TAMARIS 5,236.93 153
OPANKA 134.15 26
TOTAL 22,065,549.82 877,444
Fuente: Azaleia Perú, 2014
Número de empleados
Azaleia Perú, cuenta con un total de 229 empleados los cuales están distribuidos
en 42 administrativos y 187 personas de ventas.
Misión y Visión
a) Misión
Ofrecer calzados confortables, elaborados en los más altos estándares de
calidad y tecnología a un precio justo, brindando calidad de servicio a nuestros
clientes.
b) Visión
Ser reconocido como la empresa líder en calzados en el Perú, brindado
excelencia en nuestros productos basado en un compromiso de calidad
constante el cual brinde satisfacción a nuestros clientes.
50
c) Análisis FODA
MATRIZ FODA
Análisis Interno
Fortalezas Debilidades
F1.- Empresa de trayectoria y prestigio internacional.
D1.- Escasa presencia en redes sociales.
F2.-Locales distribuidos a nivel nacional
D2.- Carencia en tecnología como apoyo en la toma de decisiones.
F3.- Buena relación entre calidad y precio.
D3.- Carencia de integración entre áreas a través de tecnologías.
F4.-Diversidad de estilos de marcas y calzados.
An
áli
sis
del
En
torn
o
Oportunidades FO DO
O1.- Ampliación de mercado en moda y marcas.
Ampliar los puntos de venta para captar mayor cuota de mercado (F1, O1,F2)
1. Generar mayor presencia en redes sociales que se encuentren enlazadas a la página web de Azaleia (D1, O1)
O2.- Diversificación de líneas de productos demandados por los segmentos emergentes.
Conseguir alianzas estratégicas con empresas internacionales del sector que permitan expandir los productos a nuevos mercados (F2, F3, O2)
1. Implementar herramientas que apoyen a la toma de decisiones e identifiquen nuevas demandas del mercado (O1, O2, D2)
O3.- Precios elevados por parte de la competencia.
Ofrecer productos de buena calidad y diversificados al mercado nacional, manteniendo el prestigio internacional de la empresa. (F3, F4, O3)
2. Implementar nuevas tecnologías que apoyen el análisis e identificación de ventas integrada
(O3, D2,D3)
Amenazas FA DA
A1.- Competencia agresiva por nuevos canales de ventas: E-commerce.
Hacer uso de las redes sociales de manera interactiva, para captar atención del público joven. (A1, F3, F4)
Elaborar una sección online de consejos al público respecto a las tendencias en la moda de calzados (A1, D1,D2)
A2.- Competencia de otras marcas de calzados Peruanos
Organizar encuestas, show rooms y presentaciones lanzamiento de temporada, que permita conocer al público las tendencias y novedades (A2, F1,F3)
Elaborar un repositorio que permita recopilar la información de las redes sociales para explotarla e identificar las necesidades y preferencias del cliente. (A2, D1,D2)
51
2.2. Presentación del área funcional
La estructura organizacional de la Empresa Azaleia Perú, está compuesta de la
siguiente manera.
Figura 19. Organigrama Azaleia Perú
Fuente: Azaleia Perú, 2015
2.3. Cadena de Valor
La cadena de valor de Azaleia Perú, muestra la distinción de los procesos
primarios/misionales que corresponden al core de la empresa y aquellos que son de
apoyo o soporte.
Directorio Azaleia
Importaciones
China
Brasil
Logística y Almacenes
Compras
Almacenes
Productos Importados
Ventas y facturación
Mayorista
Tiendas
Catalogo
Internet
Créditos y cobranzas
Finanzas
Presupuestos
Contabilidad
Recursos Humanos
Gerencia Administrativa
52
Figura 20. Cadena de valor Azaleia Perú
Fuente: Elaboración propia, 2015
2.4. Cadena de Valor – Macro Procesos Misionales
Como procesos misionales de la empresa, se encuentra el proceso de ventas, en
sus diferentes canales, comercialización, importación y logística. Cada uno de estos
procesos forma parte crucial dentro de la estrategia de crecimiento en el mercado de
la empresa Azaleia Perú. Para un mejor entendimiento se detalla de la cada de valor
los Macro Procesos Misionales.
53
Figura 21. Macro Procesos Misionales
Fuente: Propia, 2015
2.5. Procesos de venta e importaciones Nivel 0
Figura 22. Pedido venta Azaleia
Fuente. Elaboración propia, 2015
54
Figura 23. Pedido Brasil
Fuente. Elaboración propia, 2015
Figura 24. Pedido Asia
Fuente. Elaboración propia, 2015
55
Capítulo 3: Marco Metodológico
3.1. Modelo de negocio
El área comercial de Azaleia Perú tiene la necesidad de establecer
controles internos a nivel táctico y estratégico, enfocado en los indicadores de
ventas, con el objetivo de manejar, analizar y mejorar la toma de decisiones en
los distintos niveles de la organización, evitando los sistemas heterogéneos
usados hoy en día para el análisis de la información.
Busca proporcionar a los usuarios el acceso interactivo, análisis y
manipulación de la información, que contribuya con la identificación de
problemas y oportunidades del negocio, teniendo la capacidad de acceder a
volúmenes de información para dar soporte a la toma de decisiones basado en
los objetivos estratégicos de la empresa.
3.3. Metodología de desarrollo
Enfocado en metodología ágil bajo la marco de referencia SCRUM.
También, se hará uso de las buenas practicas del PMBOK v5, el cual está
enfocado en la gestión del proyecto. Además, se trabajará con la herramienta
de Microsoft Team Foundation Server23, para realizar el seguimiento de las
actividades.
23
Herramienta de Microsoft que ofrece funciones de control de código y seguimiento de elementos de trabajo y administración de proyectos.
56
3.3.1. EDT Implementación de Inteligencia de Negocios
Mediante la estructura de desglose de trabajo (EDT), se pretende mostrar los entregables que serán ejecutados en el proceso de la
implementación por el equipo de trabajo.
PROYECTO BI AZALEIA
1. Dirección y planificación
1.1 Planificación
1.1.1 Kick Off
1.1.2 Cronograma
1.1.3 Project Charter
1.1.4 Enunaciado de trabajo de proyecto
1.1.5 Identificación de Riesgos
1.1.6 Matriz de Comunicación
1.2 Control y seguimiento
1.2.1 Informes de avance
1.2.2. Informe de Comite
1.2.3 Control de Cronogrma
1.2.4 Control de Riesgos
2. Análisis y Diseño
2.1 Análisis
2.1.1 Procesos de ventas
2.1.2 Indicadores
2.1.3 Base de datos
2.2 Diseño
2.2.1 Arquitectura BI
2.2.2 Base de datos modelo dimensional
2.2.4 Prototipos de Dashboard
3. Contrucción
3.1 Desarrollo ETL
3.2 Desarrollo Cubo OLAP
3.3 Desarrollo KPI'S
3.4 Desarrollo Tablero y Reportes
4. Pruebas
4.1 Casos de Prueba
4.2 Informe de Pruebas
5. Despliegue
5.1 Manual de Configuración
5.2 Manual de Instalación
5.3 Manual de usuario
57
3.3.2. Tablero Kanban
Un sistema de gestión de proceso virtual que indica que producir,
cuándo y cuánto. Teniendo la visibilidad del equipo de trabajo.
Figura 25. Tablero Kanban
Fuente: Elaboración propia, 2015.
3.4. Dimensionamiento del Proyecto
N° Entregable Plazo Monto $
1 KickOff y Story Mapping Mayo - 2015 $9,421.25
2
Cronograma de Proyecto (Hitos)
Documento de Arquitectura Documento de especificaciones de requerimiento
Junio - 2015 $9,421.25
3 Data Mart ventas
Documento de cubo OLAP Julio - 2015 $9,421.25
4
Solución en sus ambientes de pre producción
Guía de usuario
Guía de instalación y configuración de la solución.
Agosto- 2015 $9,421.25
TOTAL USD $37,685.00
3.5. Roles y responsabilidades
58
Rol Responsabilidades
Jefe de Proyecto
Establece los plazos, fases y entregables del proyecto.
Controla el alcance del proyecto
Define, conjuntamente con los PO, los objetivos, procedimientos y estrategias del proyecto.
Monitorea el avance del proyecto, el desempeño y las necesidades del equipo en general.
Asigna los roles, responsabilidades y tareas a los miembros del equipo.
Reporta el avance del proyecto al comité de seguimiento.
Informa tempranamente y propone alternativa de solución al comité de seguimiento sobre cualquier problema que pueda generar atrasos o inconvenientes para el normal desenvolvimiento del proyecto.
Monitores los problemas presentados y establece un proceso de solución efectivo.
Provee la gestión general y diaria del proyecto.
Analista de Calidad
Encargado del levantamiento de información.
Elaboración de prototipos (Storyboarding).
Elaboración del documento de especificación.
Elaboración de Plan e informe de Pruebas.
Elaboración de Manual de usuario.
Validación del producto.
Especialista BI
Encargado del modelo de la base de Datos
Elaboración de Normalización de la base de datos
Elaboración de ETL
Elaboración de ejecución de Jobs
Elaboración de manual de despliegue
Elaboración de tablero gerencial y reportes de gestión
3.6. Sprint Backlog Dentro del Sprint Backlog podemos identificar todos los requerimientos a
desarrollar dentro de la implementación, cada uno de estos requerimientos son
priorizados de acuerdo a la necesidad del negocio por un usuario líder, el cual
es denominado como el Product Owner o dueño del producto.
Para poder tener un Sprint Backlog afinado, tiene que haber mucha
interacción con el usuario de negocio, e identificar conjuntamente los
59
requerimientos necesarios para la implementación de la plataforma de BI. Es
ahí en donde indicamos que “el levantamiento de información es la parte
esencial de la implementación a realizar”.
Cada Sprint contiene una cantidad de requerimientos los cuales serán
trabajados y puesto a producción para la revisión y aprobación del Product
Owner.
Tabla 6. Sprint Backlog
Sprint Actividades
Sprint I: Especificar los requerimientos del negocio, desarrollo de prototipos de tablero y reportes, para identificación de las tablas y campos a extraer para la generación del Data Mart de Ventas
Creación de historias de usuario
Creación de Reglas de Negocio
Creación de Prototipos de tablero y Reportes
Creación de Arquitectura de BI
Identificación de Indicadores Claves de Gestión
Creación de Base de Datos Stage
Identificación de Tablas a Extraer
Generación de un KPI en Power Pivot
Sprint II: Depurar los datos inconsistentes de la bases de datos de Azaleia para proceder con la creación del modelo dimensional, consiguiendo integridad e integración en los datos los cuales serán explotados.
Depuración de Datos ETL
Creación de Modelo Dimensional
Creación de Jobs de Carga automáticas
Creación de Métricas y Hechos
Creación de Cubo Dimensional
Sprint III: Generación y Explotación de los indicadores, mediante gráficas y reportes
Desarrollo de tablero Gerencial
Desarrollo de Reportes
Cargas Incrementales del Cubo
Desarrollo de Pruebas
Fuente: Elaboración propia, 2015
60
3.7. Desarrollo Sprint I Dentro del Sprint I, abarcará el levantamiento preliminar, desarrollo de las
historias de usuarios, creación de los prototipos navegables y la identificación
de las tablas a extraer según los indicadores que se quieren implementar.
3.7.1. Entregables
Sprint I
Creación de historias de usuarios
Creación de Reglas de Negocio
Creación de Prototipos de tablero y Reportes
Creación de Arquitectura de BI
Identificación de Indicadores Claves de Gestión
Creación de Base de Datos Stage
Identificación de Tablas a Extraer
Generación de un KPI en Power Pivot
3.7.2. Diseño de Arquitectura Azaleia
Es necesario establecer una arquitectura, la cual permita identificar
los sistemas transaccionales de los cuales será extraída los datos para
posteriormente realizar el proceso de extracción, transformación y carga (ETL)
hasta la explotación en la herramienta de BI, que ha sido seleccionada por la
empresa Azaleia Perú.
61
Figura 26. Arquitectura Azaleia Perú
Fuente: Elaboración propia, 2015.
3.7.3. Indicadores de gestión
Los KPI (Key Perfomance Indicator) o indicadores claves de
gestión, es una medida de desempeño, el cual está ligado con los objetivos en
valores porcentuales de la empresa. Mediante el cual busca visualizar el
progreso en el proceso de ventas mediante indicadores de rendimiento que le
permita analizar y hacer comparativos para cuantificar el grado de
cumplimiento de los objetivos establecidos.
Para el caso de Azaleia Perú, los objetivos establecidos están basados en las
ventas por lo cual los indicadores que desean analizar son los siguientes:
ventas por canales y marcas, descuentos realizados, rentabilidad por categoría
de producto, costos por canal de venta, stock existente por producto, etc.
A continuación se muestra los indicadores:
62
Tabla 7. Indicador Total de ventas netas
Indicador 01 – Total de Ventas Netas
Objetivo Estratégico: Analizar la venta Neta Total la cual saldrá a partir de la sumatoria de todas las unidades de negocio.
Frecuencia de actualización: Anual, Mensual
Unidades de Medida: Soles / Dólares
Definición de fórmulas:
𝑽𝒆𝒏𝒕𝒂 𝑵𝒆𝒕𝒂𝑻𝒐𝒕𝒂𝒍 = ∑ 𝑽𝒆𝒏𝒕𝒂 𝒅𝒆 𝑼𝒏𝒊𝒅𝒂𝒅𝒆𝒔 𝒅𝒆 𝑵𝒆𝒈𝒐𝒄𝒊𝒐
Criterios de aceptación: Deberá contar con la dimensión tiempo el cual contenga Año, Trimestre, Mes,
Semana, y día. Deberá contar con la opción para elegir el origen (Brasil y Asia). Se debe contemplar campo moneda que incluya el análisis por dos tipos de moneda
(Soles y Dólares). Manejara filtros como: Clase, Marca, Colección, Categoría y sub Categoría. Incluirá el análisis comparativo de las ventas por mayor entre meses del año actual
con los meses del año – 1. El total de ventas netas deberá actualizar por año y por mes. Deberá indicar los parámetros correspondientes respecto a la meta trazada.
Definición de fórmulas:
Se mostrará un gráfico de tacómetro el cual mostrará el avance o cumplimiento de la meta total de la venta.
El tacómetro mostrara 3 tipos de colores (Rojo, Ambar y Verde) Deberá proporcionar información resumen cuando se seleccione el Tacómetro El monto total deberá aparecer debajo del tacómetro para una mejor visualización.
Fuente: Elaboración propia, 2015
63
Tabla 8.Indicador Costo promedio
Indicador 02 – Costo Promedio
Objetivo Estratégico: Identificar por cada unidad de negocio los costos totales, con el objetivo de evaluar las unidades que generan mayores costos. Las unidades de negocio a tomar en cuenta son: (Ventas por Mayor, Ventas por Tienda, Ventas por Catálogo y Ventas por NetStore)
Frecuencia de actualización: Anual, Mensual
Unidades de Medida: Soles
Definición de fórmulas:
𝑪𝒐𝒔𝒕𝒐 𝑷𝒓𝒐𝒎𝒆𝒅𝒊𝒐 = Valor Existente en el Inventario +Valor nuevas compras
𝑵𝒖𝒎𝒆𝒓𝒐 𝒅𝒆 𝒖𝒏𝒊𝒅𝒂𝒅𝒆𝒔 𝒆𝒙𝒊𝒔𝒕𝒆𝒏𝒕𝒆𝒔 𝒆𝒏 𝒆𝒍 𝒊𝒏𝒗𝒆𝒏𝒕𝒂𝒓𝒊𝒐+𝑼𝒏𝒊𝒅𝒂𝒅 𝒅𝒆 𝒍𝒂 𝒏𝒖𝒆𝒗𝒂 𝒄𝒐𝒎𝒑𝒓𝒂
Criterios de aceptación: Deberá contar con la dimensión tiempo el cual contenga Año, Trimestre, Mes,
Semana, y día. Deberá contar con la opción para elegir el origen (Brasil y Asia), en forma de combo
box. Se debe contemplar campo moneda que incluya el análisis por dos tipos de moneda
(Soles y Dólares). Manejara filtros como: Clase, Marca, Colección, Categoría y sub Categoría. Incluirá el análisis comparativo de las ventas por mayor entre meses del año actual
con los meses del año (- 1). Verificar un campo que indique los costos por unidad de negocio. Verificar actualizar los montos con cada interacción de los filtros de tiempo. Verificar contar con filtros como: Clase, Marca, Colección y categoría para el análisis.
Definición de fórmulas:
Verificar contar con un gráfico, para el análisis de ventas vs metas, que están dadas por: (Monto Vendido Neto y Meta).
Verificar un índice de rotación que estarán dadas por: (Ventas por Mayor, Ventas por Tiendas, Venta por Catálogo y Ventas por NetStore).
Verificar un análisis de unidades por Stock reflejado mediante un gráfico en cantidades respecto a: (Ventas por Mayor, Ventas por Tiendas, Ventas Catálogos, Ventas Internet, Ventas Outlet).
Elaboración propia, 2015
64
Tabla 9. Indicador Descuento
Indicador 03 – Descuento
Objetivo Estratégico: Identificar que unidades de negocio están generando mayores descuentos en comparación de sus ventas. Las unidades de negocio a tomar en cuenta son: (Ventas por Mayor, Ventas por Tienda, Ventas por Catálogo y Ventas por NetStore)
Frecuencia de actualización: Anual, Mensual.
Unidades de Medida: Soles
Definición de fórmulas:
Criterios de aceptación:
Deberá contar con la dimensión tiempo el cual contenga Año, Trimestre, Mes,
Semana, y día. Deberá contar con la opción para elegir el origen (Brasil y Asia) en forma de combo
box. Se debe contemplar campo moneda que incluya el análisis por dos tipos de moneda
(Soles y Dólares) Manejara filtros como: Clase, Marcas, Colección, Categoría. Incluirá el análisis comparativo de las ventas por mayor entre meses del año actual
con los meses del año (- 1) En la grilla análisis por unidad de venta se verifica la columna descuento Se verifica en la grilla una columna rentabilidad con su respectiva semaforización,
esta columna rentabilidad es un indicador derivado.
Elaboración propia, 2015
Tabla 10. Indicador índice de rotación
Indicador 04 – Índice de Rotación
Objetivo Estratégico:
Analizar cuáles son las unidades de negocio que tienen mejor índice de rotación en sus productos, con el fin de saber que artículos son los más solicitados por la demanda del mercado. Las unidades de negocio a tomar en cuenta son: (Ventas por Mayor, Ventas por Tienda, Ventas por Catálogo y Ventas por NetStore)
Frecuencia de actualización: Mensual, Diario
Unidades de Medida: Unidades
Definición de fórmulas:
Definición de fórmulas:
65
Criterios de aceptación:
Deberá contar con la dimensión tiempo el cual contenga Año, Trimestre, Mes,
Semana, y día. Deberá contar con la opción para elegir el origen (Brasil y Asia) en forma de combo
box. Se debe contemplar campo moneda que incluya el análisis por dos tipos de moneda
(Soles y Dólares). Manejara filtros como: Clase, Marca, Colección, Categoría y sub Categoría. Incluirá el análisis comparativo de las ventas por mayor entre meses del año actual
con los meses del año (- 1). Para el índice de rotación se tiene el promedio de las ventas. El menor índice de rotación indicara el que tiene mayor movimiento en sus artículos
según cada unidad de negocio. El stock es por 2 0 3 meses. El grafico de barras se da por vendedor. Ver cuál es el mejor de la tienda. El filtro por catálogo permite verificar cuanto se ha vendido y cuando.
Elaboración propia, 2015
Tabla 11. Indicador metas por cobranza
Indicador 05 – Metas por Cobranza
Objetivo Estratégico: Analizar a los vendedor con sus metas y el avance de la cobranza, con el fin de saber el monto total por cobranza que está siendo efectiva de las ventas por mayor, DNRS, Tienda, y Catálogos
Frecuencia de actualización: Mensual, Diario
Unidades de Medida: Soles
Definición de fórmulas:
Criterios de aceptación:
Deberá contar con la dimensión tiempo el cual contenga Año, Trimestre, Mes,
Semana, y día. Deberá contar con la opción para elegir el origen (Brasil y Asia) Se debe contemplar campo moneda que incluya el análisis por dos tipos de moneda
(Soles y Dólares) Manejara filtros como: Clase, Marca, Colección, Categoría y sub Categoría. Incluirá el análisis comparativo de las ventas por mayor entre meses del año actual
con los meses del año - 1 En la meta de cobranza se pagan las comisiones y se considera de la siguiente
manera:
- Hasta 50% no se paga comisión, se representa mediante el color rojo. - 51% hasta 89% se paga una comisión gradual menor a la pactada, se represente
mediante el color ámbar.
- 90% a más, la comisión se paga como si fuera 100%, se represente mediante el color verde.
Elaboración propia, 2015
𝑀𝑒𝑡𝑎 𝐶𝑜𝑏𝑟𝑎𝑛𝑧𝑎 = Facturas del mes acuerdo a fecha de vencimiento × .90
66
3.7.4. Historias de Usuarios
La historia de usuario es una representación de un requerimiento,
en el cual explica el usuario en un lenguaje común lo que necesita del sistema.
Las historias de usuarios son escritas por el cliente, tiene un peso y priorización
según el negocio.
Se muestra un extracto de las historias de usuarios realizadas:
Historia de Usuarios
Tabla 12. Control de acceso a Usuarios
Historia de Usuario
Número: 1 Usuario: Todos
Nombre historia: Control de acceso a Usuarios
Para: Mantener la seguridad y acceso a los datos de la empresa
Descripción: Antes de iniciar la aplicación se solicita el nombre de usuario y su clave para que tenga acceso a los datos que corresponden a su categoría de usuario. Hay dos tipos de usuario: Gerencia Comercial y Gerencia Administrativa, con distintos permisos de acceso a los menús de acceso a las funcionalidades que les corresponden.
Fuente: Elaboración propia, 2015
Tabla 13. Dimensiones del tiempo y lugar
Historia de Usuario
Número: 2 Usuario: Gerente de Ventas y usuarios
Quiero: Filtrar las ventas por tiempo y lugar
Para: identificar los meses y localidad en donde vende mayor cantidad y en donde se tiene deficiencias
67
Historia de Usuario
Descripción: El Dashboard de la aplicación deberá poder permitir escoger mediante un calendario la fecha exacta, el cual contenga Año, Trimestre, Mes, Semana, y día. Del mismo modo deberá permitir la selección del origen de los datos entre Brasil y Asia.
Fuente: Elaboración propia, 2015
Tabla 14. Visualización de análisis de las ventas
Historia de Usuario
Número: 3 Usuario: Gerente de Ventas y Usuarios
Quiero: Mejorar visualmente el análisis de las ventas
Para: Anticipar anomalías y desviaciones de las ventas
Descripción: En el dashboard de la aplicación, se deberá visualizar las ventas por canal, tanto en cantidad de pares vendedidos como monto vendido. Además la información debe filtrases, por cada categoría, localidad, tiempo y vendedor, con el fin de poder identificar las ventas a nivel de detalle.
Elaboración propia, 2015
Tabla 15. Indicadores de ventas
Historia de Usuario
Número: 4 Usuario: Gerente de Ventas
Quiero: Indicadores de las ventas
Para: Tomar acciones de negocio
Descripción: El Tablero dinámico deberá contener 5 KPI (Índice de Rotación, Stock, Venta Total, Costo de venta y Descuento) necesarios para el análisis del negocio.
Elaboración propia, 2015
68
Tabla 16. Visualización por categorías
Historia de Usuario
Número: 5 Usuario: Usuarios
Quiero: Visualizar las ventas por categorías
Para: Tener detalle de los productos que están teniendo mayor rotación en el mercado.
Descripción: El Dashboard deberá permitir realizar el análisis por las diferentes categorías como: Marca, Clase, Colección, Campaña, Línea, Referencias.
Observaciones: - Las Ventas deben ser por Mayor. - Las Ventas deben ser por Tienda. - Las Ventas deben ser por Catálogo. - Las Ventas deben ser por Internet. - Las Ventas deben ser por Outlet.
Fuente: Elaboración propia, 2015
3.7.5. Diseño de Prototipos
El diseño de los prototipos fue desarrollado de acuerdo a los
requerimientos levantados y analizados en conjunto con el dueño del producto.
El objetivo consta en mostrar al usuario una idea de cómo sería la
visualización de los tableros de control y los gráficos a usar dependiendo del
análisis de o los indicadores. Este diseño previo de la interfaz, brinda al
usuario una idea de la distribución grafica dentro de los tableros de control
solicitados.
3.7.5.1. Tablero Gerencial
Permite visualizar todos los indicadores de gestión. El
objetivo es que el gerente pueda tomar mejores decisiones en base a la
información que visualizará de manera gráfica, dinámica y en línea.
69
Figura 27. Prototipo tablero gerencial
Fuente: Elaboración propia, 2015
3.7.5.2. Ventas por Mayor
Permite hacer los comparativos y análisis de ventas con
información de ventas pasadas. El fin del reporte es poder analizar la tendencia
de crecimiento de las ventas por cada cliente, de acuerdo a cada categoría,
marca, colección etc.
70
Figura 28. Prototipo venta por mayor
Fuente: Elaboración propia, 2015
3.7.5.3. Ventas por Tienda
El objetivo de desarrollar el reporte de ventas, además de
ver la tendencia de las ventas generadas, es saber el stock que maneja cada
tienda, con el fin de analizar el índice de rotación de cada producto.
71
Figura 29. Prototipo venta por tienda Fuente: P Elaboración propia, 2015
3.7.5.4. Ventas por Catálogo
El objetivo de desarrollar un reporte que analice las ventas
por catálogo, es hacer seguimiento a cada promotora y ver cuál es la tendencia
de ventas que tiene.
72
Figura 30. Prototipo venta por catalogo
Fuente: Elaboración propia, 2015
3.8. Desarrollo Sprint II
Dentro del Sprint II se trabajará el proceso de ETL el cual permitirá
identificar y depurar la data inconsistente, para posteriormente ser almacenada
en el Data Mart de ventas. El modelo dimensional será una estructura tipo
estrella, el cual permite optimizar las consultas dentro de la herramienta de
explotación de Qlikview, que fue adquirida por Azaleia Perú.
3.8.1. Entregables
Sprint II
Depuración de Datos (Proceso ETL100%)
Creación de Dimensiones y Métricas
73
Creación del Modelo Dimensional – Data Mart Ventas
Creación de Cubo Dimensional Ventas
3.8.1.2. Modelo Dimensional
La definición de los requerimientos del negocio determina
los datos que se necesita para atender los requerimientos analíticos de los
usuarios de negocio. Diseñar modelos de datos para soportar este análisis
requiere una aproximación diferente a la usada para el diseño de sistemas
operacionales. Se empieza construyendo una matriz que representa la clave de
los procesos del negocio y su dimensión. La matriz sirve como un esquema
para asegurarse que el data Mart es pueda ser escalable para la organización
en el tiempo.
Aquí se inicia el análisis de los datos más detalladamente
uniendo este análisis con el entendimiento de los requerimientos del negocio.
Luego se desarrolla el modelo de las dimensiones. Este modelo identifica el
grado de la tabla, las dimensiones asociadas, los atributos, jerarquías y
métricas. El diseño de la base de datos lógica es completado con una
apropiada estructura de tablas y primary/foreign constraints. Se desarrolla
también el primer plan de agregaciones. Este conjunto de actividades concluye
con el desarrollo del mapeo entre los datos de origen y destino.
3.8.1.3. Diseño físico de la base de datos
El diseño físico de la base de datos se centra en la
definición de la estructura física necesaria para soportar el diseño lógico de la
base de datos. Los elementos primarios de este proceso incluyen la definición
del estándar de nomenclatura y la configuración del entorno de la base de
74
datos. También se definen los índices preliminares y la estrategia de
particionamiento.
3.8.1.4. Diseño físico de la base de datos intermedia
El diseño del repositorio de datos y el desarrollo de los
procesos es típicamente la tarea más subestimada en un proyecto de data
Mart. El proceso de almacenar la data tiene tres pasos principales: extracción,
transformación y carga. El proceso de extracción siempre expone la calidad de
la data que ha sido ingresada en los sistemas operacionales de origen. Ya que
la calidad de la data impacta directamente en la confiabilidad del data Mart, se
necesita enfocar este problema de calidad de los datos durante el
almacenamiento intermedio de los mismos. Para problemas más complicados
se necesita diseñar y construir dos procesos de almacenamiento de
warehouse, uno para la carga inicial y otro para la carga incremental.
3.8.1.5. Diseño de la arquitectura técnica
El entorno del Data Mart requiere de la integración de
numerosas tecnologías. En esta actividad se establece la arquitectura y visión
generales. Se necesita considerar tres factores: los requerimientos del negocio,
el actual ambiente tecnológico y las directivas técnicas estratégicas.
3.8.1.6. Selección e instalación de productos
Utilizando el diseño de la arquitectura técnica como un
marco, se requiere evaluar y seleccionar los componentes específicos de la
arquitectura, tales como la plataforma del hardware, el sistema de
administración de base de datos, la herramienta de carga de datos y las
herramientas de acceso a los datos. Para cada componente de la arquitectura
75
se define una técnica estándar de evaluación así como los factores de
evaluación.
3.8.1.7. Especificación de la aplicación de usuarios
Se recomienda definir un grupo de aplicaciones estándar
para los usuarios finales, ya que no todos los usuarios del negocio necesitan
accesos especiales al Data Mart. Las especificaciones de las aplicaciones de
usuario final definen las plantillas de los reportes, los parámetros manejados
por el usuario y los cálculos requeridos.
3.8.1.8. Implementación
El desarrollo representa la convergencia de la tecnología,
los datos y las aplicaciones de usuario final accesibles desde el escritorio del
usuario de negocio. Se requiere de un planeamiento extensivo para asegurar
que estas piezas se unan apropiadamente. Igualmente se debe desarrollar la
capacitación de los usuarios de negocio de forma que integre todos los
aspectos de la convergencia. Además, antes de que los usuarios tengan
acceso al Data Mart se debe establecer el soporte a los usuarios y las
estrategias de comunicación o retroalimentación.
3.8.1.9. Diseño de Extracción Transformación y Limpieza
(ETL)
Durante la etapa desarrollo se crea y prueba la
funcionalidad del sistema. Aquí el entregable final es el diseño físico, las
especificaciones técnicas finales y congeladas, y el producto desarrollado y
probado. Los responsables de educación de usuario ejecutarán los planes de
capacitación, documentación, y trabajarán con el equipo de desarrollo para
crear los componentes de tutorial y guías del usuario.
76
Pasos a ejecutar en el proyecto:
Proceso de Extracción de la Fuente de la Base de Datos
Esta actividad considera la carga de datos desde la fuente. Actividad que
está cubierta tomando como base interface con sistemas transaccionales
AZALEIA PERÚ.
Diseño del Modelos Multidimensional
Diseño de la estructura física y lógica de las Dimensiones a utilizar.
Construcción del Data Mart
Desarrollo de aplicaciones de carga de Base de Datos OLAP.
Desarrollo de ETL y procedimientos almacenados para la copia de datos
de la base de datos relacional a la base de datos OLAP del Data Data
Mart.
Creación de estructura de OLAP en MS SQL Analysis Server 2012.
Desarrollo de la estructura de cubos en MS SQL Analyzer 2012 y
programación de medidas según los requerimientos definidos en la
primera fase.
Diseño e implementación de las Tareas de carga.
Diseño de los procedimientos de carga incrementales e implementación
de las tareas para la carga diaria de la data.
Implementación de la Interface de Usuario.
Construcción de la interface de usuario conjuntamente con cada uno de los
reportes a mostrar.
77
Pruebas Integrales.
Las pruebas Se realizan conjuntamente con el equipo de sistemas y
usuarios.
Carga de Datos.
Actividad que se realiza conjuntamente con el equipo de sistemas y
usuarios. Esta actividad incluye la certificación de la data, las posibles
correcciones y los afinamientos que serán necesarios para la consistencia
de los datos.
Afinamiento de Rendimiento.
Esta actividad considera las acciones necesarias para lograr que el Data
Mart se adecue a los niveles de rendimiento definidos en la etapa de
planeamiento.
3.8.1.10. Tablas identificadas
Se identificaron las siguientes tablas de las dos bases de
datos que maneja Azaleia Perú, las cuales intervendrán para el desarrollo del
proceso de ETL.
78
Tabla 17. Fuente de datos transaccionales_Azaleia
DB: AzaleiaPeruDatastage DB: BusinessDatastage
AlmArticulos AlmCampanias AlmClase AlmColeccion AlmColores AlmCtrlMovArtCab AlmCtrlMovArtDet AlmLineas AlmLineasColores AlmLineasReferencias AlmLineasReferenciasColores AlmLineasReferenciasTallas AlmMateriales AlmMaterialesDetalle AlmTallas AlmTallasDetalle AlmTallasGrupos CtaCanalesVentaMetas CtaDocumentosDeAbono CtaDocumentosDeAbonoDetal
le CtaFacturaImportacion CtaFacturaImportacionDetalle CtaPlanillaCobranzas CtaVendedoresMetasAnual MaeClientes MaeGrupos SisAdmUsers SisTabEstados SisTabEstadosPcs SisTabParamRegDet SisTabUbiGeo VtaDocumentosDeCargo Vtadocumentosdecargodetalle VtaGuiaRemisionCab VtaGuiaRemisionDet VtaPedidoImportCab VtaPedidoImportDetalle VtaPedidosPorFacturar
AlmColeccion AlmMateriales AlmMaterialesDetalle AppEmpresa ArtClase ArtDatos ArtGrupos ArtProductos CATA_MAELIDERES CtaDocumentosDeAbono CtaDocumentosDeAbonoD
etalles MaeCatalogos MaeClientes MaeColores MaeTarjetas MaeTemporadas MaeTipoCambio MaeUbiGeo PcsMovimientos PcsMovimientosDetalles SisAdmUsers SisTabEstados SisTabFormasDePago UbigeoCourier VtaDocumentosDeCargo VtaDocumentosDeCargoDe
talles VtaDocumentosDeCargoPa
gos VtaPedidosDeVenta VtaPedidosDeVentaDetalle PcsTransferencia PcsTransferenciaDetalle
Fuente: Elaboración propia, 2015
79
3.8.1.11. Tabla de extracción – Esquema SSIS24
Permitirá la implementación de los paquetes y tareas.
Cada registro se podrá capturar en tiempo de ejecución sobre el paquete
ayudando auditar o solucionar problemas cada vez que se ejecuta.
Tabla 18.Dimensiones y métricas
Extraer DimCliente
Extraer DimEstado
Extraer DimProducto
Extraer DimTiempo
Extraer DimTienda
Extraer DimUbigeo
Extraer DimVendedor
Extraer FactCobranza
Extraer FactMetaCobranzaVendedor
Extraer FactMetaTienda
Extraer FactPedido
Extraer FactStock
Extraer FactStockPendiente
Extraer FactVenta
Extraer FactVentaStockIR
Fuente: Elaboración propia, 2015
3.8.1.12. Modelo entidad relación / Diagrama E-R
Permite identificar las dimensiones y sus relaciones entre
ellas, organizando los datos en los sistemas para un análisis de Inteligencia
de Negocios.
Se presenta el modelo dimensional del Data Mart desarrollado:
24
SQL Server Integration Services, componente de Microsoft SQL Server utilizado para la migración de datos
80
Figura 31. Modelo dimensional Data Mart
Fuente: Azaleia Peru 2015
Figura 32. Modelo dimensional Qlikview
Fuente: Azaleia Peru 2015
81
3.9. Desarrollo Sprint III
Explotación de la información consta de: La generación de Tableros de
control, el cual contiene los 5 indicadores implementados. También se
desarrollaran reportes por cada canal de venta (Por mayor, tienda, catalogo e
internet) estos reportes serán consumidos por cada responsable de canal de
venta y por los vendedores.
Se aplicará las reglas de seguridad, para el acceso a la plataforma, según
el perfil y los privilegios que tenga.
3.9.1. Entregables
Sprint III
Desarrollo de Tablero Gerencial
Desarrollo de Reportes
Cargas Incrementales del Cubo
Despliegue
Pruebas
3.9.2. Implementación de interfaz de usuario
Se realizar la construcción de los tableros de control los cual
contendrán los indicadores de gestión implementado en el sprint II.
Asimismo los reportes que servirán para el análisis a nivel de detalle para
el personal comercial y de ventas de la empresa Azaleia Perú.
A continuación se muestran el desarrollo en QlikView de los tableros
por canal de venta.
82
Figura 33. Tablero gerencial
Fuente: Azaleia Perú, 2015
83
Figura 34. Tablero canal de ventas por tienda
Fuente: Azaleia Perú, 2015
84
Figura 35. Tablero canal de ventas por tienda
Fuente: Azaleia Perú, 2015
85
Figura 36. Tablero ventas por mayor
Fuente: Azaleia Perú, 2015
86
Figura 37. Tablero de ventas por catalogo
Fuente: Azaleia Perú, 2015
87
3.9.2.1. Pruebas integrales
Las pruebas se realizan conjuntamente con el equipo de
sistemas y usuarios, en donde se valida la información que está siendo
explotada con los reportes que tienen en la base de datos, transaccional.
Además se hace pruebas de carga de datos y acceso de usuarios a la
plataforma Qlikview.
3.9.2.2. Carga de Datos
Actividad que se realiza conjuntamente con el equipo de
sistemas y usuarios. Esta actividad incluye la certificación de la data, las
posibles correcciones y los afinamientos que serán necesarios para la
consistencia de los datos
3.9.2.3. Afinamiento de rendimiento
Esta actividad considera las acciones necesarias para
lograr que el Data Mart se adecue a los niveles de rendimiento definidos en la
etapa de planeamiento.
3.9.2.4. Estabilización y pase a producción
Una vez concluida esta etapa se pasa a la fase de
“Estabilización” donde se logra la estabilidad del producto, se conducen
pruebas se desarrollan las últimas correcciones que sea necesarias, se ejecuta
el plan de trabajo para el lanzamiento y puesta en marcha del sistema. Esta
etapa genera el último de los entregables: la estrategia final de implantación del
producto, el cual contempla los aspectos logísticos necesarios para lograr una
liberación exitosa del sistema en todos sus aspectos.
Pasos a ejecutar en el proyecto:
88
a) Capacitación a usuarios Finales
Capacitación para el uso correcto de las medidas y dimensiones para los
usuarios finales.
b) Capacitación a Personal de Sistemas
Capacitación al personal de sistema que se encargará del mantenimiento
del Data Mart.
c) Documentación Técnica
Documentación técnica del desarrollo implementado para quien se
encargará del mantenimiento del Data Mart.
d) Documentación de Usuario
Documentación usuaria de las Interfaces especificando los pasos a seguir
para la correcta manipulación del mismo.
e) Pase a Producción
Instalación y Configuración de la solución en el ambiente de producción del
cliente.
3.9.2.5. Criterios de aceptación
Los criterios de aceptación del servicio de
implementación de la aplicación terminada y entregada son los siguientes:
- Validar que todas las funcionalidades requeridas se encuentran
implementadas en el sistema de acuerdo al documento de visión, alcance,
y/o de requerimientos, análisis.
89
o Políticas y normatividad de Azaleia Perú, que permita asegurar el
cumplimiento de las normas internas de la empresa. Éstas políticas
comprenden aspectos:
Auditoría de la información
Responsabilidad de la información (seguridad, responsabilidad)
Dependencias de la información (mantenimiento)
o Establecimiento y definición de los estándares aplicados al sistema,
permitiendo definir claramente criterios de accesibilidad, usabilidad,
o Conjunto de datos de prueba que permitirá conocer lo correcto, exacto,
demostrable, y preciso del sistema.
- Haber realizado una prueba del funcionamiento de la solución con un
usuario funcional designado por el Cliente, de acuerdo a las
funcionalidades y criterios de aceptación aprobadas durante la fase de
análisis.
o Después de pasar 3 días útiles de liberación del producto en el ambiente
de Certificación o Pruebas no tener problemas técnicos o funcionales
asociados al producto adquirido o no recibir observaciones y/o reportes
de errores técnicos o funcionales comunicados de manera formal dentro
del plazo.
90
3.10. Pruebas y resultados
Sobre la base de las encuestas aplicadas, Evaluación de resultados, a un número
de 20 usuarios de Azaleia, se obtuvo el siguiente resultado:
3.10.1 Contrastación de Hipótesis
a) Calidad de información
Figura 38. Evaluación Calidad de Información
Fuente: Propia, 2015
Del total de 20 encuestados, 85% están de acuerdo que ha mejorado la
calidad de la información, mientras un 0.05% no está de acuerdo y un 10% no
opina. Con lo se cumple con la hipótesis propuesta en la tesis.
b) Eficiencia y efectividad
Figura 39. Evaluación eficiencia y efectividad
Fuente: Propia, 2015
17
1 2
0
2
4
6
8
10
12
14
16
18
SI No NA
N°
En c
ues
tad
os
Registro de cumplimiento
Calidad de información
19
0 1
0
5
10
15
20
SI No NA
N°
Encu
esta
do
s
Registro de cumplimiento
Eficiencia y efectividad
91
Del total de 20 encuestados, 95% están de acuerdo que ha mejorado su
eficiencia y productiva con el sistema de inteligencia de negocios, mientras que un
0.05% no opina al respecto. Con lo se cumple con la hipótesis propuesta en la tesis
c) Aumento en la productividad de Ventas
Figura 40. Evaluación Aumento de productividad de ventas
Fuente: Propia, 2015
Del total de 20 encuestados, 90% están de acuerdo que ha aumentado la
productividad de ventas con la solución de sistema de inteligencia de negocios,
mientras que un 0.01% no opina al respecto. Con lo se cumple con la hipótesis
propuesta en la tesis
Figura 41. Crecimiento de ventas Anual
Fuente: Azaleia Perú, 2016
Figura 42. Crecimiento de Puntos de venta
Fuente: Azaleia Perú, 2016
18
0 2
0
5
10
15
20
SI NO NA
N°
Encu
esta
do
s
Registro de cumplimiento
Aumento en la Productividad de ventas
92
3.11. Retorno de Inversión
La tasa de descuento del proyecto utilizada es del 20%, que es el
costo de capital que estima la empresa.
Según las proyecciones del área financiera, el proyecto es rentable
(VAN positiva) al finalizar el cuarto mes de funcionamiento del Data Mart, con
un ingreso adicional proyectado inicial de 10,500 USD desde el primer mes de
explotación, producto del ahorro y/o aumento en ventas previsto, con un flujo
creciente de 50% en cada mes de operación.
93
Conclusiones
En la solución se ha aprovechado todas las capacidades de las herramientas
Qlikview, para la explotación de la información, aumentando mayor tiempo en el
porcentaje de análisis, basado en las encuestas, de la información que en el
propio desarrollo de esta. Además se ha demostrado un mejor acceso a la
información, al cubo OLAP, los diseño de reportes, creación de tableros de
control, alerta proactivas y el acceso vía portal web a toda la información.
No obstante se buscó disponer de forma atractiva e interactiva la información,
así como facilitar su elaboración por parte de los usuarios. Actualmente la
empresa invierte entre 3 a 4 días en la elaboración de reportes y graficas que
viene a ser el 50% del tiempo laboral que emplean. Luego de la implementación
de BI, este tiempo ha sido reducido a horas (4 horas), las cuales están
empleadas para la reportería afianzando el tiempo para el análisis de los
indicadores.
Gracias a la solución implementada se eliminó completamente la dependencia
que se tenía con el área de TI y los sistemas heterogéneos, integrando toda la
información en un repositorio centralizado de fácil acceso, potente y rápido para
el consumo de los usuarios. Los usuarios destacaron la rapidez de las consultas,
la forma de visualización, perfomance, navegación y facilidad para la creación de
nuevos reportes y gráficas.
Cabe resaltar que la solución es escalable, con lo cual permitirá en un futuro la
adecuación e implementación de otros departamentos o áreas de la empresa.
94
Recomendaciones
- Con el fin de explotar al máximo el recurso obtenido en base al Data Mart de
ventas de AZALEIA, para futuros trabajos se recomienda la implementación de
un Data Warehouse con mayores alcances, con el objetivo de tener una mayor
integración con los demás áreas y procesos de la empresa.
- Conforme se vaya teniendo un volumen mayor de información, será necesario
diseñar una nueva arquitectura, que soporte el crecimiento del Data Mart sin
afectar la performance.
- Por otro lado, será importante también revisar las prestaciones del motor de
base de datos y su afinamiento para lograr el rendimiento de tiempo de
respuesta esperado por los usuarios. Posiblemente en un futuro, será necesario
evaluar otras opciones de motores de base de datos, que soporten un mayor
volumen de datos, a fin de asegurar además, la continuidad y disponibilidad del
Data Mart.
- Desde el enfoque del negocio, integrar a aquellas ciudades con mayor
proyección en ventas, haciendo uso de la herramienta Qlikview, aprovechando al
máximo el potencial que brinda el entorno web y el acceso a la información
centralizada. Agilizando de esta forma oportunidades de negocio en cada sector
de los diversos canales de ventas.
- Analizar la implementación de una versión móvil de la solución Qlikview que
permita el acceso desde cualquier dispositivo en el lugar donde se encuentre el
usuario.
95
Referencias Bibliografía
Bazan,W.(2011). Desarrollo de un Datamart con indicadores financieros como
soporte para la toma de decisiones en el departamento financiero del gobierno
autónomo descentralizado Municipal San Francisco de Milagro.(Tesis de Maestría,
Universidad Estatal de Milagro). Recuperado de
http://repositorio.unemi.edu.ec/handle/123456789/74
Bernabeu, R., (2007). Data Warehousing: Investigación y Sistematización de
Conceptos. Metodología Propia para la Construcción de un Data Warehouse.
Bertello, E., (2013). Seminario de Business Intelligence. Buenos Aires: Centro de
Capacitación y Formación Gerencial.
Connolly, T., Begg, C., (2015). Sistemas de base de datos: un enfoque práctico
para diseño, implementación y gestión. Buentos Aires: Pearson Education.
Elías, J. y Zorrilla, F. (2010). Desarrollo de un Datamart para mejorar la toma de
decisiones en el Área de Planificación Comercial del Segmento Premium de
Telefónica del Perú. (Tesis para optar el título de ingeniero, Universidad Mayor de
San Marcos). Recuperado de
http://ateneo.unmsm.edu.pe/ateneo/handle/123456789/2754?mode=full
Inmon, W. (2012) Construyendo un Data Warehouse. 3ra ed. EEUU.: Editorial
Wiley.
Matamoros, Rafael (2010) Implantación en una empresa de un sistema Business
Intelligence SaaS / On Demand a través de la plataforma LITEBI. Universidad
politécnica de Valencia. Recuperado de:
https://riunet.upv.es/bitstream/handle/10251/8591/Proyecto%20II%20-%20C1%20-
%20DMA%20-%2056-09.pdf
Narváez, Jonathan y Otros (2013) titulado “Business intelligence solution for
managing educational resources and physical spaces in Magdalena University.
Colombia. Recuperado de: http://www.unilibre.edu.co/revistaavances/avances-10-
1/Tema_01_inteligencia_negocios.pdf
96
Nase, (2010) Inteligencia de Negocios. 5 pasos para lograr un proyecto de
Business Intelligence exitoso. Recuperado de: http://www.nase-
it.com/pdf/PasosparaBI.pdf
Navarro Ruiz, Fernando (2013) Implantación de una plataforma corporativa de
Business Intelligence. Universitat Oberta de Catalunya. UOC. Recuperado de
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/26761/6/fnavarroruTFC091
3memoria.pdf
Scribano, A. (2008). El proceso de investigación social cualitativa. Buenos Aires:
Prometeo.
Sinnexus (2010) Business Intelligence. Recuperado de
http://www.sinnexus.com/business_intelligence/index.aspx
Vitt, Elizabeth. (2013). Business Intelligence: Técnicas de análisis para la toma de
decisiones importantes. (2ed).Madrid, España: Mcgarw-hill / Interamericana de
España S.A.
Aamodt, Agnar; Nygard, Mads (1995). “Different roles and mutual dependencies
of data, information, and knowledge: an AI perspective on their integration”. En:
Data and Knowledge Engineering, Vol. (16). pp. 191-222.
Fuentes Morales, Bulmaro Adrián (2010): "la gestión de conocimiento en las
relaciones académico-empresariales. Un nuevo enfoque para analizar el impacto
del conocimiento académico." Tesis Phd. Universidad Politécnica de Valencia,
España.
Kimball, Ralph; Ross, Margy (2002). The Datawarehouse Toolkit. New York: Wiley.
Ponjuán Dante, Gloria. 1998. "Gestión de Información en las organizaciones:
Principios, conceptos y aplicaciones", Impresos Universitaria, Chile.
Saaty, Thomas. 2001. Decision making with dependence and FeedBack.
Pittsburgh
97
Suarez J.C, Gomez A. “Sistemas de Información Herramientas Prácticas para la
Gestión Empresarial”. Ra-Ma. Madrid. 2003
Vitt E, Luckevich M, Misner S. "Business Intelligence. Técnicas de análisis para la
toma de decisiones estratégicas". McGrawHill. 2002
Bellatreche L, Karlapalem K, Mohania M. "Chapter Some Issues in Design of
Data Warehousing Systems". Developing quality complex database systems:
practices, techniques and Technologies. IGI Publishing. EEUU. 2001
Cano J.L. “Business Intelligence: Competir con Información”. 2007. Libro publicado
por ESADE, Banesto, Banesto Pyme.
Laudon, Kenneth C., Jane Price Laudon. “Administración de los sistemas de
información: organización y tecnología”. Ed. Prentice-Hall Hispanoamericana”. 1999
Peña, A. (2006). Inteligencia de Negocios: una propuesta para su desarrollo en las
organizaciones. México. Instituto Politécnico Nacional Dirección de Publicaciones.
Scientia et Technica Año XIII, No 34, Mayo de 2007. Universidad Tecnológica de
Pereira. ISSN 0122-1701
98
Anexos
1.1 Formato Alcance – Documento de Especificación de PBI
Fuente: Elaboración propia, 2015
Código
Nombre
Actor
Historia de
Usuario
Tabla
Referencia
ESCENARIO 1
Resultados
Esperados
ESCENARIO 2
Resultados
Esperados
99
1.2 Acta de reunión
ACTA DE REUNIÓN
FECHA DE CREACION:
FECHA DE MODIF.:
ELABORADO POR:
REVISADO POR:
Proyecto / Tema
Lugar de Reunión Fecha Hora
Participante Empresa Abrev. Convocad
o Asistió
ID Agenda Tiempo
ID Temas Tratados
ID Cód. Detalle de Tema Tratado Responsable Fecha
Fuente: Elaboración propia, 2015
100
1.2 Acta de cierre
ACTA DE CIERRE DE PROYECTO
FECHA DE CREACION: 05/12/2014
ELABORADO POR: Jubitza Salazar
Proyecto Inteligencia de Negocios
DATA MART VENTAS
Participantes Cargo
El servicio desarrollado para el “DATA MART DE VENTAS”, se concluyeron en los
siguientes entregables:
Requerimientos
Cronograma del Proyecto (HITO)
Documento de Arquitectura del Sistema
Documento de Especificación de Requerimientos BI
Prototipo
Diccionario de Datos Stage (DBBUSINESS Y AZALEIPERU)
Documento de Especificación de Cubo OLAP
Guía de Usuario
Guía Instalación y Configuración
Aprobación del producto (09/12/14)
Por medio de la presente acta se deja constancia que AZALEIA PERU representado por
los firmantes considera como Cerrado la “IMPLEMENTACION BI DATA MART DE
VENTAS” a cargo de PROVEEDOR.
Luego de la aprobación del producto final, pasa al período de garantía de 02 meses, siendo
días calendarios*, período con el cual el PROVEEDOR se compromete a solucionar
cualquier error o vicio oculto encontrado en la solución en este periodo.
Fecha de Cierre: 05/12/2014
Fecha Inicio de garantía: 09/12/2014
Fecha Fin de garantía: 09/02/2015
En señal de conformidad con lo expuesto en la presente acta, se firma a continuación:
Nota:
_________________________ Firma:
PROVEEDOR
PROVEEDOR
_________________________ Firma:
CLIENTE
PROVEEDOR
101
* Se adjunta el Anexo 1 – Actividades realizadas
** Se adjunta el Anexo 2 - Procedimiento para atender la etapa de Garantía.
** Todos los entregables se encuentran en el portal de SharePoint.
ANEXO 1: ACTIVIDADES REALIZADAS– DATA MART DE VENTAS
Backlog Sprint I:
Tipo Actividades
%
Avance
Planificado Levantamiento de información 100%
Planificado Reglas de negocio 100%
Planificado Documento de especificación de PBI 100%
Planificado Prototipos 100%
Planificado Arquitectura de sistema 100%
Planificado Creación DataStage 100%
Planificado Creación Diccionario de datos 100%
Planificado Creación Power Pivot Tablero 100%
Planificado Validación Datos Inconsistentes 30% 100%
Backlog Sprint II:
Tipo Actividades %
Avance
Planificado Validación Datos Inconsistentes 100% 100%
Planificado Creación de dimensiones y métricas 100%
Planificado Creación del Modelo Físico Data Mart 100%
Planificado Mapeo de Datos 100%
Planificado Proceso de ETL 100%
Planificado Paquetes de Sincronización 100%
Planificado Cubo Dimensional 100%
Planificado Documento de Diseño de Cubo OLAP 100%
Planificado Creación de Qvd y Qvw 100%
Planificado Creación de Tablero 100%
Planificado Creación de Reporte 4 100%
Planificado Despliegue Cubo 100%
Backlog Sprint III:
Tipo Actividades %
Avance
102
Planificado Despliegue Qlikview 100%
Planificado Guía de Usuario 100%
Planificado Guía de Instalación y Configuración 100%
Planificado Termino de Cargas Incrementales 100%
Planificado Programación de Reproceso de Cubo 100%
Planificado Mejoras Funcionales QlikView 100%
Planificado Programación de Carga en el Management Console
QV 100%
Planificado Implementar controles de acceso en QlikView por
pestañas 100%
Planificado Filtros independientes por cada pestaña 100%
Planificado Validación de Querys 100%
Planificado Mejora de Diseño QlikView 100%
Planificado Revisión de Reporte Stock 100%
Planificado Disparador de carga de año Actual QlikView 100%
Planificado Generar permisos para usuarios QlikView 100%
Planificado Creación de tabla de auditoria 100%
Planificado Mantenimiento Base de Datos 100%
Planificado Creación de tabla de periodo de ejecución 100%
ANEXO 2: PROCEDIMIENTO DE GARANTIA
1. Objetivo de la Garantía
Asegurar que la solución desarrollada en este proyecto esté libre de defectos que impidan su funcionamiento de
acuerdo a las especificaciones funcionales correspondientes.
2. Alcance de la Garantía
Solamente defectos atribuidos durante esta consultoría que se presenten después de su puesta en producción.
Defectos en la configuración u operación de software base no forman parte de la presente garantía.
Si se identifican comportamientos de la solución durante el período de certificación que no se ciñen exactamente a
la funcionalidad esperada y el cliente decide que estos comportamientos son aceptables para la solución en
producción, la modificación de estos comportamientos no estará contemplada dentro de los alcances de la garantía.
3. Vigencia
La garantía entra en vigencia desde el día siguiente de la firma del acta de “Cierre del Proyecto”. La puesta en
producción del sistema se considera una aceptación tácita de los entregables de este proyecto.
La duración de la garantía es de 60 días - días calendarios posteriores a la fecha en que se inicia la vigencia como
se indica en el párrafo previo.
4. Condiciones de la Garantía
En caso que cliente o terceros realicen cambios en la aplicación original, la garantía automáticamente queda
anulada.
103
La garantía podrá ser activada solo si el cliente certifica la solución y/o la pone en producción.
En caso de aplicar la garantía fuera del ámbito de la ciudad de Lima Metropolitana, los costos de traslado,
alimentación y alojamiento del personal técnico, corren por cuenta del cliente.
5. Proceso de Atención de Solicitudes de Garantía
En el siguiente cuadro mostramos el proceso de atención a las solicitudes de garantía y el contacto para las
coordinaciones respectivas:
Situación Acciones Esperadas por parte de El
CLIENTE
Respuesta Esperada por Parte de
PORVEEDOR
1. Identificación de un Vicio Oculto o
Error en el ámbito del servicio
realizado.
2. Requiere atención.
1. Atención primaria del soporte
técnico del Cliente, para verificar
incidente.
2. Reporte del incidente al
Proveedor, vía telefónica o correo
electrónico
3. Asignación de un responsable
para hacer las interacciones
conducentes a la resolución del
problema.
1. Respuesta a la petición
(Ticket) en un máximo de
48 horas.
2. Coordinación de nuestro
responsable de soporte
para las actividades a
realizar.
3. Resolución del Ticket, a
más tardar a los 5 días
hábiles de respondida la
petición.
4. Atención 8 horas x 5 días a
la semana.
Persona de Contacto :
Teléfono :
Correo Electrónico :
104
1.3 Diagrama Ishikawa
105
1.4 Cronograma
Id Nombre de tarea Duración Comienzo Fin
1 Cronograma del Proyecto AZALEIA 70 días 25/05/2015 28/08/2015
2 Inicio 1 día 25/05/2015 25/05/2015
6 Planificación 4 días 26/05/2015 29/05/2015
9 Sprints 60 días 01/06/2015 21/08/2015
10 Sprint I 20 días 01/06/2015 26/06/2015
11 Análisis 4 días 01/06/2015 04/06/2015
17 Diseño 3 días 05/06/2015 09/06/2015
22 Construcción 8 días 10/06/2015 19/06/2015
31 Despliegue 5 días 19/06/2015 26/06/2015
42 Finalización Sprint I 0 días 26/06/2015 26/06/2015
43 Sprint II 20 días 29/06/2015 24/07/2015
44 Análisis y Diseño 3 días 29/06/2015 01/07/2015
48 Construcción 9 días 01/07/2015 14/07/2015
58 Despliegue 8 días 15/07/2015 24/07/2015
70 Finalización Sprint II 0 días 24/07/2015 24/07/2015
71 Sprint III 20 días 27/07/2015 21/08/2015
72 Construcción 7 días 27/07/2015 04/08/2015
86 Despliegue 13 días 05/08/2015 21/08/2015
104 Finalización Sprint III 0 días 21/08/2015 21/08/2015
105 Seguimiento y Control 60.5 días 01/06/2015 24/08/2015
120 Cierre 5 días 24/08/2015 28/08/2015
106
1.5 Diseño Multidimensional Cliente
Descripción Corresponde a los clientes de AZALEIA
Tipo Regular
Cambiante Si
Frecuencia de carga Diaria
Jerarquías
1. Cliente
Descripcion Niveles de cliente
Tipo Regular
Natural Sí
Nivel Atributo de base
Canal Canal
TipoCliente TipoCliente
RazonComercial Razon Comercial
2.Supervisor
Descripción Nivel de Supervisor
Tipo Regular
Natural Si
Nivel Atributo de base
Supervisora Supervisora
RazonComercial Razon Comercial
Atributos Tipo PK FK
Descripcion Visible Comportamiento
CodUbigeo VARCHAR(6)
N N Codigo Ubicación Geográfica
No Ninguno
CodCanal VARCHAR(1) N N Codigo de Canal No Ninguno
Canal VARCHAR(11) N N Nombre del Canal Si Ninguno
CodSupervisora
VARCHAR(15) N N Codigo de Supervisora No Ninguno
Supervisora VARCHAR(80) N N Nombre de Supervisora Si Ninguno
TipoCliente VARCHAR(7) S N Calificacion de Cliente: Nuevo o Antiguo
Si Ninguno
CodClienteAnexo
VARCHAR(16) N N Codigo del Cliente No Ninguno
RazonComercial
VARCHAR(100) N N Razon Comercial del
Cliente Si Ninguno
FechaIncripcion
DATE N N Fecha de Inscripción No Ninguno
Grupo NUMERIC(5,0) N N Grupo al que pertence el cliente
No Ninguno
LimiteCreditoSoles
NUMERIC(18,2) N N Límite de crédito en soles
No Ninguno
LimiteCreditoSolesExtension
NUMERIC(18,2) N N Límite de crédito soles Extensión
No Ninguno
LimiteCreditoSolesPedidos
NUMERIC(18,2) N N Límite de crédito soles pedido
No Ninguno
107
Tiempo
Jerarquías
1. Calendario
Descripcion Niveles del Calendario
Tipo Regular
Natural Sí
Nivel Atributo de base
Año Anio
Semestre Semestre
Trimestre Trimestre
Bimestre Bimestre
Mes Mes
Semana Semana
Día Dia
Estado
Atributos Tipo PK FK Descripcion Visible Comportamiento
CodEstado VARCHAR(2) S N Codigo Estado No Ninguno
Estado VARCHAR(2) N N Nombre de Estado Si Ninguno
Producto
Descripción Corresponde al análisis de información en diferentes aristas del tiempo.
Tipo Tiempo
Cambiante Sí
Frecuencia de carga Diaria
Atributos Tipo PK
FK Descripcion Visible Comportamiento
Anio INT N N Año Si Ninguno
CodSemestre
INT N N Numero de Semestre No Ninguno
Semestre VARCHAR(10) N N Nombre del Semestre Si Ninguno
CodTrimestre
INT N N Numero de Trimestre No Ninguno
Trimestre VARCHAR(11) N N Nombre del Trimestre Si Ninguno
CodBimestre INT N N Numero de Bimestre No Ninguno
Bimestre VARCHAR(10) N N Nombre del Bimestre Si Ninguno
CodMes INT N N Número del Mes No Ninguno
Mes VARCHAR(10) N N Nombre del Mes Si Ninguno
CodSemana INT N N Numero de Semana del Año No Ninguno
Semana VARCHAR(10) N N Nombre de Semana del Año Si Ninguno
Dia INT N N Día del Mes Si Ninguno
CodTiempo VARCHAR(10) S N Codito Tiempo No Ninguno
Fecha VARCHAR(10) N N Fecha No Ninguno
Descripción: Contiene la descripción del estado de las importaciones.
Tipo: Regular
Cambiante: Sí
Frecuencia de carga: Úna vez
108
Jerarquías
1. Por Clasificación
Descripcion Listado de Productos por Clasificación
Tipo Regular
Natural Sí
Nivel Atributo de base
Pais Pais
Marca Marca
Clase Clase
Coleccion Coleccion
Categoria Categoría
SubCategoría SubCategoría
Linea Linea
Referencia Referencia
Material Material
Color Color
Talla Talla
Ubigeo
Descripción: Permitirá analizar los productos de la organización
Tipo: Regular
Cambiante: Sí
Frecuencia de carga:
Diario
Atributos Tipo PK FK Descripcion Visible
Comportamiento
CodPais VARCHAR(2) N N Codigo de Pais No Ninguno
Pais VARCHAR(8) N N Nombre de País Si Ninguno
CodMarca VARCHAR(2) N N Codigo de Marca No Ninguno
Marca VARCHAR (15) N N Nombre de Marca Si Ninguno
CodClase VARCHAR(2) N N Codigo de Clase No Ninguno
Clase VARCHAR(50) N N Nombre de Clase Si Ninguno
CodColeccion VARCHAR(2) N N Codigo de Colección No Ninguno
Coleccion VARCHAR(50) N N Nombre de Colección Si Ninguno
CodCategoria VARCHAR(3) N N Codigo de Categoría No Ninguno
Categoria VARCHAR(120) N N Nombre de Categoría Si Ninguno
CodSubCategoria
VARCHAR(3) N N Codigo de SubCategoría
No Ninguno
SubCategoria VARCHAR(120) N N Nombre de SubCategoría
Si Ninguno
CodLinea VARCHAR(3) N N Codigo de Linea No Ninguno
Linea VARCHAR(25) N N Nombre de Linea Si Ninguno
CodReferencia VARCHAR(3) N N Codigo de Referencia No Ninguno
Referencia VARCHAR(50) N N Nombre de Refernecia
Si Ninguno
CodMaterial VARCHAR(3) N N Código de Material No Ninguno
Material VARCHAR(101) N N Nombre de Material No Ninguno
CodColor VARCHAR(6) N N Codigo Color No Ninguno
Color VARCHAR(50) N N Nombre de Color No Ninguno
CodTalla VARCHAR(5) N N Codigo Talla No Ninguno
CodProducto VARCHAR(4) S N Codigo de Producto No Ninguno
Producto VARCHAR(214) N N Nombre del Producto No Ninguno
109
Atributos Tipo PK F
K Descripcion Visibl
e Comportamiento
CodDepartamento VARCHAR(2) N N Codigo de Departamento
No Ninguno
Departamento VARCHAR(50) N N Nombre del Departamento
Si Ninguno
CodProvincia VARCHAR(4) N N Codigo Provincia No Ninguno
Provincia VARCHAR(50) N N Nombre de Provincia Si Ninguno
CodUbigeo VARCHAR(6) S N Codigo Ubicación Geográfica
No Ninguno
Distrito VARCHAR(30) N N Nombre del distrito Si Ninguno
Jerarquías
1. Ubigeo
Descripcion Como se divide la ubicación geográfica
Tipo Regular
Natural Sí
Nivel Atributo de base
Departamento Departamento
Provincia Provincia
Distrito Ubigeo
Tienda Descripción: Contiene los canales de venta de la organización
Tipo: Regular
Cambiante: Sí
Frecuencia de carga: Diario
Atributos Tipo P
K FK Descripcion Visible Comport
amiento
CodUbigeo VARCHAR(6) N N Codigo Ubicación Geográfica No Ninguno
CodTipo CHAR(1) S N Codigo Tipo Tienda No Ninguno
Tipo VARCHAR(9) N N Nombre TipoTienda Si Ninguno
CodTienda SMALLINT N N Codigo Tienda No Ninguno
Tienda VARCHAR(100) S N Nombre de la Tienda SI Ninguno
Jerarquías
1. Por Tipo
Descripcion Tipo de Tienda
Tipo Regular
Natural Sí
Nivel Atributo de base
Tipo Tipo
Descripción Refiere a la ubicación geográfica de los diferentes puntos de análisis de la aplicacion.
Tipo Regular
Cambiante Sí
Frecuencia de carga Diaria
110
Tienda Tienda
Vendedor Descripción: Permite analizar a los vendedores de AZALIA
Tipo: Regular
Cambiante: Sí
Frecuencia de carga: Diaria
Atributos Tipo PK FK Descripcion Visible Comporta
miento
CodVendedor INT S N Codigo de Vendedor No Ninguno
Vendedor INT N F Nombre de Vendedor Si Ninguno
Fact Venta Descripción: Permite analizar las ventas de AZALEIA
Tipo: Contable
Cambiante: Sí
Frecuencia de carga: Diaria
Atributos Tipo PK FK Descripción Visibl
e Comportamiento
CodClienteAnexo VARCHAR(23) N S Código del Cliente Si Ninguno
CodEstadoVenta VARCHAR(3) N N Código de Estado Venta No Ninguno
CodProducto VARCHAR(28) N S Código Producto No Ninguno
CodTiempo VARCHAR(10) N S Código Tiempo No Ninguno
CodTienda CHAR(1) N S Código Tienda
No Ninguno
CodVendedor VARCHAR(50) N S Código Vendedor Si Ninguno
CodCatalogo INT N N Código de Catalogo
No Ninguno
CodDoc VARCHAR(3) N N Código de Documento No Ninguno
NroSer VARCHAR(3) N N Número de Serie No Ninguno
NroDoc VARCHAR(8) N N Numero de documento No Ninguno
Moneda VRACHAR(3) N N Moneda(SOL,DOL) Si Ninguno
TipoCambio NUMERIC(18,5) N N Tiempo de Cambio No Ninguno
CantidadPares NUMERIC(38,0) N N Cantidad de Pares Si Ninguno
ParValor NUMERIC(20,4) N N Par Valor No Ninguno
CostoVenta NUMERIC(38,2) N N Costo de Venta Si Ninguno
ImporteVenta NUMERIC(38,2) N N Importe de Venta Si Ninguno
ImporteDescuento NUMERIC(38,2) N N Importe del Descuento Si Ninguno
ImporteTotal NUMERIC(38,2) N N Importe Total Si Ninguno
FchVence DATATIME N N Fecha Vencimiento No Ninguno
CondicionVenta VRACHAR(3) N N Condición Venta No Ninguno
DctoPieVenta NUMERIC(18,4) N N Descuento Pie de Venta
No Ninguno
DctoPtoPago NUMERIC(4,2) N N Descuento Pronto Pago
No Ninguno
PctjImpto NUMERIC(21,5) N N Porcentaje Impuesto No Ninguno
Impuesto NUMERIC(38,2) N N Impuesto No Ninguno
HoraProceso DataTime N N Hora Proceso No Ninguno
FactMeta Tienda Descripción: Permite analizar las metas de los canales de venta:
Tienda,Catalogo,outlet e internet
Tipo: Contable
Cambiante: Sí
111
Frecuencia de carga: Mensual
Atributos Tipo P
K FK Descripción Visible Comportami
ento
CodTiempo VARCHAR(6) N S Código Tiempo No Ninguno
CodTienda NUMERIC(8,0)
N S Código de Tienda No Ninguno
MetaCantidadPares
NUMERIC(18,0)
N N Metas de Cantidad de Pares
Si
MetaMontoCobranza
NUMERIC(18,2)
N N Meta de Monto Cobranza Si Ninguno
LimaProvincia VARCHAR(1) N N Indicador de ubicación geográfica de la Meta.
No Nignuno
FactMeta Cobranza Vendedor Descripción: Permite analizar las metas y cobranza de los vendedores del canal
de venta mayorista.
Tipo: Contable
Cambiante: Sí
Frecuencia de carga: Diaria
Atributos Tipo PK FK Descripcion Visible Comporta
miento
CodTiempo
VARCHAR(6) N S Codigo Tiempo No Ninguno
CodVendedor
NUMERIC(15) N S Codigo de Vendedor No Ninguno
MetaVendedorNroPares
NUMERIC(18,0) Meta Vendedor numero pares
No Ninguno
MontoCobranza
MONEY N N Monto Cobranza del vendedor
Si Ninguno
MetaMontoCobranza
NUMERIC(18,2) N N Indicador de ubicación geográfica de la Meta.
Si Ninguno
FactStock Descripción: Permite analizar el stock por cada canal de venta
Tipo: Contable
Cambiante: Sí
Frecuencia de carga: Diaria
Atributos Tipo PK FK Descripcion Visible Comportami
ento
CodAlmacen NUMERIC(15) N N Codigo de Vendedor No Ninguno
CodProducto MONEY N S Monto Cobranza del vendedor
No Ninguno
CodTiempo NUMERIC(18,2) N S Indicador de ubicación geográfica de la Meta.
No Ninguno
CodTienda VARCHAR(6) N S Codigo Tiempo No Ninguno
CodClienteAnexo
VARCHAR(17) N N
Codigo Cliente Anexo No Ninguno
CodEstadoStock
VARCHAR(3) N N
Codigo Estado No Ninguno
CodProceso VARCHAR(2) N N
Codigo de Proceso No Ninguno
CodItm INT N N
Codigo Item No Ninguno
112
CodMov INT N N
Codigo Movimiento No Ninguno
CodMon VARCHAR(3) N N
Codigo Moneda No Ninguno
CodCaja VARCHAR(10) N N
Codigo Caja No Ninguno
CodCatalogo INT N N
Codigo Catalogo No Ninguno
CodDoc VARCHAR(3) N N
Codigo Documento No Ninguno
NroSer VARCHAR(5) N N
Numero de Serie No Ninguno
NroDoc VARCHAR(20) N N
Numero de Documento No Ninguno
MovTipo VARCHAR(6) N N
Tipo de Movimiento No Ninguno
MovCpto VARCHAR(11) N N
Movimiento Concepto No Ninguno
OrgCodEmp INT N N
Codigo Empresa Origen No Ninguno
OrgCodAlm INT N N
Codigo Almacen Origen No Ninguno
DstCodAlm INT N N
Codigo Almacen destino No Ninguno
DstCodEmp INT N N
Codigo Empresa destino No Ninguno
ArtCant SMALLINT N N
Cantidad de productos No Ninguno
ArtValor NUMERIC(18,2) N N
Valor del productos No Ninguno
ValorDefFac NUMERIC(22,10)
N N Costo Unitario en dolares No Ninguno
ValorDefFacTot
NUMERIC(22,10)
N N Total costo en dolares No Ninguno
ValorOtrFac NUMERIC(22,10)
N N Costo unitario en soles No Ninguno
ValorOtrFacTot
NUMERIC(22,10)
N N Total costo en soles No Ninguno
Ingresos INT N N
Ingresos No Ninguno
Salidas INT N N
Egresos No Ninguno
Stock INT N N Stock(ingreso-egresos) Si Ninguno
FactStock Pendiente Descripción: Permite analizar el stock pendiente por facturar de los vendedores
del canal de venta mayorista
Tipo: Contable
Cambiante: Sí
Frecuencia de carga: Diaria
113
Atributos Tipo PK FK Descripcion Visible Comportamiento
CodAlmacen INT N N Codigo Almacen No Ninguno
CodClienteAnexoOriginal
VARCHAR(18) N N Codigo cliente anexo original
No Ninguno
CodClienteAnexoFinal
VARCHAR(18) N N Codigo Cliente Anexo Final
No Ninguno
CodProducto VARCHAR(25) N N
Codigo Producto No Ninguno
CodVendedorOriginal VARCHAR(15) N N Codigo vendedor
original No
Ninguno
CodVendedorFinal VARCHAR(15) N N
Codigo vendedor final No Ninguno
OrgCodCaja VARCHAR(8) N N
Código caja original No Ninguno
CodCaja VARCHAR(20) N N
Codigo Caja No Ninguno
PedNro INT N N
Numero de Pedido No Ninguno
PedItm SMALLINT N N
Item de Pedido No Ninguno
CodSolic INT N N
Codigo de Slicitud No Ninguno
ParCant SMALLINT N N
Cantidad de pares Si Ninguno
ParTalla1 VARCHAR(5) N N
Nro de talla de Par1 No Ninguno
ParCant1 TINYINT N N Cantidad de pares de
Talla 1
No Ninguno
ParTalla2 VARCHAR(5) N N
Nro de talla de Par2 No Ninguno
ParCant2 TINYINT N N Cantidad de pares de
Talla 2
No Ninguno
ParTalla3 VARCHAR(5) N N
Nro de talla de Par3 No Ninguno
ParCant3 TINYINT N N Cantidad de pares de
Talla 3
No Ninguno
ParTalla4 VARCHAR(5) N N
Nro de talla de Par4 No Ninguno
ParCant4 TINYINT N N Cantidad de pares de
Talla 4
No Ninguno
ParTalla5 VARCHAR(5) N N
Nro de talla de Par5 No Ninguno
ParCant5 TINYINT N N Cantidad de pares de
Talla 5
No Ninguno
ParTalla6 VARCHAR(5) N N
Nro de talla de Par6 No Ninguno
ParCant6 TINYINT N N Cantidad de pares de
Talla 6
No Ninguno
ParTalla7 VARCHAR(5) N N
Nro de talla de Par7 No Ninguno
ParCant7 TINYINT N N Cantidad de pares de
Talla 7
No Ninguno
ParTalla8 VARCHAR(5) N N
Nro de talla de Par8 No Ninguno
ParCant8 TINYINT N N Cantidad de pares de
Talla 8
No Ninguno
ParPrecio MONEY N N
Par Precio No Ninguno
114
ParPrecioFinalMon VARCHAR(5) N N Par Precio Final
Monto
No Ninguno
ParFob MONEY N N Precio Fob de un par No Ninguno
ParCostoDef MONEY N N Par costo en dolares No Ninguno
ParCostoDefMon VARCHAR(5) N N Moneda de Par No Ninguno
CodLote TINYINT N N Codigo Lote No Ninguno
CodLado CHAR(1) N N Codigo Lado No Ninguno
CodParhl TINYINT N N Codigo Parihuela No Ninguno
CodRac VARCHAR(3) N N Codigo Rac No Ninguno
VtaEstado VARCHAR(2) N N Estado de Caja No Ninguno
VtaProceso VARCHAR(2) N N Porceso de Caja No Ninguno
VtaSelec VARCHAR(2) N N Selección de Caja No Ninguno
OrgFacCod VARCHAR(10) N N Original de código factura
No Ninguno
ParPrecioOriginal NUMERIC(18,2)
N N Precio orginal por par No Ninguno
FactCobranza Descripción: Permite analizar la cobranza realizada diaria por lo vendedores en
el canal de venta mayorista
Tipo: Contable
Cambiante: Sí
Frecuencia de carga: Diaria
Atributos Tipo PK FK Descripcion Visible Comport
amiento
CodClienteAnexo VARCHAR(18) NO SI Codigo cliente anexo No Ninguno
CodTiempo VARCHAR(8) NO SI Código tiempo No Ninguno
CodVendedor VARCHAR(15) NO SI Codigo Vendedor No Ninguno
CodBanco SMALLINT NO NO
Codigo Banco No Ninguno
CodCuenta SMALLINT NO NO
Codigo de Cuenta No Ninguno
MontoCobranza MONEY NO NO
Monto Cobranza Si Ninguno
PlaNro VARCHAR(10) NO NO
Numero de Planilla No Ninguno
PlaDoc VARCHAR(3) NO NO Documento de
Planilla
No Ninguno
PlaItm NUMERIC(18,0)
NO NO Item de Planilla
No Ninguno
FlgPago TINYINT NO NO
Flag de Pago No Ninguno
OrgCodDoc VARCHAR(3) NO NO Código de documento
Original
No Ninguno
OrgNroSer VARHCAR(3) NO NO Numero de Serie
Original
No Ninguno
OrgNroDoc VARHCAR(8) NO NO Numero de
Documento Original
No Ninguno
TipoDep VARHCAR(5) NO NO
No Ninguno
NroTarjeta VARHCAR(50) NO NO
Numero de Tarjeta No Ninguno
NroVoucher VARHCAR(20) NO NO
Numero de Voucher No Ninguno
PagoDocCod VARHCAR(3) NO NO Código de documento
pago
No Ninguno
PagoDocSer VARHCAR(3) NO NO Serie de documento
de pago
No Ninguno
115
PagoDocNro VARHCAR(10) NO NO Numero de
documento de pago
No Ninguno
TipCam NUMERIC(18,5)
NO NO Tipo de cambio
No Ninguno
CbrImporte MONEY NO NO Importe en moneda
de pago
No Ninguno
CbrInteres MONEY NO NO Interés en moneda de
apgo
No Ninguno
CbrGastos MONEY NO NO Gastos en moneda
de pago
No Ninguno
CbrPercepcion MONEY NO NO Percepción en
modena de pago
No Ninguno
CbrTotal MONEY NO NO Total en moneda de
pago
No Ninguno
CbrMoneda VARHCAR(3) NO NO
Moneda de pago No Ninguno
DefImporte MONEY NO NO
Importe en dolares No Ninguno
DefInteres MONEY NO NO
Interés en dolares No Ninguno
DefGastos MONEY NO NO
Gastos en dolares No Ninguno
DefPercepcion MONEY NO NO Percepcion en
dolares
No Ninguno
DefTotal MONEY NO NO Total en dolares No Ninguno
OtrImporte MONEY NO NO Importe en soles No Ninguno
OtrInteres MONEY NO NO Interses en Soles No Ninguno
OtrGastos MONEY NO NO Gastos en Soles No Ninguno
OtrPercepcion MONEY NO NO Percepción en Soles No Ninguno
OtrTotal MONEY NO NO Total en soles No Ninguno
TxtObserv VARCHAR(500)
NO NO Observaciones No Ninguno
Fact Pedido Descripción: Permite analizar los pedidos de importación de los diferentes
canales de venta
Tipo: Contable
Cambiante: Sí
Frecuencia de carga: Diaria
Atributos Tipo PK FK Visible Comporta
miento
CodClienteAnexo VARCHAR(18) NO SI Codigo Cliente Anexo
No Ninguno
CodEstado VARCHAR(2) NO SI Codigo Estado No Ninguno
CodProducto VARCHAR(25) NO SI Codigo Producto No Ninguno
CodTiempo VARCHAR(10) NO SI
Codigo Tiempo No Ninguno
CodVendedor VARCHAR(15) NO SI
Codigo Vendedor No Ninguno
CodPedido VARCHAR(25) NO NO
Codgio Pedido No Ninguno
PedItm TINYINT NO NO Numero Item de
Pedido No
Ninguno
PedNro INT NO NO
Numero de Pedido No Ninguno
TotPedido SMALLINT NO NO Numero de Total de
pedido SI
Ninguno
ParTalla1 VARCHAR(5) NO NO Numero de Talla de
Par 1 No
Ninguno
116
ParCant1 SMALLINT NO NO
Cantidad de Talla 1 No Ninguno
ParTalla2 VARCHAR(5) NO NO Numero de Talla de
Par 2 No
Ninguno
ParCant2 SMALLINT NO NO
Cantidad de Talla 2 No Ninguno
ParTalla3 VARCHAR(5) NO NO Numero de Talla de
Par 3 No
Ninguno
ParCant3 SMALLINT NO NO
Cantidad de Talla 3 No Ninguno
ParTalla4 VARCHAR(5) NO NO Numero de Talla de
Par 4 No
Ninguno
ParCant4 SMALLINT NO NO
Cantidad de Talla 4 No Ninguno
ParTalla5 VARCHAR(5) NO NO Numero de Talla de
Par 5 No
Ninguno
ParCant5 SMALLINT NO NO
Cantidad de Talla 5 No Ninguno
ParTalla6 VARCHAR(5) NO NO Numero de Talla de
Par 6 No
Ninguno
ParCant6 SMALLINT NO NO
Cantidad de Talla 6 No Ninguno
ParTalla7 VARCHAR(5) NO NO Numero de Talla de
Par 7 No
Ninguno
ParCant7 SMALLINT NO NO
Cantidad de Talla 7 No Ninguno
ParTalla8 VARCHAR(5) NO NO Numero de Talla de
Par 8 No
Ninguno
ParCant8 SMALLINT NO NO
Cantidad de Talla 8 No Ninguno
ValorVenta NUMERIC(18,2)
NO NO Valor venta No
Ninguno
ValorIgv NUMERIC(18,2)
NO NO Valor IGV No
Ninguno
PrecioUnitario NUMERIC(18,2)
NO NO Precio Unitario No
Ninguno
PrecioVenta NUMERIC(18,2)
NO NO Precio Venta No
Ninguno
117
1.6 Cubo OLAP Jerarquía Cliente
118
Jerarquía Producto
119
Jerarquía Tiempo
120
1.6 Encuestas de satisfacción
Se realizó una encuesta para un total de 10 personas, Se muestra la estructura
De dicha encuesta con las preguntas realizadas.
121
1.7 Evaluación de resultados
Nombre: XXXXXXXX
Cargo: XXXXXXXXXXX
Lugar y Fecha:
Lima – Perú 2014
N° Puntos de Evaluación Registro de
Cumplimiento
SI NO NA
1 Hace uso de la solución de inteligencia
de negocios para la toma de decisiones
2 La solución de inteligencia de negocios
responde de manera adecuada ante las
necesidades del negocio
3 La solución de inteligencia de negocios,
le permite realizar búsquedas de
información de manera rápida
4 Es buena la experiencia de usuario en el
uso de la solución de inteligencia de
negocio
5 La solución de inteligencia de negocios
cumple con los objetivos principales de
rapidez e información confiable
6 La solución de inteligencia de negocios
le permite realizar análisis a nivel de
detalle
7 Son entendibles los resultados
mostrados en la solución de inteligencia
de negocios
8 Cree que ha mejorado el tiempo de
respuesta en el desarrollo de la
información con la solución de
inteligencia de negocio
9 Percibe una mejora en la productividad
de las ventas con la solución de
inteligencia de negocios.