VICERRECTORADO DE INVESTIGACIÓN

INNOVACIÓN Y TRANSFERENCIA TECNOLÓGICA

DIRECCIÓN DE POSTGRADOS

TESIS PREVIO A LA OBTENCIÓN DEL TÍTULO DE MAGÍSTER

EN GERENCIA DE SISTEMAS

TEMA: "DESARROLLO DE UN APLICATIVO BUSINESS

INTELLIGENCE PARA LA EMPRESA IMPORTADORA
TOMEBAMBA S.A."

AUTOR: DANIELA ELIZABETH MOLINA ZAMORA

DIRECTOR: ING. PAUL OCHOA A., MBA, CISA

SANGOLQUÍ

2015
 ii
CERTIFICACIÓN DEL DIRECTOR

Certifico que el presente trabajo titulado: “DESARROLLO DE UN

APLICATIVO BUSINESS INTELLIGENCE PARA LA EMPRESA
IMPORTADORA TOMEBAMBA S.A.”, fue realizado en su totalidad por la
Ingeniera DANIELA ELIZABETH MOLINA ZAMORA, como requerimiento
parcial a la obtención del título de MAGISTER EN GERENCIA DE
SISTEMAS.
DECLARACIÓN DE RESPONSABILIDAD
AUTORIZACIÓN
 DEDICATORIA

Esta tesis va dedicada a mi familia, por ser el pilar fundamental de mi

vida, por enseñarme la importancia de superarme cada día y de seguir
adelante para conseguir las metas planteadas, sin importar todos los
obstáculos que se presenten en el camino. Además extiendo esta
dedicatoria a ese ser especial que es parte ahora de mi familia y que me
apoyó incondicionalmente en cada instante de este importante proyecto, mi
esposo.

Daniela
 AGRADECIMIENTO

El desarrollo y culminación de esta tesis ha sido gracias al constante

apoyo de mis padres, hermanos, cuñados y sobrinos quienes aceptaron mis
ausencias y nunca dejaron de brindarme ánimo y cariño.
Tengo un agradecimiento especial a mi director de tesis el Ing. Paúl
Ochoa ya que con su experiencia y altos conocimientos me supo guiar de la
mejor manera en todo el proceso de mi tesis. A mi oponente el Ing. Paúl
Díaz, por su ayuda y sus importantes sugerencias. A mi coordinador y
miembro de tribunal el Ing. Carlos Procel, por estar siempre dispuesto a
ayudarme en todos los trámites que involucró esta tesis.
Además agradezco a la Universidad de las Fuerzas Armadas ESPE y a
la empresa Importadora Tomebamba S.A. por aceptar este proyecto y ver la
importancia de desarrollar Inteligencia de Negocios.
Finalmente muchas gracias al Ing. Geovanny Martínez por ser un apoyo
en todo momento, por sembrar en mí el gusto por la Inteligencia de Negocios
y por compartir conmigo este gran logro.
 ÍNDICE DE CONTENIDOS
CERTIFICACIÓN DEL DIRECTOR....................................................................................................... II

DECLARACIÓN DE RESPONSABILIDAD............................................................................................ III

AUTORIZACIÓN............................................................................................................................ IV

DEDICATORIA................................................................................................................................ V

AGRADECIMIENTO........................................................................................................................ VI

ÍNDICE DE CONTENIDOS.............................................................................................................. VII

ÍNDICE DE TABLAS......................................................................................................................... X

ÍNDICE DE GRÁFICOS..................................................................................................................... XI

RESUMEN................................................................................................................................... XIV

ABSTRACT................................................................................................................................... XV

CAPÍTULO I.................................................................................................................................... 1

INTRODUCCIÓN............................................................................................................................. 1

1.1 TEMA......................................................................................................................................1
1.2 ANTECEDENTES......................................................................................................................1
1.3 JUSTIFICACION E IMPORTANCIA............................................................................................1
1.4 DEFINICION DEL PROBLEMA...................................................................................................2
1.5 OBJETIVOS..............................................................................................................................3
1.5.1 Objetivo General............................................................................................................3
1.5.2 Objetivos Específicos.....................................................................................................3
1.6 ALCANCE DEL PROYECTO........................................................................................................3
1.7 METODOLOGÍA DE TRABAJO A UTILIZARSE...........................................................................4

CAPITULO II................................................................................................................................... 5

MARCO TEÓRICO........................................................................................................................... 5

2.1 IMPORTADORA TOMEBAMBA................................................................................................5

2.1.1 Reseña Histórica............................................................................................................5
2.1.2 Importadora Tomebamba S.A. en el Ecuador...............................................................5
2.1.3 Misión............................................................................................................................6
2.1.4 Visión.............................................................................................................................6
2.1.5 Filosofía, Acciones y Valores..........................................................................................6
2.1.6 Estructura Organizacional.............................................................................................7
2.1.7 Líneas de Comercialización............................................................................................8
2.1.8 Descripción y Cambios de la Línea de Repuestos..........................................................9
2.2 INTELIGENCIA DE NEGOCIO..................................................................................................10
2.2.1 Definición.....................................................................................................................10
2.2.2 Características.............................................................................................................12
 2.2.3 Componentes...............................................................................................................13
2.2.3.1 Análisis OLAP.......................................................................................................................15
2.2.3.2 Conceptos y Componentes..................................................................................................15
2.2.3.2.1 Cubos OLAP....................................................................................................................15
2.2.3.2.2 Medidas.........................................................................................................................16
2.2.3.2.3 Dimensiones..................................................................................................................16
2.2.3.2.4 Niveles...........................................................................................................................16
2.2.3.3 Formas de almacenar información en los cubos..................................................................16
2.2.3.4 Operaciones analíticas básicas con OLAP............................................................................17
2.2.3.5 Esquemas para el modelado de datos.................................................................................17
2.3 METODOLOGÍAS PARA EL DESARROLLO DE BI.....................................................................19
2.3.1 Selección de Metodología...........................................................................................20
2.4 METODOLOGÍA KIMBALL......................................................................................................21
2.4.1 Planificación del Proyecto...........................................................................................21
2.4.2 Análisis de Requerimientos.........................................................................................21
2.4.3 Flujo Tecnológico.........................................................................................................22
2.4.3.1 Diseño de la Arquitectura Técnica.......................................................................................22
2.4.3.2 Selección de Productos e Implementación..........................................................................22
2.4.4 Flujo de Datos..............................................................................................................22
2.4.4.1 Modelado Dimensional........................................................................................................22
2.4.4.1.1 Pequeños Cambios en Dimensiones...............................................................................24
2.4.4.2 Diseño Físico........................................................................................................................25
2.4.4.3 Diseño e Implementación del Subsistema de ETL................................................................25
2.4.5 Flujo de Integración de Aplicaciones de Inteligencia de Negocios.......................................25
2.4.5.1 Especificación de aplicaciones de BI....................................................................................25
2.4.5.2 Desarrollo de aplicaciones de BI..........................................................................................25
2.4.6 Implementación...........................................................................................................25
2.4.7 Mantenimiento y Crecimiento.....................................................................................26
2.4.8 Administración del Proyecto de DW/BI.......................................................................26

CAPITULO III................................................................................................................................. 27

APLICACIÓN DE METODOLOGÍA Y DESARROLLO DE LA SOLUCIÓN.................................................27

3.1 PLANIFICACION DEL PROYECTO...........................................................................................27

3.1.1 Definición del Proyecto................................................................................................27
3.1.2 Justificación y Objetivos..............................................................................................27
3.1.3 Alcance........................................................................................................................27
3.1.4 Identificación de Roles.................................................................................................29
3.1.5 Estrategia y método de Implementación....................................................................29
3.1.6 Origen de la fuente de Datos.......................................................................................29
3.2 ANÁLISIS DE REQUERIMIENTOS...........................................................................................29
3.2.1 Investigación Previa.....................................................................................................29
3.2.2 Entrevistas...................................................................................................................30
3.2.3 Documentación de Requerimientos............................................................................30
3.3 DISEÑO DE LA ARQUITECTURA TECNICA..............................................................................34
3.3.1 Ambiente Back Room..................................................................................................34
3.3.2 Ambiente Front Room.................................................................................................35
3.3.3 Arquitectura de la aplicación......................................................................................36
3.4 SELECCIÓN DE PRODUCTOS E IMPLEMENTACIÓN...............................................................37
3.4.1 Motor de Base de Datos..............................................................................................37
 3.4.2 Herramienta para implementar la solución BI............................................................37
3.5 MODELADO DIMENSIONAL..................................................................................................38
3.5.1 Modelo 1 - Ventas Netas de Repuestos.......................................................................39
3.5.2 Modelo 2 - Detalle de Ventas de Repuestos................................................................50
3.5.3 Modelo 3 - Compras de Repuestos..............................................................................56
3.5.4 Modelo 4 - Inventario de Repuestos............................................................................60
3.5.5 Modelo 5 - Detalle de Reservas...................................................................................63
3.5.6 Modelo 6 - Detalle de Inventario de Repuestos..........................................................67
3.5.7 Modelo 7 - Comparación de Resultados y Metas........................................................71
3.5.8 Modelo 8 - Seguimiento de Clientes de las tres líneas de análisis..............................74
3.6 DISEÑO FISICO......................................................................................................................81
3.7 DISEÑO E IMPLEMENTACION DEL SUBSISTEMA ETL............................................................83
3.7.1 Dim_Fecha...................................................................................................................85
3.7.2 Dim_Agencia...............................................................................................................86
3.7.3 Dim_Cliente.................................................................................................................87
3.7.4 Dim_Asesor..................................................................................................................89
3.7.5 Dim_TipoVenta............................................................................................................90
3.7.6 Hecho_VentaNeta.......................................................................................................91
3.8 ESPECIFICACION Y DESARROLLO DE APLICACIONES BI........................................................92
3.8.1 CONSTRUCCIÓN DE CUBOS OLAP............................................................................................92
3.8.1.1 VENTASNETAS...................................................................................................................................................93
3.8.2 APLICACIÓN PARA USUARIOS FINALES............................................................................94
3.8.2.1 REPORTE Y ANÁLISIS DE VENTAS NETAS..........................................................................94
3.8.2.2 REPORTE Y ANÁLISIS DE VENTAS A CRÉDITO Y CONTADO..............................................95
3.8.2.3 KPI´S...................................................................................................................................................................96
3.9 IMPLEMENTACIÓN...............................................................................................................97
3.10 MANTENIMIENTO Y CRECIMIENTO......................................................................................98
3.11 ADMINISTRACIÓN DEL PROYECTO DW/BI.........................................................................101
3.12 DATA MINING PARA EL AREA DE VENTAS..........................................................................101
3.12.1 ALGORITMO DE PREDICCIÓN.........................................................................................102
3.12.1.1 ALGORITMO DE ESTIMACIÓN O REGRESIÓN............................................................103

CAPITULO IV.............................................................................................................................. 105

CONCLUSIONES Y RECOMENDACIONES......................................................................................105

4.1 CONCLUSIONES..................................................................................................................105
4.2 RECOMENDACIONES..........................................................................................................106

BIBLIOGRAFÍA............................................................................................................................ 109

GLOSARIO Y ACRÓNIMOS.......................................................................................................... 111

ANEXO 1.................................................................................................................................... 115

ANEXO 2.................................................................................................................................... 118

ANEXO 3.................................................................................................................................... 129

ANEXO 4.................................................................................................................................... 133

ANEXO 5.................................................................................................................................... 145

 ÍNDICE DE TABLAS

Tabla 1 Tecnologías OLTP vs. OLAP...................................................................................15

Tabla 2 Formas de almacenamiento en los cubos OLAP.....................................................17
Tabla 3 Diferencias entre Metodologías BI...........................................................................20
Tabla 4 Requerimientos agrupados por temas analíticos y Procesos de Negocio................31
Tabla 5 Matriz de Procesos / Dimensiones del Data Mart para el Departamento de
Repuestos............................................................................................................................. 33
Tabla 6 Herramientas de PENTAHO.....................................................................................37
Tabla 7 Resumen del Proceso Iterativo del Modelado Dimensional.....................................38
Tabla 8 Atributos de Dimensión Fecha.................................................................................40
Tabla 9 Atributos de Dimensión Agencia..............................................................................41
Tabla 10 Atributos de Dimensión Cliente..............................................................................42
Tabla 11 Atributos de la Dimensión Asesor..........................................................................45
Tabla 12 Atributos de la Dimensión Tipo de Venta...............................................................46
Tabla 13 Atributos de la Dimensión Tipo de Transacción.....................................................47
Tabla 14 Atributos de la Tabla de Hechos VentaNeta...........................................................48
Tabla 15 Atributos de Dimensión Item..................................................................................51
Tabla 16 Atributos de Dimensión ICC...................................................................................52
Tabla 17 Atributos de la Tabla de Hechos Detalle de Ventas...............................................53
Tabla 18 Atributos de Dimensión Proveedor.........................................................................57
Tabla 19 - Atributos de la Tabla de Hechos Compras de Repuestos....................................58
Tabla 20 Atributos de la Tabla de Hechos Inventario............................................................61
Tabla 21 Atributos de Dimensión Estado de Proforma..........................................................64
Tabla 22 - Atributos de la Tabla de Hechos de Detalle de Reservas....................................65
Tabla 23 Atributos de Dimensión de Línea de Venta............................................................68
Tabla 24 Atributos de la Tabla de Hechos Detalle de Inventario...........................................69
Tabla 25 Atributos de la Tabla de Hechos de Comparación de Metas..................................72
Tabla 26 Atributos de Dimensión Tipo de Compra en ITSA..................................................75
Tabla 27 Atributos de la Tabla de Hechos de Seguimiento de Clientes................................76
Tabla 28 Matriz de Procesos / Dimensiones Detallada del Data Mart para el Departamento
de Repuestos........................................................................................................................ 79
 ÍNDICE DE FIGURAS

Figura 1 - Business Dimensional Lifecycle - Metodología de Kimball.....................................4

Figura 2 - Importadora Tomebamba en el Ecuador.................................................................6
Figura 3 - Estructura Organizacional de ITSA.........................................................................8
Figura 4 - El Estilo Toyota en Ventas y Mercadotecnia...........................................................9
Figura 5 - Definición de Inteligencia de Negocios.................................................................11
Figura 6 - Componentes Solución BI.....................................................................................13
Figura 7 - Procesos ETL....................................................................................................... 14
Figura 8 - Esquema Estrella.................................................................................................. 18
Figura 9 - Esquema Copo de Nieve......................................................................................19
Figura 10 - Modelo Kimball................................................................................................... 20
Figura 11 - Proceso iterativo del Modelado Dimensional......................................................23
Figura 12 - Estructura de Desglose del Trabajo (EDT).........................................................28
Figura 13 - Diseño de la Arquitectura Técnica......................................................................34
Figura 14 - Ambiente Back Room......................................................................................... 34
Figura 15 - Ambiente Front Room......................................................................................... 35
Figura 16 - Arquitectura de la aplicación...............................................................................36
Figura 17 - Gráfico de Burbujas de Ventas Netas de Repuestos..........................................39
Figura 18 - Modelo Dimensional 1 - Ventas Netas de Repuestos.........................................49
Figura 19 - Gráfico de Burbujas de Detalle de Ventas de Repuestos...................................50
Figura 20 - Modelo Dimensional 2 - Detalle de Ventas de Repuestos..................................55
Figura 21 - Gráfico de Burbujas de Compras de Repuestos.................................................56
Figura 22 - Modelo Dimensional 3 - Compras de Repuestos................................................59
Figura 23 - Gráfico de Burbujas de Inventario de Repuestos................................................60
Figura 24 - Modelo Dimensional 4 - Inventario de Repuestos...............................................62
Figura 25 - Gráfico de Burbujas de Detalle de Reservas......................................................63
Figura 26 - Modelo Dimensional 5 - Detalle de Reservas.....................................................66
Figura 27 - Gráfico de Burbujas de Detalle de Inventario......................................................67
Figura 28 - Modelo Dimensional 6 - Detalle de Inventario del Departamento de Repuestos
70 Figura 29 - Gráfico de Burbujas de Comparación con Metas...........................................71
Figura 30 - Modelo Dimensional 7 - Comparación de Metas................................................73
Figura 31 - Gráfico de Burbujas de Seguimiento de Clientes................................................74
Figura 32 - Modelo Dimensional 8 - Seguimiento de Clientes...............................................77
Figura 33 - Modelo Lógico Dimensional del Data Mart para el Departamento de Repuestos
............................................................................................................................................... 80
Figura 34 - Diagrama Físico del Data Mart para el Departamento de Repuestos de ITSA...82
Figura 35 - Ejemplo del uso de Preprocesamiento de Datos en Weka.................................83
Figura 36 - Ventana de inicio de Spoon Pentaho Data Integration........................................84
Figura 37 - Conexión al Repositorio de Transformaciones y Datos en Spoon......................84
Figura 38 - Conexiones de Fuentes y Repositorio................................................................85
Figura 39 - Estructura de la Dimensión Fecha......................................................................86
Figura 40 - Transformación de Dimensión Dim_Fecha.........................................................86
Figura 41 - Estructura de la Dimensión Agencia...................................................................86
Figura 42 - Transformación de Dimensión Dim_Agencia......................................................87
Figura 43 - Estructura de la Dimensión Cliente.....................................................................88
Figura 44 - Transformación de Dimensión Dim_Cliente........................................................89
Figura 45 - Estructura de la Dimensión Asesor.....................................................................89
Figura 46 - Transformación de Dimensión Dim_Asesor........................................................90
Figura 47 - Estructura de la Dimensión TipoVenta................................................................90
Figura 48 - Transformación de Dimensión Dim_TipoVenta...................................................90
Figura 49 - Estructura de la Tabla de Hechos Venta_Neta...................................................91
Figura 50 - Transformación de Hecho_VentaNeta................................................................91
Figura 51 - Ejemplo Verificación de Datos Vacíos - WEKA...................................................92
Figura 52 - Entorno de Trabajo de Schema Workbench.......................................................92
Figura 53 - Cubo Ventas Netas............................................................................................. 93
Figura 54 - Publicación del Cubo OLAP................................................................................93
Figura 55 - Reporte de Ventas Netas por Agencia con valores............................................94
Figura 56 - Reporte Gráfico de Ventas Netas por Agencia...................................................94
Figura 57 - Reporte de Ventas Netas por Asesor..................................................................95
Figura 58 - Reporte de los 10 Mejores Clientes....................................................................95
Figura 59 - Reporte de Ventas Contado y Crédito con valores.............................................95
Figura 60 - Reporte Gráfico de Ventas Contado y Crédito....................................................96
Figura 61 – KPIs Departamento de Sistemas.......................................................................96
Figura 62 – Acta de finalización de Pruebas.........................................................................98
Figura 63 - Actualización de la tabla Hecho_VentaNeta.......................................................99
Figura 64 - Procedimiento Estándar de Control de Calidad del Aplicativo BI......................100
Figura 65 - Interfaz Weka.................................................................................................... 102
Figura 66 - Proyección de Ventas con Weka......................................................................103
Figura 67 - Regresión Lineal............................................................................................... 104
Figura 68 - Variables de Entorno JAVA y Weka..................................................................130
Figura 69 - Interfaz Pentaho Server - Pentaho User Console.............................................130
Figura 70 - Interfaz Pentaho Server – Saiku.......................................................................131
Figura 71 - Interfaz Pentaho - Spoon..................................................................................131
Figura 72 - Interfaz Pentaho - Report Designer...................................................................132
Figura 73 - Interfaz Schema Workbench.............................................................................132
Figura 74 - Pantalla Inicial Weka......................................................................................... 132
Figura 75 - Estructura de la Dimensión Item.......................................................................133
Figura 76 - Transformación de Dimensión Item..................................................................134
Figura 77 - Estructura de la Dimensión ICC........................................................................134
Figura 78 - Transformación Dimensión ICC........................................................................135
Figura 79 - Estructura de la Tabla de Hecho_DetalleVenta................................................135
Figura 80 - Transformación de Hecho_DetalleVenta..........................................................136
Figura 81 - Estructura de Dimensión Proveedor.................................................................136
Figura 82 - Transformación de Dim_Proveedor..................................................................137
Figura 83 - Estructura de la Tabla de Hecho_ComprasTDE...............................................137
Figura 84 - Transformación de Hecho_ComprasTDE.........................................................137
Figura 85 - Estructura de Hecho_Inventario........................................................................138
Figura 86 - Transformación Hecho_Inventario....................................................................138
Figura 87 - Estructura Dimensión EstadoProforma.............................................................139
Figura 88 - Transformación Dimensión EstadoProforma....................................................139
Figura 89 - Estructura Hecho_ReservasDetalle..................................................................139
Figura 90 - Transformación Hecho_ReservasDetalle..........................................................140
Figura 91 - Estructura Dimensión Línea de Venta...............................................................140
Figura 92 - Transformación Dimensión LineaVenta............................................................140
Figura 93 - Estructura Dimensión TipoTransacción............................................................141
Figura 94 - Transformación Dim_TipoTrans........................................................................141
Figura 95 - Estructura del Hecho DetalleInventario.............................................................142
Figura 96- Transformación de Hecho_DetalleInventario.....................................................142
Figura 97 - Estructura del Hecho Compara Metas..............................................................143
Figura 98 - Transformación del Hecho ComparaMetas.......................................................143
Figura 99 - Estructura Dimensión TipoCompraITSA...........................................................143
Figura 100 - Transformación de Dimensión TipoCompraITSA............................................144
Figura 101 - Estructura Hecho Retorno_Clientes................................................................144
Figura 102 - Transformación Hecho_RetornoClientes........................................................144
Figura 103 - Cubo Detalle de Ventas Netas........................................................................145
Figura 104 - Cubo Compras TDE........................................................................................ 146
Figura 105 - Cubo Costo de Inventario...............................................................................146
Figura 106 - Cubo de Items Reservados.............................................................................147
Figura 107 - Cubo para el Detalle de Inventario..................................................................147
Figura 108 - Cubo para Comparar Metas............................................................................148
Figura 109 - Cubo para Retorno de Clientes.......................................................................148
 RESUMEN

Actualmente vivimos en la era del conocimiento, en donde no basta con

tener información, sino saberla utilizar correctamente para dirigir una
empresa. La presente tesis explica el desarrollo de un aplicativo de
Inteligencia de Negocios para el Departamento de Repuestos de
Importadora Tomebamba
S.A. El objetivo principal de este aplicativo es apoyar y facilitar las
actividades de dirección y toma de decisiones, por medio de la integración y
presentación de datos a los jefes y directivos de la Empresa. El aplicativo
consiste en la implementación de un Data mart compuesto por las áreas de
Ventas de Vehículos, Servicio de Talleres y Repuestos. Se aplica la
Metodología de Kimball, con la cual se logra una definición correcta de
requerimientos, el desarrollo ordenado del producto final empezando por la
arquitectura de la solución, el diseño e implementación del Data mart para la
verificación y control de la calidad de datos, el desarrollo del aplicativo y su
completa administración. Luego de realizar las pruebas necesarias se
procede a la publicación de la solución logrando un producto que cubre los
requerimientos detallados. Los datos almacenados en el Data mart se
analizan a través de herramientas de procesamiento analítico que muestran
los indicadores claves de gestión para el Departamento ayudando al
personal a tomar óptimas decisiones sobre sus recursos y servicio. Dentro
de esta tesis también se revisa la importancia de la Minería de Datos y se
deja abierta la posibilidad y necesidad de realizar una Inteligencia de
Negocios enfocada a las necesidades del cliente.

PALABRAS CLAVES:
 SISTEMA DE SOPORTE A LA TOMA DE DECISIONES
 INDICADORES DE GESTIÓN
 KIMBALL
 PENTAHO
 WEKA
 ABSTRACT

Nowadays we live the knowledge age, where having information is not

enough if you don´t know how to use it in your company. This thesis explains
the development of Business Intelligence for the Parts and Pieces
Department of Importadora Tomebamba S.A. The main idea of this program
is to support in all activities and directions to make good decisions by
integrating and presenting the right data to the direction of the company. This
program is based on the information provided by the Car Sales Department,
Car Repair Shop and Parts and Pieces Department implementing a Data
mart. By applying the Kimball methodology we can define the exact
requirements to develop the final product, starting by the architecture of the
solution, the design and implementation of the Data mart to verify and control
the quality of the database, the development of the program and its
management. After the needed testing we published the solution getting the
final product with the detailed requirements. The database saved in the Data
mart is analyzed by analytic process tools that shows the key performance
indicators to manage the Department helping the team to make the best
decisions related to service and resources. You will also see the importance
of Data Mining and leaving an open possibility and need to have a Business
Intelligence focus on the client’s needs.

KEY WORDS:
 SUPPORT SYSTEM FOR MAKING DECISION
 KEY PERFORMANCE INDICATORS
 KIMBALL
 PENTAHO
 WEKA
 1

CAPÍTULO I

INTRODUCCIÓN

1.1 TEMA

Desarrollo de un aplicativo Business Intelligence para la empresa

Importadora Tomebamba S.A.

1.2 ANTECEDENTES

Business Intelligence es la habilidad para transformar los datos en

información, y la información en conocimiento, de forma que se pueda
optimizar el proceso de toma de decisiones en los negocios.
Asociándolo directamente con las tecnologías de la información, se
puede definir Business Intelligence como el conjunto de metodologías,
aplicaciones y tecnologías que permiten reunir, depurar y transformar datos
de los sistemas transaccionales e información desestructurada (interna y
externa a la compañía) en información estructurada, para su explotación
directa (reporting, análisis OLTP / OLAP, alertas...) o para su análisis y
conversión en conocimiento, dando así soporte a la toma de decisiones
sobre el negocio. (Sinnexus, 2007 - 2012)
Actualmente se pueden encontrar varias herramientas de BI, tanto
comerciales como de código abierto, que ofrecen la posibilidad de analizar
datos con diferentes tratamientos sobre estos.

1.3 JUSTIFICACION E IMPORTANCIA

El propósito de esta tesis es el de solucionar los problemas de la toma

de decisiones por parte de los directivos del departamento de Repuestos
mediante el desarrollo de un aplicativo Business Intelligence.
Actualmente, existe una imperante necesidad de la Gerencia del
Departamento de responder a preguntas como: ¿Se va a lograr un monto de
ventas en un período determinado?, ¿En qué ciudad tiene mayor potencial
determinado repuesto?, ¿Qué tal se está vendiendo un repuesto con
respecto a períodos de tiempo anteriores? , ¿Cuál es el repuesto más
rentable en determinada ciudad?, ¿Cuáles son los mejores clientes?; para
actuar a tiempo y sobrellevar los cambios que se dan año tras año en el
sector automotriz.
Para el acceso a la información se requiere únicamente un navegador
sin necesidad de depender de la instalación de otras aplicaciones en cada
estación de trabajo.
El desarrollo de este aplicativo Business Intelligence brindará beneficios
directos a la Gerencia de Repuestos y Directivos encargados de la toma de
decisiones importantes y relevantes dentro del departamento y estas a su
vez benefician indirectamente a los empleados y clientes en general.

1.4 DEFINICION DEL PROBLEMA

Actualmente el departamento de Repuestos de Importadora Tomebamba

S.A. no cuenta con un sistema Business Intelligence que apoye a los
directivos y jefes departamentales en el análisis de la información, la misma
se encuentra en diferentes formatos y opciones, lo cual no permite que los
usuarios finales obtengan sus propios reportes, pues deben dar un paso
extra para generar los cuadros requeridos.
Otra necesidad es la de contar con estados actuales inmediatos, para la
correcta toma de decisiones; pues muchas veces ha tomado tiempo
considerable obtener la información necesaria ya sea a través de la entrega
y desarrollo del requerimiento de reportes al departamento de sistemas o por
generación manual de los empleados del departamento.
Dentro del departamento, la toma de decisiones debería ser estratégica
e inmediata, situación que en la actualidad no se ha alcanzado a nivel
gerencial y directivo, debido a que los datos se encuentran en constante
crecimiento y actualización, están almacenados en bases de datos
operacionales, y no pueden ser analizados en forma personalizada según
los parámetros de cada área.
1.5 OBJETIVOS
1.5.1 Objetivo General

Desarrollar un sistema de Business Intelligence para la Empresa

Importadora Tomebamba S.A, que apoye y facilite las actividades de
dirección y toma de decisiones, por medio de la integración y presentación
de datos a los jefes y directivos de la Empresa.
1.5.2 Objetivos Específicos
 Integrar las bases de datos del área de ventas de la empresa de los
últimos años.
 Depurar los datos obtenidos.
 Analizar y Diseñar el Data mart para el área de ventas.
 Identificar las variables para la toma de decisiones.
 Diseñar un Data mining para el área de ventas.
 Integrar la solución BI con el área de ventas de Importadora
Tomebamba.
 Desarrollar y publicar la solución BI.

1.6 ALCANCE DEL PROYECTO

El desarrollo aplicativo BI cubrirá las siguientes áreas y sub áreas:

 Compras / Ventas (Repuestos)
 Control de Inventario (Repuestos)
 Control de Movimientos Repuestos – Servicio (Repuestos + Servicio)
 Clientes de Importadora Tomebamba (Repuestos + Servicio +
Vehículos)
 La estructura del data mart será desarrollada basada en técnicas OLAP.
 El proyecto se integrará con los esquemas de cada área en la base de
datos de producción de la Empresa.
 El análisis y despliegue de la información para la toma de decisiones
finales se generará para los usuarios expertos.
 1.7 METODOLOGÍA DE TRABAJO A UTILIZARSE

La metodología escogida para el desarrollo del proyecto es la de Kimball

debido a que es la más óptima y cercana al proceso de desarrollo que se
quiere implementar dentro de la Empresa, con especial énfasis en los data
marts, su diseño y modelamiento dimensional.

Selección e Implementación de
Diseño de la Arquitectura técnica
Productos
Crecimiento

Diseño e Implementación del Subsistema ETL

Definición de Requerimientos del Modelado
Negocio Dimensional Diseño Físico
Planificación del Proyecto Implementación

Especificación de aplicaciones de BI
Desarrollo de aplicaciones de BI Mantenimiento

Administración del Proyecto de DW/BI

Figura 1 - Business Dimensional Lifecycle - Metodología de Kimball

Fuente: La Metodología de Kimball (Rivadera, 2010)

 CAPITULO II

MARCO TEÓRICO

2.1 IMPORTADORA TOMEBAMBA

2.1.1 Reseña Histórica

En 1964 cinco empresarios cuencanos liderados por Guillermo Vázquez

Astudillo decidieron formar la compañía Importadora Tomebamba S.A.
emprendiendo el reto de convertirla, a través de la distribución de vehículos,
en una de las empresas más importantes del país. El paso del tiempo
permitió que este objetivo se convirtiera en realidad, puesto que al momento,
la empresa se encuentra catalogada entre las cincuenta más importantes del
Ecuador.
Desde su inicio, Importadora Tomebamba S.A. se caracterizó por
representar vía distribución y comercialización, marcas líderes en el mercado
mundial. Con mucho orgullo y satisfacción, la empresa inició sus actividades
con la representación de vehículos Toyota para luego ir ampliando sus
líneas. Desde un primer momento se quiso diferenciar de la competencia no
solo por las marcas que ofrece sino sobre todo por la calidad en la atención
al cliente, constituyéndose el servicio en la prioridad de todas las actividades
desarrolladas dentro de la empresa.

2.1.2 Importadora Tomebamba S.A. en el Ecuador

Importadora Tomebamba S.A. desde su fundación logró un excelente

posicionamiento, lo que obligó a que en 1967 abra su primera sucursal en la
ciudad de Machala. Se continuó con la apertura de la sucursal en la ciudad
de Loja. En 1979 se decide iniciar actividades comerciales en Riobamba
para continuar con la apertura de sucursales en Quito y Guayaquil. A estas
seis oficinas que están operativas en la actualidad, se fueron adicionando
agencias en Ambato, Macas y Azogues en respuesta al crecimiento de las
actividades de la empresa en estas plazas.
 Figura 2 - Importadora Tomebamba en el Ecuador

Fuente: Presentación (Historia de Importadora Tomebamba)

2.1.3 Misión

Satisfacer adecuadamente las necesidades de nuestros clientes, así

como las de nuestro personal a través de la realización de una gestión
comercial enmarcada dentro del respeto al entorno, de la preservación del
medio ambiente y del apoyo a la comunidad y gobierno, con el objetivo final
de generar los rendimientos que nuestros accionistas requieren.

2.1.4 Visión

Ser el líder en la comercialización de nuestras líneas de productos,

reconocido por su éxito y respetado por contribuir con sus colaboradores,
con la comunidad y el medio ambiente.

2.1.5 Filosofía, Acciones y Valores

Para lograr un entendimiento común en toda la compañía se aplican la

siguiente filosofía, acciones y valores plasmados en su misión y visión.
  LIDER: Ocupar la primera posición en cuanto a ventas y rentabilidad,
entre las compañías en el país que se dedican a la comercialización de
productos de las mismas líneas de negocio que manejamos.
 ÉXITO: Consecuencia de la buena dirección de la empresa y la
correcta ejecución de las actividades que le agregan valor al negocio.
Resultado de ser eficaces y eficientes.
 RESPETADO: Distinción que ITSA busca a través del correcto actuar a
favor de los que aquí colaboramos y de la comunidad en la que
convivimos.
 ADECUADAMENTE: Condición que hace a ITSA ser una empresa
transparente, confiable y que antepone a los intereses personales la
satisfacción de los que en ella participan.
 RESPETO: Actuar como un amigo con el que siempre se puede
negociar, colaborar o trabajar en equipo, con todos y cada uno con los
que nos relacionamos en este negocio.
 PRESERVACION: Preocuparse por y actuar a favor de, mantener y/o
mejorar las condiciones actuales del medio en que nos desenvolvemos.
 APOYO: Cumplir con los requerimientos y participar activamente con
las personas e instituciones externas a ITSA para que todos
caminemos hacia el progreso.
 GENERAR LOS RENDIMIENTOS: Trabajar a favor de la obtención de
los resultados que satisfagan los requerimientos de la cadena que
compone esta organización, desde el primero hasta el último de sus
eslabones.

2.1.6 Estructura Organizacional

La estructura organizacional del equipo directivo de Importadora

Tomebamba S.A. está formada por el Gerente General, Sub Gerente
General, el Jefe de Auditoría, los Gerentes de cada línea de
comercialización, Gerente en Diferenciación y Gerente Administrativo.
 GERENTE GENERAL
FERNANDO VÁZQUEZ

SUBGERENTE GENERAL JEFE DE AUDITORÍA

MAURICIO VÁZQUEZ XAVIER HERMINA

GERENTEGERENTE
GERENTEGERENTE GERENTE GERENTE GERENTE DIFERENCIA-ADMINISTRA- CIÓNCIÓN
LPHVEHÍCULOS LLANTAS REPUESTOS SERVICIO

Figura 3 - Estructura Organizacional de ITSA

Fuente: Organigramas (RRHH ITSA)

2.1.7 Líneas de Comercialización

Importadora Tomebamba S.A. en la actualidad, comercializa las

siguientes líneas de productos:
 Vehículos: Esta es la línea con la cual comenzó la empresa, y
actualmente comercializa los siguientes modelos:
• Segmento Pasajeros: YARIS, COROLLA.
• Segmento Camionetas: HILUX.
• Segmento SUV: FORTUNER, RAV, RUNNER, PRADO, LAND
CRUISER.
• Segmento Comerciales: HIACE, DYNA.
• Segmento Híbridos: HIGHLINDER, PRIUS, PRIUS C.
 LPH: Dentro de LPH (Línea para el Hogar) la empresa comercializa
las marcas INNOVA (propia de ITSA, producida y ensamblada por la
fábrica Indurama de la ciudad de Cuenca), Panasonic, LG, Philips,
Continental. Además, se comercializan motocicletas de las marcas
Sukida, Motor Uno, BMA, Husqvarna y Ducati.
 Llantas: Dentro de ésta línea la empresa comercializa las llantas
taiwanesas de marca MAXXIS.
  Repuestos: Esta línea que es parte de la post-venta, comercializa
repuestos genuinos y accesorios para vehículos Toyota.
 Servicio: La línea de Servicio también es parte de la post-venta de
vehículos Toyota. En ésta área ITSA cuenta con cuatro locales en los
que brinda servicio de Mecánica y de Enderezado y Pintura; ubicados
en Cuenca, Machala, Quito y Riobamba.

2.1.8 Descripción y Cambios de la Línea de Repuestos

En Marzo del 2006, Importadora Tomebamba S.A. comienza un período

de transición pues se produce una alianza estratégica entre ITSA
(Importador único de TOYOTA en el Ecuador en ese momento) y los
exportadores japoneses. A esta alianza se une Casabaca S.A. y Toyocosta
S.A.
Así es como se crea Toyota del Ecuador (TDE) misma que funciona en
la ciudad de Quito. TDE es actualmente el importador de la línea Toyota en
el Ecuador y a su vez es el distribuidor de los concesionarios Importadora
Tomebamba, Casabaca y Toyocosta.

Figura 4 - El Estilo Toyota en Ventas y Mercadotecnia

Fuente: El Estilo Toyota en Ventas y Mercadotecnia

En este período, Importadora Tomebamba debe cambiar todos sus

procesos y todo su sistema de importador a comercializador. En la línea de
repuestos genuinos Toyota se realizaban importaciones directas de Japón,
Brasil y Colombia, manejando un inventario propio mediante el cual se
abastecía a la red de agencias de ITSA a nivel nacional. Al ser
comercializador, ITSA debe crear nuevos procesos de control de inventarios
de repuestos.
Estos cambios se encaminan hacia la creación de procesos en el
sistema, que permitan a cada una de las agencias manejar sus propios
parámetros de control y stocks; es decir, dejan de depender del stock de la
agencia Matriz y se abastecen de repuestos directamente de TDE. El
objetivo del manejo independiente del stock de cada agencia es lograr un
alto nivel de Tasa de Servicio con un monto de inventario bajo.
El control del monto de inventario se lo realiza clasificando los repuestos
con un ICC (Clase de Control de Inventario) dependiente de las ventas de
cada agencia, para así reponer solamente los repuestos que tienen alto
movimiento mediante el concepto “Vendo uno, Compro uno”. Además, se
han establecido tipos de pedidos de acuerdo al repuesto requerido, así se
tienen: Pedidos de reposición de stock, Pedidos de no-stock, Pedidos de
demanda creada y Pedidos especiales.
Todos los procesos que realiza ITSA están guiados por la filosofía de
Toyota, y por su Sistema de Producción, el cual se lo aplica diariamente en
cada actividad dentro de la empresa.

2.2 INTELIGENCIA DE NEGOCIO

2.2.1 Definición

Como se definió en el apartado 1.2, la Inteligencia de Negocios sirve

para convertir datos en información útil y relevante, con el fin de lograr que
los gerentes y directivos de las organizaciones tomen las mejores decisiones
cada día accediendo de forma directa a la información “clave” de su negocio
de manera ágil y sencilla. Para esta conversión se utilizan un conjunto de
técnicas, metodologías y herramientas, que mediante un proceso de
extracción, depuración, transformación, diseño de estructuras de
almacenamiento y explotación, se obtiene una visión integrada, completa y
totalmente actualizada.
 Con el auge de la Inteligencia de Negocios en el 2014, la ciencia de los
datos ha pasado de los especialistas (analistas de datos) a las personas
comunes, se está viviendo una nueva era, la era del conocimiento (Datos +
Análisis = Conocimiento). Las empresas exitosas buscan reducir el tiempo
entre la captura de datos, su transmisión y elaboración para de esta manera
obtener una ventaja competitiva, ya que la velocidad de la información
correctamente integrada es un catalizador para la innovación en productos y
servicios.

Ventaja Competitiva Toma de Decisiones Conocimiento

Inteligencia de Negocios
Información
Datos

Figura 5 - Definición de Inteligencia de Negocios

2.2.2 Características

Este conjunto de herramientas y metodologías que forman la inteligencia

de negocios tienen en común las siguientes características:
 Accesibilidad a la información: Los datos son la fuente principal de este
concepto. Lo primero que deben garantizar este tipo de herramientas y
técnicas es el acceso a los datos con independencia de su
procedencia.
 Velocidad de respuesta: El tiempo de respuesta a las consultas debe
ser lo más corto posible (dependiendo la complejidad de la consulta).
 Calidad de la información: Deben manejar datos de calidad y coherentes.
 Apoyo en la toma de decisiones: Brindar acceso a herramientas de
análisis que permitan seleccionar y manipular sólo aquellos datos que
les interesen y en los formatos que mejor se adapten (datos, tablas o
gráficos).
 Plataforma integrada: Una plataforma segura que contenga
herramientas ETL, procedimientos analíticos integrados (cubos OLAP)
y minería de datos.
 Servicio de reportes: Creación, administración y visualización de
reportes tanto predeterminados como adhoc.
 Integración con otras herramientas, como por ejemplo Excel.
 Generación de KPI: Proveer de indicadores claves de desempeño en
tiempo real.
 Orientación al usuario final: Se busca independencia entre los
conocimientos técnicos de los usuarios y su capacidad para utilizar
estas herramientas.
2.2.3 Componentes

Los componentes habituales de una solución BI son los siguientes:

OLAP

Archivos
DBMS

ETL ETL ETL

DBMS
DBMS

Área de Almacenamiento Temporal

Almacén Central y Datamarts
ERP

Fuentes de Datos Capa Usuario Final

Figura 6 - Componentes Solución BI

Fuente: Arquitectura Genérica de un Data Warehouse (Roland Bouman, 2009)

 Fuentes de Datos: Son los diversos sistemas OLTP, archivos Excel,

archivos planos, etc.

 Proceso ETL (Extracción, Transformación y Carga): Este proceso

cuenta generalmente con un área de almacenamiento temporal para la
información extraída en dónde se realizan las primeras
transformaciones y limpieza de la misma. El objetivo principal de este
proceso es el de generar datos de calidad, es decir, conseguir que
realmente se almacene información en el DW y no sólo una copia
formateada de los datos del origen. Los procesos ETL son claves en la
vida de una solución BI ya que estos ocupan entre el 60% y 80% del
tiempo del proyecto. A continuación se enumeran algunas de las tareas
de este proceso:
 Extracción (Lectura) de Datos
Identificación de datos que han cambiado
Extracción

ETL Limpieza y transformación

de datos
Transformación•Integración de datos
(cálculos)
Creación de claves
Obtención de agregados

Carga
Carga Pruebas de calidad de la
carga
Gestión de errores

Figura 7 - Procesos ETL

 Un Data warehouse y/o diversos Data marts: Son las bases de datos
ya modeladas de forma multidimensional que se alimentan
periódicamente mediante procesos ETL.
Data warehouse: Es una base de datos corporativa, un repositorio
empresarial, que une todos los datos de la organización en una única
estructura, desde donde todos los departamentos pueden obtener una
visión de la organización.
Data mart: Es una base de datos especializada, departamental,
orientada a satisfacer las necesidades específicas de un grupo
particular de usuarios. Existen dos tipos de DMs, los dependientes
(obtienen la información del DW) y los independientes (obtienen la
información directamente de las fuentes de datos).

 Capa de Usuario Final: Son las herramientas analíticas y de

presentación que permiten al usuario de negocio poder acceder a la
información, compartirla y analizarla. Este tipo de reportes se
caracterizan por lo complejo de sus consultas y altos tiempos de
respuesta.
2.2.3.1 Análisis OLAP
El análisis OLAP es parte del componente Data Warehouse de la
Inteligencia de Negocios. Actualmente, existen dos sistemas para el
procesamiento de la información, OLTP y OLAP. A continuación se muestran
en la siguiente tabla las características más sobresalientes de cada uno de
ellos:

Tabla 1
Tecnologías OLTP vs. OLAP

OLTP OLAP
Garantizar la consistencia de los Consolidar datos ya validados para la
Objetivo
datos. toma de decisiones.
Usuario típico Empleados / Operativos Gerentes / Analistas
Vigencia de los datos Actual Actual + Histórico
Interacción con el
Predeterminada / Repetitiva Ad-hoc
usuario
Granularidad de los
Detallada Detallada + Resumida
datos
Normalizado, estructuras de base Desnormalizado, estructuras en función
Organización
de datos complejas del análisis a realizar.
Características de los
Atómicos / Crudos Resumidos / Sumarizados
datos

Procesamiento Orientado a procesos Orientado a requerimientos

Velocidad de
respuesta Normal o Lenta Muy rápida
Decisiones
Soportadas Diarias Estratégicas
Sentencias Primarias INSERT, UPDATE o DELETE SELECT

Fuente: (Hood, 2012), (Celma, 2006), (WROV, 2013)

Como se puede observar en la tabla, OLAP es el sistema idóneo para

brindar ayuda en la toma de decisiones de la empresa ya que sirve para
consultar y analizar los millones de filas de datos que las aplicaciones OLTP
guardan en las bases de datos transaccionales.

2.2.3.2 Conceptos y Componentes

2.2.3.2.1 Cubos OLAP
Son la representación gráfica de OLAP. El cubo contiene los datos que
son de interés para los usuarios; organizados en una estructura
multidimensional.
2.2.3.2.2 Medidas
Son aquellos conceptos cuantificables que permiten medir el proceso de
negocio. Por ejemplo, en una venta existe el monto de la misma y la
cantidad vendida. Un cubo puede contener una o varias medidas,
dependiendo del diseño y los requerimientos. Existen dos tipos de medidas:
Medida regular: toma su dato directamente de una fuente disponible, tal
como la cantidad vendida, ingresos, gastos.
Medida calculada: es derivada de otras medidas, como por ejemplo
ganancia (ingresos – costos).

2.2.3.2.3 Dimensiones
Son atributos de tipo texto que describen cosas, por ejemplo, Producto,
Tiempo y Ciudad. Una dimensión puede ser privada (usada en un solo cubo)
o compartida (usada en múltiples cubos para optimizar el tiempo y evitar
duplicidad de dimensiones privadas).
Los valores de una dimensión corresponden a un nivel en particular.
Usualmente un cubo tiene de 4 a 12 dimensiones y soporta una vista de 2 o
3 dimensiones simultáneamente. (Uzcanga, 2003)

2.2.3.2.4 Niveles
Las dimensiones están construidas por niveles. Estos niveles
representan la jerarquía establecida por las estructuras organizacionales y
modelos de datos que la organización utiliza; mientras más bajo el nivel,
mayor detalle de información.

2.2.3.3 Formas de almacenar información en los cubos

A continuación se enumeran algunas de las características de las formas
de almacenar la información en los cubos:
Tabla 2

Formas de almacenamiento en los cubos OLAP

MOLAP ROLAP HOLAP

Almacenamiento Modelo Base de Datos Modelo

de agregaciones Multidimensional Relacional Multidimensional
Almacenamiento Modelo Base de Datos Base de Datos
de datos Multidimensional Relacional Relacional
Facilidad de
Sencillo Muy Sencillo Sencillo
Creación
Buena para consultas
Buena, depende sólo
Velocidad de de agregaciones
del diseño de las Regular o Baja
respuesta Regular para datos de
agregaciones bajo nivel
Es más
Escalabilidad Un poco problemático Escala bien
escalable
Recomendado Cubos de uso Para uso no Si requiere una rápida
para frecuente muy frecuente respuesta
Consume menos
Excelente rendimiento Análisis de
Ventaja espacio en disco
y compresión de datos muchos datos Consultas más ágiles

Fuente: (Geidy Acosta Méndez, 2013), (Dómina, 2008)

2.2.3.4 Operaciones analíticas básicas con OLAP

Como se comenta en el documento de (Celma, 2006, pág. 37) "lo
realmente interesante de las herramientas y cubos OLAP son sus
operadores de refinamiento o manipulación de consultas". La información
que se analiza debe estar estructurada de tal forma que se puedan realizar
las siguientes operaciones analíticas básicas:
 Agregación / Consolidación (Roll-Up): permite realizar acumulaciones
simples o agrupaciones complejas de datos.
 Disgregación / División (Drill-Down): permite introducir un nuevo criterio
de agrupación en el análisis, disgregando los grupos actuales (moverse
en dirección contraria).
 Cortar y Rotar (Slicing-Dicing-Pivot): seleccionar y proyectar datos en el
informe desde diferentes puntos de vista.

2.2.3.5 Esquemas para el modelado de datos

Un reto fundamental en la implementación de OLAP es mapear el
esquema inicial de la base de datos a un modelo multidimensional, partiendo
de un DW con información de calidad. Para esto, se revisarán los siguientes
esquemas:
 Esquema Estrella (star schema): En este esquema, la tabla de hechos
está en el centro de la estrella y se relaciona de uno a muchos a cada
dimensión; las dimensiones no se relacionan entre sí, ni tienen caminos
alternativos entre ellas. Existe redundancia de datos. La principal
ventaja de este esquema es su velocidad y simplicidad para realizar
análisis multidimensionales, además proporciona mayor comprensión,
navegabilidad y es más cercano a como el usuario final refleja la visión
de una consulta empresarial.

Dimensión de Tiempo

Dimensión de Clientes Dimensión de Ubicación

Hecho s de Venta

Dimensión de Asesores Dimensión de Productos

Figura 8 - Esquema Estrella

Fuente: (Rangel, 2010)

 Esquema Copo de Nieve (snow flake schema): El esquema de copo de

nieve varía del esquema estrella en que cada dimensión almacena
jerarquías de atributos o se separan atributos en otra entidad por
razones de desempeño y mejor utilización del espacio. No existe
redundancia de datos, ya que los niveles dimensionales son
normalizados a tablas separadas. Aunque ocupa menor espacio de
almacenamiento, aumenta el número de tablas con las que el usuario
debe interactuar, incrementando la complejidad de las consultas. No se
recomienda utilizar este esquema cuando el tiempo de respuesta sea
un factor de criticidad para el usuario final.
 Mes
Semana

Dimensión de Tiempo

Dimensión de Modelo Dimensión de Ubicación

Hecho s de Venta

Dimensión de Asesores Dimensión de Producción

Sucursa

Región Tipo

Figura 9 - Esquema Copo de Nieve

Fuente: (Rangel, 2010)

2.3 METODOLOGÍAS PARA EL DESARROLLO DE BI

Para que un DW pueda conseguir su objetivo, los procesos de negocio
se seleccionan y se modelan, estableciendo un nivel de granularidad para
cada uno de ellos. Para que el modelado sea exitoso, es muy importante
entender correctamente los datos de los diferentes sistemas dentro de la
organización y las relaciones entre ellos.
Existen varias metodologías o enfoques para la construcción de un DW,
en esta tesis, se van a revisar la Bottom-Up de Ralph Kimball y la Top-Down
definida por Will Inmon. A continuación se enumeran algunas características
básicas de cada una.
Tabla 3

Diferencias entre Metodologías BI

Top-Down Bottom-Up

Autor Bill Inmon Ralph Kimball

Énfasis DW - Nivel Empresarial DMs - Nivel Departamental

Modelo Dimensional de DMs

Modelo normalizado basado en la
Diseño diseñados a detalle para enlazarse y
empresa
formar componentes más grandes.

Los problemas que se van a

Está basada en experimentos y
solventar ya son conocidos de
prototipos.
Síntesis antemano.
Es más flexible, menos costosa y más
Tienen un mayor costo ya que
rápida.
cada fase alcanza un alto nivel de
detalle

Fuente: (Gutiérrez, 2006)

2.3.1 Selección de Metodología

Para el desarrollo de esta tesis, se ha seleccionado la metodología
Kimball, ya que proporciona un enfoque de menor a mayor, muy versátil, y
una serie de herramientas prácticas que ayudan a la implementación de un
DW. Además, se pueden implementar con pocos recursos; pequeños Data
Marts en áreas específicas de la organización (compras, ventas, etc.), para
luego ir integrándolos en un gran almacén de datos.
Esta metodología utiliza en el modelo dimensional el esquema estrella, y
su arquitectura es la siguiente:

DM1
ETL

OLTP
Data
Wareho use
DM2
Cubo OLAP Capa de Reportes
ETL
ETL

Fuentes de Datos
DM3

Gráfico 10 - Modelo Kimball

Fuente: Kimball and Inmon DW Models, (Austin, 2010)

2.4 METODOLOGÍA KIMBALL
La metodología propuesta por Kimball ayuda a simplificar la complejidad
que implica la construcción de una solución de DW/BI. Las tareas de esta
metodología (ciclo de vida) se muestran en el (Figura 1), donde se puede
observar que la tarea de definición de requerimientos es el soporte inicial de
las tareas subsiguientes.
En este ciclo de vida, se puede ver tres flujos o caminos que se enfocan
en tres diferentes áreas:
 Flujo Tecnológico (Camino Superior): Implica tareas relacionadas con
hardware y software específicos.
 Flujo de Datos (Camino del medio): Área en la que se diseña e
implementa el modelo dimensional, y se desarrolla el subsistema de
ETL para cargar el DW.
 Flujo de Integración de Aplicaciones de Inteligencia de Negocios
(Camino Inferior): En este flujo se diseñan y desarrollan las
aplicaciones para los usuarios finales.

Estas rutas se combinan cuando se instala finalmente el sistema. En la

parte inferior de la figura se muestra la actividad general de administración
del proyecto. A continuación se describe cada una de las tareas.

2.4.1 Planificación del Proyecto

Con la planificación del proyecto se busca identificar los objetivos y el
alcance del proyecto de desarrollo del sistema DW, incluyendo las
justificaciones del negocio, las evaluaciones de factibilidad, de costes, etc.

2.4.2 Análisis de Requerimientos

Es muy importante la correcta interpretación de los diferentes niveles de
requerimientos expresados por los distintos grupos de usuarios, para así
determinar el alcance del DW (qué datos debe contener, cómo deben estar
organizados, cada cuánto tiempo deben actualizarse, quiénes y desde
dónde accederán o manipularán el sistema, etc.).
2.4.3 Flujo Tecnológico
2.4.3.1 Diseño de la Arquitectura Técnica
Los entornos de DW requieren la integración de numerosas tecnologías.
Se debe tener en cuenta tres factores para poder establecer el diseño de su
arquitectura técnica:
 Los requerimientos del negocio.
 Los entornos técnicos disponibles.
 Las directrices técnicas y estratégicas planificadas por la compañía.

2.4.3.2 Selección de Productos e Implementación

Los entornos de DW requieren del uso de ciertos productos y
herramientas SW adicionales; es en esta tarea donde se selecciona cuales
se instalan y se capacita al personal (en caso de que no conozca el SW)
para su manipulación.

2.4.4 Flujo de Datos

2.4.4.1 Modelado Dimensional
La creación de un modelo dimensional es un proceso dinámico y
altamente iterativo de cuatro pasos, que busca presentar los datos de una
forma intuitiva y que proporcione acceso rápido y de alto desempeño. Es
importante resaltar que éste proceso debe iniciar cuando todos los
requerimientos del negocio se encuentran totalmente claros.
 REQUERIMIENTOS
DEL NEGOCIO

MODELO
DIMENSIONAL
SELECCIÓN DEL PROCESO DE NEGOCIO
REALIDAD DE LOS GRANULARIDAD
DATOS DIMENSIONES
HECHOS

Figura 11 - Proceso iterativo del Modelado Dimensional

Fuente: Proceso iterativo del Modelado Dimensional, (Rivadera, 2010)

Cada Modelo Dimensional está compuesto por una tabla con una llave
combinada, llamada tabla de hechos, y un conjunto de tablas más pequeñas
llamadas tablas de dimensiones. Los elementos de este modelo se pueden
definir de la siguiente manera:
 Hechos: son la representación en el DW de un proceso de negocio de
la organización. Los hechos se pueden reconocer además porque
siempre tienen asociado una fecha, y una vez registrados no se
modifican ni se eliminan (para no perder la historia).
 Medidas: son los indicadores de negocio de un proceso de negocio, se
lo definió en el apartado 2.2.3.2.2.
 Dimensiones: su definición se describió en el apartado 2.2.3.2.3; pero
dentro de la metodología, también existen dimensiones degeneradas
que hacen referencia a un campo que se utiliza como criterio de
análisis y se almacena en la tabla de hechos (se identifican con DD en
la tabla de hechos), posee el mismo nivel de granularidad que todos los
datos de su tabla y puede servir para agrupar por ejemplo todos los
items vendidos en una factura. (Ralph Kimball, 2002, pág. 50)
 Además, es importante comentar sobre las Dimensiones Conformadas
(en una definición anterior se las llama Compartidas); ya que son
esenciales en un DW pues se administran una sola vez en el ETL y se
utilizan en varias tablas de hechos para brindar atributos consistentes a
lo largo de los diferentes modelos dimensionales y eliminar un diseño
redundante. (Ralph Kimball, 2002, pág. 82)

2.4.4.1.1 Pequeños Cambios en Dimensiones

Los atributos de las dimensiones pueden ser cambiados en el ámbito
operacional, es por esto que se debe tener una estrategia para reproducir
ese cambio en el modelo dimensional. Según (Ralph Kimball, 2002, pág. 95),
existe tres técnicas básicas para lidiar con estos cambios.
1. Sobrescribir el valor: esta es la técnica más simple de lidiar con
cambios, de esta manera siempre se reflejará el valor reciente. Su
ventaja es ser fácil y rápida. La tabla de hechos no se toca. La
desventaja es que no se tiene un historial de cambios.
2. Agregar una nueva fila: con esta técnica se mantiene un historial, ya
que con cada cambio se crea un nuevo registro. Al utilizar esta técnica,
se necesita una llave extra a la usada en el nivel operacional. La tabla
de hechos no se toca. Es la más recomendada siempre y cuando no se
la utilice sobre dimensiones que manejen más de un millón de
registros.
3. Agregar una nueva columna: se crea una columna para registrar el
cambio del atributo. Esta técnica se utiliza cuando se requiere analizar
el antes y el después del cambio (dos mundos simultáneamente), y en
atributos que son etiquetados por los analistas más no en
características físicas de los productos.
Además se puede utilizar una técnica híbrida que nace de la
combinación de las técnicas dos y tres, que consiste en crear una nueva fila
para capturar el cambio del atributo y una nueva columna para rastrear las
asignaciones pasada y actual.
2.4.4.2 Diseño Físico
El diseño físico de la base de datos se focaliza en la selección de las
estructuras necesarias para soportar el diseño lógico. Un elemento principal
de este proceso es la definición de estándares del entorno de la base de
datos, así como la indexación.

2.4.4.3 Diseño e Implementación del Subsistema de ETL

El subsistema ETL es la base sobre la cual se alimenta el DW, todas sus
tareas son altamente críticas pues tienen que ver con la calidad de la
materia prima (los datos y la información) del DW.

2.4.5 Flujo de Integración de Aplicaciones de Inteligencia de Negocios

2.4.5.1 Especificación de aplicaciones de BI
Una parte fundamental de todo proyecto de DW/BI es el proporcionar a
una gran cantidad de usuarios una forma más estructurada y por lo tanto,
más fácil, de acceder al almacén de datos. En este punto, se especifican las
aplicaciones estándar o analíticas que se desarrollarán para lograr los
objetivos planteados.

2.4.5.2 Desarrollo de aplicaciones de BI

Esta etapa trata de la configuración de los metadatos del negocio y la
infraestructura de las herramientas de BI. Conlleva la construcción y
validación de aplicaciones BI analíticas y operacionales junto con un portal
de navegación para su uso.

2.4.6 Implementación
La implementación representa la convergencia de la tecnología, los
datos y las aplicaciones de usuarios finales. Hay varios factores extras que
aseguran el correcto funcionamiento de todas estas piezas, entre ellos se
encuentran la capacitación, el soporte técnico, la comunicación, las
estrategias de feedback.
2.4.7 Mantenimiento y Crecimiento
Tras la implementación se inicia una fase de mantenimiento del sistema
en producción. Incluye tareas técnicas operacionales como monitorización,
tunning, backups; que son necesarias para mantener en estado óptimo el
flujo de trabajo habitual del sistema.
También está la fase de crecimiento, que inevitablemente se tiene que
producir de continuo en un sistema de DW, priorizando los nuevos
requerimientos para iniciar un nuevo ciclo de vida.

2.4.8 Administración del Proyecto de DW/BI

La administración del proyecto asegura que las actividades del DW se
lleven en forma y sincronizadas, y es una fase que acompaña todo el ciclo
de vida dimensional del negocio. Entre sus actividades principales se
encuentran el monitoreo del estado del proyecto, la comunicación entre los
requerimientos del negocio y las restricciones de información.

Estas son las fases para la implementación de almacenes de datos

pequeños y medianos con un enfoque ascendente, que permite construirlos
en forma escalonada.
 CAPITULO III

APLICACIÓN DE METODOLOGÍA Y DESARROLLO DE LA

SOLUCIÓN
A continuación se detalla el desarrollo del aplicativo Business Intelligence
para la empresa Importadora Tomebamba S.A.

3.1 PLANIFICACION DEL PROYECTO

3.1.1 Definición del Proyecto

El desarrollo de este aplicativo BI nace de la necesidad de tener

información actualizada y resumida para la toma de decisiones en el
departamento de repuestos de Importadora Tomebamba, así como lograr
generar una independencia del personal de desarrollo de sistemas en cuanto
al análisis de información.

3.1.2 Justificación y Objetivos

La planeación del proyecto se la definió en el capítulo I del presente

documento.

En términos generales se puede decir que la solución se basa en

elaborar un Data mart con la información necesaria para la toma de
decisiones en el Departamento de Repuestos de Importadora Tomebamba,
logrando de esta manera visualizar los datos procesados por los cubos que
se van a elaborar a partir de los requerimientos y necesidades de los
usuarios.

3.1.3 Alcance

El alcance de la tesis se detalla a continuación en la Estructura de Desglose

del Trabajo (EDT), delimitando así los trabajos y entregables necesarios
para desarrollar e implementar un sistema de inteligencia de negocios para
el Departamento de Repuestos de Importadora Tomebamba.
 28

Figura 12 - Estructura de Desglose del Trabajo (EDT)

 29
3.1.4 Identificación de Roles
 Patrocinador de Negocio: Importadora Tomebamba S.A.
 Administrador de Bases de Datos: Jefe de Sistemas.
 Analista del sistema de negocio: Asistente de Sistemas.
 Personal involucrado en el negocio: todos los empleados del
departamento de repuestos y los empleados del departamento de
sistemas que administren los módulos de repuestos, vehículos y
talleres.
 Roles para el desarrollo del Data mart (Desarrollador, modelador de
datos, diseñador, líder del proyecto): La persona encargada de esta
tesis.

3.1.5 Estrategia y método de Implementación

Como se comentó anteriormente, se ha elegido la metodología de

Kimball para la implementación del data mart, puesto que el objetivo es
satisfacer las necesidades de un departamento particular de la empresa.

3.1.6 Origen de la fuente de Datos

Las fuentes de datos para la aplicación serán:

 La base de datos Oracle 11g Enterprise Edition, donde están

almacenados todos los datos transaccionales de los departamentos de
la misma.
 Archivos de texto plano que se descargan de la web de Toyota del
Ecuador para las métricas a mes caído.
 Archivos de tipo Excel que almacenan las metas del Departamento de
Repuestos y otras clasificaciones necesarias para la aplicación.

3.2 ANÁLISIS DE REQUERIMIENTOS

3.2.1 Investigación Previa

Dentro de esta fase se revisaron los Formularios Transaccionales más

utilizados por el CSO y COOs del departamento de repuestos, para analizar
la información que graban, modifican y consultan. A continuación se nombran
algunos:

Formularios Transaccionales

 Ventas
 Compras
 Gastos de Taller
 Ajustes
 Reposición de Stock
 Items Inventario
 Selección Items Vendedores

Formularios de Reportes

 Resumen de Ventas
 JPM
 Items Facturados TDE
 Consulta Items Bodega

3.2.2 Entrevistas

Para el levantamiento de requerimientos se realizó una entrevista al CSO

del Departamento de Repuestos, misma que se encuentra en detalle en el
Anexo 1.

3.2.3 Documentación de Requerimientos

Una vez realizada la entrevista, se identificaron algunos temas analíticos

y procesos de negocio; mismos que ayudan a agrupar los siguientes
requerimientos comunes:
Tabla 4

Requerimientos agrupados por temas analíticos y Procesos de Negocio

Análisis o
Proceso de
Tema requerimiento
Modelo negocio de Comentarios
Analítico inferido o
soporte
pedido
Modelo de reporte

Obtener ventas Ventas / Devolución por fecha

1
netas de Ventas por agencia
por cliente
por asesor
Realizar un Reporte
Ventas / Devolución
Obtener ventas
2 de Ventas / por fecha
netas por ICC
Maestro de items por agencia
por grupo ICC
Gestión de Modelo de reporte
Ventas
Mostrar ventas Ventas / Devolución por fecha
1
a crédito de Ventas por agencia
por cliente
por tipo de cliente
Realizar un Reporte

por fecha
Obtener ventas Ventas / Devolución
2 por agencia
por item de Ventas
total cantidades
total neto
total costos
Reporte de datos de clientes de
vehículos, taller y repuestos
Ventas - Vehículos /
consolidado de tal manera que
Seguimiento Retorno de Ordenes de trabajo
8 se pueda observar quienes no
de Clientes Clientes - Taller / Ventas -
acuden a los servicios de post-
Repuestos
venta para lograr un seguimiento
de los mismos
Modelo de reporte
Obtener el Compras /
3 monto de Devolución de por fecha
compras a TDE Compras por agencia
por asesor
Modelo de reporte
Obtener el
Control de monto de Saldos / Kardex /
4 por fecha
Inventario inventario por Costos
por agencia
ICC
por ICC
Modelo de reporte
Reportar los
5 Items Proformas por fecha
reservados por agencia
por asesor

CONTINÚA
 Mostrar items con stock mayor a
0 y sus movimientos en kardex
Reportar los
items con Saldos / Kardex /
6 por agencia
existencia y sus Maestro de Items
por ICC
movimientos
sumarizados por costo, precio de
venta y cantidad
Mostrar los items comprados
Reportar los
Items Maestro de items / por fecha
6
Comprados y no Saldos / Kardex por proveedor
facturados por línea de venta
por agencia
Realizar un Reporte
Inventario / Ventas
Reportar los
7 / Devolución de por fecha , por agencia
Meses de Stock
Ventas
Comparación con Metas
Realizar un Reporte

por fecha, por agencia

Reportar
Ventas / Devolución
Metas 7 márgenes de
de Ventas / Costos Margen de rentabilidad entre
Rentabilidad
meses elegidos

Comparación con Metas

Ventas Netas
Comparar
Ventas / Devolución
Ventas Netas
7 de Ventas / por fecha, por agencia
con
Presupuestos
Presupuestos
Comparación con Metas
Proyección de ventas basada en
los cinco últimos años

Proyección de Ventas Repuestos / Proyección de ventas basada en

Proyecciones
ventas Ventas Vehículos las UIOs vendidas

por agencia
a nivel nacional

Como se puede observar en la columna de Comentarios, se describen

brevemente los requerimientos de la Gerencia de Repuestos.

Para el correcto desarrollo del aplicativo BI, se procedió a realizar una

Especificación de Requerimientos según el estándar IEEE 830, misma que
se detalla en el Anexo 2.

Luego de este análisis, se crea la matriz de procesos / dimensiones (Bus

Matrix). Esta matriz es uno de los entregables más importantes en la
implementación del Data Warehouse ya que se trata de un recurso híbrido;
pues es una herramienta de diseño técnico, así como de gestión de
proyectos y parte de comunicación. (Ralph Kimball, 2002, pág. 81)
 33

Tabla 5

Matriz de Procesos / Dimensiones del Data Mart para el Departamento de Repuestos

Dimensiones
Proceso de
Negocio Tipo Línea Tipo de
Tipo Grupo Tipo Estado
Fecha Agencia Cliente Asesor ICC Item de de Compr Proveedor
Cliente ICC Transacción Proforma
Vent Vent a ITSA
a a
Ventas - Repuestos X X X X X X X X X X X

Ventas - Vehículos X X X X

Ordenes - Talleres X X X X

Compras X X X X

Proformas X X X X X X

Inventario X X X X X X X

KPI / Indicadores X X X

Metas / Presupuestos X X X
 34
3.3 DISEÑO DE LA ARQUITECTURA TECNICA

En ésta fase se muestra la Arquitectura Técnica de Importadora

Tomebamba, puesto que no se va a crear una nueva, sino se va a utilizar la
existente.

Asesor Logística de Repuestos

INTRANET OLAP
Windows Server 2008
Pentaho Data Integration

Gerente de Repuestos

IBM System p5 DB Oracle

DATA MART ITSA

Figura 13 - Diseño de la Arquitectura Técnica

3.3.1 Ambiente Back Room

ORIGEN DE DATOS PROCESO ETL DATA MART DMITSA

Figura 14 - Ambiente Back Room

Dentro del ambiente Back Room se van a utilizar las bases de datos
origen Repuestos, Vehículos y Talleres que se encuentran en Oracle. Esta
base de datos es la que funciona como base operacional de la empresa y la
que almacena todos los datos transaccionales de los módulos que están
involucrados en este DM. Además se tomarán los archivos planos
descargados de la web de Toyota del Ecuador para cierre de mes y archivos
de tipo excel en los que constan datos específicos del manejo del
Departamento de Repuestos y los presupuestos y metas definidas por
Gerencia.

Para los procesos ETL se va a utilizar el Data Integration de Pentaho.

Como los datos transaccionales provienen de una sola base de datos, no es
necesario el área de almacenamiento temporal. Los datos se transforman
con las herramientas de Pentaho y van a poblar directamente el Data Mart.

Finalmente, el Datamart para el Departamento de Repuestos se lo creará

y almacenará en el esquema DMITSA en Oracle, en el mismo servidor que
actualmente aloja la base de datos transaccional.

3.3.2 Ambiente Front Room

DATA MART DMITSA PROCESO DE USUARIOS

DISTRIBUCIÓN FINALES
Gerente de Repuestos

Asesor Logística de Repuestos

Figura 15 - Ambiente Front Room

La extracción y visualización de la información transformada del Data

Mart DMITSA se lo realizará a través del Pentaho User Console y su plugin
SAIKU.
3.3.3 Arquitectura de la aplicación

USUARIO FINAL

PLATAFORMA BI

CAPA DE PRESENTACIÓN
BrowserPortal

Reportería Análisis Cuadros de Mando Proceso Gerencial

Clientes Data Mining Integración

Métricas

Stock / Items OLAP Definición

KPIs
Ad-hoc Explorar Ejecución

PLATAFORMA DE INTELIGENCIA DE NEGOCIOS

SeguridadAdministraciónLógica de NegociosRepositorio

INTEGRACIÓN DE DATOS
ETL

FUENTES DE INFORMACIÓN

Figura 16 - Arquitectura de la aplicación

3.4 SELECCIÓN DE PRODUCTOS E IMPLEMENTACIÓN
3.4.1 Motor de Base de Datos

El motor de base de datos elegido para alojar el Data Mart es Oracle 11g
Enterprise Edition, pues ya se encuentra instalado en la Empresa
almacenando los datos transaccionales. El motor se encuentra en un
Servidor IBM System p5, en donde se ha creado un Esquema llamado
DMITSA mismo que servirá de repositorio.

3.4.2 Herramienta para implementar la solución BI

Para la implementación de la solución BI, se ha elegido Pentaho BI
Community Edition, ya que es una herramienta completa y open source; está
basada en JAVA y se define a sí misma como una plataforma de BI
“orientada a la solución” y “centrada en procesos”.

Pentaho es una suite que incluye todas las herramientas para crear
inteligencia de negocios como son: consultas, reportes, análisis dashboards,
procesos ETL y minería de datos.

Tabla 6

Herramientas de PENTAHO

Producto Codename Característica

Pentaho Analysis
Mondrian Servidor OLAP
Services

Pentaho Report
Pentaho Reportig Reporteador
Engine

Pentaho Data Integración de Datos

Kettle
Integration (ETL)

Pentaho Data Mining Weka Data Mining

Fuente: Pentaho: la solución Open Source BI, (Todo BI, 2011)

Las características y detalle de la instalación de las herramientas se

describen en el Anexo 3
3.5 MODELADO DIMENSIONAL

Luego del análisis de requerimientos y en base a la matriz de procesos /

dimensiones realizada anteriormente; se identificaron ocho procesos de
negocio necesarios para formar el data mart del Departamento de
Repuestos de Importadora Tomebamba, mismo que servirá para responder
a los requerimientos del CSO y COOs del mismo.

Tabla 7

Resumen del Proceso Iterativo del Modelado Dimensional

Dimensiones
Proceso de Negocio Modelo Granularidad Hechos
Compartidas
Modelo 1 Gruesa 6
Ventas - Repuestos Modelo 2 Fina 5 3
Modelo 8 Gruesa 4

Ventas - Vehículos Modelo 8 Gruesa 4 0

Ordenes - Talleres Modelo 8 Gruesa 4 0

Compras Modelo 3 Fina 6 1

Proformas Modelo 5 Fina 6 1

Modelo 4 Gruesa 3
Inventario 2
Modelo 6 Fina 7

KPI / Indicadores Modelo 7 Gruesa 3 1

Metas / Presupuestos Modelo 7 Gruesa 3 0

Una vez concluido este proceso iterativo, se realizan los gráficos de

burbujas; la identificación de atributos de dimensiones y tablas de hechos, y
los modelos dimensionales para cada proceso de negocio.
3.5.1 Modelo 1 - Ventas Netas de Repuestos

Este modelo se crea para el análisis de montos de ventas y devoluciones

netas, así como para obtener las ventas al contado y crédito.

Fecha

Tipo
Transacción Agencia

Ventas Netas
Venta Neta
Devolucion Neta

Tipo de Cliente
Venta Tipo Cliente

Asesor

Figura 17 - Gráfico de Burbujas de Ventas Netas de Repuestos

 40

Tabla 8

Atributos de Dimensión Fecha

Nombre Dim-Fecha
Tipo Dimensional
Descripción Contiene las fechas de las transacciones detalladas para consultas requeridas
Usado en VentaNeta
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo de Tipo de Ta
Campo Descripción Tam Clave por Esquema Tabla Campo Null
Dato valores Dato m
defecto
CodFecha Código de Fecha Number 4 PK 1, 456, 200 Llena Tesista
Fecha Fecha completa Date 20/09/2013 Llena Tesista
20 de
Como mostrar la
FechaCompleta Varchar 25 Septiembre Llena Tesista
fecha
del 2013
Dia Día de la fecha Varchar 2 20 Llena Tesista
Mes Mes de la fecha Varchar 2 9 Llena Tesista
Anio Año de la fecha Varchar 4 2013 Llena Tesista
MesNombre Nombre del mes Varchar 10 Septiembre Llena Tesista
Trimestre para la Trimestre 1,
Trimestre Varchar 15 Llena Tesista
empresa Trimestre 4
Semestre para la Semestre 1,
Semestre Varchar 15 Llena Tesista
empresa Semestre 2
Tabla 9

Atributos de Dimensión Agencia

Nombre Dim-Agencia
Tipo Dimensional
Descripción Contiene Información de las Agencias de Repuestos de Importadora Tomebamba
Usado en VentaNeta
REGLAS DE
TABLA DIMENSIONAL TABLA ORIGEN CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato de valores Dato
defecto
Llenado
CodAgencia Código de Agencia Number 2 PK 1,5,10 secuencialmente
al poblar
Código de Agencia
CodAgenciaT Transaccional Varchar 2 01, 16, 41 NUCLEO ADM_AGENCIA AGECODIGO N VARCHAR 2
Nombre de la Cuenca,
NombreAgencia Agencia Varchar 20 Macas
NUCLEO ADM_AGENCIA AGENOMBRE N VARCHAR 20

País donde se Se busca con

Ecuador,
UbicaPais encuentra la Varchar 20 NUCLEO ADM_PAIS PAINOMBRE N VARCHAR 20 código de tabla
Agencia Japon ADM_AGENCIA
Provincia donde se Se busca con
UbicaProvincia encuentra la Varchar 20 Azuay NUCLEO ADM_PROVINCIA PRVNOMBRE N VARCHAR 20 código de tabla
Agencia ADM_AGENCIA
Cantón donde se Se busca con
Cuenca,
UbicaCanton encuentra la Varchar 30 NUCLEO ADM_CANTON CANNOMBRE N VARCHAR 30 código de tabla
Agencia Puyo ADM_AGENCIA
Estado actual de la
EstadoAgencia Char 1 1 1, 2 NUCLEO ADM_AGENCIA AGEESTADO N CHAR 1
Agencia
Tipo de Agencia
TipoAgencia dentro de ITSA Char 1 R A, I NUCLEO ADM_AGENCIA AGETIPO N VARCHAR 1

Clasifica si es una Limpiar datos

VirtualAgencia Char 1 0 S, N NUCLEO ADM_AGENCIA AGEVIRTUAL Null VARCHAR 1
agencia Virtual Null
Tabla 10

Atributos de Dimensión Cliente

Nombre Dim-Cliente
Tipo Dimensional
Descripción Contiene los clientes de las líneas de Repuestos, Vehículos y Talleres
Usado en VentaNeta
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo de Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato valores Dato
defecto
Llenado
Código del
CodCliente Number 8 PK secuencialme
Cliente
nte al poblar
Documento
DocItentidad de Identidad Varchar 13 REPUESTOS ADM_CLIENTE CLINUMDOCIDENTIDAD N VARCHAR 13
del Cliente
Tipo de Cedula, C=Cedula
TipoDocIdentidad Documento Varchar 10 RUC, REPUESTOS ADM_CLIENTE CLITIPODOCUMENTO N VARCHAR 1 R=RUC
de Identidad Pasaporte P=Pasaporte

Limpiar datos
Apellidos del Null (colocar
Apellidos Varchar 40 REPUESTOS ADM_CLIENTE CLIAPELLIDO Null VARCHAR 40
Cliente un punto en
vacíos)

Limpiar datos
Nombres del Null (colocar
Nombres Varchar 40 REPUESTOS ADM_CLIENTE CLINOMBRE Null VARCHAR 40
Cliente un punto en
vacíos)
Limpiar datos
Dirección
Direccion Varchar 60 REPUESTOS ADM_DIRECCION CLIULTISECUDIRE VARCHAR 60 Null (colocar
del Cliente
S/D en vacíos)

CONTINÚA
 Limpiar datos
Teléfono del
Telefono Varchar 10 REPUESTOS ADM_TELEFONO CLIULTISECUTELE VARCHAR 10 Null (colocar
Cliente
S/T en vacíos)
Limpiar datos
Email del
Email Varchar 60 REPUESTOS ADM_CLIENTE CLIEMAIL Null VARCHAR 60 Null (colocar
Cliente
"sin email")
Limpiar datos
Null (hacer
recorrido
Género del completo)
Genero Varchar 1 F, M REPUESTOS ADM_CLIENTE CLISEXO Null VARCHAR 1
Cliente Modificar
datos
erróneos (d, s,
n)
Nombres de
Agencia
agencias.
donde se Cuenca,
AgenciaCliente Varchar 20 Cuenca REPUESTOS ADM_CLIENTE CLIAGECODIGO Null VARCHAR 2 Limpiar datos
creó el Macas
Null (colocar
cliente Cuenca)
1=A
Estado del
EstadoCliente Varchar 1 A, I REPUESTOS ADM_CLIENTE CLIESTADO N VARCHAR 1 2=A
Cliente 9=I
Clasifica el
Limpiar datos
Cliente es
EsTarjetaCredito Varchar 1 N N, S REPUESTOS ADM_CLIENTE CLITARJETACREDITO Null VARCHAR 1 Null (Colocar
una Tarjeta
N)
de Crédito
Clasifica si
Limpiar datos
el Cliente es
EsEmpresaVinvulada Varchar 1 N N, S REPUESTOS ADM_CLIENTE CLIVINCULADO Null VARCHAR 1 Null (Colocar
Empresa
N)
vinculada
Clasifica si
Limpiar datos
el cliente
CalculaIVA Varchar 1 S N, S REPUESTOS ADM_CLIENTE CLIIVASINO Null VARCHAR 1 Null (Colocar
paga o no
IVA S)
Clasifica si Limpiar datos
Empleado,
TipoCliente el Cliente es Varchar 10 Normal REPUESTOS ADM_CLIENTE CLITIPOCLIENTE Null VARCHAR 3 Null (Colocar
Empleado Normal NOR)

CONTINÚA
 Segmento al Llena Tesista,
Mayorista,
que Cliente según
SegmentoCliente Varchar 17 Aseguradora,
pertenece el Final parámetros de
Cliente Final
cliente Gerencia
Tipo de
Limpiar datos
TipoClienteTaller Cliente de Varchar 3 CPU, INT REPUESTOS ADM_CLIENTE CLITIPOCLIENTETALLER VARCHAR 3
Taller Null (N)
Clasifica si
el Cliente Limpiar datos
DiasGracia tiene días Varchar 1 N N, S REPUESTOS ADM_CLIENTE CLITIENEDIASGRACIA Null VARCHAR 1 Null (Colocar
de gracia en N)
pagos
Limpiar datos
Estado Civil Soltero,
EstadoCivil Varchar 15 REPUESTOS ADM_CLIENTE CLIESTADOCIVIL Null VARCHAR 3 Null (Colocar
del Cliente Casado
Casado)
Clasifica el
Limpiar datos
tipo de Natural,
TipoPersona Varchar 10 REPUESTOS ADM_CLIENTE CLITIPOPERSONA Null VARCHAR 3 Null (Colocar
persona del Juridica
Natural)
cliente
Tabla 11

Atributos de la Dimensión Asesor

Nombre Dim-Asesor
Tipo Dimensional
Descripción Contiene Información de los asesores de Repuestos
Usado en VentaNeta
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato de valores Dato
defecto
Llenado
CodAsesor Código de Asesor Number 2 PK secuencialmen
te al poblar
Código DB de
CodAsesorT Varchar 4 REPUESTOS REP_VENDEDOR VERCODIGO N VARCHAR 4
Asesor
Numero doc
CIAsesor Varchar 13 REPUESTOS REP_VENDEDOR CLINUMDOCIDENTIDAD N VARCHAR 13
identidad asesor

Apellidos del
ApellidoVendedor Varchar 40 REPUESTOS ADM_CLIENTE CLIAPELLIDO Null VARCHAR 40
Asesor

Nombres del
NombreVendedor Varchar 40 REPUESTOS ADM_CLIENTE CLINOMBRE Null VARCHAR 40
Asesor

Nombre de la
Cuenca,
NombreAgencia Agencia en que Varchar 20 NUCLEO ADM_AGENCIA AGENOMBRE N VARCHAR 20
trabaja Macas
Clasifica si el 1=A
EstadoAsesor asesor está activo Varchar 1 A, I REPUESTOS REP_VENDEDOR VERESTADO N VARCHAR 1 2=A
o inactivo 9=I
Tabla 12

Atributos de la Dimensión Tipo de Venta

Nombre Dim-TipoVenta
Tipo Dimensional
Descripción Contiene los tipos de venta que se aplican en
repuestos
Usado en VentaNeta
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo de Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato valores Dato
defecto
Código de Tipo de
CodTipoVenta Number 2 PK Llena Tesista
Venta
Crédito,
TipoVenta Tipo de Venta Varchar 10 Contado Llena Tesista
Dias de plazo para 0, 1, 30,
DiasPlazo Number 3 180 Llena Tesista
pago
Estado del Tipo de
EstadoTipoVenta Venta Varchar 1 A, I Llena Tesista
Tabla 13

Atributos de la Dimensión Tipo de Transacción

Nombre Dim-TipoTransaccion
Tipo Dimensional
Descripción Contiene los tipos de transacciones que existen en Repuestos
Usado en Detalle Inventario
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor Ejemplo
Tipo de Tipo de
Columna Descripción Tam Clave por de Esquema Tabla Campo Null Tam
Dato defecto valores Dato
Código del Llenado
CodTipoTrans tipo de Number 2 PK secuencialmente
transacción al poblar
Código del
Se agregarán
tipo de
CodTipoTransT Varchar 3 PK REPUESTOS REP_TIPO_DOCUMENTO TDCCODIGO N VARCHAR 3 más
transacción
transacciones
transaccional
Nombre del
NombreTipoTrans tipo de Varchar 40 REPUESTOS REP_TIPO_DOCUMENTO TDCDESCRIPCION N VARCHAR 40
transacción
Clasifica 1=A
EstadoTipoTrans estado del tipo Varchar 1 REPUESTOS REP_TIPO_DOCUMENTO TDCESTADO N VARCHAR 1 2=A
de transacción 9=I
Tabla 14

Atributos de la Tabla de Hechos VentaNeta

Nombre Hecho-VentaNeta
Tipo Hechos
Descripción Contiene las ventas netas de
Repuestos
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor Ejemplo Tipo
Tipo de
Columna Descripción Tam Clave por de Esquema Tabla Campo Null de Tam
Dato
defecto valores Dato
Código de 0001,
CodFecha Fecha Number 4 PK 0456 Llena Tesista

Llenado
Código de
CodAgencia Number 2 PK 1,5,10 secuencialmente
Agencia
al poblar
Llenado
Código del
CodCliente Number 8 PK secuencialmente
Cliente
al poblar
Llenado
Código de
CodAsesor Number 2 PK secuencialmente
Asesor
al poblar
Código de
CodTipoVenta Number 2 PK Llena Tesista
Tipo de Venta
Código del Llenado
CodTipoTans tipo de Number 2 PK secuencialmente
transacción al poblar
Total Neto de
VENCSUBTOTAL, subtot vendido -
VentaNeta ventas de Number 14,2 REPUESTOS REP_VENTA_CABE
VENCVALORDESCUENTO dscto aplicado
repuestos
Total Neto de
DVECSUBTOTAL, subtot devuelto -
DevolucionNeta devoluciones Number 14,2 REPUESTOS REP_DEVO_VENT_CABE
DVECVALORDESCUENTO dscto aplicado
de repuestos
Figura 18 - Modelo Dimensional 1 - Ventas Netas de Repuestos
 50

3.5.2 Modelo 2 - Detalle de Ventas de Repuestos

Este modelo se crea para el análisis de ventas por ICC y por item.

Fecha

Tipo Detalle de Ventas

Transacción Agencia
Control Interno Total Cantidad Total Neto
Total Costo

ICC Item
Grupo ICC

Figura 19 - Gráfico de Burbujas de Detalle de Ventas de Repuestos

Se utilizarán las dimensiones conformadas Dim-Fecha (Tabla 8), Dim-

Agencia (Tabla 9) y Dim_TipoTransaccion (Tabla 13).
 51

Tabla 15

Atributos de Dimensión Item

Nombre Dim-Item
Tipo Dimensional
Descripción Contiene los items que se comercializan en Repuestos
Usado en Detalle de Ventas
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Tipo de Valor por Ejemplo Tipo de
Columna Descripción Tam Clave Esquema Tabla Campo Null Tam
Dato defecto de valores Dato
Código Llenado
CodigoItem secuencial Number 6 PK secuencialmente al
del item poblar
Código del
CodMaestroIte
maestro de Varchar 15 REPUESTOS REP_ITEM ITECODIGO N VARCHAR 15
m items
Línea de Accesorios, AC=ACCESORIOS
LineaNegocio Negocio del Varchar 10 Repuestos Baterias, REPUESTOS REP_ITEM LIRCODIGO N VARCHAR 2 BA=BATERIAS
item Repuestos VT=REPUESTOS
Descripción ITEDESCRIPCI
Descripción del item Varchar 60 REPUESTOS REP_ITEM
ON
N VARCHAR 60

Código del
item que ITECODIGOSU Limpiar datos Null
CodReemplazo Varchar 15 REPUESTOS REP_ITEM Null VARCHAR 15
reemplaza, STITUTO (Colocar "N")
es histórico
Limpiar datos Null
Fob del item
(Buscar en tabla
FobItem (precio Number 14,2 REPUESTOS REP_ITEM ITEFOB Null NUMERIC 14,2
JMP, caso contrario
Japón)
colocar 0)
ICC
Limpiar datos Null
(Nacional) ITECLASIFICA
ICCNAC Char 2 REPUESTOS REP_ITEM Null CHAR 2 (Colocar "R" porque
del item, es DORICC
son reemplazos)
histórico
CONTINÚA
 Contiene
el modelo
del ITEUNIDADME Limpiar datos Null
ModeloVehiculo Varchar 10 REPUESTOS REP_ITEM Null VARCHAR 10
vehículo al DIDA (Colocar "UNID")
cual
pertenecen
los
repuestos
Obtener las
Procedencia procedencias de
Procedencia Varchar 40 REPUESTOS REP_ITEM IPRCODIGO Null VARCHAR 3
del item REP_ITEM_PROCE
DENCIA

Código de ZZ1Z, Limpiar datos Null

PNC Varchar 4 REPUESTOS REP_ITEM JPMPROCOD Null VARCHAR 4
Producto REST (Colocar "REST")
Grupo en
Obtener el Grupo del
sistema del Competitive
GrupoPNC Varchar 30 Excel
Código de , Hybrid
Factores_Precio
Producto
1=A
Estado del
EstadoItem Varchar 1 A, I REPUESTOS REP_ITEM ITEESTADO Null VARCHAR 1 2=A
item
9=I

Tabla 16

Atributos de Dimensión ICC

Nombre Dim-ICC
Tipo Dimensional
Descripción Contiene los ICC y sus grupos utilizados en Repuestos
Usado en VentaNeta
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo de Tipo de Ta
Columna Descripción Tam Clave por Esquema Tabla Campo Null
Dato defecto valores Dato m
CodICC Código de ICC Number 2 PK Llena Tesista
A1, A2, C2,
ICC La Letra de ICC Varchar 2 Llena Tesista
F
Grupo al que
GrupoICC pertenece ICC Varchar 1 A, C, F Llena Tesista
EstadoICC Estado ICC Varchar 1 A, I Llena Tesista
Tabla 17

Atributos de la Tabla de Hechos Detalle de Ventas

Nombre Hecho-DetalleDeVentas
Tipo Hechos
Descripción Contiene las ventas diarias de Repuestos
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor Ejemplo
Tipo de Tipo de
Columna Descripción Tam Clave por de Esquema Tabla Campo Null Tam
Dato Dato
defecto valores
Código de 0001,
CodFecha Number 4 PK 0456 Llena Tesista
Fecha
Llenado
Código de
CodAgencia Number 2 PK 1,5,10 secuencialmente al
Agencia
poblar
Código Llenado
CodigoItem secuencial Number 6 PK secuencialmente al
del item poblar
Código de
CodICC ICC Varchar 2 PK Llena Tesista

Código del Llenado

CodTipoTrans tipo de Number 2 PK secuencialmente al
transacción poblar
Número de REP_VENTA_DET Se toma el número de
control REPUEST A VENCNUMERO VARCH control interno de la
ControlInterno Varchar 9 DD N 9
interno de la OS REP_DEVO_VENT DVECNUMERO AR factura vendida o de la
factura _CABE nota de crédito
Total de Verificar si es correcto
REPUEST REP_VENTA_DET NUMBE
CantidadVendida Cantidad Number 10 OS A
VENDCANTIDAD N R
10 que existan cantidades
Vendida =0
Subtotal Verificar si es correcto
REPUEST REP_VENTA_DET NUMBE
SubtotalVendido Vendido en Number 14,2 OS A
VENDPRECIOTOTAL N R
14,2 que existan cantidades
dólares =0
CONTINÚA
 Descuento Calcular el % de
REPUEST REP_VENTA_DET VENCPORCDESCUE NUMBE
DescuentoEnVenta aplicado en Number 10,2 OS A NTO
N R
5,2 descuento por línea
dólares facturada o devuelta
Costo de la Verificar si es correcto
REPUEST REP_VENTA_DET NUMBE
CostoDeVenta venta en Number 14,2 OS A
VENDCOSTOTOTAL N R
14,2 que existan cantidades
dólares =0
Total de Verificar si es correcto
REPUEST REP_DEVO_VENT NUMBE
CantidadDevuelta Cantidad Number 10 OS _DETA
DVEDCANTIDAD N R
10 que existan cantidades
Vendida =0
Subtotal Verificar si es correcto
REPUEST REP_DEVO_VENT NUMBE
SubtotalDevuelto Vendido en Number 14,2 OS _DETA
DVEDPRECIOTOTAL N R
14,2 que existan cantidades
dólares =0
Descuento Calcular el % de
REPUEST REP_DEVO_VENT DVECPORCDESCUE NUMBE
DescuentoDevuelto aplicado en Number 10,2 OS _DETA NTO
N R
5,2 descuento por línea
dólares facturada o devuelta
Costo de la Verificar si es correcto
REPUEST REP_DEVO_VENT NUMBE
CostoDevuelto venta en Number 14,2 OS _DETA
DVEDCOSTOTOTAL N R
14,2 que existan cantidades
dólares =0
 ADM_PAIS Relationship_1 ADM_PROVINCIA
Dim-Fecha
PAICODIGO <pi> Vari PAINOMBREVari PRVCODIGO <pi> Variabl PRVNOMBREVariabl CodFecha <pi> Number (4) <M>
PAIESTADOCha PRVESTADOCharact Fecha Date
FechaCompleta Variable characters (25)
Identifier_1 <pi> Dia Variable characters (2)
Identifier_1 <pi>
Mes Variable characters (2)
Anio Variable characters (4)
MesNombre Variable characters (10)
Relationship_2
Trimestre Variable characters (15) REP_LINEA
Semestre Variable charactersLIRCODIGO<pi>
(15) Variable characters (2) <M> LIRDESCRIPCIONVariable characters (20) LIRESTADOVariable characters (1)
ADM_CANTON DiaFestivo Variable characters (20)
CANCODIGO <pi> Var CANNOMBREVar Identifier_1 <pi>
CANESTADOCha
Identifier_1 <pi>

Identifier_1 <pi>

Relationship_17 Relationship_22

Relationship_36
REP_ITEM
Hecho-DetalleDeVentas ITECODIGO<pi> Variable characters (15) <M> ITEDESCRIPCIONVariable characters (60)
ADM_AGENCIA
ControlInternoVariable characters (9) CantidadVendidaNumber (10) ITECODIGOSUSTITUTOVariable characters (15)
AGECODIGO <pi> Variable characters (2) <M> AGENOMBREVariable characters (20) AGEESTADOCharacters (1)
SubtotalVendidoNumber (14,2) DescuentoEnVenta Number (5,2) ITEFOBNumber (14,2) ITECLASIFICADORICCCharacters (2)
AGETIPOVariable characters (1) AGEVIRTUALVariable characters (1) Relationship_20 Relationship_18
ITEUNIDADMEDIDAVariable characters (10)
CostoDeVentaNumber (14,2)
ITEESTADOVariable characters (1)

Identifier_1 <pi> Identifier_1 <pi>

Relationship_19 Relationship_40

REP_ITEM_PROCEDENCIA
Dim-ICC
CodICC <pi> Variable characters (2) <M> IPRCODIGO<pi> Variable characters (3) <M> IPRDESCRIPCIONVariable characters (40)
ICC Variable characters (2) IPRESTADOVariable characters (1) IPRCODIGOALTERNOVariable characters (10)
GrupoICC Variable characters (1)
EstadoICC Variable characters (1)
Identifier_1 <pi> Identifier_1 <pi>

Figura 20 - Modelo Dimensional 2 - Detalle de Ventas de

Repuestos
 56

3.5.3 Modelo 3 - Compras de Repuestos

Este modelo se crea para analizar el monto de compras de repuestos, a
Toyota del Ecuador.

Fecha

ICC Agencia

Compras
Cantidad Costo

Item Asesor

Proveedor

Figura 21 - Gráfico de Burbujas de Compras de Repuestos

Se utilizarán las dimensiones conformadas Dim-Fecha (Tabla 8), Dim-

Agencia (Tabla 9) y Dim-Asesor (Tabla 11), Dim_Item (Tabla 15), Dim_ICC
(Tabla 16).
 57

Tabla 18

Atributos de Dimensión Proveedor

Nombre Dim-Proveedor
Tipo Dimensional
Descripción Contiene los proveedores de Repuestos
Usado en Compras
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato de valores Dato
defecto
Llenado
Código de
CodProveedor Number 2 PK secuencialment
Proveedor
e al poblar
Numero
documento CLINUMDOCIDE
CIProveedor Varchar 13 REPUESTOS REP_PROVEEDOR N VARCHAR 13
identidad del NTIDAD
proveedor
Se toman datos
Nombres del
Nombres Varchar 40 REPUESTOS DIM_CLIENTE CLINOMBRE Null VARCHAR 40 de la dimension
Proveedor
limpiada
Se toman datos
Apellidos del
Apellidos Varchar 40 REPUESTOS DIM_CLIENTE CLIAPELLIDO Null VARCHAR 40 de la dimension
Proveedor
limpiada
Clasifica si el 1=A
EstadoProveedor proveedor esta Varchar 1 A, I REPUESTOS REP_PROVEEDOR PRRESTADO N VARCHAR 1 2=A
activo o inactivo 9=I
Tabla 19

Atributos de la Tabla de Hechos Compras de Repuestos

Nombre Hecho-Compras
Tipo Hechos
Descripción Contiene las compras ingresadas de repuestos
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato de valores Dato
defecto
CodFecha Código de Fecha Number 4 PK 0001, 0456 Llena Tesista
Llenado
CodAgencia Código de Agencia Number 2 PK 1,5,10 secuencialmente
al poblar
Llenado
CodAsesor Código de Asesor Number 2 PK secuencialmente
al poblar
Llenado
Código de
CodProveedor Number 2 PK secuencialmente
Proveedor
al poblar
Llenado
Código secuencial
CodigoItem Number 6 PK secuencialmente
del item
al poblar
CodICC Código de ICC Varchar 2 PK Llena Tesista
Número de Factura Se llena desde
NumeroCompra Number 10 DD
de Compra archivo TDE
CantidadCompra Cantidad Se llena desde
Number 10
da comprada archivo TDE
Costo de la REP_COMPRA
CostodeCompra Number 14,2 REPUESTOS CCACOSTOTOTAL N NUMBER 14,2
compra _CABE
 ADM_PAIS ADM_PROVINCIA
Relationship_1
PAICODIGO <pi> Vari PAINOMBREVari
PRVCODIGO <pi> Variabl PRVNOMBREVariabl Dim-Fecha
PRVESTADOCharact CodFecha <pi> Number (4) <M>
PAIESTADOCha
Fecha Date
Identifier_1 <pi> FechaCompleta Variable characters (25)
Identifier_1 <pi>
Dia Variable characters (2)
Mes Variable characters (2)
Anio Variable characters (4)
Relationship_2
MesNombre Variable characters (10)
Trimestre Variable characters (15)
ADM_CANTON Semestre Variable characters (15)
DiaFestivo Variable characters (20)
CANCODIGO <pi> Var CANNOMBREVar
CANESTADOCha Identifier_1 <pi>

Identifier_1 <pi> Relationship_23

Hecho-Compras
TotalCompra Number (14,2)
Relationship_36

ADM_AGENCIA
Relationship_24 Relationship_26 REP_VENDEDOR
VERCODIGO <pi> Variable characters (4) <M>
AGECODIGO <pi> Variable characters (2) <M> AGENOMBREVariable characters (20) AGEESTADOCharacters (1)
VERESTADO Variable characters (1)
AGETIPOVariable characters (1) AGEVIRTUALVariable characters (1)
Identifier_1 <pi>

Identifier_1 <pi>
Relationship_8

Relationship_25

REP_PROVEEDOR
PRRCODIGO <pi> Variable characters (1) <M> PRRESTADOVariable characters (1)

Identifier_1 <pi>

Figura 22 - Modelo Dimensional 3 - Compras de Repuestos

 60

3.5.4 Modelo 4 - Inventario de Repuestos

Este modelo se crea para obtener el monto de inventario por ICC.

Fecha

Inventario
Total Costo

ICC Agencia

Figura 23 - Gráfico de Burbujas de Inventario de Repuestos

Se utilizarán las dimensiones conformadas Dim-Fecha (Tabla 8), Dim-

Agencia (Tabla 9) y Dim-ICC (Tabla 16).
 61

Tabla 20

Atributos de la Tabla de Hechos Inventario

Nombre Hecho-Inventario
Tipo Hechos
Descripción Contiene el Costo de Inventario a la fecha requerida
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo de Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato valores Dato
defecto
CodFecha Código de Fecha Number 4 PK 0001, 0456 Llena Tesista
Llenado
CodAgencia Código de Agencia Number 2 PK 1,5,10 secuencialment
e al poblar
CodICC Código de ICC Varchar 2 PK Llena Tesista
Sólo guarda
Cantidad en KARSALDOCANTIDA NUMBE
TotalCantidad Number 5,2 REPUESTOS REP_KARDEX N 5,2 cantidades
Inventario D R
mayores a 0
KARSALDOCANTIDA
D Multiplica saldo
NUMBE
TotalCosto Costo de Inventario Number 14,2 REPUESTOS REP_KARDEX * N R
14,2 final a la fecha
KARCOSTOUNITARI * Costo
O
 ADM_PAIS ADM_PROVINCIA
Relationship_1
PRVCODIGO <pi> Variabl PRVNOMBREVariabl
PAICODIGO <pi> Vari PAINOMBREVari
PRVESTADOCharact
PAIESTADOCha
Dim-Fecha

Identifier_1 <pi> CodFecha <pi> Number (4) <M>

Identifier_1 <pi> Fecha Date
FechaCompleta Variable characters (25)
Dia Variable characters (2)
Relationship_2 Mes Variable characters (2)
Anio Variable characters (4)
MesNombre Variable characters (10)
ADM_CANTON
Trimestre Variable characters (15)
CANCODIGO <pi> Var CANNOMBREVar Semestre Variable characters (15)
CANESTADOCha DiaFestivo Variable characters (20)
Identifier_1 <pi>
Identifier_1 <pi>

Hecho-Inventario
Relationship_36
TotalCosto Number (14,2)

ADM_AGENCIA
Relationship_27
AGECODIGO <pi> Variable characters (2) <M> Relationship_28
AGENOMBREVariable characters (20) AGEESTADOCharacters (1)
AGETIPOVariable characters (1) AGEVIRTUALVariable characters (1)

Identifier_1 <pi>

Relationship_29

Dim-ICC
CodICC <pi> Variable characters (2) <M>
ICC Variable characters (2)
GrupoICC Variable characters (1)
EstadoICC Variable characters (1)
Identifier_1 <pi>

Figura 24 - Modelo Dimensional 4 - Inventario de Repuestos

 63

3.5.5 Modelo 5 - Detalle de Reservas

Este modelo se crea para reportar los items reservados y pendientes de

facturar.

Fecha

Estado
Agencia
Proforma
Detalle de
Reservas
Cantidad Reservada

Item Cliente

Asesor

Figura 25 - Gráfico de Burbujas de Detalle de Reservas

Se utilizarán las dimensiones conformadas Dim-Fecha (Tabla 8), Dim-

Agencia (Tabla 9), Dim-Cliente (Tabla 10), Dim-Asesor (Tabla 11), Dim-Item
(Tabla 15).
 64

Tabla 21

Atributos de Dimensión Estado de Proforma

Nombre Dim-Estado Proforma

Tipo Dimensional
Descripción Contiene los estado posibles de las
proformas
Usado en Reservas Detalle
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato de valores Dato
defecto

Llenado
Código del estado
CodEstadoProf Number 1 PK secuencialmente
de proforma
al poblar
Reserva,
Nombre del tipo de
NombreEstProf Varchar 10 Proforma, Llena Tesista
estado de proforma
Venta
Clasifica estado del
EstadoEstProf Varchar 1 A A, I Llena Tesista
estado de proforma
Tabla 22

Atributos de la Tabla de Hechos de Detalle de Reservas

Nombre Hecho-ReservasDetalle
Tipo Hechos
Descripción Contiene los items reservados pendiente de facturar
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor Ejemplo
Tipo de Tipo de
Columna Descripción Tam Clave por de Esquema Tabla Campo Null Tam
Dato Dato
defecto valores
Código de 0001,
CodFecha Fecha Number 4 PK 0456 Llena Tesista
Llenado
Código de
CodAgencia Number 2 PK 1,5,10 secuencialmente
Agencia
al poblar
Llenado
Código del
CodCliente Number 8 PK secuencialmente
Cliente
al poblar
Llenado
Código de
CodAsesor Number 2 PK secuencialmente
Asesor al poblar
Código del
CodItem item Varchar 15 PK REPUESTOS REP_ITEM ITECODIGO N VARCHAR 15
Código del Llenado
CodEstadoProf estado de Number 1 PK secuencialmente
proforma al poblar
Cantidad
CantidadReserva reservada Number 2 REPUESTOS REP_PROFORMA_DETA PRFDCANTIDAD N NUMBER 2
 ADM_PROVINCIA
ADM_PAIS Relationship_1
Dim-Fecha
PRVCODIGO
<pi> Number<pi> Variabl PRVNOMBREVariabl
(4) Date Dim-Estado Proforma
PAICODIGO PAINOMBRE PAIESTADO
<pi> Vari CodFecha Fecha FechaCompleta Dia <M>
PRVESTADOCharact
Variable characters (25) Variable characters (2) Variable characters (2) Variable characters (4) Variable characters (10) Variable characters (15) Variable charactersNumber
CodEstadoProf (15) Variable
(1) characters (20)
Vari Cha Mes Anio
MesNombre Trimestre Semestre NombreEstProf Variable characters (10)
Identifier_1 <pi> DiaFestivo EstadoEstProf Variable characters (1)
Identifier_1 <pi>
Identifier_1 <pi>

Relationship_2
REP_LINEA
LIRCODIGO LIRDESCRIPCION LIRESTADO
<pi> Variable
ADM_CANTON Identifier_1 <pi> Variable Variable
<pi> Var
CANCODIGO CANNOMBRE CANESTADO
Relationship_7 Relationship_39
Var Cha

Identifier_1 <pi>Relationship_30Relationship_22
Relationship_36
Hecho-ReservasDetalle
ContadorReservas Number (3) REP_ITEM
ITECODIGO<pi> Variable characters (15) <M> ITEDESCRIPCIONVariable characters (60)
ITECODIGOSUSTITUTOVariable characters (15) ITEFOBNumber (14,2)
ADM_AGENCIA Relationship_38 ITECLASIFICADORICCCharacters (2)
<pi> Variable characters (2) Variable characters (20) Characters (1) ITEUNIDADMEDIDAVariable characters (10)
AGECODIGO AGENOMBRE AGEESTADO AGETIPO AGEVIRTUAL <M>
Variable characters (1) Variable characters (1) ITEESTADOVariable characters (1)
Relationship_31 Identifier_1 <pi>
Relationship_8

Identifier_1 <pi>

Relationship_40
Relationship_32

ADM_PARROQUIA Relationship_33 REP_ITEM_PROCEDENCIA

PARCODIGO <pi> Varia PARNOMBREVaria IPRCODIGO<pi> Variabl IPRDESCRIPCIONVariabl

PARESTADOChar ADM_CLIENTE IPRESTADOVariabl
CLINUMDOCIDENTIDAD <pi> Variable characters (13) <M> IPRCODIGOALTERNOVariabl
Identifier_1 <pi>
Identifier_1 <pi> Variable characters (1) Variable characters
CLITIPODOCUMENTO
(40) Variable characters
CLIAPELLIDO
(60) Variable characters (1) Variable characters (40) Variable characters (2) Variable characters (1) Variable characters (1) Variable characters (1)
Relationship_37 CLIEMAIL CLISEXO CLINOMBRE CLIAGECODIGO CLIESTADO
Relationship_34 CLITARJETACREDITO CLIVINCULADO

ADM_DIRECCION
REP_VENDEDOR
DIRNUMSECUENCIAL <pi> Numbe DIRDIRECCIONVariab
Rela(Dti)onship_9 VERCODIGO <pi> Variable characters (4) <M> VERESTADOVariable characters (1)
DIRESTADOVariab
Identifier_1 <pi>
Identifier_1 <pi>

Figura 26 - Modelo Dimensional 5 - Detalle de Reservas

 67

3.5.6 Modelo 6 - Detalle de Inventario de Repuestos

Este modelo se ha creado para analizar el movimiento y stock de los

items del Departamento de Repuestos.

Fecha

Item Agencia

Detalle de Inventario
Stock Total Costo Total PVP
Total Cantidad

Tipo
ICC
Transaccion

Línea de
Proveedor
Venta

Figura 27 - Gráfico de Burbujas de Detalle de Inventario

Se utilizarán las dimensiones conformadas Dim-Fecha (Tabla 8), Dim-

Agencia (Tabla 9), Dim-TipoTransaccion (Tabla 13), Dim-Item (Tabla 15),
Dim-ICC (Tabla 16), Dim-Proveedor (Tabla 18).
 68

Tabla 23

Atributos de Dimensión de Línea de Venta

Nombre Dim-LineaDeVenta
Tipo Dimensional
Descripción Contiene las líneas de venta de Importadora Tomebamba y sus
Departamentos
Usado en Detalle Inventario
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor Ejemplo
Tipo de Tipo de
Columna Descripción Tam Clave por de Esquema Tabla Campo Null Tam
Dato Dato
defecto valores
Llenado
Código de la
CodLineaVenta Number 2 PK secuencialmente
línea de venta
al poblar
Código de la
CodLineaVentaT línea de venta Varchar 2 PK REPUESTOS REP_LINEA LIRCODIGO N VARCHAR 2
transaccional
Nombre de la
NombreLineaVenta Varchar 20 REPUESTOS REP_LINEA LIRDESCRIPCION N VARCHAR 20
línea de venta
Clasifica estado 1=A
EstadoLineaVenta de la línea de Varchar 1 REPUESTOS REP_LINEA LIRESTADO N VARCHAR 1 2=A
venta 9=I
Tabla 24

Atributos de la Tabla de Hechos Detalle de Inventario

Nombre Hecho-DetalleInventario
Tipo Hechos
Descripción Contiene todas las transacciones realizadas con los items de Repuestos
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Tipo Valor Ejemplo
Tipo de
Columna Descripción de Tam Clave por de Esquema Tabla Campo Null Tam
Dato
Dato defecto valores
Num 0001,
CodFecha Código de Fecha ber 4 PK 0456 Llena Tesista
Llenado
Código de Num
CodAgencia 2 PK 1,5,10 secuencialmente
Agencia ber
al poblar
Código Llenado
Num
CodigoItem secuencial del 6 PK secuencialmente
ber
item al poblar
Varc
CodICC Código de ICC har 2 PK Llena Tesista
Llenado
Código de Num
CodProveedor 2 PK secuencialmente
Proveedor ber
al poblar
Código de la Num
CodLineaVenta 2 PK REPUESTOS REP_LINEA LIRCODIGO N VARCHAR 2
línea de venta ber
Se agregarán
Código del tipo Nu
CodTipoTrans 2 PK REPUESTOS REP_TIPO_DOCUMENTO TDCCODIGO N VARCHAR 3 más
de transacción mber
transacciones
Número de
Varc Depende de la transacción
NumeroDoc Documento de 10 DD
Transacción har que se grabe

Num Depende de la transacción

CantidadInventario Cantidad movida 10
ber que se grabe
Costo al Num Depende de la transacción
CostoInventario movimiento ber 14,2 que se grabe
Precio de venta Num Depende de la transacción
PrecioVentaInventario 14,2
al movimiento ber que se grabe
Saldo final luego Num Depende de la transacción
SaldoFinalInventario 10
del movimiento ber que se grabe
 ADM_PROVINCIA
ADM_PAIS Relationship_1
REP_LINEA
PAICODIGO PRVCODIGO <pi> Variabl Dim-Fecha LIRCODIGO <pi> Variable
<pi> Vari
PAINOMBRE PRVNOMBRE Variabl CodFecha <pi> Number (4) <M> LIRDESCRIPCION Variable
Vari
PAIESTADO PRVESTADO Charact Fecha Date LIRESTADO Variable
Cha
Identifier_1 <pi> FechaCompleta Variable characters (25) Identifier_1 <pi>
Identifier_1 <pi>
Dia Variable characters (2)
Mes Variable characters (2) Relationship_22
Anio Variable characters (4)
Relationship_2
MesNombre Variable characters (10) REP_ITEM
Trimestre Variable characters (15) ITECODIGO <pi> Variable characters (15) <M>
Semestre Variable characters (15) ITEDESCRIPCION Variable characters (60)
ADM_CANTON
DiaFestivo Variable characters (20)
CANCODIGO Identifier_1 <pi> Relationship_45 ITECODIGOSUSTITUTO Variable characters (15)
CANNOMBRE <pi> Var ITEFOB Number (14,2)
CANESTADO Var ITECLASIFICADORICC Characters (2)
Cha ITEUNIDADMEDIDA Variable characters (10)
Identifier_1 <pi> ITEESTADO Variable characters (1)
Relationship_41
Identifier_1 <pi>
Relationship_36
Relationship_40
ADM_AGENCIA Hecho-DetalleDeInventario
AGECODIGO REP_ITEM_PROCEDENCIA
<pi> Variable characters (2) <M> CantidadInventario Number (10)
AGENOMBRE Variable characters (20) CostoInventario Number (14,2) IPRCODIGO <pi> Variabl
AGEESTADO Characters (1) PrecioVentaInventario Number (14,2) IPRDESCRIPCION Variabl
AGETIPO Variable characters (1) Relationship_42 SaldoFinalInventario Number (10) IPRESTADO Variabl
AGEVIRTUAL Variable characters (1) IPRCODIGOALTERNO Variabl
Identifier_1 <pi> Identifier_1 <pi>

Dim-ICC Dim-TipoTransaccion
Relationship_47
CodICC <pi> Variable characters (2) <M>
Relationship_46 CodTipoTrans <pi> Variable characters (3) <M>
ICC Variable characters (2)
NombreTipoTrans Variable characters (40)
GrupoICC Variable characters (1)
Relationship_43 Relationship_44 EstadoTipoTrans Variable characters (1)
EstadoICC Variable characters (1)
Identifier_1 <pi>
Identifier_1 <pi>

REP_PROVEEDOR
PRRCODIGO <pi> Variable characters (1) <M>
PRRESTADO Variable characters (1)
Identifier_1 <pi>
Dim-LineaDeVenta
CodLineaVenta<pi> Variable characters (2) <M> NombreLineaVentaVariable characters (20) EstadoLineaVentaVariable characters (1)

Identifier_1 <pi>

Figura 28 - Modelo Dimensional 6 - Detalle de Inventario del Departamento de Repuestos

 71

3.5.7 Modelo 7 - Comparación de Resultados y Metas

Este modelo se crea para realizar una comparación entre las metas
fijadas por Gerencia y los resultados de la gestión.

Fecha

Compara Metas
Total Meses Stock + Previsto Total TS + Previsto
Total TS Inmediata + Previsto Total Rentabilidad + Previsto
Total Venta Neta + Previsto

ICC
Grupo ICC Agencia

Figura 29 - Gráfico de Burbujas de Comparación con Metas

Se utilizarán las dimensiones conformadas Dim-Fecha (Tabla 8), Dim-

Agencia (Tabla 9) y Dim-Item (Tabla 16).
Al ser un modelo para comparación, la tabla de hechos se poblará con
los resultados de las bases de datos transaccionales y con las metas fijadas
por Gerencia desde un archivo Excel.
 72

Tabla 25

Atributos de la Tabla de Hechos de Comparación de Metas

Nombre Hecho-ComparaMetas
Tipo Hechos
Descripción Contiene todas las metas utilizadas en el Departamento de Repuestos
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor Ejemplo Tipo
Tipo de
Columna Descripción Tam Clave por de Esquema Tabla Campo Null de Tam
Dato
defecto valores Dato
0001,
CodFecha Código de Fecha Number 4 PK 0456 Llena Tesista
Llenado
Código de
CodAgencia Number 2 PK 1,5,10 secuencialmente
Agencia
al poblar

CodICC Código de ICC Varchar 2 PK Llena Tesista

Monto de
Inventario /
Promedio de
MesesStock Meses de Stock Number 4,2 REPUESTOS
Costo de Venta
de los Últimos 6
meses
Meses de Stock Se carga desde
MesesStockMeta Number 4,2
Fijado en Meta Excel

TotalNeto *
Monto de
MontoRentabilidad Number 14,2 REPUESTOS Porcentaje de
Rentabilidad
Rentabilidad
Monto de
Se carga desde
MontoRentabilidadMeta Rentabilidad Number 14,2
Fijado en Meta Excel
Total Neto de
TotalNeto Monto Neto Total Number 14,2 REPUESTOS
Ventas
Monto Neto Total Se carga desde
TotalNetoMeta Number 14,2
Fijado en Meta Excel
 Dim-Fecha
ADM_PAIS <pi> Number (4) Date
ADM_PROVINCIA CodFecha Fecha FechaCompleta Dia <M>
Variable characters (25) Variable characters (2) Variable
Mes Aniocharacters (2) Variable characters (4) Variable characters (10) Variable characters (15) Variable characters (15) Variable characters (20)
PAICODIGO <pi> VariRelationship_ PRVCODIGO
1 <pi> Variabl
PRVNOMBRE PRVESTADO Variabl Charact MesNombre Trimestre Semestre
PAINOMBREVari
DiaFestivo
PAIESTADOCha
Identifier_1 <pi>
Identifier_1 <pi> Identifier_1 <pi>

Relationship_2
REP_LINEA
LIRCODIGO <pi>
LIRDESCRIPCION
ADM_CANTON LIRESTADO
CANCODIGO CANNOMBRE CANESTADO
<pi> Variabl
Variabl Charac Identifier_1 <pi>
Relationship_48

Identifier_1 <pi>
Relationship_22
Hecho-ComparaMetas
Relationship_36
MesesStockNumber (2,2)
MesesStockMeta TasaServicio Number (2,2) REP_ITEM
TasaServicioMeta Number (2,2)
IT ECODIGO <pi> Variable cha
ADM_AGENCIA TasaServicioInmediata Number (2,2) Dim-ICC
IT EDESCRIPCION Variable cha
Number (2,2) <pi> Variable characters (2) <M> Variable characters (2)
AGECODIGO AGENOMBRE<pi> Variable characters
AGEESTADO (2) Variable characters (20) Characters
AGETIPO AGEVIRTUAL <M> (1) CodICC IT ECODIGOSUSTITUTO Variable cha
Variable characters (1) Variable characters (1) Relationship_49 TasaServicioInmediataMeta Number (2,2) 5 0IT EFOB Variable characters (1)
R hip_ICC
elations Number (14,2
MontoRentabilidad MontoRentabilidadMeta TotalNeto
Number (14,2) GrupoICC IT ECLASIFICADORICC Characters (2
TotalNetoMeta Number (14,2) EUNIDADMEDIDA Variable cha
ITEstadoICCVariable characters (1)
Number (14,2)
ITIdentifier_1
EESTADO <pi> Variable cha
Number (14,2)
Identifier_1 <pi> Id entifier_1 <pi>

Relationship_40

REP_ITEM_PROCEDENCI

Figura 30 - Modelo Dimensional 7 - Comparación de Metas

 74

3.5.8 Modelo 8 - Seguimiento de Clientes de las tres líneas de análisis

Este modelo se ha creado para analizar los clientes que compran
vehículos Toyota y utilizan o no las líneas de post-venta.

Fecha

Compras a
Cliente ITSA Agencia
Cuenta Compras

Tipo de
Compra ITSA

Figura 31 - Gráfico de Burbujas de Seguimiento de Clientes

Se utilizarán las dimensiones conformadas Dim-Fecha (Tabla 8), Dim-

Agencia (Tabla 9) y Dim-Cliente (Tabla 10).
 75

Tabla 26

Atributos de Dimensión Tipo de Compra en ITSA

Nombre Dim-TipoCompraITSA
Tipo Dimensional
Descripción Contiene los tipos de compras que afectan a las líneas analizadas
Usado en Seguimiento Clientes
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo de Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato valores Dato
defecto
Código de compra
CodCompraITSA Number 1 PK Llena Tesista
ITSA
Vehiculos,
Nombre de la
NombreCompraITSA Varchar 10 Repuestos, Llena Tesista
compra en ITSA Taller
Clasifica estado de Llenado al
EstadoCompraITSA la compra de ITSA Varchar 1 poblar el hecho
Tabla 27

Atributos de la Tabla de Hechos de Seguimiento de Clientes

Nombre Hecho-SeguimientoClientes
Tipo Hechos
Descripción Contiene los clientes que han realizado compras de Vehículos, Repuestos o han asistido al Taller
Esquema ITSA
TABLA DIMENSIONAL TABLA ORIGEN
REGLAS DE
CONVERSION
COMENTARIOS
Valor
Tipo de Ejemplo Tipo de
Columna Descripción Tam Clave por Esquema Tabla Campo Null Tam
Dato de valores Dato
defecto
CodFecha Código de Fecha Number 4 PK 0001, 0456 Llena Tesista
Llenado
CodAgencia Código de Agencia Number 2 PK 1,5,10 secuencialmente
al poblar
Llenado
CodCliente Código del Cliente Number 8 PK secuencialmente
al poblar
Código de compra
CodCompraITSA ITSA Number 1 PK Llena Tesista
Cuenta las
compras Llenado al
ContadorComprasITSA Number 5
realizadas por el poblar el hecho
cliente en ITSA
 Dim-Fecha
CodFecha <pi> Number (4) <M>
Fecha Date
ADM_PAIS ADM_PROVINCIA
FechaCompleta Variable characters (25)
PRVCODIGO <pi> Variable c PRVNOMBREVariable c Dia Variable characters (2)
PAICODIGO <pi> Vari PAINOMBREVari
Relationship_
PAIESTADOCha 1
PRVESTADOCharacters Mes Variable characters (2)
Anio Variable characters (4)
Identifier_1 <pi> MesNombre Variable characters (10)
Identifier_1 <pi>
Trimestre Variable characters (15)
Semestre Variable characters (15)
Relationship_2 DiaFestivo Variable characters (20)
Identifier_1 <pi>

ADM_CANTON
Relationship_51 ADM_CLIENTE
CANCODIGO <pi> Variabl CANNOMBREVariabl
CANESTADOCharac CLINUMDOCIDENTIDAD <pi> Variable characters (13) <M>
Variable characters (1) Variable characters
Hecho-SeguimientoClientes CLITIPODOCUMENTO
(40) Variable characters
CLIAPELLIDO
(60) CLIEMAIL
Variable characters (1) Variable characters (40) Variable characters (2) Variable characters (1) Variable
Identifier_1 <pi> CLISEXO CLINOMBRE
ContadorComprasITSA Number (3) Relationship_5 CLIAGECODIGO
CLIESTADO
CLITARJETACREDITO
Relationship_36
4

ADM_AGENCIA
AGECODIGO <pi> Variable characters (2) <M> AGENOMBREVariable characters (20) AGEESTADOCharacters (1)
AGETIPOVariable characters (1) AGEVIRTUALVariable characters (1)
Relationship_52 Relationship_34 ADM_DIRECCION
DIRNUMSECUENCIAL <pi> Numbe DIRDIRECCIONVariab
DIRESTADOVariab
Identifier_1 <pi> Relationship_7
Relationship_53 Identifier_1 <pi>

Relationship_37
Dim-TipoCompraITSA
CodCompraITSA <pi> Number (1) <M> ADM_PARROQUIA
NombreCompraITSA Variable characters (10)
PARCODIGO <pi> Varia PARNOMBREVaria
EstadoCompraITSA Variable characters (1)
PARESTADOChar
Identifier_1 <pi> a
Identifier_1 <pi>

Figura 32 - Modelo Dimensional 8 - Seguimiento de Clientes

 78

Una vez que se han detallado los modelos dimensionales que formarán
parte del Data Mart, se realiza una segunda matriz de procesos /
dimensiones (Bus Matrix); esta vez, detallando las dimensiones y tablas de
hechos que forman parte de cada proceso de negocio que resultó del
análisis de requerimientos.

Además se realiza el modelo dimensional completo del Data Mart, en

donde se pueden observar todas las tablas de hechos y las dimensiones
incluyendo las conformadas.
 79

Tabla 28

Matriz de Procesos / Dimensiones Detallada del Data Mart para el Departamento de Repuestos

Dimensiones

Dim-Fecha

Dim-Agencia

Dim-Cliente

Dim-TipoCompraITSA
Dim-Asesor

Dim-TipoVenta

Dim-Item

Dim-ICC

Dim-Proveedor

Dim-EstadoProforma

Dim-LineaDeVenta

Dim-TipoTransaccion
Tablas de Hechos Granularidad

Hecho-VentaNeta Gruesa X X X X X X

Hecho-DetalleDeVentas Fina X X X X X

Hecho-SeguimientoClientes Gruesa X X X X

Hecho-Compras Fina X X X X X X

Hecho-ReservasDetalle Fina X X X X X X

Hecho-Inventario Gruesa X X X

Hecho-DetalleDeInventario Fina X X X X X X X

Hecho-ComparaMetas Gruesa X X X
Figura 33 - Modelo Lógico Dimensional del Data Mart para el Departamento de Repuestos
 81

3.6 DISEÑO FISICO

A continuación se muestra el diagrama físico del Data Mart del
Departamento de Repuestos, mismo que se crea a partir de las tablas de
dimensiones y hechos detalladas en el paso anterior.
Este diseño es independiente de la herramienta que se utilice para su
implementación.
 82

Figura 34 - Diagrama Físico del Data Mart para el Departamento de Repuestos de ITSA
 83

3.7 DISEÑO E IMPLEMENTACION DEL SUBSISTEMA ETL

En este punto es importante comentar que el análisis de los datos
transaccionales para definir las transformaciones que se ajusten a las reglas
de conversión que se aplicaron para la limpieza de los mismos (reglas
documentadas en las tablas de atributos de Dimensiones y Hechos en el
apartado 3.5 Modelado Dimensional) se lo realizó con la herramienta de
Preprocesamiento de Datos de Weka.

Figura 35 - Ejemplo del uso de Preprocesamiento de Datos en Weka

Luego de este análisis; se empezó a implementar el subsistema ETL,

para lo cual se ha utilizado Pentaho Data Integration, específicamente en
este punto se utiliza Spoon que es el diseñador gráfico de transformaciones
y trabajos del sistema de ETLs, también conocido como Kettle (Kettle
Extraction, Transformation, Transportation, Load Environment).
 Figura 36 - Ventana de inicio de Spoon Pentaho Data Integration

Dentro de la aplicación se crea una conexión al repositorio donde se

guardarán las transformaciones y datos generados.

Figura 37 - Conexión al Repositorio de Transformaciones y Datos en Spoon

 A continuación se detallan las conexiones de las fuentes de información y
del repositorio que se crea:

ConexionFuentes
ConexionRepositorio

ConexionNucleo

OLTP DATA MART

ESQUEMAS
REPUESTOS
TALLERES
VEHICULOS
CIENTES
ESQUEMAS
DMITSA

Figura 38 - Conexiones de Fuentes y Repositorio

Una vez que se verifica el correcto estado de las conexiones, se van

desarrollando las tareas necesarias para extraer, transformar y cargar
finalmente datos de calidad.
A continuación se detallaran las dimensiones necesarias para poblar el
Hecho VentaNeta, la carga de las demás dimensiones involucradas en el
proyecto de Tesis se realizaron de la misma manera; utilizando la
herramienta Spoon de Pentaho, sus estructuras y transformaciones se
encuentran en el Anexo 4.

3.7.1 Dim_Fecha
La dimensión fecha se pobló desde un archivo CSV que contiene diez
años de tiempo (2009 al 2019).
 Figura 39 - Estructura de la Dimensión Fecha

Figura 40 - Transformación de Dimensión Dim_Fecha

3.7.2 Dim_Agencia
Esta dimensión se pobló desde la tabla transaccional ADM_AGENCIA y
sus relaciones (ADM_PAIS, ADM_PROVICIA, ADM_CANTON); así también
se eliminaron los datos nulos en el campo AGEVIRTUAL.

Figura 41 - Estructura de la Dimensión Agencia

 Figura 42 - Transformación de Dimensión Dim_Agencia

3.7.3 Dim_Cliente
La dimensión Cliente es una de las dimensiones con más
transformaciones y limpieza de datos dentro de este Data Mart, ya que
existen muchos campos que no han sido ingresados correctamente por el
personal de los Departamentos de Ventas de Importadora Tomebamba.
Los datos se tomaron desde la tabla ADM_CLIENTE y sus relaciones
(ADM_DIRECCION, ADM_TELEFONO, ADM_AGENCIA); se eliminaron los
datos vacíos y se depuró información de varios campos a excepción de
CLINUMDOCIDENTIDAD y CLITIPODOCUMENTO.
Además se reemplazaron las abreviaturas y nomenclaturas de los
campos CLITIPODOCUMENTO, CLIESTADO, CLITIPOPERSONA,
CLIESTADOCIVIL y CLITIPOCLIENTE.
Se incluyó también el campo SegmentoCliente, el mismo que se generó
en base a una clasificación que proporcionó el CSO en un archivo Excel.
Finalmente se buscó el género de los clientes que no tenían grabado en
la base de datos transaccional, utilizando un archivo plano con nombres
femeninos.
Figura 43 - Estructura de la Dimensión Cliente
 Figura 44 - Transformación de Dimensión Dim_Cliente

3.7.4 Dim_Asesor
Para la dimensión de Asesores, se tomaron los datos de la tabla
transaccional REP_VENDEDOR y sus relaciones (ADM_CLIENTE,
ADM_AGENCIA), así también se reemplazó la nomenclatura utilizada.

Figura 45 - Estructura de la Dimensión Asesor

 Figura 46 - Transformación de Dimensión Dim_Asesor

3.7.5 Dim_TipoVenta
Esta dimensión se pobló directamente desde la herramienta con los datos
necesarios (Contado y Crédito)

Figura 47 - Estructura de la Dimensión TipoVenta

Figura 48 - Transformación de Dimensión Dim_TipoVenta

3.7.6 Hecho_VentaNeta
Una vez que se ha realizado la limpieza y carga de datos de calidad en
las dimensiones necesarias para la tabla de Hechos VentaNeta, se procede
a poblar la misma.
La llave primaria de este Hecho es el conjunto de las llaves foráneas de
sus dimensiones (Dim_Fecha, Dim_Agencia, Dim_Cliente, Dim_Asesor,
Dim_TipoVenta) y contiene la suma de ventas (REP_VENTA_CABE) y
devoluciones (REP_DEVO_VENT_CABE) netas de los años de análisis.

Figura 49 - Estructura de la Tabla de Hechos Venta_Neta

Figura 50 - Transformación de Hecho_VentaNeta

 Al finalizar el proceso de carga de datos en las tablas de Hechos, se
utiliza nuevamente la herramienta WEKA para verificar que no existan datos
nulos.

Figura 51 - Ejemplo Verificación de Datos Vacíos - WEKA

3.8 ESPECIFICACION Y DESARROLLO DE APLICACIONES BI

Dentro de los objetivos de este proyecto de Tesis está el Desarrollar y

Publicar la solución BI para el Departamento de Repuestos de Importadora
Tomebamba, a continuación se comentan las herramientas y el proceso para
cumplir el mismo.

3.8.1 Construcción de Cubos OLAP

Para la construcción de cubos OLAP se utilizó la herramienta Schema
Workbench, en la cual se detallan los hechos y dimensiones que
responderán a los requerimientos del Departamento de Repuestos de
Importadora Tomebamba.

Figura 52 - Entorno de Trabajo de Schema Workbench

En esta herramienta se crean los cubos tal como se analizaron con la

Metodología Kimball, incluyendo su granularidad especificada.
3.8.1.1 VentasNetas
El cubo de Ventas Netas se crea en base al Modelo 1, para responder los
siguientes requerimientos:
 Obtener ventas netas
 Mostrar ventas a crédito

Figura 53 - Cubo Ventas Netas

Una vez creado el cubo, y el mismo se encuentra sin errores, se procede

a publicarlo en el servidor de Pentaho para realizar el análisis de
información.

Figura 54 - Publicación del Cubo OLAP

 Tal como se procedió en el punto anterior, los demás cubos se
encuentran detallados en el Anexo 5.

3.8.2 Aplicación para Usuarios Finales

Luego de la publicación de los cubos, se procede a comprobar que los
mismos sean capaces de responder a los requerimientos del Departamento
de Repuestos, mediante su utilización en la aplicación para usuarios finales,
Pentaho User Console.
Dentro de esta interfaz se ha instalado el componente Saiku que permite
realizar reportes y análisis de datos ad hoc con simples pasos Drag&Drop.
A continuación se muestran las respuestas obtenidas con los cubos del
Modelo 1.

3.8.2.1 Reporte y Análisis de Ventas Netas

Figura 55 - Reporte de Ventas Netas por Agencia con valores

Figura 56 - Reporte Gráfico de Ventas Netas por Agencia

 Figura 57 - Reporte de Ventas Netas por Asesor

Figura 58 - Reporte de los 10 Mejores Clientes

3.8.2.2 Reporte y Análisis de Ventas a Crédito y Contado

Figura 59 - Reporte de Ventas Contado y Crédito con valores

 Figura 60 - Reporte Gráfico de Ventas Contado y Crédito

Además se muestran algunos reportes y cuadros de mando generados

para la Gerencia de Repuestos

3.8.2.3 KPI´s

Figura 61 – KPIs Departamento de Sistemas

 Este cuadro de mando es uno de los más importantes para la Gerencia
de Repuestos, ya que contiene en una sola pantalla todos los indicadores de
su área de negocio. Estos indicadores se calcularon y obtuvieron desde los
archivos Excel de metas y las bases de datos transaccionales.
 Meses de Stock: Monto de Inventario / Promedio de Costo de
Venta de los Últimos 6 meses
 Rentabilidad: TotalNeto * Porcentaje de Rentabilidad
 Venta Neta: Subtotal - Descuento
 Ventas por Grupo ICC (monto y cantidad): Este indicador se
consideró necesario en este cuadro de mando, ya que dentro del
control de inventario se requiere mantener mayor cantidad de items
con ICC A al F tanto en bodegas como en ventas por mostrador.

3.9 IMPLEMENTACIÓN
Una vez implementado el portal para el análisis de la información, se
procede con la capacitación a los usuarios que van a formar parte del
proyecto, en este caso el CSO y COOs del Departamento de Repuestos.
Durante este tiempo, se entrega todo el soporte técnico requerido ya que
de esto depende el éxito de la solución BI.
El uso de este componente y todas las plantillas generadas para el
aplicativo, se evaluaron con el usuario final, quedando en total conformidad
según la siguiente Acta:
 Figura 62 – Acta de finalización de Pruebas

3.10 MANTENIMIENTO Y CRECIMIENTO

En este último paso de la metodología se han tomado en cuenta tanto la
actualización de información en el Data mart como el control de calidad de
los datos, procesos y reportes en producción.
Al empezar a definir procesos de actualización, se debe considerar que
tipo de cambio se va a utilizar en cada dimensión, tal como se comentó en el
apartado 2.4.4.1.1. Pentaho cuenta con dos componentes capaces de
gestionar la actualización y son los siguientes:
  Dimension Lookup/Update, este componente se utiliza para las
dimensiones de cambio lento. Sirve tanto para actualizar como para
insertar y buscar información dentro de la dimensión. Para su uso, se
configura la llave técnica (la llave primaria de la dimensión) y se definen
los campos que se actualizarán al encontrar alguna coincidencia en las
llaves que se definan (las llaves transaccionales). En este tipo de
actualización, la llave técnica no cambia.
 Combination Lookup/Update, este componente se utiliza para
dimensiones de cambio frecuente. Sirve para actualizar la información
dentro de la dimensión. Para su uso, se configura el conjunto de llaves
que forman la llave primaria, si encuentra la llave primaria, no realiza
ninguna acción, caso contrario, almacena el registro nuevo en la base
de datos. Es decir, se realiza una comparación total de los campos de
los registros almacenados con el nuevo registro, más no se realiza una
comparación con la clave primaria como en el caso anterior.
A continuación se observa el ejemplo de un job que realiza la
actualización de las Ventas Netas, la misma se realiza cada sábado a las
14:00 y su proceso consiste en verificar que el Servidor se encuentre activo
y actualizar tanto la Dimensión Clientes como la tabla de Hechos VentaNeta.

Figura 63 - Actualización de la tabla Hecho_VentaNeta

Dentro del proceso de control de calidad, se encuentran reuniones

quincenales para entrevistar al personal que ha utilizado el portal, en donde
se recopilan dudas, errores y nuevos requerimientos para poder darle el
seguimiento correcto con el fin de lograr que el proyecto se mantenga y
crezca.
A continuación se muestra el procedimiento estándar, según formato de
la empresa, que se definió para esta tarea.
 100

Administrador Gerente de
País Ecuador Jefe de Sistemas
del Proyecto Repuestos

Standar Operation Daniela

Concesionario Importadora Tomebamba S.A. Remigio López Eduardo Ávila
Procedure (SOP) Molina

Proceso Control de Calidad BI Año: 2014 Mes: Julio Día: 11

Pasos Dónde Qué Quién Operaciones Observaciones

Gerente de 1. Recopilar quincenalmente las dudas y

Repuestos / requerimientos que existan en el Departamento de
Oficina Revisión de
Administrador Repuestos, en consenso con todo el personal
1 Gerente de Datos y
del Proyecto y involucrado.
Repuestos Procesos
Personal de 2. Verificar lo anotado con todos los presentes.
Repuestos 3. Agendar próxima revisión de avances.

1. Analizar posibles cambios y mejoras con respecto a

Oficina Analizar dudas
Administrador lo registrado en la reunión con el personal de
2 Administrador y
del Proyecto Repuestos.
del Proyecto requerimientos
2. Realizar un cronograma de entrega de cambios.

Administrador 1. Coordinar con el Jefe de Sistemas, siempre que los

Coordinar
Oficina Jefe de del Proyecto / cambios requieran información nueva del sistema
3 cambios de
Sistemas Jefe de transaccional.
ser
Sistemas
necesario
Figura 64 - Procedimiento Estándar de Control de Calidad del Aplicativo BI
 101

3.11 ADMINISTRACIÓN DEL PROYECTO DW/BI

La administración de este proyecto se encuentra a cargo de la Ing.
Daniela Molina, quien además de revisar su correcto funcionamiento, debe
estar en constante comunicación con el Departamento de Sistemas, quienes
comunicarán sobre cambios de estructuras o diseño en los sistemas
transaccionales del Departamento de Repuestos y en los módulos de Ventas
y Servicio que se encuentran involucrados en esta solución BI.
Con la designación de la administración del proyecto, el mismo se
encuentra finalizado según la metodología Kimball.
A continuación se detalla un punto más que es parte de la solución
presentada en este proyecto de tesis, la minería de datos para el área de
Ventas.

3.12 DATA MINING PARA EL AREA DE VENTAS

Una vez que se han obtenido datos de calidad y se mantiene información
histórica, se puede ir un paso más adelante, explotando datos válidos
mediante análisis estadísticos, con el fin de confirmar sospechas, encontrar
nichos nuevos de negocio o combos de productos para mejorar las ventas.
Esto se logra mediante la minería de datos y sus algoritmos.
La minería de datos se establece como una de las etapas de un proceso
más genérico llamado Knowledge Discovery in Databases (KDD), el cual, es
el proceso de análisis de bases de datos que busca encontrar relaciones
inesperadas que son de interés o valor para el poseedor de dicha base de
datos (Francisco Barrientos, 2013). En términos simples es encontrar
relaciones no triviales en los datos (la materia prima) mediante las ventajas
de varias áreas como la Estadística, la Inteligencia Artificial, la Computación
Gráfica, las Bases de Datos y el Procesamiento Masivo.
Existen varios algoritmos de Datamining que, en base a parámetros y
datos de entrada, buscan patrones de comportamiento. Entre los más
utilizados están los de predicción, clasificación, clustering y asociación.
 Para esta tesis se va a utilizar el programa Weka y su algoritmo de
Predicción; con el cual se responderá el requerimiento de proyección de
ventas.
Todas las técnicas de Weka se basan en la suposición de que los datos
están disponibles como un único archivo plano, donde se encuentran un
número fijo de atributos (numéricos o nominales). Para este análisis, se
utiliza la opción Explorer.

Preprocesamiento, selección, aprendizaje y visualización

Realización de experimentos, pruebas estadísticas, algoritmos de aprendizaje automático y diseñ

Interfaz de línea de comandos WEKA

Figura 65 - Interfaz Weka

3.12.1 Algoritmo de Predicción

Estos algoritmos sirven para proveer un resultado estimado de la verdad
a corto plazo. Es importante aclarar que la veracidad en las predicciones
depende del conocimiento y habilidad del usuario, además del conjunto de
parámetros utilizados; por esto, se deben evaluar distintos conjuntos de
valores en base a los resultados de las simulaciones e ir mejorando con
simulaciones posteriores.
Se recomienda que se consideren datos en un período de tiempo
óptimos para predecir qué pasará en un tiempo posterior.
Para responder el requerimiento de la proyección de ventas en base a
los años anteriores; se utiliza la opción Forecast, dentro de la cual, se
probaron varios algoritmos, siendo el "LinearRegression" la mejor opción.
 Figura 66 - Proyección de Ventas con Weka

Los datos para el análisis se obtienen directamente del Data mart creado,
del cual se extraen dos variables para este análisis:
 anio: es la variable independiente que se proyecta en el tiempo para la
predicción requerida.
 montoventa: es la variable dependiente sobre la cual se va a predecir el
monto de venta del próximo año.

3.12.1.1 Algoritmo de Estimación o Regresión

Este es el modelo de predicción más popular, ayuda a calcular una
relación lineal entre una variable independiente y otra dependiente, tomando
la forma que mejor represente una serie de datos.
 Figura 67 - Regresión Lineal

Para el análisis de una regresión se considera una variable dependiente

(Y) y una variable independiente (X). La fórmula de este modelo es:
𝑌=𝛼+𝛽∗𝑋+𝜖
En donde 𝛼 es el origen o constante y 𝛽 es la pendiente del modelo.
Cada punto de datos del diagrama tiene un error (𝜖) asociado con su
distancia con respecto a la línea de regresión, por esto, se busca ajustar tanto
𝛼 como 𝛽 al ángulo y la ubicación de la recta de regresión, hasta que la suma
de los errores asociados a todos los puntos alcance su valor mínimo.
 CAPITULO IV

CONCLUSIONES Y RECOMENDACIONES

El entendimiento y administración correctos de uno de los activos más

importantes hoy en día, la información, son de vital importancia para la
correcta toma de decisiones y acciones en el escenario siempre cambiante
en el que se desenvuelven los negocios.
A continuación se detallan las conclusiones de los resultados obtenidos y
las recomendaciones que se deberían considerar para lograr el
mantenimiento, crecimiento y explotación de esta herramienta, consiguiendo
así una ventaja competitiva cada vez más poderosa.

4.1 CONCLUSIONES
 La integración de las fuentes de información que intervinieron en este
aplicativo; archivos planos, archivos Excel y bases de datos
transaccionales, se realizó satisfactoriamente con la ayuda de las
herramientas de Pentaho.
 Durante el análisis de los datos almacenados en la base de datos
transaccional se encontraron varias inconsistencias que siguen
presentes desde el cambio del sistema web; además la información
que se tiene es extensa y un poco desordenada, razón por la cual no
se podían obtener los análisis que requiere la Gerencia. La herramienta
Spoon ha sido de gran utilidad para lograr una información depurada,
capaz de entregar al usuario final un análisis completo y veraz con
datos de gran calidad.
 El Data mart para el Departamento de Repuestos de Importadora
Tomebamba se diseñó en base a los requerimientos de sus dirigentes,
aplicando la metodología de Kimball, una metodología muy prolija en
su procedimiento. Es importante acotar que existen pasos que en la
práctica se pueden excluir del análisis en pro de agilitar el desarrollo y
publicación de la aplicación, siempre dependiendo del proyecto y su
alcance.
  Este aplicativo se ha desarrollado en base a las variables para la toma
de decisiones que requiere el Departamento de Repuestos, las mismas
que en esta fase inicial se han centrado en el control de inventario y
monto de ventas. Al unificar toda la información y colocarla en este
aplicativo de fácil uso, se dotó al Gerente de las herramientas
necesarias para decidir qué repuestos mantener en stock, qué hacer
con su inventario al verificar en cada momento su costo según el ICC,
en qué agencia gestionar ventas para cumplir los presupuestos, cuáles
son las agencias que realizan compras innecesarias que afectarán a
los meses de stock a mes caído, etc.
 Al estar en la fase inicial de este proyecto, se realizó el único
requerimiento de datamining que se solicitó. La proyección de ventas
basado en un algoritmo probado como lo es la Regresión Lineal, es
mucho más apegado a la realidad que como se realizaba
anteriormente, con cálculos en hojas de Excel que dependían mucho
de la experiencia de la Gerencia de turno.
 El área de ventas de Importadora Tomebamba es parte fundamental
del proceso de ventas de Repuestos ya que, en ésta área es donde se
originan los clientes potenciales para las líneas de post venta. El
obtener un escenario completo de los clientes y movimientos de las
áreas involucradas en la venta de repuestos ha sido de mucha ayuda
para el Gerente de Repuestos, ya que mantiene información
actualizada de los clientes a los cuales gestionar ventas dirigidas (por
modelo del vehículo adquirido).
 La publicación del aplicativo BI a constituido una herramienta muy
importante dentro del Departamento de Repuestos, ya que provee en el
momento exacto, toda la información de calidad y relevante para el
área de negocio. Además, ha mejorado la eficiencia y eficacia de todo
el personal involucrado en el análisis de la información, pues el tiempo
se invierte en analizar datos más no en crearlos manualmente.

4.2 RECOMENDACIONES
  Las operaciones que se realizan en el aplicativo BI son de consulta y
no de modificación de datos, es por esto que se recomienda que el
esquema que contiene el datafile, se aloje en un disco independiente
así también que se configure un bloque de datos de tamaño mayor.
 La mayor parte del tiempo de este proyecto se utilizó en el análisis de
las bases de datos, es muy importante que dentro del Departamento de
Sistemas se genere toda la documentación sobre las bases de datos
transaccionales del negocio.
 Es importante que una persona que conozca de las bases de datos y el
flujo de procesos del área de negocio, participe activamente del
proyecto.
 En cuanto a la calidad de los datos, se puede puntualizar lo siguiente:
 Mayor validación en el ingreso de vehículos en cuanto al número
de chasis (que sean únicos).
 Llevar a cabo un proyecto de calidad de datos para los clientes e
items, ya que esta es información vital para poder realizar minería
de datos efectiva.
 Solicitar los accesos del web service de TDE para que la carga de
información de compras sea directamente desde la nube y evitar el
depender de la descarga manual del archivo.
 La coordinación tanto con el Departamento de Sistemas como con el
Departamento de Mercadeo o Negocios, es vital en este tipo de
proyectos, ya que depende directamente de la estructura de las bases
transaccionales, así como de la visión del negocio para lograr una
herramienta totalmente adaptada a las necesidades.
 El éxito del proyecto siempre dependerá de la calidad de la
información, el seguimiento y la importancia que le dé el personal que
lo utiliza.

Una vez concluido el desarrollo y publicación del Data mart, se puede

decir que éste se encuentra en la capacidad de ayudar a la toma de
decisiones gerenciales, ya que contiene información de calidad y relevante
para el Departamento de Repuestos de Importadora Tomebamba S.A.;
además es importante acotar que este repositorio sirve de base para la
aplicación de Data
Mining y generación de consultas para aprovechar la gran cantidad de datos
disponibles.
 BIBLIOGRAFÍA

Austin, B. (2 de Mayo de 2010). Benny Austin. Obtenido de

http://bennyaustin.wordpress.com/2010/05/02/kimball-and-inmon-dw-
models/

BI Consulting. (2013). BI Consulting. Obtenido de

http://www.biconsulting.com.mx/index.php?option=com_content&view
=article&id=51&Itemid=58

Celma, M. (2006). Parte II: Almacenes de Datos. Tutorial DW. Valencia,

España.

Data Prix. (12 de Mayo de 2009). Data Prix. Obtenido de

http://www.dataprix.com/data-warehousing-y-metodologia-hefesto/1-
business-intelligence/13-proceso-bi

Dómina, M. C. (Diciembre de 2008). Tesis de Licenciatura en Ciencias de la

Computación. Data Warehousing. Relevamiento y aplicación de
técnicas de modelado dimensional. Bahía Blanca, Buenos Aires,
Argentina.

Francisco Barrientos, S. A. (2013). Aplicación de Minería de Datos para

Predecir Fuga de Clientes en la Industria de las Telecomunicaciones.
Revista Ingeniería de Sistemas, 76.

Geidy Acosta Méndez, D. J. (2013). MERCADO DE DATOS PARA UNA

DIRECCIÓN DE SALUD EN CUBA. Ediciones pensando el futuro, 3.

Gutiérrez, P. M. (2006). PROYECTO FIN DE CARRERA INGENIERÍA

TÉCNICA EN INFORMÁTICA DE GESTIÓN. DATA WAREHOUSE:
MARCO DE CALIDAD. Madrid, España: UNIVERSIDAD CARLOS III.

Hood, R. (19 de Octubre de 2012). Inteligencia de Negocios. Obtenido de

http://business-intelligencex12.blogspot.com/2012/10/diferencias-
entre-un-sistema-oltp-y-olap.html

Proal, C. (11 de 2007). Carlos Proal. Obtenido de Carlos Proal:

http://www.carlosproal.com/dw/dw05.html

Ralph Kimball, M. R. (2002). The Data Warehouse Toolkit, Second Edition.

The Complete Guide to Dimensional Modeling. Canada: John Wiley
and Sons, Inc.

Rangel, P. W. (2010). Inteligencia de Negocio. Modelado Multidimensional.

Sistemas de Información. Venezuela.
Rivadera, G. R. (2010). Universidad Católica de Salta. Obtenido de
www.ucasal.edu.ar

Roland Bouman, J. v. (2009). Pentaho® Solutions: Business Intelligence and

DataWarehousing with Pentaho and MySQL®. Indianapolis: Wiley
Publishing, Inc.

Sinnexus. (2007 - 2012). Sinnexus. Obtenido de

http://www.sinnexus.com/business_intelligence/

Todo BI. (21 de Mayo de 2011). Todo BI Business Intelligence. Obtenido de

http://todobi.blogspot.com/2006/05/pentaho-la-solucion-open-
source.html

Uzcanga, J. M. (2 de Diciembre de 2003). UDLAP BIBLIOTECAS. Obtenido

de
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rosette_u_jm/port
ada.html

WROV. (27 de Abril de 2013). Firebird SQL. Obtenido de

http://firebird21.wordpress.com/2013/04/27/aplicaciones-oltp-y-
aplicaciones-olap/
 GLOSARIO Y ACRÓNIMOS

Literalmente "para esto". Generalmente se refiere a

una solución específicamente elaborada para un
Ad-hoc
problema o fin preciso y, por tanto, no generalizable
ni utilizable para otros propósitos.
Backups Copias de Seguridad.
Business Intelligence - Inteligencia de Negocios,
conversión de datos en información e información
BI
en conocimiento. Permite optimizar el proceso de
toma de decisiones en los negocios.
Chief Operations Office (Jefe de Operaciones). Es
un ejecutivo corporativo responsable de gestionar el
día a día las actividades de la empresa y la gestión
COOs
de operaciones (OM). Generalmente reporta al CEO
(Chief Executive Officer - Director Ejecutivo) o al
CSO.
Chief Strategy Officer. Es el ejecutivo líder de una
unidad de negocios y que decide sobre las
CSO
cuestiones estratégicas en juego, para lograr un
objetivo.
Es una interfaz donde el usuario puede visualizar
Dashboards una gran cantidad de resúmenes y mediciones
detallados.
Un Data mart es una versión especial de almacén
Data mart de datos. Son subconjuntos de datos con el
(DM) propósito de ayudar a que un área específica dentro
del negocio pueda tomar mejores decisiones.
El datamining (minería de datos), es el conjunto de
técnicas y tecnologías que permiten explorar
grandes bases de datos, de manera automática o
Datamining semiautomática, con el objetivo de encontrar
patrones repetitivos, tendencias o reglas que
expliquen el comportamiento de los datos en un
determinado contexto.
Es una colección de datos orientada a un
Datawarehouse determinado ámbito, integrado, no volátil y variable
(DW) en el tiempo, que ayuda a la toma de decisiones en
la entidad en la que se utiliza.
Data Base Management System - Sistemas de
DBMS Gestión de Bases de Datos (SGBD)
Estructura de Desglose del Trabajo. Es una
herramienta fundamental en la gestión de
proyectos. El propósito de una EDT es organizar y
EDT definir el alcance total aprobado del proyecto según
lo declarado en la documentación vigente. Su forma
jerárquica permite una fácil identificación de los
elementos finales, llamados "Paquetes de Trabajo".
 Enterprise Resource Planning - Planificación de
Recursos Empresariales. Es una solución que
permite a las compañías centralizar e integrar los
procesos y captura de información de todas las
áreas involucradas (finanzas, ventas, compras,
ERP
RRHH, etc.), automatizando las actividades
asociadas a aspectos operativos y productivos, para
que las organizaciones operen de manera óptima
bajo un sistema estandarizado y cuenten con
información confiable.
Extract, Transform and Load - Extraer, Transformar
y Cargar. Es el proceso que permite a las
organizaciones mover datos desde múltiples
ETL
fuentes, reformatearlos y limpiarlos, y cargarlos en
otra base de datos para analizar o apoyar un
proceso de negocio.
Retroalimentación o dar respuesta a un
Feedback
determinado pedido o acontecimiento.
Inventory Control Class - Clase de Control de
Inventario. Es una clasificación que se utiliza en
ICC Repuestos; calculada según una fórmula basada en
la demanda de ventas, para controlar grupos y
números de partes de movimiento similar.
ITSA Importadora Tomebamba S.A.
Key Performance Indicators - Indicadores de
Rendimiento. Son datos estadísticos que permiten
KPI elaborar un juicio sobre el funcionamiento o
comportamiento de un sistema o un conjunto de
datos.
Línea para el Hogar. Es la línea de ITSA donde se
LPH comercializan artículos para el hogar (línea blanca,
audio y video)
On-Line Analytical Processing. Sistema para el
procesamiento de información, orientado a
OLAP requerimientos, maneja datos actuales e históricos,
orientado al análisis y tiene una interacción ad-hoc
con el usuario.
On-Line Transaction Processing. Sistema para el
procesamiento de información, orientado a
OLTP procesos, maneja datos actuales, solamente
transaccionales y tiene una interacción
predeterminada con el usuario.
Es un ORDBMS(Object Relational Database
Management System) sistema de gestión de base
Oracle de datos objeto-relacional multiplataforma de
licencia privativa desarrollado
por Oracle Corporation.
Reporting Reportería
 Sport Utility Vehicle - Vehículo deportivo utilitario,
SUV automóvil todo camino, vehículo todoterreno ligero,
y en algunos casos Jeep
Software. Conjunto de programas y rutinas que
SW permiten a la computadora realizar determinadas
tareas.
Toyota del Ecuador. Es el distribuidor de TOYOTA
TDE para el Ecuador.
Tunning Afinación de bases de datos
Units In Operation - Vehículos que se encuentran
UIO rodando en el parque automotriz del área de
estudio.
ANEXOS
 ANEXO 1

ENTREVISTA

La entrevista para recolectar los requerimientos, se realizó al Gerente de

Repuestos (CSO), con el objetivo de entender los procesos que se realizan a
diario y qué información le puede resultar útil para facilitar la toma de
decisiones y análisis de riesgos en su Departamento.

A continuación se detallan las preguntas realizadas y un resumen de las

respuestas del CSO.

Gerencia de Repuestos

1. ¿Qué tipo de decisiones son las que usted toma frecuentemente?

2. ¿Qué información clave se requiere para hacer o soportar las
decisiones que usted toma?
3. ¿Qué tan difícil es en este momento conseguir esa información?
4. ¿Cuáles son los reportes que más le ayudan a hacer su trabajo?
5. ¿Qué datos en el reporte son importantes?
6. ¿Cómo usa esta información? ¿Si el reporte fuera dinámico, que sería
distinto en él?
7. ¿Qué tan frecuente la necesita: Diario, Semanal, Mensual, Anual?
8. ¿Qué preguntas le han quedado sin responder simplemente porque
usted sabe que no hay respuesta disponible?
9. ¿Existe alguna otra información faltante que crea puede tener un
impacto significativo en ayudarle a alcanzar sus metas?
10. ¿Hace uso de métricas en su área?
11. SI, ¿Qué métricas utiliza y para qué?
12. ¿Estas métricas sirven para medir el alcance de sus objetivos?
13. SI, Que objetivos
14. Cuál es la frecuencia de obtención de las métricas
15. ¿Qué funciones o departamentos dentro de ITSA son importantes
para que el éxito sea alcanzado?
16. ¿Con quienes discute y analiza la información de su área?
17. ¿Cómo le ayuda el sistema actual a desempeñar su trabajo y a la
toma de decisiones?
18. ¿A que le llamaría factor crítico de éxito en su departamento?
19. ¿Qué debe alcanzar este proyecto para ser considerado exitoso?

Respuestas de Gerencia de Repuestos

Decisiones más Gestión de Ventas
frecuentes Abastecimiento de repuestos y accesorios
Seguimiento de Clientes
Control compras del personal del departamento
Información Márgenes de rentabilidad
Clave Montos de Venta
Meses de stock
Compras a TDE
La información necesaria existe pero se debe obtener
manualmente a partir de varios reportes y esto, además de
Disponibilidad ser trabajoso evita tener la información a mano siempre

Reportes de uso Ventas Netas (reporte manual)

más frecuente Por Agencia
Por Fecha
Por Cliente
Por Vendedor
Resumen de ventas por agencia y nacional (resumen del
sistema)
Ventas por ICC (reporte manual)
Monto de inventario por ICC (cálculos manuales)
Compras a TDE (reporte manual)
Por Agencia
Por Vendedor
Por Fecha
Datos importantes Monto de Venta
Monto de stock
Forma de Reportes en varios formatos (modificable e imprimible)
presentación Gráficos
preferida Filtros
Frecuencia de Diaria
uso de Mensual (consolidado)
información Semestral
Información Ventas a crédito
faltante Por Clientes
Por agencia
Ventas por item
 Por monto
Por cantidad
Por Fecha
Por Agencia
Ventas por Asesor
Items reservados y no facturados
Items por ICC
Por Agencia
Por costo
Por precio de venta
Por cantidad
Compras de Repuestos a TDE
Por Proveedor
Por Fecha
Por línea de venta
Por stock actual (si se mantiene o no en stock)
Por transferencias a Agencias
Comparación con metas
Medir el retorno de clientes (vehículos y servicio)

Métricas Monto de Venta

Indicadores Meses de stock
Rentabilidad
Frecuencia de
obtención Mensualmente (Reporte a TDE)
de Métricas
Objetivos Cumplir las metas de ventas
Bajar el monto de inventario
Interacción con Venta de Vehículos
demás Taller de Servicio
dependencias Sistemas
Los reportes actuales brindan información que debe ser
manipulada para realizar los informes gerenciales y así
Desempeño del poder
sistema actual monitorear el desempeño y tomar decisiones, dejándola
en la toma de
decisiones vulnerable a errores humanos
Factor crítico de éxito Cumplir las metas de ventas
Información clara y real para guiar en la toma de
Objetivo del Proyecto decisiones
Brinde información de los vehículos vendidos y sus
propietarios
Brinde información de los vehículos atendidos en el Taller
de Servicio
Proyección de ventas
Basado en montos de 3 años atrás
 ANEXO 2

ESPECIFICACIÓN DE REQUERIMIENTO SEGÚN ESTÁNDAR

IEEE 830

A continuación se detallan los requerimientos del Departamento de

Repuestos de Importadora Tomebamba para el Data Mart.

 Acrónimos
Identificador de cada requisito funcional:
RFXX R = Requisito
F = Funcional
XX = Secuencia de cada requisito
Identificador de cada requisito no funcional:
RNFXX R = Requisito
NF = No Funcional
XX = Secuencia de cada requisito

 Restricciones

Este aplicativo BI será accedido solamente por el CSO y COOs del

Departamento de Repuestos.

 Suposiciones y Dependencias
El aplicativo BI ha sido desarrollado en Pentaho, mismo que se ha
instalado sobre la plataforma Windows. Para su funcionamiento en los
clientes sólo necesita un Navegador Web.
  Requerimientos Funcionales

Identificación del requerimiento

RF01
Nombre del Requerimiento Obtener Ventas Netas

Tema Analítico Gestión de Ventas

Modelo Multidimensional Modelo 1
Proceso Soporte Ventas y Devoluciones de Ventas
Descripción del requerimiento
El sistema reportará las ventas netas según los filtros solicitados en el momento

Las ventas netas se pueden reportar por Fecha, Agencia, Cliente y Asesor
Reporte con valores en forma de tabla
Características Reporte en gráficos
Frecuencia de obtención del reporte: en cualquier momento que se requiera

Más Detalles

Se entregaron los archivos en Excel de la información que generan actualmente.

200,000.00 ene
150,000.00 feb mar abr may
100,000.00 jun
50,000.00
0.00
MILF TALL SRCR

TALL PECF

Prioridad del requerimiento:

Alta
Identificación del
RF02
requerimiento
Nombre del
Obtener Ventas Netas por ICC
Requerimiento
Tema Analítico Gestión de Ventas
Modelo Multidimensional Modelo 2
Proceso Soporte Ventas, Devoluciones de Ventas y Maestro de Items
Descripción del El sistema reportará las ventas netas por ICC según los
requerimiento filtros solicitados en el momento
 Las ventas netas por ICC se pueden reportar
por Fecha y Agencia
 Reporte con valores en forma de tabla
Características
 Reporte en gráficos
 Frecuencia de obtención del reporte:
en cualquier momento que se requiera
Más Detalles

Se entregó el tipo de ICC y grupos que se tienen en el

Departamento de Repuestos para agrupar de esta manera
la información solicitada

Prioridad del
Alta
requerimiento:

Identificación del
RF03
requerimiento
Nombre del
Mostrar Ventas a Crédito
Requerimiento
Tema Analítico Gestión de Ventas
Modelo Multidimensional Modelo 1
Proceso Soporte Ventas y Devoluciones de Ventas
Descripción del El sistema reportará las ventas a crédito según los filtros
requerimiento solicitados en el momento
 Las ventas a crédito se pueden reportar por
Fecha, Agencia y Cliente
Características
 Reporte con valores en forma de tabla
 Reporte en gráficos
  Frecuencia de obtención del reporte:
en cualquier momento que se requiera

Más Detalles
Actualmente se genera manualmente un archivo en Excel
con la información de ventas y devoluciones de ventas

Prioridad del
Media
requerimiento:

Identificación del
RF04
requerimiento
Nombre del
Obtener Ventas por Item
Requerimiento
Tema Analítico Gestión de Ventas
Modelo Multidimensional Modelo 2
Proceso Soporte Ventas y Devoluciones de Ventas
Descripción del El sistema reportará las ventas por item según los filtros
requerimiento solicitados en el momento
 Las ventas por item se pueden reportar por
Fecha y Agencia
 Reporte con valores en forma de tabla
Características
 Reporte en gráficos
 Frecuencia de obtención del reporte:
en cualquier momento que se requiera
Más Detalles
Se acordó con el CSO de Repuestos que se agregará en
la búsqueda, los 5 primeros dígitos de los items buscados
para que la respuesta sea más rápida ya que actualmente
cuentan con un maestro de items de más de 60.000
referencias.

Este reporte se lo creará de cero ya que no cuentan con

uno al momento.

Prioridad del
Media
requerimiento:
Identificación del
RF05
requerimiento
Nombre del
Retorno de Clientes
Requerimiento
Tema Analítico Seguimiento de Clientes
Modelo Multidimensional Modelo 8
Venta de Vehículos, Ordenes de Trabajo de Taller y Venta
Proceso Soporte
de Repuestos
El sistema reportará el número de transacciones realizadas
Descripción del
por los clientes en los departamentos de venta y post venta
requerimiento
TOYOTA
 Las transacciones de clientes se pueden
reportar entre fechas seleccionadas al
Características momento.
 Frecuencia de obtención del reporte:
en cualquier momento que se requiera
Más Detalles
Reporte de número de transacciones realizadas por los
clientes de vehículos, taller y repuestos consolidado de tal
manera que se pueda observar quienes no acuden a los
servicios de post-venta para lograr un seguimiento de los
mismos

Este reporte se lo creará de cero ya que no cuentan con

uno al momento.

Prioridad del
Media
requerimiento:

Identificación del
RF06
requerimiento
Nombre del
Obtener la cantidad y costo de compras a TDE
Requerimiento
Tema Analítico Control de Inventario
Modelo Multidimensional Modelo 3
Proceso Soporte Compras a TDE
Descripción del El sistema reportará las compras de repuestos realizadas a
requerimiento TDE
 Las compras se pueden reportar por Fecha,
Agencia, Asesor, ICC e item
 Reporte con valores en forma de tabla
Características
 Reporte en gráficos
 Frecuencia de obtención del reporte:
en cualquier momento que se requiera
Más Detalles
 Actualmente esta información la suman o filtran en un
archivo Excel con datos de compras que se tienen que
descargar de la web de TDE al momento requerido.

Prioridad del
Alta
requerimiento:

Identificación del
RF07
requerimiento
Nombre del
Obtener el monto de inventario por ICC
Requerimiento
Tema Analítico Control de Inventario
Modelo Multidimensional Modelo 4
Proceso Soporte Saldos, Kardex, Costos
Descripción del El sistema reportará el monto del inventario de repuestos a
requerimiento la fecha solicitada
 El costo de inventario a la fecha se puede
reportar por Agencia y por ICC
 Reporte con valores en forma de tabla
Características
 Reporte en gráficos
 Frecuencia de obtención del reporte:
en cualquier momento que se requiera
Más Detalles
Se entregó esta hoja de Excel para toma en cuenta la
información que se requería sobre este tema. Al momento
ya no lo utilizan porque es muy complicado generarlo
manualmente.
Prioridad del
Media
requerimiento:

Identificación del
RF08
requerimiento
Nombre del
Reportar los Items reservados
Requerimiento
Tema Analítico Control de Inventario
Modelo Multidimensional Modelo 5
Proceso Soporte Proformas
Descripción del El sistema reportará los items reservados y pendientes de
requerimiento facturar
 Los items reservados y pendientes de facturar
se pueden reportar por Fecha, Agencia y por
Asesor
Características  Reporte con valores en forma de tabla
 Reporte en gráficos
 Frecuencia de obtención del reporte: en
cualquier momento que se requiera
Más Detalles

Prioridad del
Alta
requerimiento:
Identificación del
RF09
requerimiento
Nombre del
Reportar los items con existencia y sus movimientos
Requerimiento
Tema Analítico Control de Inventario
Modelo Multidimensional Modelo 6
Proceso Soporte Saldos, Kardex y Maestro de Items
Descripción del
El sistema mostrará items con stock mayor a 0
requerimiento
 Los items con existencia se pueden reportar por
Agencia, ICC
Características  Los items deben estar sumarizados por costo,
precio de venta y cantidad
 Frecuencia de obtención del reporte: cada mes
Más Detalles
Esta información sería de mucha utilidad para controlar
que lo comprado se venda, actualmente no se lo ha podido
generar en el sistema transaccional; y la información que
se obtiene es difícil de leerla y analizarla.

Este reporte se lo creará de cero ya que no cuentan con

uno al momento.

Prioridad del
Media
requerimiento:

Identificación del
RF10
requerimiento
Nombre del
Reportar los Items Comprados y no facturados
Requerimiento
Tema Analítico Control de Inventario
Modelo Multidimensional Modelo 6
Proceso Soporte Maestro de items, Saldos y Kardex
Descripción del El sistema reportará los items que han sido comprados y no
requerimiento facturados en un período no mayor a 3 meses
 Los items comprados y no facturados se
pueden reportar por Fecha, Proveedor,
Características Agencia, Línea de Venta
 Frecuencia de obtención del reporte:
cada quince días
Más Detalles
 Se entregó el archivo en Excel que actualmente utilizan
para que se mantenga toda la información requerida.

Prioridad del
Media
requerimiento:

Identificación del
RF11
requerimiento
Nombre del
Reportar los Meses de Stock
Requerimiento
Tema Analítico Metas
Modelo Multidimensional Modelo 7
Proceso Soporte Inventario, Ventas y Devoluciones de Ventas
Descripción del El sistema reportará los meses de stock a mes caído y lo
requerimiento comparará con la meta previamente establecida
 Los meses de stock se pueden reportar por
Fecha y Agencia
 Se debe realizar una comparación con la meta
Características  Reporte con valores en forma de tabla
 Reporte en gráficos
 Frecuencia de obtención del reporte:
cada cierre de mes
Más Detalles

Este reporte se lo creará de cero ya que no cuentan con

uno al momento.

Prioridad del
Baja
requerimiento:

Identificación del
RF12
requerimiento
Nombre del
Reportar márgenes de Rentabilidad
Requerimiento
Tema Analítico Metas
Modelo Multidimensional Modelo 7
Proceso Soporte Ventas, Devoluciones de Ventas y Costos
El sistema reportará el margen de rentabilidad de venta de
Descripción del
repuestos y lo comparará con la meta previamente
requerimiento
establecida
 El margen de rentabilidad se puede reportar por
Fecha y Agencia
 Se debe realizar una comparación con la meta
Características
 Mostrar varios meses comparativos
 Reporte con valores en forma de tabla
 Reporte en gráficos
  Frecuencia de obtención del reporte:
cada cierre de mes

Más Detalles

Este reporte se lo creará de cero ya que no cuentan con

uno al momento.

Prioridad del
Baja
requerimiento:

Identificación del
RF13
requerimiento
Nombre del
Comparar Ventas Netas con Presupuestos
Requerimiento
Tema Analítico Metas
Modelo Multidimensional Modelo 7
Proceso Soporte Ventas, Devoluciones de Ventas y Presupuestos
Descripción del El sistema reportará la venta neta de repuestos y lo
requerimiento comparará con la meta previamente establecida
 El margen de rentabilidad se puede reportar por
Fecha y Agencia
 Se debe realizar una comparación con la meta
Características  Reporte con valores en forma de tabla
 Reporte en gráficos
 Frecuencia de obtención del reporte:
cada cierre de mes
Más Detalles

Este reporte se lo creará de cero ya que no cuentan con

uno al momento.

Prioridad del
Baja
requerimiento:

Identificación del
RF14
requerimiento
Nombre del
Proyección de ventas
Requerimiento
Tema Analítico Proyecciones
Modelo Multidimensional Datamining
Proceso Soporte Ventas de Repuestos
Descripción del El sistema realizará proyecciones de ventas basadas en:
requerimiento  Ventas de repuestos de los últimos 5 años
  La proyección de ventas se calculará por
Agencia y Nacional
 Reporte con valores en forma de tabla
Características
 Reporte en gráficos
 Frecuencia de obtención del reporte: cada seis
meses
Más Detalles

Este reporte se lo creará de cero ya que no cuentan con

uno al momento.

Prioridad del
Baja
requerimiento:

 Requerimientos No Funcionales

Identificación del
RNF01
requerimiento:
Nombre del
Interfaz del aplicativo
Requerimiento:
Descripción del El aplicativo debe tener una interfaz de uso intuitiva y
requerimiento: sencilla.
El aplicativo presentará una interfaz de usuario sencilla
Características:
para que sea de fácil manejo a los usuarios del sistema.
Prioridad del
Alta
requerimiento:
 ANEXO 3

CARACTERÍSTICAS E INSTALACIÓN DE PENTAHO

Algunas de las características de Pentaho Data Integration (PDI) o Kettle

son:
 Plataforma 100% J2EE, asegurando la escalabilidad, integración y
portabilidad.
 Es una herramienta gráfica y Open Source.
 Servidor: puede correr en servidores compatibles con J2EE como
JBOSS AS, WebSphere, Tomcat, WebLogic y Oracle AS.

 Base de datos: vía JDBC, IBM DB2, Microsft SQL Server, MySQL,
Oracle, PostgreSQL, NCR Teradata, Firebird.

 Sistema operativo: no hay dependencia, lenguaje interpretado.

En cuanto a la instalación de las herramientas de Pentaho Community
Edition, es importante aclarar que, al momento, no existe un ejecutable; en
su lugar, se descargan las carpetas requeridas, se ubican en un directorio
común para Pentaho y se ejecutan con su respectivo archivo .bat de inicio.
Las herramientas descargadas para esta tesis son:
 Pentaho BI server (biserver-ce-4.5.0-stable.tar)
 Pentaho Data Integration (Kettle - Spoon 4.3.0)
 Ctools
 Saiku plugin 2.3
 Pentaho Report Designer
 Pentaho Aggregation Designer
 Schema Workbench (interfaz cubos OLAP)

Además de los paquetes de Pentaho, se utilizó Weka para minería de

datos, esta aplicación si cuenta con un ejecutable. Para el correcto
funcionamiento de las herramientas mencionadas anteriormente, es
necesario seguir las siguientes configuraciones:

 Definir la variable de entorno para JAVA

  Definir la variable de entorno para WEKA

Figura 68 - Variables de Entorno JAVA y Weka

 Grabar los controladores (jdbc) para la conexión con la base de datos.

En este caso se descargaron de Oracle y se ubican en las carpetas:
o biserver-ce\tomcat\lib
o data-integration\libext\JDBC
o administration-console/jdbc
o Pentaho Report Designer.app\lib\jdbc
o aggregation-designer\lib
Una vez que se han instalado los componentes a utilizar, se describen
algunas pantallas de su uso.
 BI Server, Ctools, Saiku. Usuario: itsa_dm, Clave: daniela_itsa

Figura 69 - Interfaz Pentaho Server - Pentaho User Console

 Figura 70 - Interfaz Pentaho Server – Saiku

 Spoon: Usuario: admin, Clave: admin

Figura 71 - Interfaz Pentaho - Spoon

 Report Designer

Figura 72 - Interfaz Pentaho - Report Designer

 Schema Workbench

Figura 73 - Interfaz Schema Workbench

 Weka

Figura 74 - Pantalla Inicial Weka

 ANEXO 4

TRANSFORMACIONES DE DIMENSIONES Y HECHOS

Las dimensiones y hechos que se crearon para el Data mart del

Departamento de Repuestos de Importadora Tomebamba, además de las
expuestas en el Capítulo 3, son los siguientes:

1. Dim_Item
Esta dimensión se pobló desde la tabla transaccional REP_ITEM,
eliminando los datos nulos en los campos ITECODIGOSUSTITUTO,
ITECLASIFICADORICC, ITEUNIDADMEDIDA y FOB.

Figura 75 - Estructura de la Dimensión Item

 134

Figura 76 - Transformación de Dimensión Item

2. Dim_ICC
Esta dimensión se pobló directamente desde un archivo plano, ya que
la clasificación ICC es una constante que se maneja dentro del
Departamento de Repuestos.

Figura 77 - Estructura de la Dimensión ICC

 135

Figura 78 - Transformación Dimensión ICC

3. Hecho_DetalleVentas
La Tabla de Hechos DetalleVentas se pobló con una llave primaria
compuesta por las llaves foráneas de sus dimensiones (Dim_Fecha,
Dim_Agencia, Dim_Item, Dim_ICC, Dim_Transaccion) y el número de
documento, conteniendo la suma de cantidad, subtotal, descuento y costo
vendido (REP_VENTA_DETA); y cantidad, subtotal, descuento y costo
devuelto (REP_DEVO_VENT_DETA) de los años de análisis.

Figura 79 - Estructura de la Tabla de Hecho_DetalleVenta

 136

Figura 80 - Transformación de Hecho_DetalleVenta

4. Dim_Proveedor
La dimensión Dim_Proveedor se alimenta de la tabla transaccional
REP_PROVEEDOR y de los datos formateados de la dimensión
Dim_Cliente para nombres y apellidos.

Figura 81 - Estructura de Dimensión Proveedor

 137

Figura 82 - Transformación de Dim_Proveedor

5. Hecho_ComprasTDE
La Tabla de Hecho_ComprasTDE se pobló con una llave primaria
compuesta por las llaves foráneas de sus dimensiones (Dim_Fecha,
Dim_Agencia, Dim_Asesor, Dim_Proveedor, Dim_Item, Dim_ICC) y el
número de factura de compra, conteniendo la suma de cantidad, y costo
de los años de análisis.

Figura 83 - Estructura de la Tabla de Hecho_ComprasTDE

Figura 84 - Transformación de Hecho_ComprasTDE

6. Hecho_Inventario
La Tabla de Hecho_Inventario se pobló con una llave única formada
por las llaves foráneas de sus dimensiones (Dim_Fecha, Dim_Agencia,
Dim_ICC), y con la suma de cantidad y costo de inventario
(REP_KARDEX) de los años de análisis.

Figura 85 - Estructura de Hecho_Inventario

Figura 86 - Transformación Hecho_Inventario

7. Dim_EstadoProforma
La dimensión Dim_EstadoProforma se pobló directamente de un
archivo plano con los datos proporcionados por el Departamento de
Repuestos.

Figura 87 - Estructura Dimensión EstadoProforma

Figura 88 - Transformación Dimensión EstadoProforma

8. Hecho_ReservasDetalle
La Tabla de Hecho_ReservasDetalle se pobló con una llave única,
formada por las llaves de sus dimensiones (Dim_Fecha, Dim_Agencia,
Dim_Cliente, Dim_Asesor, Dim_Item), la cantidad reservada y el estado
de la Proforma (REP_PROFORMA_DETA) de los años de análisis.

Figura 89 - Estructura Hecho_ReservasDetalle

 Figura 90 - Transformación Hecho_ReservasDetalle

9. Dim_LineaVenta
La dimensión LineaVenta se cargó directamente de la tabla
transaccional REP_LINEA, reemplazando unicamente los valores del
campo LIRESTADO.

Figura 91 - Estructura Dimensión Línea de Venta

Figura 92 - Transformación Dimensión LineaVenta

10. Dim_TipoTrans
La dimensión Tipo de Transacción se cargó directamente de la tabla
transaccional REP_TIPO_DOCUMENTO, reemplazando unicamente los
valores del campo TDCESTADO.

Figura 93 - Estructura Dimensión TipoTransacción

Figura 94 - Transformación Dim_TipoTrans

11. Hecho_DetalleInventario
La Tabla de Hecho_DetalleInventario se pobló con una llave primaria
compuesta por las llaves foráneas de sus dimensiones (Dim_Fecha,
Dim_Agencia, Dim_TipoTrans, Dim_Proveedor, Dim_LineaVenta,
Dim_ICC, Dim_Item) y el número de documento de la transacción,
conteniendo la cantidad, costo, precio y saldo final de la transacción, de
los años de análisis.
 Figura 95 - Estructura del Hecho DetalleInventario

Figura 96- Transformación de Hecho_DetalleInventario

12. Hecho_ComparaMetas
La Tabla de Hecho_ComparaMetas se pobló con una llave primaria
compuesta por las llaves foráneas de sus dimensiones (Dim_Fecha,
Dim_Agencia, Dim_ICC), conteniendo los meses de stock, monto de
rentabilidad y total neto, tanto reales como su presupuesto.
 143

Figura 97 - Estructura del Hecho Compara Metas

Figura 98 - Transformación del Hecho ComparaMetas

13. Dim_TipoCompraITSA
La dimensión Dim_TipoCompraITSA se pobló directamente de un Excel
con los códigos de las líneas de negocio involucradas en el análisis.

Figura 99 - Estructura Dimensión TipoCompraITSA

 144

Figura 100 - Transformación de Dimensión TipoCompraITSA

14. Hecho_RetornoClientes
La Tabla de Hecho_RetornoClientes se pobló con una llave primaria
compuesta por las llaves foráneas de sus dimensiones (Dim_Cliente,
Dim_Fecha, Dim_Agencia) y TipoCompra, conteniendo la cantidad de
compras realizadas.

Figura 101 - Estructura Hecho Retorno_Clientes

Figura 102 - Transformación Hecho_RetornoClientes

 ANEXO 5

GENERACIÓN DE CUBOS OLAP

Los cubos que se crearon para responder los requerimientos del

Departamento de Repuestos de Importadora Tomebamba, además del
expuesto en el Capítulo 3, son los siguientes:

1. DetalleDeVentas
Este cubo se crea en base al Modelo 2, con el objetivo de responder los
siguientes requerimientos:
 Obtener ventas netas por ICC
 Obtener ventas por item

Figura 103 - Cubo Detalle de Ventas Netas

2. ComprasTDE
El cubo ComprasTDE se crea en base al Modelo 3, respondiendo los
siguientes requerimientos:
 Obtener la cantidad de items comprados a TDE
 Obtener el costo de compra a TDE
 Figura 104 - Cubo Compras TDE

3. CostoInventario
El cubo CostoInventario se crea en base al Modelo 4, respondiendo los
siguientes requerimientos:
 Obtener el monto de Inventario por ICC

Figura 105 - Cubo Costo de Inventario

4. ReservasDetalle
En base al Modelo 5, se crea el cubo ReservasDetalle, respondiendo a los
siguientes requerimientos:
 Reportar los items reservados
 Figura 106 - Cubo de Items Reservados

5. DetalleInventario
Este cubo se crea en base al Modelo 6, para responder los siguientes
requerimientos:
 Reportar los items con existencia y sus movimientos
 Reportar los items comprados y no facturados

Figura 107 - Cubo para el Detalle de Inventario

6. ComparaMetas
En base al Modelo 7, se crea el cubo ComparaMetas, para responder a
los siguientes requerimientos:
 Reportar y comparar los Meses de Stock
 Reportar y comparar Márgenes de Rentabilidad
  Reportar y comparar Ventas Netas

Figura 108 - Cubo para Comparar Metas

7. RetornoClientes
En base al Modelo 8, se crea el cubo RetornoClientes, para responder los
siguientes requerimientos:
 Retorno de Clientes

Figura 109 - Cubo para Retorno de Clientes