TTTTTTTTTTTTTTT

FACULTAD DE INGENIERÍA Y ARQUITECTURA
ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS
IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTELIGENCIA DE

NEGOCIO PARA INCREMENTAR LAS VENTAS DEL ÁREA DE
BANCA MINORISTA DE UN BANCO
PRESENTADA POR
KAREN EVELYN GARCIA ARIAS
EMERSON RENAN ZUBIA PANTIGOSO
ASESORA
NORMA BIRGINIA LEÓN LESCANO
TESIS
PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO
DE COMPUTACIÓN Y SISTEMAS
LIMA – PERÚ
2016
CC BY-NC-SA
Reconocimiento – No comercial – Compartir igual
Los autores permiten transformar (traducir, adaptar o compilar) a partir de esta obra con fines no
comerciales, siempre y cuando se reconozca la autoría y las nuevas creaciones estén bajo una licencia con
los mismos términos.
http://creativecommons.org/licenses/by-nc-sa/4.0/
ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS
IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTELIGENCIA

DE NEGOCIO PARA INCREMENTAR LAS VENTAS DEL ÁREA
DE BANCA MINORISTA DE UN BANCO
TESIS
PARA OPTAR POR EL TÍTULO PROFESIONAL DE INGENIERO DE

COMPUTACIÓN Y SISTEMAS
PRESENTADA POR
GARCIA ARIAS, KAREN EVELYN

ZUBIA PANTIGOSO, EMERSON RENAN
LIMA – PERÚ
2016
Dedico esta tesis a Dios y a mis
padres, quienes me dieron la vida,
educación, apoyo, consejos y con su
ejemplo y dedicación me alentaron a
lograr mis metas.
Karen Evelyn García Arias
ii
Agradezco a las personas que me
brindaron su apoyo, en especial a mi
familia, compañeros de trabajo e
ingenieros, para la realización de la
investigación. Gracias por todo el
apoyo durante el tiempo que ha
durado la realización de la tesis.
Karen Evelyn García Arias
iii
Dedico la presente tesis a Dios por
permitirme experimentar triunfos en
momentos difíciles que me han
enseñado a crecer como persona. A
mis padres que me acompañaron y
alentaron en cada paso de esta
experiencia.
Emerson Renan Zubia Pantigoso
iv
Agradezco el amor brindado, la
paciencia y dedicación que mis
padres me mostraron al preocuparse
por el desarrollo de mi tesis; gracias
a ellos logré culminar con satisfacción
esta etapa y ser un profesional.
Emerson Renan Zubia Pantigoso
v
ÍNDICE
Página
RESUMEN xiii
ABSTRACT xiv
INTRODUCCIÓN xv
CAPÍTULO I MARCO TEÓRICO 1
1.1 Antecedentes 3
1.2 Bases teóricas 6
1.3 Definición de términos básicos 21
CAPÍTULO II METODOLOGÍA
2.1 Materiales 24
2.2 Métodos 27
CAPÍTULO III DESARROLLO
3.1. Fase 1: Planificación del proyecto 32
3.2. Fase 2: Definición de requerimientos del negocio 36
3.3. Fase 3: Diseño de la arquitectura técnica 40
3.4. Fase 4: Modelado dimensional 42
3.5. Fase 5: Diseño físico 48
3.6. Fase 6: Diseño e implementación del subsistema ETL 50
3.7. Fase 7: Especificación y desarrollo de aplicaciones de BI 56
3.8. Fase 8: Implementación 60
CAPÍTULO IV: PRUEBAS Y RESULTADOS
vi
4.1. Pruebas 65
4.2. Resultados 69
CAPÍTULO V: DISCUSIÓN Y APLICACIÓN
5.1. Discusión 74
5.2. Aplicaciones 79
CONCLUSIONES 81
RECOMENDACIONES 82
FUENTES DE INFORMACiÒN 83
ANEXOS 90
vii
LISTA DE FIGURAS
Página
Figura 1: Participación de mercado 2015 2
Figura 2: Niveles de toma de decisiones 8
Figura 3: Sistema de inteligencia de negocios 9
Figura 4: Fases de la metodología Kimball 10
Figura 5: Metodología Inmon 11
Figura 6: Resultados obtenidos con analysis services 13
Figura 7: Integration services 14
Figura 8: Reporting services 14
Figura 9: Data quality project 15
Figura 10: Proceso ETL 17
Figura 11: Plataforma de Pentaho BI 19
Figura 12: Power pivot 20
Figura 13: Cuadro de mando integral 21
Figura 14: Ciclo de vida de la metodologia Kimball 29
Figura 15: Entrada y salida de las fase 1 34
Figura 16: Cronograma de actividades 36
Figura 17: Entrada y salida de la fase 2 36
Figura 18: Diagrama star net 38
Figura 19: Diagrama de dimensiones 39
viii
Figura 21: Diseño de la arquitectura técnica 41
Figura 23: Modelo dimensional 43
Figura 25: Modelo físico del proyecto 49
Figura 27: Data flow / centralización de fuentes 53
Figura 28: Script de alerta 54
Figura 29: Diagrama carga STG 55
Figura 30: Diagrama carga DM 55
Figura 32: Resultados por áreas 57
Figura 33: Resultados por canales % de ventas 57
Figura 34: Resultados por canales centro de contacto 57
Figura 35: Resultados por canales fuerza de ventas 58
Figura 36: Ventas efectivas por agencia 58
Figura 37: Ventas efectivas por región 59
Figura 38: Venta efectiva por banca 59
Figura 39: Ranking agencias 60
Figura 41: Ventas totales 61
Figura 42: Ventas por canal ADVS 61
Figura 43: Ventas por el canal BEX 62
Figura 44: Cumplimiento por funcionario a nivel agencia 62
Figura 45: Cumplimiento por producto a niveles funcionario 63
Figura 46: Ranking por funcionario a nivel agencia 63
Figura 47: Cumplimiento por producto a nivel de área y región 64
Figura 48: SharePoint de la división comercial 64
Figura 49: Data Flow Centralización 66
Figura 50: Carga STG 67
Figura 51: Carga DIM 67
Figura 52: Correo de validación de fuentes 68
Figura 53: Ventas totales - CC. Camino Real 72
Figura 54: Ventas totales - CC. La Rambla 73
ix
Figura 55: Agencia piloto con seguimiento diario 75
Figura 56: Agencia sin seguimiento diario 75
Figura 57: Ventas por canal ADVS - CC. Camino Real 76
Figura 58: Ventas por canal BEX - CC. La Rambla 76
Figura 59: Ventas crédito personal - CC. Camino Real 77
Figura 60: Ventas de crédito personal - CC. Multiplaza 77
Figura 61: Ejecución de carga y validación diaria 78
Figura 62: Correo de validación de fuentes 78
Figura 63: Dashboard de ventas 79
x
LISTA DE TABLAS
Página
Tabla 1: Recursos humanos 24
Tabla 2: Herramientas a usar en el desarrollo del proyecto 25
Tabla 3: Infraestructura que se utilizará en el desarrollo del
proyecto 26
Tabla 4: Cuadro comparativo de metodologías 27
Tabla 5: Ponderación por metodología 28
Tabla 6: Tabla de riesgos 35
Tabla 7: Tabla matriz BUS 39
Tabla 8: Glosario de términos de la arquitectura lógica y
sistema ETL 41
Tabla 9: Requerimientos no funcionales 41
Tabla 10: Detalles del modelo dimensional 44
Tabla 11: Dimensión cliente 44
Tabla 12: Dimensión segmento 45
Tabla 13: Dimensión funcionario 45
Tabla 14: Dimensión tiempo 45
Tabla 15: Dimensión agencia 45
Tabla 16: Dimensión distrito 46
Tabla 17: Dimensión provincia 46
Tabla 18: Dimensión departamento 46
xi
Tabla 19: Dimensión región 46
Tabla 20: Dimensión área 46
Tabla 21: Dimensión productos 47
Tabla 22: Dimensión canal 47
Tabla 23: Tabla de hechos de ventas 47
Tabla 24: Características lógicas de los servidores 48
Tabla 25: Pruebas realizadas 65
Tabla 26: Requerimientos atendidos 68
Tabla 27: Tiempo de carga y validación de la información 69
Tabla 28: Validación por mes 70
Tabla 29: Elaboración del dashboard 70
Tabla 30: Incremento de las ventas 71
Tabla 31: Ventas totales - CC. Camino Real 72
Tabla 32: Ventas totales del CC La Rambla 73
xii
RESUMEN
La presente tesis tiene como objetivo realizar una solución de

inteligencia de negocio, para proporcionar la información de ventas de los
productos del banco de manera rápida y así proporcionar a la división
comercial, equipo de productos y gerentes de agencia, información para la
gestión de ventas que permitirá un incremento en ventas de las campañas de
multiproductos.
Este proyecto está basado en la metodología Kimball, tiene cuatro

principios, los cuales presentan fases y actividades que permitieron
desarrollar la solución de inteligencia de negocio en el banco. Como resultado,
se logró implementar una solución de inteligencia de negocio que permite que
la división comercial, equipo de productos y gerentes de agencia obtengan
información actualizada con un desfase de un día y llevar un seguimiento de
las ventas para poder tomar decisiones en el planteamiento de nuevas
estrategias en el mes y campaña. La implementación de la solución de
inteligencia de negocio permitió lograr un incremento de las ventas en un 6%
en promedio, solo durante el primer mes de prueba; adicionalmente se obtuvo
una reducción en los tiempos de carga y validación de las fuentes de
información con un dashboard de interfaz amigable para el comité de
gerencia.
Palabras clave: Inteligencia de Negocio, Campañas de multiproductos,

Metodología Kimball, ventas, fuentes de información.
xiii
ABSTRACT
This thesis aims to realize a business intelligence solution to provide

faster information about bank products sales in a way that commercial division,
product team and agency managers receive data on sales management which
allow sale increment in multi-product campaigns.
This project is based on Kimball methodology, it has four principles,

which present phases and activities that allowed the development of business
intelligence solution in the bank. As a result, a business intelligence solution
was implemented; it allows the business division, product team, and agency
managers to obtain updated information with one-day lag and to track sales to
be able to make decisions on the strategies in the month and the campaign.
The implementation of business intelligence solution allowed an

average sales increment of 6% only during the first month of testing;
additionally it permits loading time decrease and information source approval
with a friendly interface dashboard for the management committee.
Keywords: Business intelligence, Kimball methodology, multi-products

campaigns, sales, information sources.
xiv
INTRODUCCIÓN
Actualmente, en el área de Planeamiento Comercial Banca Minorista,

desea incrementar las ventas y realizar un seguimiento constante de ellas
dentro de las campañas de multiproductos, por ello este proyecto tiene como
principal objetivo realizar una solución de inteligencia de negocio para
proporcionarle a la División Comercial, equipo de productos y gerentes de
agencia información a un día anterior (t-1) para apoyar a la gestión de ventas.
Hoy en día las empresas manejan un gran flujo de información, la cual
muchas veces es difícil de manejar, y es en ese momento donde entra una de
las herramientas más utilizadas últimamente en las áreas de tecnología de
información (TI): inteligencia de negocio o “business intelligence”.
Las organizaciones contemporáneas han enfrentado una necesidad de
toma de decisiones complejas y semiestructuradas. La dispersión de las
fuentes de información y descentralización de este tipo de proceso resultan
en la insuficiencia de los modelos actuales de gestión de la información. En
esta situación, las organizaciones ofrecen la aplicación de sistemas de BI,
“business intelligence”. Estos representan un entorno integrado que consiste
principalmente en almacenes de datos, herramientas ETL (extract, transform
and load) y técnicas OLAP (on line analytical processing) (Olszak & Ziemba,
2006)
Una buena gestión inicia con el control, por lo que se hace eminente la
medición. Esto conlleva a que las empresas tengan que mejorar el
xv
seguimiento y evaluación de actividades. Con este antecedente, el diseño de
un sistema de indicadores que permitan medir la gestión y desempeño del
área de ventas basado en un modelo de inteligencia de negocios sería
beneficioso y generaría valor empresarial (Novoa, 2014).
El diseño de los dashboards es fundamental para facilitar la
visualización efectiva de grandes cantidades de información. A través de una
buena agrupación y diseño, se logra entender características inherentes en
los datos que pueden ser casi imposibles de detectar mediante otros métodos,
apoyando así, una toma de decisiones eficiente, partiendo de las principales
métricas y variables establecidas previamente (Calderón Gómez, Díaz Minguí,
Ariza Nieves, Giraldo Ardila, & others, 2015).
El analizar los requerimientos de usuarios, para diseñar y construir un
datamart, debido a sus sistemas actuales no soportan el manejo adecuado de
grandes volúmenes de información, se tiene dificultades para utilizarla y
emplearla en la toma de decisiones de la sección, es por ello que (Altamirano
Zelada, 2015) planteó como medida de solución la construcción de un
datamart con el fin de mejorar la toma de decisiones en el Banco de la Nación.
La implementación de una solución de inteligencia de negocio es
combinar las herramientas disponibles, la tecnología y procesos de
transformación de datos así obtener información relevante para el negocio.
El problema general es la limitada información para la gestión de ventas

dentro de las campañas de multiproductos de un banco. Dentro de los comités
de ventas se tiene un dashboard con información desfasada de una semana,
el cual no permite tomar acciones inmediatas para obtener un incremento en
las ventas y cumplir con las metas al cierre de cada campaña.
El objetivo general es mejorar la gestión de ventas del área de Banca

Minorista. Como objetivos específicos se precisan: Implementar una solución
de negocios a través de un datamart para el área ventas de Banca Monorista.
Mejorar la elaboración del Dashboard para la gestión de ventas y reducir los
tiempos de carga y validación de la información de ventas.
xvi
La justificación teórica se basa en la solución de inteligencia de negocio
que hoy en día se aplica en empresas de diferentes rubros, tanto públicas
como privadas, los cuales buscan mejorar las mediciones y la gestión de sus
indicadores para tener información que apoye a la gestión de ventas. La
implementación de una solución de inteligencia de negocios logra mejorar la
eficiencia en el uso de la información para la empresa, reduciendo tiempos en
procesos de carga de información.
La justificación practica implica que el área de Planeamiento Banca

Minorista de un banco, desea incrementar sus ventas dentro de las campañas
de multiproductos; para ello requiere una solución de inteligencia de negocio,
el cual implica mejorar y automatizar la obtención de información de ventas al
crear un datamart que logrará integrar las fuentes de información de los
productos, proporcionando información al día anterior (t-1) para la División
Comercial, equipo de productos y gerentes de agencia; teniendo un
seguimiento diario de las ventas para apoyar a la toma de decisiones de
nuevas estrategias de los diferentes productos. Además, esta solución
ayudará a reducir tiempos en los procesos de carga de información y procesos
de validación.
La estructura de la tesis denominada Implementación de una solución

de inteligencia de negocio para incrementar las ventas del área de Banca
Minorista de un banco, consta de cinco capítulos. En el Capítulo I, se describe
diferentes tipos de proyectos realizados utilizando inteligencia de negocio,
también se describe algunas teorías de BI; en el Capitulo II, se describe la
metodología que se utilizó para el desarrollo del proyecto; en el Capitulo III,
se describe el desarrollo del proyecto utilizando la metodología descrita en el
capitulo anterior; en el Capitulo IV, se describen las pruebas realizadas al
proyecto y los resultados obtenidos de estas pruebas; en el Capitulo V, se ve
las aplicaciones que se elaboraron.
xvii
CAPÍTULO I
MARCO TEÓRICO
El Banco de Crédito del Perú (BCP), inició sus actividades el 9 de abril

de 1889, adoptando una política crediticia inspirada en los principios que
habrían de guiar su comportamiento institucional en el futuro. (Banco de
Crédito del Perú, 2016)
Con el propósito de conseguir un mayor peso internacional el BCP
instaló sucursales en Nassau y en Nueva York, hecho que los convirtió en el
único banco peruano presente en dos de las plazas financieras más
importantes del mundo. Hoy en día el banco tiene 125 años en el mercado
local. Esta institución cuenta con 375 agencias, más de 1,800 cajeros
automáticos, más de 5,600 agentes BCP y más de 15,000 colaboradores; así
como bancos corresponsales en todo el mundo. (Banco de Crédito del Perú,
2016)
El banco tiene cinco gerencias centrales, como se muestra en el Anexo

1; una de estas gerencias es la de banca minorista y gestión de patrimonios,
la cual tiene como principal objetivo brindar servicios a personas y pequeñas
empresas.
La gerencia de banca minorista y gestión de patrimonios (organigrama
ver en Anexo 2: Organigrama banca minorista y gestión de patrimonios)
brinda servicios a personas y pequeñas empresas, así como a instituciones
1
sin fines de lucro. El objetivo de esta banca es establecer relaciones rentables
y de largo plazo con esos clientes, mediante estrategias orientadas a
satisfacer las necesidades específicas de cada segmento, así como también
incrementar su participación de mercado.
Se muestra la participación de mercado del año 2015 en la Figura 1.
(Banco de Crédito del Perú - memorial anual, 2016)
Figura 1: Participación de mercado 2015

Fuente: Banco de Crédito del Perú - memorial anual, 2016
En el área se genera un reporte de seguimiento de ventas para

la alta gerencia y funcionarios el cual se le llama “tablero de control”, este
muestra los avances de los cumplimientos de las colocaciones por producto y
segmento.
Los problemas identificados que se tienen la información
desfasada, el cual limita tomar decisiones inmediatas generando un
incumplimiento de su meta, esto es a causa de que los procesos de carga
manual de las fuentes de información tardan demasiado. Luego de esto se
debe validar manualmente la información (campos errados, archivos
incompletos, formato incorrecto), el cual también toma tiempo y como proceso
final la demora de la elaboración del reporte que es manual, lo cual retrasa la
entrega para el comité. Todo este proceso al equipo de inteligencia comercial
les toma 7hrs. para su realización y 3 analistas semanalmente.
2
1.1 Antecedentes
La inteligencia de negocio BI, “business intelligence”, es una

herramienta bajo la cual diferentes tipos de organizaciones pueden soportar
la toma de decisiones basadas en información precisa y oportuna;
garantizando la generación del conocimiento necesario que permita escoger
la alternativa que sea más conveniente para el éxito de la empresa. (Gómez
& Bautista, 2010)
La inteligencia de negocio es un conjunto de estrategias y

herramientas dirigidas a convertir datos en información e
información en conocimiento mediante el análisis del conjunto de
datos que se disponen en una organización, independiente de cuál
sea su soporte, para conducir de manera eficaz los procesos de
negocio de las organizaciones. En la actualidad la inteligencia de
negocio constituye una disciplina puntera para obtener
conocimiento de un negocio. (Núñez, 2010)
El autor en mención describe los cinco principales usos que
soportan las herramientas de BI:
1. Reporting: elaboración de informes, el reporting es considerado
el núcleo de BI y es la aplicación más utilizada.
2. Análisis: herramientas de consulta ad-hoc y OLAP.
3. Planificación y modelización.
4. Monitoring: Dashboards y Scorecards.
5. Análisis avanzado: Datamining y Textmining.
Los primeros sistemas de BI eran herramientas individuales

especializadas en uno de estos usos o funciones. Hoy día las
soluciones de BI son herramientas completas que realizan varias
de estas funcionalidades. También los sistemas de BI son
herramientas de desarrollo y administración, que permiten crear,
desarrollar y mantener aplicaciones de BI (Núñez, 2010).
3
(Durand Mendoza, 2014), desarrolló un datamart para mejorar la
toma de decisiones en el área de ventas de la corporación Furukawa; el
problema principal de esta corporación es que no tiene un control exacto de
las ventas que realizan las áreas de la empresa, es por ello que esta tiene la
necesidad de analizar sus ventas por las diferentes áreas de la corporación,
a su vez tomar decisiones de continuidad, de expansión o de absorción de las
mismas; para ello se necesita desarrollar un datamart para mejorar la toma de
decisiones.
(Fernandez, 2013), realizó una solución de inteligencia de negocios
como apoyo a la toma de decisiones en la gerencia mediante un software de
apoyo de inteligencia de negocio. Un gerente puede acceder a grandes
cantidades de información consistente del negocio, con la que es posible
encontrar características que generan mayor conocimiento sobre el
comportamiento de la organización.
(Sánchez, 2011), realizó una solución de inteligencia de negocios
y automatización en la gestión de puntos y fuerza de ventas en un empresa
de tecnología; esta solución se compone de un análisis situacional actual, un
levantamiento de los procesos relacionados con la estratega de reportes y un
rediseño sobre estos para que puedan ser implementados en un sistema de
información. Los requerimientos y principales necesidades de la empresa son
descritos, para posteriormente diseñar e implementar una solución rentable
de inteligencia de negocios que automatice la creación de reportes,
permitiendo visualizar tableros o dashboards dinámicos con acceso a
información histórica.
(García, 2010), realizó una solución de inteligencia de negocios
como herramienta para la toma de decisiones estratégicas en las empresas,
a la que denominó Análisis de su aplicabilidad en el contexto corporativo
colombiano. A nivel práctico, se puede decir que esta gran mayoría de
empresas que están en proceso o ya tienen implementado sistemas de
inteligencia de negocio, han incorporado el uso de información como parte del
desarrollo de sus procesos organizacionales con lo cual, con el paso del
tiempo se van afianzando los conocimientos del manejo y administración de
datos que como se dijo anteriormente, constituyen el primer paso para la
generación de información relevante.
4
(Falcón Rodríguez, 2012), desarrolló de una solución de
inteligencia de negocios en el manejo de estadísticas de control en la venta
de repuestos de la empresa Talleres Ambamazda S.A. de la ciudad de
Ambato. Las nuevas tendencias tecnológicas apuntan a la utilización de
sistemas complejos para la aplicación de servicios y facilidad en la entrega de
información que permitan una excelente administración de las ventas y
manejo de stock en bodega; ya que un buen manejo y crecimiento de la
empresa está basado en buenos y ágiles procedimientos.
(Díaz, 2011), desarrolló un sistema automatizado basado en
inteligencia de negocio que integre los procesos administrativos de almacén,
del supermercado Bello Monte. El sistema de petición de compras a los
vendedores, registro en el almacén y ventas de los alimentos se llevaba de
manera totalmente manual, acarreando una serie de inconvenientes tanto de
los proveedores como de los clientes. En vista a esto, se le propuso la
automatización de los diferentes procesos administrativos del almacén
brindando un cómodo, rápido y seguro cambio en el paradigma de trabajo en
el mencionado comercio de alimentos.
(Hernández, 2016), realizó tableros de mando como herramienta
de inteligencia de negocios para la toma de decisiones en el sector bancario
privado. Es muy importante que los análisis de los nuevos negocios de los
clientes que se toman en junta directiva sean presentados usando el
dashboard o tablero de mando, ya que la mayoría de los presentadores
utilizan diferentes herramientas para mostrar los casos y provoca diferencias
de visualización que a la postre se convierten en decisiones erradas por parte
de los directivos.
(Garavito Triana et al., 2015), diseñó una herramienta de negocios
para el manejo de información de ventas de una empresa comercializadora
de productos agropecuarios, diseñar un sistema de indicadores de gestión
enfocados a las ventas para empresas de comercialización del sector
agropecuario, donde los usuarios puedan usar la información de los
resultados de los procesos de venta, para diseñar estrategias y tomar
decisiones; esto bajo control y observación, en pro del aumento de las ventas
en los tiempos proyectados. Se espera que el usuario, pueda ver donde se
encuentran sus falencias y sus fortalezas; por consiguiente, saber hacia
5
dónde direccionar el manejo de los recursos para cumplir con sus objetivos,
siendo en este caso el principal objetivo, vender competitivamente en el
mercado y obtener la rentabilidad esperada.
(Cabanillas & Peña, 2011), realizó un análisis, diseño e
implementación de una solución de inteligencia de negocios para el área de
compras y ventas de una empresa comercializadora de electrodomésticos; se
toma en cuenta que los reportes satisfagan las necesidades de los usuarios
para una adecuada toma de decisiones. Además de ello, les ayuda a reducir
tiempos de respuesta en el procesamiento y análisis de información, lo que se
traduce en que lleguen a ser empresas sostenibles en el tiempo bajo un
entorno competitivo.
(Guerra Tapia & Marcillo Cruz, 2015), realizaron un análisis, diseño
e implementación de una solución de inteligencia de negocios en la unidad
educativa Mundo América. Los usuarios operativos generan reportes en sus
tareas del día a día, pero cuando un directivo solicitaba una información
consolidada de manera mensual tenían que trabajar con varios archivos en
Excel a la vez, lo que hacía que un reporte pueda tardar hasta tres días. En la
solución que se implementó, se consolidan todos los datos en el data
warehouse por lo que los reportes se generan de manera automática sin que
tome tiempo de construcción para el usuario.
1.2 Bases teóricas
Las bases teóricas, comprenden los conceptos de inteligencia de

negocios, metodologías para su desarrollo, herramientas para la
implementación y herramientas para el acceso a los datos que apoyan a la
creación de reportes según la necesidad del negocio.
1.2.1 Data Warehouse
El data warehouse, como su nombre lo indica, hace

referencia a un almacén de datos. Estos pueden provenir de distintas fuentes
y deben de estar estructurados de determinada manera que no haya
inconsistencias; asimismo, deben tratarse de datos que poseen cierta relación
entre sí. Por otro lado, ya que estos datos van a representar una tendencia,
6
deben tener un contenido histórico considerable. Como última característica,
los datos en este sistema no deben de ser volátiles, por lo que se entiende
que deben de ser permanentes y no modificados. (Minnaard, Servetto, Pascal,
& Mirasson, 2016)
Fue William Inmon, ingeniero especializado en bases de datos
quien acuñó por primera vez el término de data warehouse para
hacer referencia a un almacén de información temática orientado a
cubrir las necesidades de aplicaciones de los sistemas de soporte
de decisiones (DSS) y de la información para directivos (EIS), que
permite acceder a la información corporativa para la gestión, control
y apoyo a la toma de decisiones. (Alcalá, de Pablos Heredero, &
Lozano, 1998)
“Según el profesor Hugh J. Watson, un data warehouse es
una colección de información creada para soportar las aplicaciones de toma
de decisiones” (Núñez, 2010).
1.2.2 Datamart
Un datamart, es un subconjunto de un data warehouse, o

en otras palabras un datamart es un data warehouse pequeño, con un alcance
de contenido limitado, que está orientado específicamente a un área o un
problema particular de análisis de la empresa. Asimismo, un datamart puede
ser alimentado desde los datos de un data warehouse o integrar por sí mismo
un compendio de distintas fuentes de información (Altamirano Zelada, 2015).
El datamart, es un sistema orientado a la consulta, en el
que se producen procesos “batch” de carga de datos con una frecuencia baja
y conocida. Es consultado mediante herramientas OLAP (“On Line Analytical
Processing” – Procesamiento Analítico en Línea) que ofrecen una visión
multidimensional de la información. Sobre estas bases de datos se pueden
construir EIS (“Executive information Systems” – Sistemas de Información
para Directivos) y DSS (“Decision Support Systems” – Sistemas de Ayuda a
la toma de Decisiones) (Durand Mendoza, 2014).
7
En síntesis, se puede decir que los datamart son pequeños
data warehouse centrados en un tema o un área de negocio específico dentro
de una organización.
1.2.3 Inteligencia de negocios
“La primera persona en acuñar el concepto de inteligencia

de Negocios fue Howard Dresner y se le considera el padre de la inteligencia
de negocios” (Armendáriz et al., 2016). Dresner describe como inteligencia de
negocio: “Un conjunto de conceptos y métodos para mejorar el proceso de
decisión utilizando un sistema de soporte basado en hechos”.(Osorio, 2012)
La inteligencia de negocios es el conjunto de productos y
servicios que permiten a los usuarios finales acceder y analizar de manera
rápida y sencilla la información para la toma de decisiones de negocio de nivel
operativo, táctico y estratégico; como se puede visualizar en la Figura 2.
Figura 2: Niveles de toma de decisiones

Fuente: Durand Mendoza, 2014
Inteligencia de negocios, es el arte de extraer la

información de un negocio por medio de sistemas de información
convencionales y con fundamento en ella obtener conocimiento útil para el
futuro de la organización. Basado en los resultados ofrecidos por los sistemas
de inteligencia de negocios, el gerente de una organización podría tomar
8
decisiones soportadas por el comportamiento histórico del negocio y del
entorno donde funciona; así generaría un mayor desempeño en los procesos
y una mejor utilidad económica mediante una reducción importante en sus
costos.(Fernandez, 2013)
Las aplicaciones de business intelligence (BI), son
herramientas de soporte de decisiones que permiten en tiempo real, acceso
interactivo, análisis y manipulación de información crítica para la empresa.
Estas aplicaciones proporcionan a los usuarios un mayor entendimiento que
les permite identificar las oportunidades y los problemas de los negocios. Los
usuarios son capaces de acceder y apalancar una vasta cantidad de
información, analizar sus relaciones y entender las tendencias que
últimamente están apoyando las decisiones de los negocios. Estas
herramientas previenen una potencial pérdida de conocimiento dentro de la
empresa que resulta de una acumulación masiva de información que no es
fácil de leer o de usar.(Soto, 2010). En la Figura 3, se explica el funcionamiento
de un sistema de BI.
Figura 3: Sistema de inteligencia de negocios

Fuente: Sánchez, 2011
1.2.4 Metodología de Kimball
La metodología de Kimball, se basa en lo que él denomina

Ciclo de vida dimensional del negocio, “Business Dimensional Lifecycle”, ver
en la Figura 4, (Kimball, 2008). El ciclo de vida está basado en cuatro
principios:
9
a) Centrarse en el negocio: hay que concentrarse en la identificación de los
requerimientos del negocio y su valor asociado, y usar estos esfuerzos
para desarrollar relaciones sólidas con el negocio, agudizando el análisis
del mismo y la competencia consultiva de los implementadores.
b) Construir una infraestructura de información adecuada: diseñar una base
de información única, integrada, fácil de usar, de alto rendimiento donde
se reflejará la amplia gama de requerimientos de negocio identificados en
la empresa.
c) Realizar entregas en incrementos significativos: crear el almacén de datos
(DW) en incrementos entregables en plazos de 6 a 12 meses. Hay que
usar el valor de negocio de cada elemento identificado para determinar el
orden de aplicación de los incrementos. En esto la metodología se parece
a las metodologías ágiles de construcción de software.
d) Ofrecer la solución completa: proporcionar todos los elementos
necesarios para entregar valor a los usuarios de negocios. Para
comenzar, esto significa tener un almacén de datos sólido, bien diseñado
con calidad probada, y accesible. También se deberá entregar
herramientas de consulta ad hoc, aplicaciones para informes y análisis
avanzado, capacitación, soporte, sitio web y documentación.
Figura 4: Fases de la metodología Kimball

Fuente: Rivadera, 2014
10
1.2.5 Metodología de Inmon
La metodología de Bill Inmon, es similar a la propuesta por

Kimball pero posee algunas variantes al momento de implementar un proyecto
de Inteligencia de Negocio. Inmon propone una metodología basada en la
arquitectura denominada fábrica de información corporativa (CIF), la cual
provee una estructura que ayuda a describir los componentes utilizados para
adquirir capacidades de inteligencia de negocio, esta estructura se puede
visualizar en la Figura 5.
Esta metodología se clasifica como una metodología “Top
Down”, los datos son extraídos desde los sistemas operacionales, los cuales
son cargados y consolidados en un data warehouse corporativo y a su vez
son distribuidos a los diferentes datamarts de cada unidad del negocio para
satisfacer los requerimientos de la organización. (Altamirano Zelada, 2015).
Figura 5: Metodología Inmon

Fuente: Espinosa Montiel, 2013
1.2.6 Oracle BI
Oracle BI, es una solución integrada para inteligencia de

negocio y almacenamiento de datos que se adapta a las necesidades de las
empresas. Es un activo empresarial mediante la estandarización en una
plataforma de inteligencia de negocio único y escalable que permite a los
usuarios crear fácilmente sus propios informes con información relevante para
ellos. Ayuda a obtener una visión más clara, a través de datos, generando así
11
mejores resultados de negocio.(Oña Acosta, 2013). Seis características
principales:
a) Es una herramienta útil para la elaboración de prototipos en tiempos
cortos y puede extenderse de manera sencilla a informes, análisis,
minería o al manejo de grandes volúmenes de datos, en donde se tiene
conocimiento de que tipo de datos se quieren consultar, con un enfoque
de Cuadro de Mando.
b) Paquete diseñado para que todo sistema se ejecute en un solo servidor.
c) Interfaces de usuarios comerciales que no requieren codificación, SQL ni
otras capacidades técnicas.
d) Diseño y nivel de informes utilizando herramientas cotidianas como
Microsoft Word y Adobe Acrobat.
e) Cuadro de Mando interactivos con modalidad “drag and drop”.
f) Utiliza tecnología líder en su categoría, para cada componente.
1.2.7 SQL Server analysis services (Ssas)
Herramienta que permite crear estructuras de consulta

multidimensionales de alto rendimiento, lógica de negocios e indicadores
clave del desempeño (KPI) dentro de un modelo de datos con varios fines que
puede acceder a cualquier aplicación cliente que admita analysis services
como origen de datos, (Sandoval & Peña, 2015). En la Figura 6, se puede

visualizar los resultados obtenidos con analysis services.
Ssas, incluye tres características que ayudan con facilidad

a desarrollar y comparar varios modelos predictivos y tomar medidas
posteriormente en función a los resultados:
a) Conjuntos de pruebas de datos de exclusión
b) Filtros de modelo de minería de datos
c) Obtención de detalles para casos de estructura y columnas de estructura
12
Figura 6: Resultados obtenidos con analysis services
Fuente: Sandoval & Peña, 2015
1.2.8 SQL Server integration services (Ssis)
Es una plataforma para construir una integración de datos

a nivel empresa y soluciones ETL. Los servicios de integración de datos se
usan para crear paquetes que automatizan tareas como el copiado y descarga
de archivos, enviar correos en respuesta a eventos y actualizar bases de
datos, limpiar y examinar datos y manejar objetos de SQL server datos, como
se puede visualizar en la Figura 7. Integrar datos en tiempo real en
aplicaciones SQL server, oracle, teradata, CRM, share point y en la nube
(Sandoval & Peña, 2015). Cuatro características claves de esta herramienta:
a) Acceso a datos de cualquier estándar (Oracle, SQL, DB2, Teradata), XML,
archivos planos y aplicaciones de negocio a través de BizTalk o
conectores para SAP, ERP, CRM, Servicios Web y aplicaciones
principales.
b) Herramientas gráficas para gestión compleja de datos sin escribir una sola
línea de código.
c) Servicios de calidad de datos integrados dentro del flujo de trabajo para
limpieza de información.
d) Procesamiento de datos complejos en tiempo real dentro de los procesos
de negocio y ETL con SQL Server Streaminsigth.
13
Figura 7: Integration services
1.2.9 SQL Server reporting services (Ssrs)
Reporting Services, es una plataforma de creación de

informes basada en servidores. Puede publicar informes en un servidor de
informes, o como parte de una aplicación de Microsoft Windows, o en un sitio
de SharePoint. Puede programar el procesamiento de informes, el acceso a
informes a petición, la suscripción a informes publicados y la exportación de
informes a otras aplicaciones como Microsoft Excel. Puede crear también
alertas de datos en los informes publicados en un sitio de SharePoint y recibir
mensajes de correo electrónico cuando cambien los datos del informe
(Microsoft, 2016). Puede seleccionar entre una variedad de formatos de
visualización, como se observa en la Figura 8.
Figura 8: Reporting services

Fuente: Microsoft, 2016
14
1.2.10 Data quality services (DQS)
Los servicios de calidad de datos (DQS), es una nueva

oferta que hace parte de SQL server 2012, permitiéndoles a los usuarios
limpiar, comparar, estandarizar y enriquecer su información para entregar
información verídica para su inteligencia de negocios, almacenes de datos y
procesos transaccionales (Sandoval & Peña, 2015).
Los servicios de calidad de datos abstraen la creación de
una base de conocimiento para los usuarios finales que entienden el negocio
y pueden gestionar la gobernabilidad y el cumplimiento de sus datos, tal como
se observa en la Figura 9. Cuatro características principales:
a) Limpieza de datos para asegurar la precisión y validez de su información
recién descubierta.
b) Fácil adquisición de reglas de terceros desde la nube con Azure
Marketplace.
c) Limpieza de datos en el flujo de trabajo de ETL con los servicios de
integración (Ssis).
d) Encontrar y consolidar duplicados de los datos con reglas minuciosas de
comparación.
Figura 9: Data quality project

15
1.2.11 Procesos ETL
Los procesos ETL, son probablemente los componentes

más importantes y de mayor valor añadido en una infraestructura que implique
la integración de varias fuentes de datos. En la Figura 10Error! Reference
source not found., se puede observar la estructura de un ETL.
En consecuencia, representan un pilar fundamental tanto
de simples proyectos de recopilación como de soluciones complejas de big
data o business intelligence, especialmente si se requiere mucha precisión o
actualización en los datos (Durand Mendoza, 2014).
Como su propio nombre indica, los procesos ETL se
dividen en tres frases:
a) Extracción: Consiste en obtener los datos del sistema origen, realizando
volcados completos o incrementales.
En ocasiones esta etapa suele apoyarse en un almacén intermedio,
llamado ODS, “Operational Data Store”, que actúa como pasarela entre
los sistemas fuente y los sistemas destino, y cuyo principal objetivo
consiste en evitar la saturación de los servidores funcional de la
organización.
b) Transformación: Los datos procedentes de repositorios digitales
distintos no suelen coincidir en formato. Por tanto, para lograr integrados
resulta imprescindible realizar operaciones de transformación. El objetivo
no es otro que evitar duplicidades innecesarias e impedir la generación de
islas de datos inconexas.
Las transformaciones aplican una serie de reglas de negocio (o funciones)
sobre los datos extraídos para convertirlos en datos destino.
c) Carga: Se trata de introducir los datos, ya adaptados al formato deseado,
dentro del sistema destino. En algunos casos se sobrescribe la
información antigua con la nueva, mientras que en otros se guarda un
historial de cambios que permite consultas retrospectivas en el tiempo, así
como revertir modificaciones.
Para la carga masiva de datos suele ser necesario desactivar
temporalmente la integridad referencial de la base de datos destino.
16
Figura 10: Proceso ETL
Fuente: Durand Mendoza, 2014
1.2.12 OLAP
El término OLAP, fue presentado en 1993, publicado por

Codd y asociados y apoyado por Arbor Software Corporation, compañía que
creó ESSBASE una de las primeras herramientas OLAP que aparecen en el
mercado, adquirida luego por Hyperion Software.
Según la definición que le dio Codd, OLAP es un tipo de
procesamiento de datos que se caracteriza, entre otras cosas, por permitir el
análisis multidimensional. Dicho análisis consiste en modelar la información
en medidas, dimensiones y hechos. Las medidas son los valores de un dato,
en particular, las dimensiones son las descripciones de las características que
definen dicho dato y los hechos corresponden a la existencia de valores
específicos de una o más medidas para una combinación particular de
dimensiones.
Este modelo se representa vectorialmente: los hechos se
ubican lógicamente en una celda que queda en la intersección de ciertas
coordenadas según el modelo (x, y, z,...), donde cada una de las coordenadas
de la celda representa una dimensión. Para materializar el análisis
multidimensional en una base de datos se usa la correspondencia entre los
elementos del modelo (hechos y coordenadas) y los de la base (tabla de
hechos y dimensiones) (Frade & Castillo, 2007).
17
Existen tres tipos de sistemas OLAP, los cuales son los
siguientes:
a) Procesamiento analítico relacional en línea (ROLAP): Del inglés,

“Relational OLAP”, son herramientas OLAP que acceden a la información
de bases de datos relacionales.
Una herramienta ROLAP requiere de un data warehouse sobre el que
acceder para recuperar los datos. Las herramientas ROLAP realizan
mediante consultas SQL un mapeo de los datos almacenados en el data
warehouse a un modelo multidimensional.
b) Procesamiento analítico multidimensional en línea (MOLAP): Del
inglés, “Multidimensional OLAP”, son herramientas que utilizan
almacenamiento multidimensional, es decir acceden a las llamadas bases
de datos multidimensionales (MDDB).
c) Procesamiento analítico híbrido en línea (HOLAP): Del inglés, “Hybrid
OLAP”, las herramientas HOLAP son una combinación de las MOLAP y
las OLAP, la idea es quedarse con lo mejor de cada una de las soluciones.
Estos sistemas mantienen los registros detallados en la base de datos
relacional, mientras que los datos resumidos o agregados se almacenan
en una base de datos multidimensional separada.
1.2.13 Pentaho
Es un conjunto de aplicaciones utilizadas para crear y

entregar soluciones para la toma de decisiones gerenciales. Es orientada a la
solución y centrado en los procesos; cuando se habla de orientada a la
solución es debido a que por medio de pentaho se desarrolla o implementa
una solución; en cambio cuando se habla de centrado de procesos se debe a
que cada componente de pentaho tiene un motor de procesos en su núcleo
que básicamente soporta entradas y salidas.
Al mismo tiempo, cada proceso de pentaho puede
ejecutarse dentro de otros procesos, lo que permite llevar a cabo tareas muy
complejas y brinda una gran flexibilidad. (Tacco Meléndez, 2015)
18
En la Figura 11, se pueden observar todos los
componentes de la plataforma Pentaho, con esta estructura se pueden
implementar la fábrica de información corporativa o la multidimensional.
Figura 11: Plataforma de Pentaho BI

Fuente: Tacco Meléndez, 2015
1.2.14 Power pivot
Power pivot, es una herramienta y tecnología integrada en

excel que ofrece la realización de análisis complejos de datos sin requerir la
intervención de técnicos, también transforma rápidamente grandes
cantidades de datos en información significativa e importante para conseguir
una respuesta certera, como lo indica (González, 2012). Además, es un
complemento de Excel que funciona a partir de Excel 2010 que se puede usar
para realizar un análisis de datos eficaz y crear modelos de datos sofisticados.
Power pivot permite combinar grandes volúmenes de datos de orígenes
diferentes, realizar análisis de la información rápidamente y compartir puntos
de vista con facilidad. (Medina, Sarzosa, & Barba, 2015)
Excel y power pivot, permiten crear un modelo de datos, un
conjunto de tablas con relaciones, así como se muestra en la Figura 12.
Los libros de Excel que se modifican con power pivot
pueden ser compartidos con otras personas como se comparte cualquier
archivo; aunque es mejor y con mayor ventaja publicarlo en entorno
sharepoint que tenga habilitados los servicios de Excel permitiendo procesar
19
y presentar datos en una ventana para poder ser analizados por otras
personas; esto es factible en la versión sharepoint 2013 agregando el
complemento obteniendo soporte de colaboración y administración de
documentos.
Figura 12: Power pivot

Fuente: (Farai, 2013)
1.2.15 Cuadro de mando integral
El cuadro de mando integral, “balanced scorecard”, es una

herramienta que permite alinear los objetivos de las diferentes áreas o
unidades con la estrategia de la empresa y seguir su evolución.
El uso que se le puede dar a un cuadro de mando integral
es tan diverso que se puede contemplar autoevaluaciones del personal, hasta
la definición de conceptos netamente organizacionales como son; la misión,
la política de calidad; plan de comunicación, imagen corporativa, acciones de
formación, catálogo de servicios; la confección de una cartera de clientes y la
realización de acciones para conocer mejor sus opiniones y preferencias, así
como para personalizar la presentación de la oferta de servicios para los
clientes más importantes.
En fin, la ejecución de un cuadro de mando es tan amplia y
generosa que puede llegar a cambiar la forma en que se presta un servicio en
20
entidades públicas (Gómez & Bautista, 2010). Un ejemplo de un cuadro de
mando se puede observar en la Figura 13.
Figura 13: Cuadro de mando integral

Fuente: los autores
1.3 Definición de términos básicos
• Arribos
Este término indica la llegada de un cliente a la agencia el cual
puede realizar alguna operación o solicitar algún producto del
banco.
• Campaña multiproductos (CMP)

Son campañas con una duración de tres meses, definidas por
el equipo de División Comercial; en este lapso se venden los
diferentes productos del banco a clientes que lo solicitan o
clientes LEAD.
• Canales
Es el medio por el cual el cliente realiza una compra de un
producto del banco.
21
• Clientes LEAD
Se define clientes LEAD, cuando tienen un gran potencial de
compra de un producto específico del banco como por ejemplo:
crédito vehicular, seguro, tarjeta crédito, etc.
• Colocaciones
Solicitudes de ventas de productos del banco (tarjetas,
créditos, etc.) que ingresan los funcionarios ante el arribo de un
cliente a las agencias o derivación.
• Cumplimiento
Este término es un cálculo del monto real entre la meta
propuesta.
• Dashboard (tablero de control)

Aquí podemos observar de manera gráfica los principales KPI’s
que van relacionados con los objetivos estratégicos de la
organización.
• Data warehouse (DWH)

Colección de datos orientada a un determinado ámbito,
integrado, no volátil y variable en el tiempo, que ayuda la toma
de decisiones en la entidad en la que se utiliza.
• Datamart
Base de datos orientado a un área de negocio, el cual cuenta
con información detallada para mejorar la perspectiva de la
gerencia, de esta forma se tiene una estructura óptima.
• DB2
Es una de las familias de productos de sistemas de gestión de
base de datos relacionales de IBM, que sirven a varias
plataformas diferentes de sistemas operativos.
• Dimensión
Tamaño o extensión de una cosa, en una o varias magnitudes,
por las cuales ocupa mayor o menor espacio.
22
• ETL (Extract, Transform and Load)
Este es el procedimiento que se utiliza para poder extraer y
cargar la información de diferentes fuentes hacia un modelo
datos o datamart; además, en este proceso se puede
transformar la información de acuerdo a los requerimientos del
negocio.
• Flujo de datos
Son paquetes que contienen tareas de procesamiento de data
en un determinado flujo. Estas tareas se ejecutarán y la
finalización del paquete anterior en caso este dependa de un
paquete previo para su ejecución.
• Fuentes de información
Se denomina fuentes de información a diversos tipos de
documentos que contienen datos útiles para satisfacer una
demanda de información o conocimiento.
• Gestión de desarrollo humano (GDH)

Es una división del banco encargado de las gestiones de
personal.
• Key performance indicator (KPI’s)

Son indicadores claves para el manejo gerencial el cual apoya
directamente para la toma de decisiones.
• Variación de cumplimiento
Este término se basa en la resta de cumplimiento actual menos
el cumplimiento del mes anterior.
• Ventas válidas
Dentro de una campaña se realizan múltiples ventas de los
productos del banco de las cuales según los filtros que cada
producto propone se filtran estas ventas tomando las
consideradas para el pago de comisiones.
23
CAPÍTULO II
METODOLOGÍA
La investigación aplicada, se caracteriza porque busca la aplicación o

utilización de los conocimientos adquiridos, a la vez que se adquieren otros,
después de implementar y sistematizar la práctica basada en investigación. El
uso de conocimiento y los resultados de investigación queda como resultado
una forma rigurosa, organizada y sistemática de conocer la realidad. (Cordero
& Rosa, 2009)
En el presente capítulo, se describen las herramientas y las actividades
de cada fase de la metodología, la cual se tomó como base para este
proyecto.
2.1 Materiales
2.1.1 Recursos Humanos

Los roles con los cuales contará el proyecto se muestran en la
Tabla 1.
Tabla 1: Recursos humanos

RECURSOS HUMANOS
DESCRIPCIÓN DEL
ROL NOMBRE
ROL
Gestor de Proyecto García Arias, Karen Persona que lidera al
Zubia Pantigoso, Emerson equipo guiándolo para
que cumpla las reglas y
24
procesos de la
metodología.
Analista Funcional García Arias, Karen Encargado de levantar los
Zubia Pantigoso, Emerson requerimientos
funcionales y no
funcionales y compararlo
con el producto elegido.
Analista de Base de Zubia Pantigoso, Emerson Encargado de levantar la
Datos base de datos.
Elaboración: los autores
2.1.2 Herramientas
A continuación, se describen las herramientas que se
utilizaron durante el desarrollo del proyecto.
Estas herramientas, están clasificadas en seis tipos según
su uso, también se describe la versión que se utilizó para cada software, tanto
para la computadora de la empresa como las personales. Ver Tabla 2.
Tabla 2: Herramientas a usar en el desarrollo del proyecto
Herramienta de Gestión de Proyectos

Software Versión Descripción
Herramienta de Microsoft que
permite establecer y gestionar los
MS – Project 2013
costos, tiempos y recursos de un
proyecto
Herramienta de Desarrollo
Permite desarrollar, probar, depurar
PL/SQL V. 9.0.1.1613 (64
errores y optimizar PL/SQL de
Developer Bits)
Oracle.
Herramienta de Base de Datos
Oracle Database 10c
Sistema de gestión de base de
Oracle Enterprise Edition
datos desarrollado por Oracle
Database Release 10.1.0.2.0 -
Corporation.
64bit Production
Herramientas de Comunicación
25
Se usará para la comunicación vía
Gmail Libre
email.
Herramienta de comunicación en
Drive Libre línea y se utilizará para almacenar
todos los archivos trabajados.
Permite compartir y controlar
escritorios, establecer reuniones
Skype Libre
online, video llamadas y transferir
archivos.
Herramientas de Conectividad
Permite conectarse remotamente a
Cisco VPN V. 4.x (64 bits)
otra máquina.
Herramientas de Documentación
Microsoft Paquete de Office que comprende
2013
Office Word, Excel y PowerPoint.
Además del uso de las herramientas detalladas

anteriormente, se identificaron los equipos de infraestructura que se utilizó
durante el desarrollo del proyecto, los cuales cuentan con la descripción de
sus características proporcionadas por la empresa. Ver Tabla 3.
Tabla 3: Infraestructura que se utilizará en el desarrollo del proyecto

Infraestructura
Equipo Descripción
Servidor proporcionado por la empresa. Req. Mínimos :
Servidor de • Procesador 4 núcleos
Desarrollo • Memoria RAM 16gb
• Disco duro 1TB
Computadora de la empresa: Req. Mínimos :
• Procesador Intel core i5
Computadoras
• Memoria RAM 6gb
• disco duro 500gb
26
Computadoras personales: Req. Mínimos :
• Procesador Intel core i7
• Memoria RAM 8gb
• disco duro 640gb
2.2 Métodos
Para la selección de la metodología, en la cual se basará el

desarrollo del proyecto, se muestra un cuadro comparativo de la metodología
Kimball y la metodología Inmon, como se muestra en la Tabla 4.
Luego de esta comparación de metodologías se muestra un cuadro
de ponderación, como se visualiza en la Tabla 5, lo cual permitió determinar
cuál era la metodología más adecuada para el desarrollo del proyecto.
Tabla 4: Cuadro comparativo de metodologías

Metodología Metodología
Kimball Inmon
Todas las empresas necesitan almacenar, analizar e

interpretar los datos que van generando y acumulando,
para luego tomar decisiones críticas que les permitan
Objetivo maximizar la prosperidad. Para ello, se necesita un sistema
que les ayude a entender los datos y logren cumplir sus
objetivos, de esta forma nace la idea de “implementar una
Data Warehouse”.
Diseño del Data Utiliza el enfoque “Bottom – Utiliza el enfoque “Top –

Warehouse Up” Down”
Tiene un enfoque por
procesos que son Tiene un enfoque global de
manejados por las diferentes toda la empresa. No está
Enfoque
áreas del proceso. Trata de basado en requerimientos
responder necesidades específicos.
específicas según el tema.
Debido a que en primer lugar
debemos implementar los
Datamart, el tiempo de
implementación es rápido.
Debido a que se implementa
Tiempo de Sin embargo, se tiene que
por completo el DWH se
Implementación del tener cuidado ya que si se
demanda mucho más
DWH trabaja de forma
tiempo.
independiente cada
Datamart el entorno del
DWH se desintegraría
rápidamente.
27
Implementar cada Datamart Los costos aumentan, debido
Costos permite que la solución no a que se replican grandes
presente un alto costo. cantidades de datos.
Inmon propone tres niveles
en el modelo de datos del
data Warehouse:
-Alto nivel: ERD (Entity
Kimball plantea usar el Relationship Diagram)
modelamiento dimensional: -Nivel Medio: DIS (Data Item
Modelo de Datos esquema estrella. Set)
Identificación de -Nivel Bajo: llamado Modelo
dimensiones y hechos. Físico (Physical Model)
Sin embargo, menciona que
para implementar las
Datamart debe hacerse con
modelamiento dimensional.
Fuente: Rojas Zaldívar, 2014
En la siguiente tabla se muestra la ponderación de cada

metodología en base a la información y enfoque que se tiene del negocio.
Tabla 5: Ponderación por metodología

Metodología Kimball Inmon
Enfoque general 4 3
Estructura de la
4 3
Arquitectura
Complejidad 3 4
Orientación de datos 4 3
Accesibilidad del
5 3
usuario final
Objetivo 4 3
Total 24 19
Fuente: Conde Humareda & Osorio Sánchez, 2015
La metodología que se utilizó para el diseño y construcción del

datamart, está basada en la metodología de Kimball, en donde se ha utilizado
las siguientes fases: planificación del proyecto, definición de requerimientos
del negocio, diseño de la arquitectura técnica, modelo dimensional, diseño
físico, diseño e implementación del subsistema de ETL, especificación y
desarrollo de aplicaciones de BI e implementación.
28
Estas fases se encuentran remarcadas en color rojo en la siguiente
Figura 14.
Figura 14: Ciclo de vida de la metodologia Kimball

Fuente: Rivadera, 2014
Elaboración: Los autores
2.2.1 Fase 1: Planificación del proyecto

En esta fase se determinará el alcance del proyecto, la
identificación de los riesgos y la identificación y programación de las
actividades, los resultados obtenidos son: el alcance del proyecto, riesgos
identificados y cronograma del proyecto, el cual se obtiene de las reuniones
con las personas involucradas en el proceso. Ver Figura 15.
2.2.2 Fase 2: Definición de requerimientos del negocio

Esta fase es determinante para el éxito del proyecto. Se
debe de tener claro los requerimientos de los usuarios, los cuales son claves
porque nos guiarán para realizar los diseños adecuados. En esta fase se
realizará el diagrama star net, el cual ayudará para la realización de una matriz
de los indicadores del negocio identificados versus las dimensiones (matriz
Bus), para luego poder realizar el diagrama de dimensiones. Ver Figura16.
Para realizar esta fase se sugiere entrevistar al siguiente
personal de la empresa:
• Los directivos responsables de las decisiones estratégicas.
29
• Los administradores responsables de explotar alternativas estratégicas y
aplicar decisiones.
• Personal de sistemas que conocen los problemas informáticos y datos de
la organización.
2.2.3 Fase3: Diseño de la arquitectura técnica

En esta fase se debe de tener en cuenta, los
requerimientos finales de los usuarios, los entornos técnicos y el proceso a
seguir para la extracción, transformación y carga de la información. Ver Error!
Reference source not found.17.
2.2.4 Fase 4: Modelado dimensional

En esta fase se tomó en cuenta la matriz BUS realizada en
la fase 2 para determinar la dimensionalidad que tendrá el desarrollo del
proyecto. Los tres pasos que se realizaron para la elaboración del modelo
dimensional son los siguientes: primero, estableceremos el nivel de
granularidad; segundo, elegiremos las dimensiones y tercero, identificaremos
medidas y las tablas de hechos. Ver Error! Reference source not found..
2.2.5 Fase 5: Diseño físico

En esta fase se especifica cuantas estructuras serán
necesarias para soportar el diseño lógico. La clave de este proceso es la
definición de estándares del entorno de la base de datos. Ver en la Error!
2.2.6 Fase 6: Diseño e Implementación del subsistema ETL

En esta fase realizaremos las actividades de extracción,
transformación y carga (ETL); estas actividades son importantes porque
tienen que ver con los datos de las fuentes de información. Ver Error!
2.2.7 Fase 7: Especificación y desarrollo de aplicaciones de

BI
30
En esta fase se determina los diferentes tipos de
aplicaciones que se requiere para cada uno de los perfiles de usuario. Ver
Error! Reference source not found.21.
Dentro de esta fase tenemos las siguientes categorías:
• Informes estándar: informes relativamente simples, de formato
predefinido y de parámetros de consulta fijos. Los informes estándar
proporcionan a los usuarios un conjunto básico de información, que son
usados día a día.
• Aplicaciones analíticas: estas son más complejas que los informes
estándar. Por lo general estas aplicaciones se centran en un proceso de
negocio específico y resumen cierta experiencia acerca de cómo analizar
e interpretar ese proceso de negocio.
2.2.8 Fase 8: Implementación

En esta fase se determinará el buen funcionamiento de la
tecnología utilizada, los datos y las aplicaciones de los usuarios del negocio.
Ver Error! Reference source not found..
31
CAPÍTULO III
DESARROLLO
Para el desarrollo de este proyecto se consideraron ocho fases,

después de la fase de definición de requerimientos del negocio. Las siguientes
fases se realizaron en paralelo para que luego estas se integren en la fase de
implementación.
3.1 Fase 1: Planificación del proyecto

En el área de planeamiento banca minorista se realizan campañas
trimestrales, las cuales se denominan campañas multiproductos; durante ellos
se realizan tres procesos los cuales ayudaron a obtener los históricos de
ventas de cada funcionario, de los cuales se generaron las metas y reportes
para los respectivos comités y tomas de decisiones. A continuación, los
procesos involucrados:
• Proceso de generación de metas

Este proceso empezó con el equipo de planeamiento comercial el cual
solicita la información necesaria para poder generar las metas de cada
campaña. En primer lugar pide el orgánico para la división comercial a
gestión de desarrollo humano (GDH) el cual unifica todos los orgánicos
de las diferentes agencias, consolida los nuevos colaboradores y
actualiza a los que ya no se encuentran laborando. Luego de esto GDH
informó sobre el envió de la información requerida, la cual es validada
32
manualmente por el equipo de planeamiento, de estar errada se
devuelve y se pide la base corregida. De la misma forma la solicitud a
inteligencia comercial para generar las tablas requeridas para el cruce
del orgánico.
Luego de tener las bases solicitadas planeamiento cruzó y validó los
históricos para poder generar según metodología definida por el
equipo; al tener este cruce, se cargaron en tablas tanto las metas como
el orgánico para luego brindar accesos al equipo de inteligencia
comercial. Estas tablas se validaron y se pudieron utilizar como input
para los procesos requeridos. Ver Anexo 3: Proceso de generación
de metas.
• Proceso de carga y generación de fuentes de información CMP
Este proceso empezó cuando el equipo de inteligencia generó

cronograma de CMP para entrega de las fuentes de información de la
campaña semanalmente para lo cual se envió fechas predeterminadas
en el envío de las bases. El pedido se realizó a GDH, división banca
personas y planeamiento; para este último conto con un proceso el cual
es validar fuentes desactualizadas de orgánicos el cual se detallará
más adelante.
Luego de que el equipo de inteligencia tuvo las bases, se validaron de
uno en uno en caso de tener errores se solicitó volverlas a enviar o
cargar. Como parte final del proceso estas fuentes se cargaron
manualmente en la base de datos para luego ser compartidas a los
usuarios que utilizan la información de ventas. A partir de esto el equipo
pudo generar los reportes según requerimiento de gerencia para los
comités. Ver Error! Reference source not found..
• Proceso de verificación de metas
Este proceso surgió por la necesidad que se tuvo para tener los
orgánicos lo más actualizado posible, por lo que semanalmente se
valida cambios en el orgánico para volver a generar las metas según
funcionario, para lo cual sigue el mismo flujo del proceso de generación
33
de metas pero en este caso no intervino el equipo de inteligencia
comercial. Ver Error! Reference source not found..
Estos procesos tienen dentro de ellos mucho trabajo manual, lo cual

hace que haya fallas y se tenga que reprocesar data, es por ello que se
propuso una solución de inteligencia de negocio que ayudo con la información
y redujo tiempos.
Para esta fase se elaboró un diagrama de entrada, proceso y salida,
como se puede visualizar en la Figura 15.
ENTRADA PROCESO SALIDA
•Reuniones •Definir el •Alcance del

División alcance proyecto
comercial, •Identificación •Riesgos
Planeamiento de riesgos identificados
Comercial y •Identificación •Cronograma
equipos de y del proyecto
productos programación
de actividades
Figura 15: Entrada y salida de la fase 1

Continuando con el desarrollo de esta fase se pactaron reuniones con

los usuarios finales; se realizaron tres reuniones en las cuales participaron el
gerente adjunto de la división comercial, gerente adjunto de planeamiento
comercial, gerentes adjuntos de los equipos de productos y gerente adjunto
de inteligencia comercial; de esta forma se logró definir lo siguiente:
• Alcance del proyecto creado
Se deberá contar con una herramienta que le permita tener información

actualizada de las ventas realizadas con la posibilidad de ver el detalle
a nivel de funcionario y en base a este análisis se pueda tomar
decisiones según el avance de las ventas a nivel de agencia, mes y
funcionario. De esta forma los equipos de productos pueden plantear
mejor sus estrategias inmediatas a través de campañas o publicidad
34
dirigida a los diferentes tipos de clientes y poder obtener el
cumplimiento definido en cada campaña.
Además, se describen las siguientes suposiciones y dependencias
▪ La moneda por defecto será nuevos soles (Local).

▪ La información adicional utilizada para el registro en la base de
datos de los funcionarios, agencias, productos y tipos de clientes
será provista a más detalle en las siguientes etapas del
requerimiento.
De igual forma para poder identificar los posibles riesgos a ocurrir se
realizó dos reuniones con todos los involucrados en el proyecto;
gerente adjunto de la división comercial, gerente adjunto de
planeamiento comercial, gerentes adjuntos de los equipos de
productos, asesor de información (DWH) y gerente adjunto de
inteligencia comercial, de esta forma se identificaron los siguientes
riesgos:
• Riesgos identificados
Durante las reuniones realizadas se identificaron los riesgos, los cuales

impactan en el desarrollo del proyecto. Estos riesgos fueron informados
a todos los interesados para su conocimiento y definidos como
probabilidad alta por su repetida ocurrencia anteriormente. Ver Tabla 6.
Tabla 6: Tabla de riesgos
N° Descripción del Riesgo Probabilidad Estrategia
Puede ocurrir un incumplimiento en las

fechas del cronograma, si lo usuarios no
1 Alta Transferir
están disponibles para las reuniones de
entendimiento de los requerimientos.
Puede ocurrir un incumplimiento en la
entrega de los requerimientos debido a la
2 Alta Transferir
disponibilidad de las fuentes de
información.
Puede ocurrir un error en la entrega de
3 información debido al incumplimiento del Alta Transferir
cierre y/o actualización de metas.
35
En todos los riesgos identificados los responsables a los cuales se
transfirió se comprometieron en que no ocurra el riesgo asignado. Para
el primer riesgo, todos los interesados e involucrados se
comprometieron a asignar la prioridad para el proyecto y en caso no
puedan asistir a las reuniones, enviarán a un representante de su
equipo y se asumirá todos los acuerdos pactados en la reunión. Para
el segundo riesgo se transfirió al equipo de DWH que es el encargado
de realizar la carga de las fuentes de información de los productos, las
cuales serán consumidas para la solución y como tercer riesgo se
transfirió al equipo de planeamiento comercial; los cuales se
comprometieron en gestionar la información junto con GDH.
• Cronograma del proyecto
En la Figura 16, se observa las fases y los intervalos que se

desarrollaron respectivamente en el proyecto, para visualizar las
actividades de cada fase ver el Anexo 6: Cronograma del proyecto
.
Figura 16: Cronograma de actividades

3.2 Fase 2: Definición de requerimientos del negocio
•Reuniones con los •Análisis de •Requerimientos

usuarios requerimientos finales de los usuarios
•Alcance del proyecto •Diagrama Star Net
•Matriz Bus
•Diagrama de
dimensiones
36
• Requerimientos de usuarios
Para obtener los requerimientos de los usuarios finales, se pactó una
reunión con los usuarios de la división comercial y los equipos de
productos.
Estas reuniones ayudaron a comprender las necesidades de los
usuarios de tener la información centralizada y de esta forma reducir
tiempos.
• Análisis de Requerimientos
Los requerimientos indicados por los usuarios, fueron analizados y nos
dio como resultado la lista final.
Estos requerimientos, ayudaron a mapear las fuentes de información
para poder elaborar el diagrama star net, que ayudó a entender las
dimensiones que interactúan para generar los indicadores solicitados.
Luego, se debió definir la granularidad, para identificar las dimensiones
que se debe de considerar al obtener los indicadores señalados en la
lista de requerimientos.
• Lista de Requerimientos
De las reuniones realizadas se obtuvieron siete requerimientos finales:
Req. 1: Se requiere visualizar las ventas trimestralmente en un rango

de un año y por meses.
Req. 2: Se necesita que se muestre el avance de ventas de los canales
por mes y trimestre.
Req. 3: Se requiere que las ventas se midan en base a la meta
presupuestada indicando el porcentaje de cumplimiento obtenido por el
funcionario.
Req. 4: Se necesita visualizar las ventas realizadas por agencias
totalizando las metas asignadas a cada funcionario, de esta forma
obtener un cumplimiento por agencia.
Req. 5: Se requiere tener el detalle de productos vendidos por
funcionario, además del porcentaje de ventas por producto.
37
Req. 6: Se necesita obtener un ranking de los mejores vendedores
según ventas totales que muestre a que área y región están asignadas.
Req. 7: Se requiere tener el porcentaje de cumplimiento de ventas a
nivel de área y región.
Req. 8: Se requiere que se tenga en cuenta que cada funcionario
pertenece a una agencia y la agencia pertenece a un departamento,
las cuales están agrupadas en regiones y a su vez cada una de estas
pertenecen a un área.
• Diagrama star net

En este diagrama se puede observar las posibles dimensiones a
considerar con su nivel de granularidad, el cual se utilizó para la
elaboración del datamart.
Figura 18: Diagrama star net

• Matriz BUS
Para la elaboración de la matriz Bus se cruzó las dimensiones definidas
con los indicadores solicitados para poder determinar el número de
tablas de hechos a elaborar en el datamart según la coincidencia que
tengan las dimensiones con respecto a los indicadores.
38
En la Tabla 7, se puede observar el cruce de todas las dimensiones con
los indicadores, por lo cual el datamart tiene solo una tabla de hechos.
Tabla 7: Tabla matriz BUS

CLIENTE FUNCIONARIO AGENCIA PRODUCTO TIEMPO
MontoTotalVentas X X X X X
CumplimientoVentas X X X X X
Metas X X X X X
CantidadTotalVentas X X X X X
• Dimensiones
Luego de analizar los requerimientos, realizar el star net y la matriz bus
podremos realizar un diagrama de dimensiones que se usarán para el
datamart, como se observa en la Figura 19.
CLIENTE
TIEMPO FUNCIONARIO
TABLA DE
HECHOS VENTAS
PRODUCTO AGENCIA
Figura 19: Diagrama de dimensiones

Definición de dimensiones
➢ Tiempo: Dimensión que sirve para ubicar en el tiempo las ventas

realizadas en la CMP.
39
➢ Producto: Dimensión que servirá para tener todos los productos
del banco.
➢ Agencia: Dimensión donde se tendrá las agencias con las que
cuenta el banco.
➢ Funcionario: Dimensión donde se encuentran todos los
funcionarios con los que cuenta el banco.
➢ Cliente: Dimensión donde se encuentran todos los clientes del
banco.
3.3 Fase 3: Diseño de la arquitectura técnica
• Requerimien • Construcción • Diseño de la

tos finales del diseño arquitectura
de los de la técnica
usuarios arquitectura
• Reuniones
con los
usuarios
• Arquitectura técnica del sistema de extracción, transformación y

carga
A continuación vamos a observar un diagrama que ilustra el

componente de carga de datos de la arquitectura. Además, este
diagrama es importante como primer paso en la determinación de los
diferentes elementos involucrados del proceso de extracción,
transformación y carga de un datamart.
El proceso empieza con la extracción de las fuentes de la información,
las cuales se ubican en los sistemas fuentes; estas se encuentran
validadas para luego proceder con su extracción, que nos lleva a la
preparación de datos, parte del proceso que da forma a la información
almacenándolo en tablas dentro del esquema del equipo de inteligencia
comercial. Luego esta información es cargada a las tablas de
40
dimensiones que genera la tabla de hechos. Los cuales se encuentran
en los datos relacionales, para luego extraerlas para la generación de
indicadores, que serán usados por el área de división comercial y el
equipo de productos.
Figura 21: Diseño de la arquitectura técnica

Tabla 8: Glosario de términos de la arquitectura lógica y sistema ETL

Término Descripción
Fuentes de Información de Origen de la información almacenada en
ventas Data Warehouse.
Durante este proceso se transporta los
Proceso de Extracción,
datos y los transforma a lo largo de la
Transformación y Carga
arquitectura.
Reportes que permiten visualizar la
Dashboards información que se encuentra en el
datamart.
Para el desarrollo de la arquitectura se tomó en cuenta los siguientes

requerimientos no funcionales. Ver Error! Reference source not
found.9.
Tabla 9: Requerimientos no funcionales
Accesos servidor Oracle BCPDW3
41
SQL Server PAUTGSQLD03
Oracle 520 MB
Espacio mínimo
SQL Server 520 MB
Remoto desktop VPN
Control Total Administrador
Permisos de acceso Oracle Usuario red
Windows
SQL Server
authentication
Analista Inteligencia
Rol RBCPGEPABPTGI01
Comercial
3.4 Fase 4: Modelado dimensional
•Matriz Bus •Mapeo de •Granularidad de

•Requerimientos atributos para las tablas
finales de los las dimensiones •Dimensiones y
usuarios según atributos
•Resumen de requerimientos y •Tabla de hechos
matriz BUS
entrevistas •Descripción de
dimensiones

• Modelo dimensional
Para definir este modelo nos basamos en la matriz BUS y diagrama de
dimensiones, señalado en la fase2.
Estos diagramas trabajados anteriormente nos ayudaron a realizar el
modelo dimensional, el cual muestra a detalle los atributos que tienen
cada tabla y la estandarización de los nombres de ellos. Además, se
puede visualizar en el modelo dimensional como es la relación entre
cada tabla y como estas se relacionan con la fact table.
Dentro de la tabla de hechos se pueden observar que contiene las
llaves de cada tabla con la que se está relacionando. Ver Figura 23.
42
Figura 23: Modelo dimensional
43
Tabla 10: Detalles del modelo dimensional
Nombre Descripción
Contiene la información necesaria del cliente para
CLIENTE
poder determinar la venta.
Contiene la información de los funcionarios a nivel de
FUNCIONARIO
matrícula.
Contiene la información de las agencias como la
AGENCIA
ubicación.
Contiene la información de los Productos del banco
PRODUCTO
según su clasificación.
Contiene los atributos asociados con la fecha en que
TIEMPO
se realizó la venta.
DISTRITO Contiene toda la información de los distritos
PROVINCIA Contiene toda la información de las provincias
DEPARTAMENTO Contiene toda la información de los departamentos
Contiene la información de las regiones definidas por
REGIÓN
el banco
Contiene la información de las áreas definidas por el
ÁREA
banco
SEGMENTO Contiene los segmentos generados por el banco
FAMILIA Contiene las familias agrupadas que cuenta el banco
Contiene información de los diferentes canales del
CANAL
banco
• Detalle de las dimensiones
Tabla 11: Dimensión cliente

Atributo Descripción Posibles Valores
CODUNICOCLI Identificador único de los clientes “0000124741211”
APEPACLI Apellido paterno del cliente Juárez
APEMACLI Apellido materno del cliente Cuba
NOMBRE Nombre del cliente Eduardo
44
Tabla 12: Dimensión segmento
Posibles
Atributo Descripción
Valores
Identificador único de los
CODSUBSEGMENTO “X1N”
segmentos
SEGMENTO Descripción del segmento CONSUMO
Tabla 13: Dimensión funcionario

Posibles
Valores
Identificador único del código del
MATRICULA S51417
Funcionario
AGUILAR
NOMBRE Nombre completo del Funcionario PEREZ
JUAN
Identificador del sector asignado a una
SECTOR 192204
agencia
Tabla 14: Dimensión tiempo

Posibles
Valores
CODTIEMPO Identificador único del tiempo 201611
AÑO Representa al año 2016
Representa al número de trimestre 1ER
TRIMESTRE
del año TRIMESTRE
MES Representa al número de mes 11
Tabla 15: Dimensión agencia

Posibles
Valores
CODOFICINA Identificador único de las agencias 240015
C.C. REAL
AGENCIA Contiene el nombre de la agencia
PLAZA
45
Tabla 16: Dimensión distrito
Posibles
Valores
CODDISTRITO Identificador único de los distritos 15
LA
DISTRITO Descripción de los distritos
VICTORIA
Tabla 17: Dimensión provincia

Posibles
Valores
CODPROVINCIA Identificador único de las provincias 05
PROVINCIA Descripción de las provincias LIMA
Tabla 18: Dimensión departamento

Posibles
Valores
Identificador único de los
CDODEPARTAMENTO 08
departamentos
DEPARTAMENTO Descripción de los departamentos LIMA
Tabla 19: Dimensión región

Posibles
Valores
Identificador único de las regiones
CODREGION 08
del banco
REGIÓN Descripción de las regiones REGIÓN 5
Tabla 20: Dimensión área

Posibles
Valores
CODAREA Identificador único de las áreas del banco 10
AREA Descripción de las áreas LIMA 1
46
Tabla 21: Dimensión productos
Posibles
Valores
Identificador único de los tipos de
CODPRODUCTO 15
producto existentes en el banco
PRODUCTO Descripción de los productos VISA
Tabla 22: Dimensión canal

Posibles
Valores
Identificador único de los tipos de
CODCANAL AVDS
canales existentes en el banco
PdV
CANAL Descripción de canales
Consumo
• Tabla de hechos
Tabla 23: Tabla de hechos de ventas

Regla de
Métrica Descripción agregación
por defecto
Monto totalizado y solarizado de las
MONTOTOTAL SUM
ventas
Cantidades totalizadas de las ventas
CANTIDADTOTAL SUM
dependiendo el producto a medir
Porcentaje de cumplimiento en base a
CUMPLIMIENTO DIV
las metas del funcionario
META Monto totales de las metas asignadas SUM
47
Tabla 24: Características lógicas de los servidores
Servidor Producto
PRESENTACIÓN SharePoint 2010 Enterprise Edition
DWH Oracle 10g
REPORTES SQL Server Reporting Services 2008 / Excel
ANÁLISIS SQL Server Analysis Services 2008
PROCESAMIENTO SQL Server Integration Services 2008
3.5 Fase 5: Diseño físico
• Modelado • Definición • Modelo

Dimensional de nombres Fisico
• Generación
de
sentencias
SQL

Para la elaboración de modelo físico se crearon sentencias SQL para

cada dimensión basándonos en el modelo dimensional. Ver anexo 5.
Este diseño representa el datamart, del cual se extrajo la información
para los reportes.
En la Figura 25, visualiza las relaciones de las tablas; como por ejemplo
se puede observar que una agencia se encuentra en un distrito, el cual está
en una provincia y está en un departamento, el departamento en una región y
la región pertenece a un área. También, otra relación que se puede observar
es que un cliente se encuentra dentro de un segmento.
48
Figura 25: Modelo físico del proyecto
49
3.6 Fase 6: Diseño e implementación del subsistema ETL
•Fuentes de •Extracción, •Flujos de control

Información transformación y •Flujos de data
•Modelo físico. carga de la •Sentencias SQL
•Requerimientos información
finales de los
usuarios

En esta fase se muestran los ETL diseñados en el desarrollo del

proyecto.
El siguiente ETL se elaboró para poder ordenar, validar y centralizar las
fuentes de información, las cuales se encuentra en data warehouse y la carga
de este proceso se realizó y seguirá realizándose todos los días a las 7 am.
En cada proceso de carga de producto se creó lógicas las cuales son
ejecutadas automáticamente y estas son centralizadas teniendo las lógicas de
campaña multiproductos, lo cual se puede observar en la Figura 27. Al término
de este proceso se definió un proceso de envío de correo a todos los
interesados para la confirmación de la población de las tablas de ventas
diarias de los productos, lo cual se podrá observar en la Figura 28.
Para este proceso de centralización de fuentes se realizó en conjunto
con los equipos de productos tomando como bases lógicas creadas por ellos
y lógica creadas anteriormente.
A continuación, se describe a grandes rasgos las lógicas
implementadas en el proceso de ETL.
a) Carga tabla pyme CP CH
En este proceso de ETL, como primer paso se tiene la “carga tabla

pyme CP CH” el cual dentro de este proceso se ejecuta un proceso el
cual limpia las tablas temporales a utilizarse en nuestro stage. Luego
toma de la tabla MD_PRESTAMO de DWH (data warehouse), solo los
50
créditos desembolsados sin considerar créditos hipotecarios y Mi
vivienda con sus tramos. Adicionalmente, como filtro se está tomando
la fecha de rango, el inicio y fin de la campaña con los atributos que se
necesitarán para poder cargar a la tabla final de ventas. Como siguiente
paso, se creó una tabla temporal de todas las solicitudes con los
montos de préstamos según tipo de moneda obteniéndolo de la tabla
MD_SOLICITUDES_MIC de DWH, el cual contiene todas las
solicitudes de los préstamos del banco.
b) Fuente CP_CH
En este proceso de ETL, se tiene un batch el cual tomando las tablas

temporales creadas anteriormente, se cruzan con la tabla
MD_DESTIPOFINALIDADCREDHIP_MIC,
DE_ACTUALIZASOLICITUDVENTA y MD_CAMPANIA_MIC de DWH
en los cuales se navega para poder obtener campos específicos de las
ventas; además, como filtros se agregaron que el tipo de solicitud solo
sea número 3 y 2, las fechas de rango sean dentro de la campaña y
como flag eliminado igual a “N”.
Luego de tomar toda esta información con los campos necesarios se
realizó una limpieza de información de la tabla creada; por ejemplo se
retiran las solicitudes que se ingresaron previamente a la tabla de
excepciones, que son créditos que fueron solicitados modificar
manualmente, además se retiran las solicitudes con tipo 2 y 3 que no
sean tipo de crédito GAHI (garantía hipotecaria) ni GAPC (garantía para
crédito personal).
Para los subsegmentos privada, enalta y gremio se le asignó un código
de derivador ficticio siempre y cuando el canal sea ADVS (asesor de
ventas) y los créditos no sean GAHI ni GAPC. Para los créditos
vehiculares se asigna el tipo de venta 38 y a todas las solicitudes se
eliminan espacios.
Para los créditos personales se toma todas las solicitudes con los tipos
asignados para créditos personales, además de tomar el rango de
fechas de la campaña y con los montos en soles.
51
Finalmente, se les brinda accesos a las diferentes matrículas de los
equipos de productos.
c) Fuente pyme
Para esta sentencia implementada lo que se realizó, fue el cruce de las

tablas temporales creadas anteriormente y realizando un cruce con
tablas de DWH como por ejemplo MD_CAMPANIA,
MD_DESPRODUCTOSOLICITUD, MD_EMPRESA_MIC y
DE_ACTUALIZACIONVENTA se extrajo solo las solicitudes con los
códigos de 223, 51, 50, 268, 266 y 206, para el tipo de solicitud solo los
estados válidos de la campaña.
Luego de esta extracción de información se crearon tablas temporales
para activos fijos, capital de trabajo, tarjeta de servicio y ampliación
TSN. Para cada tabla se realizó una limpieza eliminando los
duplicados, el mismo procedimiento para efectivo preferente pyme
donde se filtró fechas de campaña y se realizó limpieza de repetidos.
d) Fuente_TCA
Para el proceso de carga del producto de tarjeta de créditos

adicionales, lo que se realizó fue tomar de las tablas de DWH
principalmente de la tabla MD_TARJETAADICIONAL_MIC la
información de las adicionales vendidas en el periodo de la campaña
considerando las que no sean “VISA PRIMAX ORO”, “VISA
EMPRESARIAL”, “VISA EDELNOR”, luego se agregaron todas las
cuentas de las tarjetas, se eliminaron los duplicados y se creó una tabla
con las tarjetas que no serán consideradas en la campaña. Finalmente
se brindó acceso de las tablas creadas, para luego actualizar tipo de
venta de las tarjetas y eliminamos los tipos 17, 18 y 32.
e) Fuente TC_AMP
En este proceso la sentencia que se realizó fue la creación de tablas

temporales de todas las tarjetas de crédito que realizaron una
52
ampliación, obteniéndolas de las fuentes de DWH solo los tipos de
solicitud igual a 1 y con la fecha de solicitud dentro de la campaña.
De igual forma que la lógica anterior se actualizó los tipos de venta para
VISA, AMEX y MATERCARD.
f) Consolidar ventas
Como proceso final de centralización de ventas con las tablas

temporales creadas en este paso se le estandariza y obtiene los datos
necesarios de ventas realizando una unión de todas estas tablas según
producto. Luego, se creó una temporal para agregar las cantidades y
montos según fuentes de información, tanto tablas temporales como
tablas compartidas por productos.
Figura 27: Data flow / centralización de fuentes

Como resultado final se tiene las ventas centralizadas de todos los

productos del banco en la tabla MD_VENTASCMP, el cual fue compartido a
todos los productos luego de su actualización, enviando un correo de
validación con el detalle de las fuentes cargadas y un porcentaje de carga
según inicio de semana al día que se ejecuta el proceso. Ver Figura 28.
53
Figura 28: Script de alerta
En la siguiente Figura 29, tenemos el ETL STG, el cual contiene las

tablas intermedias donde se limpia y da formato a la información para la carga
de las tablas de dimensiones. El motivo por el cual se crea el flujo de carga es
para que la información siempre esté disponible por si hubiera algún
inconveniente con la información.
El flujo comienza limpiando las tablas intermedias para luego poblar la
base de datos con la información de las fuentes, el proceso corre en paralelo
para reducir tiempos de carga.
54
Figura 29: Diagrama carga STG
En la Figura 30, tenemos el ETL de carga DM, el cual sirve para poblar
las dimensiones del datamart. En este proceso lo que se realiza es el cruce
con las tablas intermedias para poder agregar la información nueva que se
genera. Este proceso tiene un inicio en cada una de las tablas de dimensiones
finalizando en la tabla de hechos, realizando un cruce con todas las
dimensiones para poder poblarla con la nueva información.
Figura 30: Diagrama carga DM

55
3.7 Fase 7: Especificación y desarrollo de aplicaciones de BI
•Aplicaciones de •Identificación de •Reportes

BI roles y perfiles de Específicos
•Requerimientos usuarios
finales de los •Construcción de
usuarios resportes

Para la realización de esta fase se seleccionó los tres productos que se

utilizarán:
a) SQL Server 2008

b) SQL Server Business Intelligence Development Studio
c) Excel - Power Pivot
Tomando en cuenta la identificación de roles y perfiles se clasificó la
visualización de la información de la siguiente manera:
• Área de división comercial: Podrán visualizar los reportes realizados:
seguimiento de funcionarios por producto, avances de agencias por
producto, ranking.
• Gerentes de agencias: Podrán visualizar los reportes de avances de
ventas de los funcionarios de cada agencia por producto.
• Equipo de productos: Podrán visualizar los reportes realizados:
resultados totales de producto por campaña.
• Equipo Inteligencia Comercial Banca Minorista: Acceso total a la
información, para poder crear, editar reportes según sea el caso.
Los reportes realizados son los siguientes:

• Resultados totales:
En este reporte se tiene una vista general de las ventas activas por
área, por canales (áreas comerciales, centro de contacto, fuerza de
ventas).
56
Esta vista muestra el nivel de cumplimiento con respecto a la meta
asignada, mediante esta vista, el área de división comercial podrá
darles seguimiento a las diferentes áreas y canales, las cuales se
realizan las ventas de los productos a los clientes.
Figura 32: Resultados por áreas

Figura 33: Resultados por canales % de ventas

Figura 34: Resultados por canales centro de contacto

57
Figura 35: Resultados por canales fuerza de ventas
• Reporte venta efectiva por agencia:
Este reporte muestra las ventas a nivel agencia, también se puede

visualizar un cumplimiento por cada mes de la campaña, un promedio
y la meta de cada mes. En cada mes se tiene un semáforo donde se
visualiza si la agencia cumplió su meta durante ese mes o no.
Figura 36: Ventas efectivas por agencia

• Reporte venta efectiva por región:
Al igual que el reporte anterior, este muestra las ventas a nivel región,
donde se puede visualizar un cumplimiento por cada mes de la
campaña, el promedio de la campaña, la meta por mes y también un
semáforo para visualizar los cumplimientos por mes.
58
Figura 37: Ventas efectivas por región
• Reporte venta efectiva por banca:
Este reporte muestra las ventas a nivel Banca donde se puede

visualizar un cumplimiento por cada mes de la campaña, el promedio
de la campaña, la meta por mes y también un semáforo para visualizar
los cumplimientos por mes.
Figura 38: Venta efectiva por banca

• Reporte ranking agencias:
Este reporte muestra en orden descendente el porcentaje de ventas

efectivas del mes y también un promedio de ventas por CMP, listando
59
todas las agencias que hay en el banco, junto con su código y área de
ubicación.
Figura 39: Ranking agencias

3.8 Fase 8: Implementación
•Procesos ETL. •Revisión de •Carga del

•Reportes procesos ETL reporte en el
Específicos •Revisión de los SharePoint
reportes y
aplicaciones
que se han
utilizado
•Definición de
medios de
entrega

Esta solución se implementó como un piloto para el área de división

comercial y equipo de productos para su validación de la información
mostrada en los diferentes reportes, realizando la comparación con reportes
utilizados anteriormente, para luego poder desplegarlo a las agencias, así
ellos podrán realizar los seguimientos por funcionario. Según el listado de
60
requerimientos solicitados se generó un dashboard, de este mismo se
extrajeron las siguientes vistas para la validación de los requerimientos.
Cumpliendo con el Req. 1, en la Figura 41Error! Reference source
not found., se puede observar las ventas totales realizadas en las campañas
multiproductos divididos por mes y trimestre.
Figura 41: Ventas totales

Cumpliendo con el Req. 2, en la Figura 41 y la Figura 42, se puede

observar las ventas que se realizaron por el canal ADVS y BEX
respectivamente durante cada trimestre y mes.
Figura 42: Ventas por canal ADVS

61
Figura 43: Ventas por el canal BEX
Cumpliendo con el Req. 3 y Req. 4, se realizó una vista donde el

gerente de agencia tiene la lista de los funcionarios a cargo con su nivel de
cumplimiento de ventas en porcentaje, además del cumplimiento total de la
agencia como se muestra en la Figura 43.
Figura 44: Cumplimiento por funcionario a nivel agencia

Cumplimiento con el Req. 5, se realizó una vista donde se muestra las

ventas por producto a nivel funcionario, en ella se muestra la relación de todos
los funcionarios y el canal asignado, también su nivel de cumplimiento, venta
realizada y meta por cada uno de los productos del banco. Tener en cuenta,
62
que se mostrará información en caso que el funcionario asignado a un canal
pueda realizar la venta del producto. Como se puede observar en la Figura
44.
Figura 45: Cumplimiento por producto a niveles funcionario

Cumpliendo con el Req. 6, se trabajó una vista ranking por funcionario

a nivel Área y Región para obtener el funcionario que más ventas obtuvo
durante cada campaña. La vista se puede visualizar en la Figura 45.
Figura 46: Ranking por funcionario a nivel agencia

Cumpliendo con el Req. 7, en la siguiente Figura 46, se trabajó una

vista donde se muestra el cumplimiento por ventas a nivel área y región.
63
Figura 47: Cumplimiento por producto a nivel de área y región
Cumpliendo con el Req. 8, la relación solicitada se tomó en cuenta para

el desarrollo del modelo de datamart.
El reporte realizado se encuentra en el sharepoint de la división
comercial compartido con el equipo de productos; como se visualiza en la
Figura 47.
Figura 48: SharePoint de la división comercial

64
CAPÍTULO IV
PRUEBAS Y RESULTADOS
En este capítulo se detallan las pruebas realizadas y resultados

obtenidos de la implementación de una solución de inteligencia de negocio
para apoyar a la toma de decisiones y poder incrementar las ventas.
Para ello, se logró un acuerdo entre el equipo de inteligencia de negocio
y los usuarios finales (división comercial, equipo de productos y agencias
piloto); este acuerdo consistió en programar los procesos DTS para las cargas
diarias de las fuentes de información de ventas y la generación de información
correspondiente para el seguimiento diario de las mismas.
4.1 Pruebas
Las pruebas realizadas tuvieron una duración de cuatro semanas,
en las cuales se tuvo un procedimiento para la generación de información con
el cual los usuarios finales pudieron dar seguimiento a las ventas de las
agencias piloto. A continuación, se describe el listado de pruebas realizadas
en el proyecto, con el objetivo de la prueba y las posibles causas de
incumplimiento. Ver Tabla 25.
Tabla 25: Pruebas realizadas

ID NOMBRE OBJETIVO DE PRUEBA POSIBLE INCUMPLIMIENTO
DE PRUEBA
1 Carga de Poder validar la carga de los registros Posibles diferencias en
Datos en la base de datos cantidad de registros
65
2 Ejecución Validar la ejecución correctamente de Posibles errores en el DTS
ETL los DTS realizando una ejecución
incompleta
3 Tiempo Poder reducir los tiempos de carga y Posible incremento en tiempo
ejecución transformación con respecto al tiempo de la
ETL elaboración manual
4 Validación Poder asegurar el correcto enlace Posible error en la información
Datamart entre dimensiones del Reporte
5 Prueba de Poder validar los permisos brindados al Posible error en el acceso por
Acceso Sharepoint de los usuarios indicados el tipo de acceso brindado
6 Prueba de Poder validar la información que se Posible desfase en montos o
Pares muestra con respecto al anterior totales con respecto al reporte
reporte garantizando la información manual
mostrada en el DASHBOARD
Adicionalmente, detallamos el procedimiento que se siguió durante

el despliegue. El procedimiento es el siguiente:
• El equipo de data warehouse carga diariamente las fuentes de información
de los productos; este proceso se realiza a las 4am y se obtiene
información de los aplicativos a un T-1.
• El equipo de inteligencia comercial programó los DTS de centralización de
fuentes, carga de tablas intermedias y finalmente la población del
datamart. De esta forma se probaron las primeras corridas manualmente
mostrando la ejecución correctamente de cada DTS, tanto para las tablas
intermedias como para la actualización de las tablas dimensionales y
finalmente, la Fact Table.
Figura 49: Data Flow Centralización

66
Figura 50: Carga STG
Figura 51: Carga DIM

• El DTS de centralización de fuentes tiene lógicas por producto para poder

estandarizar y cargar en una sola fuente las ventas generadas; en este
flujo de datos se agregó una alerta de las cargas de productos, la cual
actúa enviando un correo a todos los involucrados indicando que la carga
ha sido o no satisfactoria. Si el correo indica que no fue satisfactoria, este
a su vez indicaría la fuente errada; de esta manera se comprueba que el
job y el correo final de alerta programado esté corriendo correctamente.
67
Figura 52: Correo de validación de fuentes
• Luego de la centralización de fuentes, el siguiente DTS de carga de tablas

intermedias, al tener la información ya validada procede a la actualización
de la información por cada dimensión sin perjudicar la disponibilidad de la
información del datamart.
• Finalmente, el flujo de datos de la actualización del datamart procede a
agregar la nueva información diaria obtenida y así los usuarios finales
puedan darles seguimiento a las ventas de los productos.
Luego de realizar las pruebas funcionales, se confirman los
requerimientos de los usuarios mostrando su atención. Ver en la Tabla 26.
Tabla 26: Requerimientos atendidos

REQUERIMIENTOS ATENDIDO
Req. 1: Se requiere visualizar las ventas
Este requerimiento fue atendido en la
trimestralmente en un rango de un año y por
Error! Reference source not found.41
meses.
Req. 2: Se necesita que se muestre el Este requerimiento fue atendido en las
avance de ventas de los canales por mes y Error! Reference source not found.41 y
trimestre. Error! Reference source not found.42
Req. 3: Se requiere que las ventas se midan
en base a la meta presupuestada indicando Este requerimiento fue atendido en la
el porcentaje de cumplimiento obtenido por Error! Reference source not found.43
el funcionario.
Req. 4: Se necesita visualizar las ventas Este requerimiento fue atendido en la
realizadas por agencias totalizando las Error! Reference source not found.43
68
metas asignadas a cada funcionario, de esta
forma obtener un cumplimiento por agencia.
Req. 5: Se requiere tener el detalle de
productos vendidos por funcionario, además
del porcentaje de ventas por producto.
Req. 6: Se necesita obtener un ranking de
los mejores vendedores según ventas Este requerimiento fue atendido en la
totales que muestre a que área y región Error! Reference source not found.45
están asignadas.
Req. 7: Se requiere tener el porcentaje de
cumplimiento de ventas a nivel de área y
región.
Req. 8: Se requiere que se tenga en cuenta
que cada funcionario pertenece a una
agencia y la agencia pertenece a un Este requerimiento fue atendido en la
departamento, las cuales están agrupadas Error! Reference source not found.47
en regiones y a su vez cada una de estas
pertenecen a un área.
4.2 Resultados
Como parte de la implementación del datamart, se obtuvo una
reducción de tiempos y errores de las fuentes de información de ventas.
Como se comentó anteriormente, los tiempos de carga y validación
de las fuentes de información generaba una carga laboral de 7 horas y 3
recursos semanalmente para la realización de estos procesos, los cuales se
trabajaban de forma manual, pues cada fuente de información era depositada
en una ruta compartida distinta.
Cabe indicar que se realizó un análisis y evaluación de la
información al 100%, por lo cual se procedió a transferir las cargas a data
warehouse y la realización de un flujo de datos (ETL) para la centralización de
las fuentes, el cual redujo la carga laboral a 30 minutos en promedio sin ningún
recurso, tal como se muestra en la Tabla 27.
Tabla 27: Tiempo de carga y validación de la información

CARGA TIEMPO DE
PROCESO TIEMPO RECURSOS
LABORAL ELABORACIÓN
ANTES 7 horas 3 88% 100%
AHORA 0.5 horas 0 6% 7%

69
Adicionalmente, para el proceso de validación manual de las
fuentes de información se logró mitigar los errores reduciendo en un 50% con
respecto al proceso anterior, como se puede observar en la Tabla 28, donde
se muestra el número de errores que se tenía al cargar la información
semanalmente contra la carga diaria automática.
Tabla 28: Validación por mes

PROCESO #
# ERRORES X
DE VALIDACIONES %
MES
VALIDACION X MES
ANTES 4 2 50%
AHORA 22 0 0%
Y con respecto a la mejora de elaboración del dashboard, como se

puede visualizar en la Tabla 29Error! Reference source not found., antes
se realizaba un dashboard manualmente tomando un tiempo de 60 minutos,
lo cual con la implementación de la solución de negocio y la mejora del
dashboard, ese tiempo se redujo a 10 minutos, dándonos un 83% de
disminución en los tiempos.
Tabla 29: Elaboración del dashboard
ELABORACIÓN DEL
TIEMPO RECURSOS %
DAHSBOARD
60
ANTES 1 100%
minutos
10
AHORA 1 17%
minutos
Para el seguimiento de las ventas se tiene información disponible

diariamente a un T-1, el cual favoreció para que la División Comercial, equipos
de productos y gerentes de agencia, tengan un continuo y correcto
seguimiento de los funcionarios durante las cuatro semanas de pruebas; en
ellas se dio un incremento en las ventas de las agencias piloto.
70
En la Tabla 30, se observan las ventas realizadas por mes del
último trimestre de las agencias piloto, de las cuales para obtener el
incremento de las ventas se calculó la variación por mes de los últimos dos
meses y este cálculo se dividió con el último mes. Como se puede observar,
en este último, donde se realizó la implementación de la solución de
inteligencia de negocio, es de un 6%.
Tabla 30: Incremento de las ventas

3er Trimestre Incremento
AGENCIA
JULIO AGOSTO SEPTIEMBRE SEP/AGO
AGENCIA
287 270 279 3%
PILOTO 1
AGENCIA
102 164 181 10%
PILOTO 2
TOTAL
389 434 460 6%
VENTAS
Para realizar un análisis de las ventas totales de cada agencia

piloto, se muestra a continuación, los detalles por mes y por trimestre de cada
agencia piloto.
En la Tabla 31, se puede observar las ventas realizadas desde el

mes de enero hasta el mes de septiembre, con su respectiva meta y
cumplimiento del mes. Además, se puede analizar lo siguiente: al inicio de
cada campaña se genera una meta según las ventas realizadas en los
históricos. Se pudo observar que durante el cierre de la última campaña y
algunas suposiciones por parte del equipo de planeamiento comercial, la meta
se incrementa o disminuye al igual que las ventas.
Para el mes de pruebas a pesar de que la meta disminuye teniendo

un seguimiento diario de las ventas, estas aumentan sin seguir el mismo
patrón anterior.
71
Tabla 31: Ventas totales - CC. Camino Real
PERIODO VENTAS META CUMPL.

1er Trimestre 79 116 68%
Enero 25 45 56%
Febrero 22 35 63%
Marzo 33 37 89%
2do Trimestre 495 293 169%
Abril 95 73 130%
Mayo 172 107 161%
Junio 227 113 201%
Julio 287 160 179%
Agosto 270 148 182%
Septiembre 279 122 229%
Total general 1,410 839 168%
Para entender mejor lo relatado anteriormente, se puede observar

la Figura 53, la cual muestra las ventas totales de la agencia piloto 1 - CC.
Camino Real, la reducción de las metas y las ventas descritas en la tabla
anterior.
Figura 53: Ventas totales - CC. Camino Real

Al igual que en la agencia anterior se puede observar la información

de la agencia piloto 2.
72
Tabla 32: Ventas totales del CC La Rambla
PERIODO VENTAS META CUMPL.
Enero 17 52 32%
Febrero 16 47 33%
Marzo 36 75 48%
2do Trimestre 209 278 75%
Abril 75 87 86%
Mayo 67 104 64%
Junio 67 86 78%
Julio 102 120 85%
Agosto 164 148 111%
Septiembre 181 118 153%
Total general 724 837 86%
Para la Tabla 32, también se mostrará su respectivo gráfico.
Figura 54: Ventas totales - CC. La Rambla

73
CAPÍTULO V
DISCUSIÓN Y APLICACIÓN
5.1 Discusión
En el área de planeamiento comercial banca minorista se
realizaban reportes manuales para llevar un control de las ventas. Para la
realización de estos reportes, existía una demora de 7 horas utilizando 3
recursos, el cual se realizaba semanalmente con un desfase de 1 semana,
por lo cual al no tener información actualizada la división comercial, equipo de
productos y los gerentes de agencia, no tenían un correcto seguimiento de las
ventas para poder tomar decisiones inmediatas y así incrementarlas llegando
a la meta mensualmente, pues no contaban con una solución de inteligencia
de negocio, es por eso que solo hacían seguimiento al cumplimiento
esperado.
Como se demostró en el capítulo anterior, se brindó información
actualizada, sin errores y un dashboard rediseñado. Se logró apoyar a la
gestión de ventas para su incremento, obteniéndose un 6% en promedio en
el último mes de la campaña multiproductos para las dos agencias piloto
donde se realizaron las pruebas; por lo cual, al realizar una comparación entre
una agencia sin el seguimiento diario y una agencia piloto, se obtienen los
siguientes resultados:
a. Para la agencia piloto 1, según lo explicado en el capítulo
anterior, el comportamiento normal de las metas se incrementa
o disminuye al igual que las ventas; pero esto no pasa con las
74
agencias piloto; ya que no siguen el mismo comportamiento,
pues al tener una menor meta según el comportamiento que se
tiene históricamente, las ventas deberían de disminuir; pero al
tener un seguimiento diario y con información a un T-1, se
puede observar el incremento de las ventas. Ver Figura 55.
Figura 55: Agencia piloto con seguimiento diario

Para un mejor entendimiento, se tomó como referencia una

agencia con las mismas características y comportamientos que
tienen las agencias piloto. Por ejemplo, ventas en crecimiento,
ubicación en un centro comercial y años de vigencia similar.
Así podemos observar que para esta agencia, el patrón
descrito anteriormente se llega a cumplir y se puede apreciar
con mayor énfasis en el último mes. Ver Figura 56.
Figura 56: Agencia sin seguimiento diario

75
b. Adicionalmente, para poder confirmar estos incrementos
obtenidos se realizó un análisis por canales para las
agencias pilotos, seleccionando un canal diferente para
cada agencia y poder validar los resultados obtenidos. En la
siguiente Figura 57, se puede observar la agencia piloto 1,
con las ventas por el canal ADVS realizadas por mes y
trimestre. Aquí se observa el crecimiento en las ventas para
el mes de pruebas (setiembre).
Figura 57: Ventas por canal ADVS - CC. Camino Real

De la misma forma se extrajo la información para la agencia

piloto 2. Se mostró las ventas por el canal BEX realizadas
por mes y trimestralmente y se pudo observar que realizando
un seguimiento diario y con información actualizada se logra
incrementar, tal como se observa en la Figura 58.
Figura 58: Ventas por canal BEX - CC. La Rambla

76
c. Para observar el incremento obtenido según el seguimiento
realizado por el equipo de producto con la solución de
inteligencia de negocio implementada, se visualiza también
un crecimiento a pesar de asignar una meta menor para el
producto crédito personal en la agencia Piloto 1. Ver en la
Figura 59.
Figura 59: Ventas crédito personal - CC. Camino Real

d. Se realizó un análisis de la misma forma con la agencia que

no forma parte del piloto; se obtuvo los resultados que se
explicó anteriormente; se le asignó una meta menor pues se
esperaba ventas menores. Esto se puede observar en la
Figura 60 sobre las ventas realizadas para el mismo
producto de la agencia piloto 1, mostrando una caída.
Figura 60: Ventas de crédito personal - CC. Multiplaza

77
e. Con respecto a los objetivos logrados durante la
implementación de la solución de inteligencia de negocio
para las cargas diarias, se puede visualizar en la Figura 61,
que son ejecutadas todos los días satisfactoriamente, así se
puede demostrar que los tiempos de elaboración de carga y
validación se redujeron en un 93%.
Figura 61: Ejecución de carga y validación diaria

En la Figura 62Error! Reference source not found., se visualiza

la información que es enviada diariamente a todos los usuarios involucrados
validando la fecha de actualización de las fuentes de información.
Figura 62: Correo de validación de fuentes

Elaboración: los usuarios
78
5.2 Aplicaciones
Las aplicaciones realizadas luego de la implementación del

datamart, para poder brindar apoyo a la gestión de ventas se muestra en la
Figura 63.
Figura 63: Dashboard de ventas

5.2.1 Ventas dirigidas
En esta pestaña se puede ver el historial de ventas por mes y

trimestre; además, se puede seleccionar el canal para poder visualizar las
ventas por Área y si uno selecciona el producto puede ver el historial del canal
con el producto seleccionado y su evolución de ventas.
5.2.2 Ventas por Área y Región
En esta pestaña uno puede visualizar la información a nivel

de área y región. Al seleccionar el área los gráficos se actualizan; también se
puede seleccionar la región y el mes que desea ver la participación de
mercado a nivel de canal y área.
79
5.2.3 % Cumplimiento por Agencia
En esta pestaña uno puede navegar seleccionando la

agencia, mes y vendedor, el cual mostrará el cumplimiento total de agencia,
así como por funcionario y mes.
5.2.4 Ventas por Departamento
En esta pestaña se puede ver mes a mes a nivel de

departamento y el nivel de cumplimiento por canal.
5.2.5 Ranking
En esta pestaña se puede ver en forma descendente el nivel

de cumplimiento de todos los funcionarios y se puede seleccionar el mes.
80
CONCLUSIONES
1. Se logró mejorar la gestión de ventas e incrementarlas dentro de las

campañas de multiproductos de un banco, realizando una interfaz
amigable, de fácil navegabilidad, diseñado para mostrar información
relevante y actualizada.
2. Mediante la implementación de un datamart que contenga la
información de ventas se logró reducir los tiempos en el proceso de
carga, obteniendo una reducción en un 93%. De igual manera se
obtuvo una reducción de errores en el proceso de validación, con lo
cual se llegó a obtener un 0% en errores.
3. Mediante la mejora de la elaboración del Dashboard para la gestión de
ventas, se obtuvo una reducción de tiempos en un 83%.
4. Se redujo los tiempos de carga y validación de la información.
81
RECOMENDACIONES
1. Continuar con el seguimiento durante una campaña completa para así

validar el crecimiento real por campaña.
2. Ampliar la muestra de número de agencias piloto con diferentes
características y perfiles realizando el seguimiento continuo para luego
poder implementarlo a nivel nacional.
3. Realizar un plan de mantenimiento al datamart, para su buen
funcionamiento.
4. Comprar de licencias de herramientas de BI para la explotación de datos,
lo cual facilitaría la consulta desde un móvil para los funcionarios de los
segmentos premium del banco y así obtener un menor tiempo en la
elaboración de reportes.
5. Identificar un nuevo aplicativo para el producto hipotecario, el cual se
desplegará en enero del 2017, se recomienda realizar las gestiones
necesarias en conjunto con el equipo de data warehouse para que sean
los encargados de brindar la fuente de información y no tener interacción
con el aplicativo, como se realizó con los demás productos.
82
FUENTES DE INFORMACIÓN
Bibliográficas
Alcalá, G. C., de Pablos Heredero, C., & Lozano, I. A. (1998). El proceso de
implantación del data warehouse en la organización: análisis de un caso.
Investigaciones europeas de dirección y economía de la empresa, 4(3), 73–
92.
Calderón Gómez, H., Díaz Minguí, M. R., Ariza Nieves, N. J., Giraldo Ardila,
M. J., & others. (2015). Diseño de herramienta de inteligencia de negocios
para apoyar la toma de decisiones del área de ventas de un restaurante
móvil de sushi« Sushi Truck». Recuperado a partir de
http://dspace.poligran.edu.co/handle/10823/759
Cordero, Z. R. V., & Rosa, Z. (2009). La investigación aplicada: una forma de

conocer las realidades con evidencia científica. Revista Educación, 33(1),
155–165.
Fernandez, H. A. F. (2013). Inteligencia de negocios como apoyo a la toma

de decisiones en la gerencia. Vínculos, 9(2), 11–23.
Frade, D. O. A., & Castillo, J. N. P. (2007). Estado actual de las tecnologías

de bodega de datos y OLAP aplicadas a bases de datos espaciales.
Ingeniería e Investigación, 27(1), 58–67.
83
Gómez, A. A. R., & Bautista, D. W. R. (2010). Inteligencia de negocios:
Estado del arte. Scientia Et Technica, 1(44), 321–326.
Olszak, C. M., & Ziemba, E. (2006). Business intelligence systems in the

holistic infrastructure development supporting decision-making in
organisations. Interdisciplinary Journal of Information, Knowledge, and
Management, 1(1), 47–57.
Electrónicas
Altamirano Zelada, J. E. (2015). Análisis, diseño y construcción de un
Datamart para la mejora en la toma de decisiones en la Sección Soporte Mesa
de Dinero de la Oficina Principal del Banco de la Nación. Recuperado a partir
de http://repositorio.unprg.edu.pe/handle/UNPRG/243
Armendáriz, R. N., Urdiales, M. G. V., Corral, J. J. V., Salcido, M. H. T.,

Favela, J. A. A., & Ávila, R. M. L. (2016). Evolución de la inteligencia de
negocios. CULCyT, (57). Recuperado a partir de
http://erevistas.uacj.mx/ojs/index.php/culcyt/article/view/788
Banco de Crédito del Perú. (2016). Recuperado 18 de noviembre de 2016, a

partir de https://www.viabcp.com/wps/portal/viabcpp/nuestro-banco/quienes-
somos
Banco de Crédito del Perú - memorial anual. (2016). Recuperado 18 de

noviembre de 2016, a partir de
https://www.viabcp.com/wps/portal/viabcpp/nuestro-banco/relaciones-con-
inversionistas/informacion-financiera/memoria-anual
Cabanillas, K. G. R., & Peña, A. L. M. (2011). Análisis, diseño e

implementación de una solución de inteligencia de negocios para el área de
compras y ventas de una empresa comercializadora de electrodomésticos.
Pontificia Universidad Católica del Perú. Facultad de Ciencias e Ingeniería.
Mención: Ingeniería Informática. Recuperado a partir de
84
http://www.academia.edu/download/44744923/RODRIGUEZ_CABANILLAS_
KELLER_INTELIGENCIA_NEGOCIOS_ELECTRODOMESTICOS.pdf
Conde Humareda, J. C., & Osorio Sánchez, S. R. (2015). Predicción de la tasa

de venta para rentas vitalicias en una empresa aseguradora. Recuperado a
partir de http://www.repositorioacademico.usmp.edu.pe/handle/usmp/1451
Díaz, M. (2011). Desarrollo de un sistema automatizado basado en

inteligencia de negocios, que integre os procesos administrativos del almacén,
del Supermercado Bello Monte. Recuperado a partir de
http://www.miunespace.une.edu.ve/jspui/handle/123456789/361
Durand Mendoza, A. J. (2014). Desarrollo de un datamart para mejorar la toma

de decisiones en el área de ventas de la corporación Furukawa. Recuperado
a partir de http://repositorio.untecs.edu.pe/handle/UNTELS/100
Espinosa Montiel, C. A. (2013). Guía para implementar una solución BI

(Business Intelligence), caso de estudio Empresa Espinosa & Espinoza.
Recuperado a partir de http://repositorio.puce.edu.ec/handle/22000/6216
Falcón Rodríguez, N. A. (2012). Desarrollo de una solución de Inteligencia de
Negocios en el manejo de estadísticas de control en la venta de repuestos de
la empresa Talleres Ambamazda SA de la Ciudad de Ambato. Recuperado a
partir de http://repositorio.uta.edu.ec/handle/123456789/3008
Farai. (2013). Excel 2013 PowerPivot. Recuperado a partir de

https://lgitsmart.com/2013/11/19/excel-2013-stand-alone-now-includes-
powerpivot/
Garavito Triana, M., Gómez Soto, L. V., López Cadena, O. M., Valencia
Camacho, J. A., Gustavo Adolfo, M. J., & others. (2015). Diseño de
herramienta de inteligencia de negocios para el manejo de la información de
ventas de una empresa comercializadora de productos agropecuarios.
Recuperado a partir de http://alejandria.poligran.edu.co/handle/10823/756
85
García, J. H. M. (2010). La inteligencia de negocios como herramienta para
la toma de decisiones estratégicas en las empresas. Análisis de su
aplicabilidad en el contexto corporativo colombiano. Recuperado a partir de
http://www.docentes.unal.edu.co/hrumana/docs/TESIS_JHMG_Inteligencia_
de_Negocios_2010.pdf
Guerra Tapia, M. W., & Marcillo Cruz, D. A. (2015). Análisis diseño e

implementación de una solución de inteligencia de negocios en la Unidad
Educativa Mundo América. Recuperado a partir de
http://www.dspace.ups.edu.ec/handle/123456789/10338
Hernández, J. G. (2016). Tableros de mando como herramientas de

inteligencia de negocios para la toma de decisiones en el sector bancario
privado. Recuperado a partir de
http://bb9.ulacit.ac.cr/tesinas/publicaciones/Articulo%20Cientifico%20%20Jai
ro%20Gomez%20H%20Revisado%20.pdf
Kimball, R. (2008). The data warehouse lifecycle toolkit. John Wiley & Sons.
Recuperado a partir de
https://books.google.es/books?hl=es&lr=&id=XaUV6r2Xy0IC&oi=fnd&pg=PP
1&dq=The+Data+Warehouse+Lifecycle+Toolkit&ots=H-
v5MQWuCz&sig=2y9fLsGXeUGMO3G8aUFXVT8YNco
Medina, R. P., Sarzosa, E. S., & Barba, A. P. O. (2015). APLICACIÓN DE

INTELIGENCIA DE NEGOCIOS APOYADO EN POWERPIVOT. Recuperado
a partir de http://www.eumed.net/libros-gratis/actas/2016/empresas/msb.pdf
Microsoft. (2016). Reporting Services (SSRS). Recuperado 24 de noviembre

de 2016, a partir de https://msdn.microsoft.com/es-es/library/ms159106.aspx
Minnaard, C., Servetto, D., Pascal, G., & Mirasson, U. L. (2016). Nuevas
dimensiones y métricas en la información para la toma de decisiones:
Aplicación Data WareHouse en Instituciones Universitarias. Revista
86
Iberoamericana de Producción Académica y Gestión Educativa. Recuperado
a partir de http://www.pag.org.mx/index.php/PAG/article/view/448
Novoa, D. (2014). Diseño de un sistema de indicadores de gestión y

desempeño sobre el área de ventas basado en un modelo de inteligencia de
negocios. Gaceta Sansana, 1(1). Recuperado a partir de
http://publicaciones.usm.edu.ec/index.php/GS/article/view/35
Núñez, C. C. (2010). Análisis de los sistemas Business Intelligence y su

aplicación práctica en los proyectos software. Madrid, España: Universidad
Carlos III de Madrid. Recuperado a partir de
http://orff.uc3m.es/bitstream/handle/10016/10658/PFC_BI_FINAL_%20Carm
en_Camara_Nunez.pdf?sequence=1&isAllowed=y
Oña Acosta, D. B. (2013). Estudio y diseño de un modelo de inteligencia de

negocios empresarial y desarrollo de un caso de estudio con la herramienta
Oracle BI. Recuperado a partir de
http://www.dspace.uce.edu.ec:8080/handle/25000/2078
Osorio, E. J. H. (2012). Diseñando un modelo de procesos de inteligencia de

negocios con proceso unificado: Estado de Arte. Recuperado a partir de
http://sites.google.com/site/eherrerao902/PrimeraVersion.pdf
Rivadera, G. R. (2014). La metodología de Kimball para el diseño de

almacenes de datos (Data warehouses). Salta, Argentina: Cuadernos de la
Facultad, (5). Recuperado a partir de
http://www.academia.edu/download/37011190/Metodologia-
Kimball_DWH.pdf
Rojas Zaldívar, A. (2014). Implementación de un Data Mart como solución de

inteligencia de negocios, bajo la metodología de Ralph Kimball para optimizar
la toma de decisiones en el Departamento de Finanzas de la Contraloría
87
General de la República. Recuperado a partir de
http://www.repositorioacademico.usmp.edu.pe/handle/usmp/1061
Sánchez, J. A. R. (2011). Inteligencia de negocios y automatización en la

gestión de puntos y fuerza de ventas en una empresa de tecnología.
Recuperado a partir de http://www.tesis.uchile.cl/tesis/uchile/2011/cf-
recasens_js/pdfAmont/cf-recasens_js.pdf
Sandoval, L. J., & Peña, S. (2015). Herramientas para el diseño de sistemas

de gestión del conocimiento basadas en inteligencia empresarial. Revista
tecnológica.(2014), 7 (1), 7-13. Recuperado a partir de
http://www.redicces.org.sv/jspui/handle/10972/2534
Soto, J. A. M. (2010). Business Intelligence. Teoría y conceptos. Recuperado

a partir de http://www.gestiopolis.com/business-intelligence-teoria-y-
conceptos/
Tacco Meléndez, J. C. (2015). Implementación de una solución de inteligencia

de negocios (BI) para el módulo de ventas de claro utilizando la herramienta
pentaho. Recuperado a partir de
http://dspace.udla.edu.ec/handle/33000/4692
88
LISTA DE ANEXOS
Página
Anexo 1: Organigrama BCP 90
Anexo 2: Organigrama banca minorista y gestión de patrimonios 91
Anexo 3: Proceso de generación de metas 92
Anexo 4: Proceso de carga y generación de fuentes de información
CMP 93
Anexo 5: Proceso de verificación de metas 94
Anexo 6: Cronograma del proyecto 95
89
ANEXOS
Anexo 1: Organigrama BCP

D. Cumplimiento
Directorio Corporativo
B. Falero
D . Auditoría
J. Esposito
A. Cumplimiento A. Gestión de
Gerencia General PLA FT
A. Cornejo
Cumplimiento
E. Dedekind
A. Aud itor ía de A. Aud itor ía
Pro cesos Continua y D.Corp. W. Bayly
C. Martínez L. Loayza BCP Bolivia
M. Trigo
D. Asuntos D. Gest. y Des. D. Legal y G. Central de Riesgos

D. Eficiencia
Corporativos Humano Secretaría General R. Llosa
Diego Cavero
P. De la Flor B. Sambra G. Morales
A. Gestión de A. Transparencia A. Selección, D. Administración D. de Riesgos

A. Gestión del con el cliente y Aprend., Procesos y A. Asesoría L egal de Riesgos D. de Créditos Banca Minorista
Eficiencia y P. Miñán
Talento Co rp. Productividad Eventos Bienestar H. Calero H. Marcenaro M. Torres
U. Alvarez M. Moya P. Fost er C. Sulópulos
A. Gestión del A. Adm. Riesgos A. Créditos Banca A. Créditos Bca. A. Riesgos
A. Asesoría e n A. Unidad es de Op. y G estión
A. Aná lisis y Gob. Programa de Corporativa Empresa S. Isidro Consumo
Eficiencia GyDH Leg ales de Seg uros
Estr até gico de Inf. M. Salsi A. Franco J. Gómez T. Llosa
P. Correa G. Ledesma K. Loncharich
D. Saenz
A. Plan eam. de A. Secretaría A. Créditos Bca. A. Ctas Especiales A. Riesgos P YME
Emp. OP, Bcos y y Sgto de Créditos y Pr eci os Minorista
Compensaciones Gen eral Corp. del Ext.
M. Bojórquez M. Bottger A. Gavilano C. Arias E. Vicente
G. Central de G. Central de Banca G. Central de Banca G. Central de Ops.,

Minorista y Gestión de
Planeamiento y Fin. Mayorista Patrimonios Sistemas y Adm.
F. Dasso P. Rubio G. Ferrari J. Ramírez del Villar
D.D.Contabilidad
Contabilid ad D. Banca D. Gestión de D. Comercial D. Banca D. Clientes
D. Sistemas
General
Gen eral Empresarial Patrimonios L. Derteano
Personas Contentos J. Ortiz
J.J.L.L.Muñoz
Muñoz L.A. Carrera E. Montero C. Casabonne F. Raff o
D. Tesorería A.Ban ca Empre sas A.Ban ca A. Planeamiento A. Centro de A. Infra estructura y

Financiero y A. Ban ca Privad a A. Comercial L1 A. Medios de Pago y A. de Ope raciones
A. Figuerola Lima I Corpor ativa Financ. al Consumo InnovaCXión Ope raciones de TI
Comercial P. Dibós M. Bustamante B. Castro S. Luperdi
P. Zaván M. Baca M.P. Ruiz C. Herrera
A. Gestión del A. Ban ca de A. Asesoría d e A. Transfo rmació n A. Arq uite ctura y A. Cobran za
A. Ban ca A. Ser vicios p ara A. Comercial L2 A. Pro d. Transac.,
Bala nce Aho rro e Inversión de la Experien cia
Empresas Lima 2 Empresas Negocios Patrimonio s del Cliente Está ndare s de TI Ban ca Minorista
P. Hurtado P. Macarachvili J. Jenkins
M. Del Mar E. De la Fuente J. Ichazo B. Ghio R. Rossi L. Almandoz
D. Planeamiento y A. Bancaseguros y A. Marketing y A. Ingenie ría y A. Créditos B anca

A. Ban ca A. Negocios A. Ena lta A. Comercial L3 Experie ncia d el
Control Financiero A. Ban ca Pyme Crédito Vehicular Desarrollo de TI Minorista
Empresas Lima 3 Inte rnac. y Le asi ng V. Chiappe M. Iberico D. Lindley Cliente
C. Ríos A. Del Solar A.L. Jáuregui R. Cigüeñas V. de Rivero
A. Corzo A. Arredondo
A. Negocios A. Gestión de A. Gestión y Transf.
A. Plan eamiento A. Comercial P1
A. Bca Institucional y Hipotecarios Pro yectos de Procesos
Estr até g. y Pr esu p. BCP Miami F. Muñiz
Bca Emp. Provincias N. Tueros A. Sánchez A. Ast ete
B. Zapata C. St uart
J. Oliveros
A. Aná lisis y A. Comercial P2 A. Admini stración
Control Fin anciero A. Plan. Estratégico E. Benavides L. De la Puente
C. Sanguineti y Desarrollo de Neg.
M. Rivas A. Canale s
A. Aná lisis A. Negociac. de
Financiero y Alterna tivos Compras
Pricing A. Johnson
C. Benavides J. Siu
A. Estr ate gia y A. Centro de
Desarrollo A. Infra estructura
Contacto
Corpor ativo L. Verastegui
M. Roca P. Jiménez
A. Estr ate g. de A. Seg uridad

Inve rs. y Estudios Inte gral para los
Económicos Negocios
J. Marangunich
C.Prieto
A. Relacione s co n BCP Pana má

Inve rsio nistas
G. Cusquen M. Abras
Figura 64: Organigrama BCP

Fuente: Banco de Crédito del Perú
Anexo 2: Organigrama banca minorista y gestión de patrimonios
Gerencia Central de Banca Minorista y

Gestión de Patrimonios
Gianfranco Ferrari
Gerencia de Área
Planeamiento
Financiero y Comercial
María del Pilar Ruiz
Gerencia de Marketing
y Experiencia del
Cliente
Anna Lenka Jáuregui
Gerencia de División Gerencia de División Gerencia de División

de Personas Comercial Gestión de Patrimonios
Eduardo Montero Lionel Derteano Fernando Fort
Gerencia de Área Gerencia de Área Gerencia de Área Gerencia de Área

Centro de InnovaCXión Pyme Banca de Negocios Canales Alternativos
Francesca Raffo César Casabonne Javier Ichazo Arturo Johnson
Figura 65: Organigrama banca minorista y gestión de patrimonios

Fuente: Banco de Crédito del Perú
91
Anexo 3: Proceso de generación de metas
Figura 66: Proceso de generación de metas

92
Anexo 4: Proceso de carga y generación de fuentes de información CMP
Figura 67: Proceso de carga y generación de fuentes de información CMP

93
Anexo 5: Proceso de verificación de metas
Figura 68: Proceso de verificación de metas

94
Anexo 6: Cronograma del proyecto
Figura 69: Cronograma del proyecto

95

TTTTTTTTTTTTTTT

Cargado por

Copyright:

Formatos disponibles

TTTTTTTTTTTTTTT

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TTTTTTTTTTTTTTT

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA Y ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS

IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTELIGENCIA DE

KAREN EVELYN GARCIA ARIAS

EMERSON RENAN ZUBIA PANTIGOSO

NORMA BIRGINIA LEÓN LESCANO

IMPLEMENTACIÓN DE UNA SOLUCIÓN DE INTELIGENCIA

PARA OPTAR POR EL TÍTULO PROFESIONAL DE INGENIERO DE

GARCIA ARIAS, KAREN EVELYN

Karen Evelyn García Arias

Karen Evelyn García Arias

Emerson Renan Zubia Pantigoso

Emerson Renan Zubia Pantigoso

La presente tesis tiene como objetivo realizar una solución de

Este proyecto está basado en la metodología Kimball, tiene cuatro

Palabras clave: Inteligencia de Negocio, Campañas de multiproductos,

This thesis aims to realize a business intelligence solution to provide

This project is based on Kimball methodology, it has four principles,

The implementation of business intelligence solution allowed an

Keywords: Business intelligence, Kimball methodology, multi-products

Actualmente, en el área de Planeamiento Comercial Banca Minorista,

El problema general es la limitada información para la gestión de ventas

El objetivo general es mejorar la gestión de ventas del área de Banca

La justificación practica implica que el área de Planeamiento Banca

La estructura de la tesis denominada Implementación de una solución

El Banco de Crédito del Perú (BCP), inició sus actividades el 9 de abril

El banco tiene cinco gerencias centrales, como se muestra en el Anexo

Figura 1: Participación de mercado 2015

En el área se genera un reporte de seguimiento de ventas para

La inteligencia de negocio BI, “business intelligence”, es una

La inteligencia de negocio es un conjunto de estrategias y

Los primeros sistemas de BI eran herramientas individuales

1.2 Bases teóricas

Las bases teóricas, comprenden los conceptos de inteligencia de

1.2.1 Data Warehouse

El data warehouse, como su nombre lo indica, hace

Un datamart, es un subconjunto de un data warehouse, o

1.2.3 Inteligencia de negocios

“La primera persona en acuñar el concepto de inteligencia

Figura 2: Niveles de toma de decisiones

Inteligencia de negocios, es el arte de extraer la

Figura 3: Sistema de inteligencia de negocios

1.2.4 Metodología de Kimball

La metodología de Kimball, se basa en lo que él denomina

Figura 4: Fases de la metodología Kimball

La metodología de Bill Inmon, es similar a la propuesta por

Figura 5: Metodología Inmon

Oracle BI, es una solución integrada para inteligencia de

1.2.7 SQL Server analysis services (Ssas)

Herramienta que permite crear estructuras de consulta

como origen de datos, (Sandoval & Peña, 2015). En la Figura 6, se puede

Ssas, incluye tres características que ayudan con facilidad

1.2.8 SQL Server integration services (Ssis)

Es una plataforma para construir una integración de datos

1.2.9 SQL Server reporting services (Ssrs)

Reporting Services, es una plataforma de creación de

Figura 8: Reporting services

Los servicios de calidad de datos (DQS), es una nueva