2019 Palacios Navarro

FACULTAD DE INGENIERÍA
Carrera de Ingeniería Informática y de Sistemas
GESTIÓN DE CARTERA DE CLIENTES DE UNA

ENTIDAD FINANCIERA CON QLIKVIEW
Trabajo de Suficiencia Profesional para optar el Titulo

Profesional de Ingeniero Informático y de Sistemas
MIGUEL ENRIQUE PALACIOS NAVARRO
Asesor:
Cecilia Marín Tena de Sebastián
Lima – Perú
2019
ii
Dedicatoria
Gracias a Dios, a mis padres Javier y Mercedes,
a mis hermanos Rosa, Miriam y Carlos, gracias
a ellos alcanzo este objetivo, sin su apoyo no
hubiera sido posible. Y a mi hijo Joaquín, quien
es el motor de cada acción en mi vida y lo que
me motiva a levantarme de cada situación difícil.
Esto va para ellos…

3
ÍNDICE DE CONTENIDOS
INTRODUCCION .............................................................................................. 8
CAPITULO 1. GENERALIDADES DE LA EMPRESA ...................................... 10
1.1 Datos Generales ............................................................................. 10
1.2 Nombre o razón social de la empresa. ............................................ 10
1.3 Ubicación de la empresa................................................................. 10
1.4 Giro de la empresa. ........................................................................ 11
1.5 Tamaño de la empresa. .................................................................. 11
1.6 Breve reseña histórica de la empresa. ............................................ 12
1.7 Organigrama de la empresa. .......................................................... 12
1.8 Misión, Visión de la empresa. ......................................................... 13
1.9 Productos y clientes. ....................................................................... 13
1.10 Premios y Certificaciones ............................................................ 14
1.11 Relación de la empresa con la sociedad. ..................................... 14
CAPITULO II. PLANTEAMIENTO DEL PROBLEMA ....................................... 16
2.1 Características del área en que se participó. .................................. 16
2.2 Antecedentes y Definición del problema ......................................... 17
2.3 Objetivos ......................................................................................... 22
2.4 Justificación .................................................................................... 22
2.5 Alcances y limitaciones ................................................................... 23
CAPITULO III. MARCO TEÓRICO .................................................................. 24
3.1 Marco legal ..................................................................................... 24
3.2 Marco Técnico ................................................................................ 24
3.3 Gestión de Cartera de Clientes ....................................................... 25
3.4 Sistema Financiero Peruano ........................................................... 27
3.5 Business Intelligence ...................................................................... 33

4
3.6 Desarrollo y evolución del Business Intelligence ............................. 35
3.7 Gobierno de Datos .......................................................................... 38
3.8 Customer Relationship Management CRM ..................................... 44
3.9 Metodologías de Gestión de Proyectos........................................... 50
3.10 Diferencias entre las PMBOK y SCRUM...................................... 63
3.11 Metodología de Kimball ............................................................... 64
CAPITULO IV. DESARROLLO DEL PROYECTO ........................................... 69
4.1 Identificación de Stakeholders. ....................................................... 70
4.2 Alcance del Proyecto. ..................................................................... 71
4.3 Diagrama de secuencia lógica del proyecto. ................................... 72
4.4 Equipo y roles ................................................................................. 77
4.5 Cronograma de actividades ............................................................ 79
4.6 Arquitectura de QlikView ................................................................. 80
4.7 Requerimientos a DWH .................................................................. 83
4.8 Desarrollo (DashBoard) .................................................................. 84
4.9 Riesgos y planes de acción post implementación. .......................... 88
4.10 Capacitación a usuarios. ............................................................. 91
4.11 Gestión del conocimiento ............................................................ 92
4.12 Cierre del proyecto. ..................................................................... 93
CAPITULO V. ANÁLISIS Y RESULTADOS .................................................... 94
5.1 Resultados de la implementación del proyecto. .............................. 94
5.2 Conclusiones .................................................................................. 97
5.3 Recomendaciones .........................................................................101
5.4 Referencias bibliográficas ..............................................................102
5.5 Anexos ...........................................................................................104

5
ÍNDICE DE FIGURAS
Figura 1. Mapa de ubicación de la empresa. ................................................................. 11

Figura 2. Productos financieros del Banco Falabella. ................................................... 13
Figura 3. Comunicación a clientes campaña “Ahorros CMR”. ...................................... 18
Figura 4. Diagrama FODA del problema. ...................................................................... 20
Figura 5. Diagrama de Ishikawa del problema. ............................................................. 20
Figura 6. Flujo del proceso de una base para campaña de marketing. ........................ 21
Figura 7. Flujo del proceso de análisis de resultados de la campaña. ......................... 21
Figura 8. Flujo del proceso de análisis de un segmento de clientes............................. 21
Figura 9. Porcentaje Deuda Tarjeta de Crédito por entidad bancaria........................... 29
Figura 10. Saldos Tarjeta de Crédito de la Banca Múltiple. .......................................... 32
Figura 11. Morosidad en Tarjeta de Crédito de la Banca Múltiple. ............................... 32
Figura 12. Morosidad de Tarjetas de Crédito. ............................................................... 33
Figura 13. Pirámide de Gestión de Información. ........................................................... 35
Figura 14. Evolución de BI y Análisis de data. .............................................................. 35
Figura 15. Tendencia Palabras clave Perú 2018. ......................................................... 36
Figura 16. Tendencia Palabras clave Estados Unidos 2018......................................... 36
Figura 17. Roles de especialistas en una estructura de BI. .......................................... 37
Figura 18. Modelo de Identificación de calidad de data. ............................................... 42
Figura 19. Matriz de resultados del estado de calidad de data. .................................... 42
Figura 20. Modelo de Gobierno de Datos propuesto por S. Zatyko.............................. 43
Figura 21. Modelo de Gobierno de Datos propuesta por J. Ladley. ............................. 44
Figura 22. Ciclo de administración de una base de datos de fidelización de clientes. . 49
Figura 23. Elementos de un programa de fidelización de cliente. ................................ 50
Figura 24. Grupos de procesos de la Dirección de Proyectos. ..................................... 52
Figura 25. Estructura de un Proceso PMI. ..................................................................... 53
Figura 26. Interacción de los grupos de procesos. ........................................................ 54
Figura 27. Correspondencia entre Grupos de Procesos y Áreas de conocimiento. ..... 54
Figura 28. Roles dentro de la Metodología SCRUM. .................................................... 59
Figura 29. SCRUM Framework. ..................................................................................... 61
Figura 30. Product Backlog. ........................................................................................... 62
Figura 31. Sprint. ............................................................................................................ 62
Figura 32. SCRUM Vs PMI. ........................................................................................... 63
Figura 33. Generación de Campaña antes de implementación. ................................... 74
6
Figura 34. Generación de Campaña Post Implementación. ......................................... 75

Figura 35. Nuevas funciones Analista Producto. ........................................................... 76
Figura 36. Carga de datos a Base QlikView. ................................................................. 76
Figura 37. Arquitectura QlikView. ................................................................................... 81
Figura 38. Ciclo del QilkView. ........................................................................................ 82
Figura 39. Funcionalidad del QlikView. .......................................................................... 82
Figura 40. Muestra de datos generados por DWH para archivo QVD. ......................... 83
Figura 41. Muestra de Indicadores generados en QlikView. ......................................... 84
Figura 42. Dashboard Integral Falabella. ....................................................................... 85
Figura 43. Dashboard Gestión de Cartera Rapicash. ................................................... 85
Figura 44. Flujo de filtrado de Base por variables de negocio. ..................................... 86
Figura 45. Base seleccionada y exportada a MS Excel. ............................................... 86
Figura 46. Base de clientes según los filtros indicados, exportada a excel. ................. 87
Figura 47. Flujo de Validación de procesos QlikView. .................................................. 90
Figura 48. Modelo de Ficha de Capacitación. ............................................................... 91
Figura 49. Modelo de Base de Gestión de Conocimiento. ............................................ 92
Figura 50. Modelo de Ficha de Cierre de Proyecto. ...................................................... 93
Figura 51. Campaña de reactivación de Cuentas. ........................................................ 94
Figura 52. Campaña Reactivación Tottus...................................................................... 95
Figura 53. Campaña de reactivación por giros de negocio. .......................................... 96
7
ÍNDICE DE TABLAS
Tabla 1: Distribución de la cartera de clientes del Banco Falabella.............................. 26

Tabla 2: Distribución cuentas en Situación 1 (nuevas). ................................................ 27
Tabla 3: Distribución Sistema Financiero Peruano. ...................................................... 27
Tabla 4: Distribución porcentual de productos financieros. ........................................... 28
Tabla 5: Distribución de créditos de consumo por entidad financiera. ......................... 29
Tabla 6: Distribución de créditos en Tarjeta de Crédito por entidad financiera. ........... 30
Tabla 7: Distribución de créditos en efectivo por entidad financiera. ............................ 31
Tabla 8: Número de tarjetas de crédito por entidad financiera. .................................... 31
Tabla 9: Cronograma del Proyecto. ............................................................................... 79
Tabla 10: Cartera de Clientes CMR - Consumos banco. .............................................. 89
Tabla 11: Cartera de Clientes CMR - Consumos Saga Falabella. ................................ 89
Tabla 12: Cartera de Clientes CMR - Consumos Tottus. .............................................. 89
Tabla 13: Cartera de Clientes CMR - Consumos Sodimac. .......................................... 90
Tabla 14: Modelo de Cálculo de Tasa Respuesta de Campaña. .................................. 97
Tabla 15: Comparativo entre herramientas BI. .............................................................. 99
8
INTRODUCCION
El proyecto que desarrollo el Banco Falabella, durante los años 2013 y 2014,
comprendía mejorar la Gestión de Cartera de clientes de la Tarjeta de Crédito CMR, a
la vez de ser más eficientes en la administración de recursos de análisis del área.
Es necesario indicar que gestionar una cartera de clientes de una empresa del rubro
financiero, conlleva a administrar mucha información, de ahí lo importante que dicha
gestión sea oportuna y eficaz. Información como datos del cliente, datos de contacto,
hábitos de pago, los consumos y pagos realizados, entre otros indicadores relevantes
para una adecuada gestión de su comportamiento, de tal forma que se pueda garantizar
su continuidad como cliente, a la vez de asegurar la integridad y actualización de datos.
El objetivo del proyecto que se plasmara en el presente informe, es gestionar

adecuadamente la cartera de clientes, contando con indicadores relevantes,
estratégicos que den un amplio panorama, no solo de la situación actual, sino de los
siguientes meses.
Para lograr este objetivo, fue necesario sostenerlo sobre otros específicos, tal cual es
segmentar la cartera con criterios de consumo, contar con un tablero de gestión, que
permita modular los indicadores que también serán generados y que la combinación de
parámetros nos permita acceder de forma rápida al conjunto de clientes resultantes de
la estrategia definida.
Cabe señalar que la gestión mencionada, abarca la identificación de clientes, para que
a posteriori sean diseñadas campañas comerciales en respuesta a ciertos segmentos
de estos. Es decir, no se profundizará en como son estas campañas o cual es el
tratamiento a cierto perfil de cliente, dado que estos temas son propios de una gestión
posterior relacionados a tópicos de CRM (Customer Relationship Management), pero se
citará algunos ejemplos del impacto que tuvo el proyecto sobre la gestión de algunas
campañas comerciales.
Para poder alcanzar los objetivos indicados, se implementó una solución de análisis de
datos o también llamada explotación de datos, con una herramienta de las denominada
“self service” que sumado al esquema ya existente del Data Warehouse, se obtuvo un
nuevo repositorio actualizado, con nuevos indicadores y de una interfaz más amigable,
intuitiva y potente. Como un alcance adicional del presente trabajo, se mostrará el uso
9
de las herramientas ya indicadas, en este caso el QlikView, y su funcionalidad en la

explotación de data y el tratamiento de esta.
Dentro del documento, se indicará los datos más relevantes y de carácter público de la
empresa, así como el escenario y la forma de administración de la data antes de realizar
el proyecto, para luego indicar las funcionalidades de la herramienta que se desarrolló.
Se dará un soporte procedimental, de gestión y el marco teórico que obedece al

proyecto a fin de demostrar su concepción y desarrollo del mismo.
El presente trabajo comprende en el primer capítulo las generalidades de la empresa,

organigrama, visión y misión, productos financieros, rol de la empresa con la sociedad
entre otros, que nos ayudaran a situarnos en un contexto y entender el giro en el que se
encuentra.
En el segundo capítulo, se mencionará los antecedentes del proyecto, lo que fue el

punto de partida para iniciar la concepción del mismo. Se planteará el problema abordar,
se mostrarán detalles de la casuística a tomar en cuenta, los lineamientos del presente
proyecto y sus objetivos específicos.
Durante el siguiente capítulo, se revisará el marco teórico, se comentará en base a la

experiencia del autor y aportes bibliográficos, temas relativos a Business Intelligence,
Analytics, CRM, metodologías de proyectos referentes.
En el cuarto capítulo, que corresponde al Desarrollo del proyecto, se brindara

información relativa a los stakeholders, cronograma de actividades, procedimientos
modificados, tanto de negocio como procedimentales y la arquitectura que se definió
como solución al problema mencionado anteriormente.
En el último capítulo, se analizará los resultados de la implementación del proyecto,

conclusiones y recomendaciones referentes al desarrollo del proyecto, así como a la
puesta en servicio de la solución.
Por último, es necesario mencionar que la información brindada en el documento, fue

proporcionada por la misma empresa, con ciertos lineamientos de confidencialidad, pero
ajustada para fines académicos, complementada con información pública de la SBS, así
como información recopilada de otras fuentes y la experiencia del autor, quien participo
en la implementación del proyecto.
10
CAPITULO 1. GENERALIDADES DE LA EMPRESA
1.1 Datos Generales

El Banco Falabella forma parte del Grupo del mismo nombre, inicio operaciones en Perú
el 07 de febrero del 2007, después que la Superintendencia de Banca, Seguros y AFP
autorizara la transformación de Financiera CMR a Banco mediante Resolución SBS Nª
760-2007. Cabe mencionar que la Financiera CMR inicio operaciones el 31 agosto de
1996, desde un inicio desarrollo una fuerte ventaja competitiva teniendo al retail
Falabella como su principal aliado. En la actualidad el Retail está integrado por Saga
Falabella, Hipermercados Tottus, Sodimac y Maestro. Por medio de esta ventaja el
banco puede acceder a ser el canal de pago para campañas exclusivas de las
mencionadas tiendas.
En la actualidad con casi 1.4 millones de clientes en Perú es uno de los bancos con
mayor colocación de tarjetas de crédito en el mercado, siendo su principal producto la
tarjeta de crédito CMR. Además, el banco tiene presencia en países como Chile,
Colombia y Argentina.
1.2 Nombre o razón social de la empresa.

La razón social es el nombre oficial y legal por el cual es conocida una empresa. Es la
que aparece en toda documentación oficial. Así mismo el RUC (Registro único de
contribuyente) es el código entregado por la Superintendencia Nacional de Aduanas y
de Administración Tributaria (SUNAT). En el caso del banco, ambos datos son los
siguientes:
Razón Social: Banco Falabella Perú S.A.
RUC 20330401991
1.3 Ubicación de la empresa.

En noviembre del 2018 las instalaciones de las oficinas principales del banco, se
trasladaron del Centro Financiero de San Isidro hacia San Borja. Siendo su actual
dirección:
Calle Carpaccio 250 (pisos 4,8,9,10 y 12) San Borja, Provincia de Lima, Departamento
de Lima, Perú.
Los números de teléfono de la central telefónica, así como la página web, se indican a
continuación.
11
Teléfono (511) 01 – 6180000
Dirección WEB www.bancofalabella.pe
Figura 1. Mapa de ubicación de la empresa.
Fuente: Google maps (07 de marzo de 2019). Banco Falabella. Lima, Perú. Recuperado
de https://goo.gl/maps/djVb96EbkMn.
1.4 Giro de la empresa.
El Banco Falabella, es una entidad financiera, dentro del grupo Banca Múltiple. Al 31
diciembre del 2018, el banco mantiene el 11° lugar en depósitos, mientras que en
colocaciones se ubica en el 10° lugar, así mismo en patrimonio se sitúa en el 9° lugar.
1.5 Tamaño de la empresa.
El Banco Falabella está considerado como uno de los principales operadores financieros
en cuanto se refiere al número de tarjetas de crédito colocadas en el sistema financiero,
siendo a diciembre del 2018 el líder en número de tarjetas emitidas con un 1.4 millones
de tarjetas, con una participación del mercado del 22%.
Al informe del 31 diciembre 2018 de la SBS, mostramos los siguientes indicadores: el

patrimonio del banco Falabella asciende a S/755 millones, superior en un 3.6% respecto
al cierre del ejercicio 2017.
Tiene al cierre del año 2018, a 2290 empleados (incluyendo gerentes y funcionarios),
así como 68 centros de atención a los clientes, distribuidos entre Lima y provincias.
12
Registro una utilidad neta en el ejercicio del 2018 superior a los S/. 67 millones (inferior
en 6.7% respecto al margen del cierre del año anterior).
1.6 Breve reseña histórica de la empresa.
Banco Falabella inició operaciones como Financiera CMR el 31 de agosto de 1996.

Teniendo como principal aliado al retail Falabella en un inicio solo Saga Falabella y
posteriormente Hipermercados Tottus, Sodimac y Maestro, entre los principales
miembros del grupo.
La ventaja competitiva de Financiera CMR fue el acceso de sus clientes a ofertas

exclusivas a través de la Tarjeta CMR.
En febrero del 2007 se transformó en Banco y modificó sus estatutos, adoptando la

denominación de Banco Falabella Perú S.A. Recibió la autorización de funcionamiento
el 11 de junio del mismo año, mediante Resolución SBS N° 760 – 2007. Su constitución
consta inscrita en la Partida Electrónica N° 11006610 del Registro de Personas Jurídicas
de Lima.
Banco Falabella es una subsidiaria de Falabella Perú S.A.A. y pertenece a la

Clasificación Internacional Industrial Uniforme (CIIU) 6519. El objeto de la sociedad es
actuar como empresa bancaria con el fin de promover el desarrollo de actividades
productivas y comerciales en el país, de acuerdo con la Ley General del Sistema
Financiero y del Sistema de Seguros y Orgánica de la Superintendencia de Banca,
Seguros y AFP.
Se adjunta como anexo número 1, un gráfico con la línea de tiempo respecto a la historia
del banco. En ella se podrá observar los principales hitos referenciales de la misma, lo
podrá encontrar en la sección correspondiente a los anexos del documento.
1.7 Organigrama de la empresa.
Se adjunta como anexo número 2, un gráfico respecto al organigrama del Banco

Falabella, lo podrá encontrar en la sección correspondiente a los anexos del documento.
Cabe señalar que la información organizacional descrita del banco, así como la
descripción de sus productos, la fuente de datos es la memoria anual del Banco
Falabella 2017, la página web del banco, así como el conocimiento del autor del
presente documento, dado que laboro en dicha entidad por siete años.
13
1.8 Misión, Visión de la empresa.
Según el documento oficial Memoria Anual 2017 y la página web del Banco Falabella, a
continuación, se indica la misión y visión de la empresa.
Visión
Ser el mejor banco de personas del sistema financiero peruano.
Generando relaciones de largo plazo, a partir de: Ser líderes por nuestra transparencia,
simplicidad, conveniencia y compromiso. Atraer, desarrollar y motivar un equipo de
excelencia, comprometido, colaborativo y apasionado por los clientes. Ser valorados por
nuestro aporte a las comunidades en que trabajamos, en particular por nuestro esfuerzo
en educación financiera.
Misión
Hacer posibles las aspiraciones de nuestros clientes, a través de una oferta integrada
de servicios financieros que supere sus expectativas, potenciada por los beneficios del
“Mundo Falabella”.
1.9 Productos y clientes.
El Banco Falabella cuenta con los siguientes productos, orientados hacia personas
naturales: Siendo el principal producto la Tarjeta de Crédito CMR.
Figura 2. Productos financieros del Banco Falabella.
Fuente: Pagina web Banco Falabella (www.bancofalabella.pe)

14
1.10 Premios y Certificaciones.
Los premios a los que el Banco Falabella ha accedido, son principalmente en temas
referentes a publicidad:
2018: Top Influencers 2018
Reconocimiento a las empresas peruanas con un rol de influencia “influencers”, en

canales digitales.
Campaña Miércoles Gourmet
Categoría Mejor Campaña Banca y Finanzas
Premios Effie:
Reconocimiento a las empresas que han desarrollado una campaña publicitaria

sobresaliente y con objetivos estratégicos alcanzados:
2016: Effie Bronce
Campaña Cuenta Sueldo / CTS
Categoría Servicios Financieros
2015: Effie Plata
Campaña Todos los días descuentos y beneficios
Categoría Relanzamientos
1.11 Relación de la empresa con la sociedad.
El Banco Falabella participa hace 10 años en el programa de ayuda social “Haciendo

Escuela”. El programa busca mejorar el desarrollo académico y personal de cientos de
niños a nivel nacional a través de la educación. Esto mediante cuatro iniciativas:
Educación Financiera: Enseñando buenas prácticas y lo que significa un endeudamiento

responsable, para proteger la salud financiera de la comunidad.
Proyectos de desarrollo local y construcción de redes de cooperación continental: En

conjunto con la Organización América Solidaria, el banco a través de profesionales de
distintos países donde tiene presencia, desarrollan proyectos para mejorar la calidad de
vida de comunidades de bajos recursos.
15
Voluntariado Social: Apoyado fuertemente por sus colaboradores quienes participan en

diversas actividades recreativas en fechas conmemorativas o en la implementación de
diversos talleres en los colegios de Fe y Alegría.
Implementación educativa en Colegios Fe y Alegría: Por varios años, el apoyo realizado

en los centros educativos de Fe y Alegría, han ayudado a implementar diversos talleres,
bibliotecas, salas de cómputo, y otros a nivel nacional. Entre los principales colegios son
Nª 53 Huaycan, Nª 63 Trujillo, Nª 26 San Juan de Lurigancho, entre otros.
16
CAPITULO II. PLANTEAMIENTO DEL PROBLEMA
2.1 Características del área en que se participó.

El proyecto se desarrolló dentro de la gerencia de Inteligencia de Clientes, durante el
año 2013 y 2014, en ese momento conformado por una gerencia, una jefatura y 8
analistas. Su principal función era la de proveer las bases de clientes o potenciales
clientes según la campaña comercial que el Banco Falabella emitiera, estas bases se
ceñían a los lineamientos emitidos por las gerencias de Negocio y Riesgos, así como
presentar informes periódicos de los resultados de las campañas emitidas.
En otras actividades se puede mencionar el análisis de datos del retail Falabella, así
como de la Superintendencia de Banca, Seguros y AFP’s (en adelante SBS), participar
y liderar proyectos relacionados a la gestión de información del banco y retail.
Para el presente proyecto se tomarán en consideración dos funciones específicas:
 La generación de las bases de clientes para campañas de marketing.

 La generación de tableros de control para la gestión de la cartera de clientes.
Cabe mencionar que toda base de campaña que fuera generada por la gerencia de
Inteligencia de Clientes, incluían varias áreas:
 El área de negocio que es el solicitante, por ejemplo, Gestión de Cartera de

clientes de Tarjeta de crédito, sobre el cual nos vamos a enfocar en este
proyecto.
 El área regulatoria, en este caso es la Gerencia de Riesgos, a través de los
lineamientos para prevenir elevar la tasa de morosidad del banco.
 El área de Inteligencia de clientes, que como ya se ha mencionado es el
encargado de generar las bases de campaña.
 El área de Marketing y publicidad, que son los que diseñan la comunicación con
el cliente y debe estar alineado con la base que se genera.
 El área de procesamiento de datos, que son los encargados de generar los
archivos finales de impresión y control.
Es necesario mencionar que, al ser la información del cliente, sensible y regulada, esta
solo es tratada por el área de Inteligencia de clientes y Riesgos. El área de
procesamiento de datos y las demás mencionadas, no tienen una participación directa
en la data, solo se ciñen a la generación de archivos necesarios para la impresión de
17
las comunicaciones y definición de los segmentos a los que serán enviados las
campañas.
2.2 Antecedentes y Definición del problema.
Antecedentes.
A inicios del año 2013, surge la necesidad de fortalecer la marca Falabella, tanto por el
lado financiero con la Tarjeta CMR, como en las ventas del retail. Como ya se ha
mencionado, la ventaja competitiva entre banca y retail, aseguraba promociones de
venta exclusivas para clientes del banco. Era el momento de potenciar esta ventaja. Se
ideo la campaña “Ahorros CMR”, la cual consistía en comunicar a toda la cartera de
clientes los ahorros que habían incurrido por comprar en el retail con la Tarjeta CMR,
durante todo el año anterior (2012).
Uno de los principales inconvenientes fue, la aprobación del proyecto, por la Gerencia
de Sistemas, debido a que este no se encontraba en el portafolio de proyectos a
desarrollar.
De esta forma, el desarrollo del proyecto recae al 100% sobre la Gerencia de Inteligencia
de Clientes, quienes lo realizan exclusivamente con recursos del área. Sin embargo,
esto mostro junto a otros escenarios, la poca reacción que se tenía frente a propuestas
comerciales, que tenían que ser atendidas de forma inmediata dado su alto valor en
oportunidades comerciales y que muchas veces no podían ser atendidas por el área de
TI o la misma Gerencia de Inteligencia de Clientes, dado que se encontraban atendiendo
requerimientos recurrentes del área de negocios.
Es así, que se busca liberar al área de Inteligencia de Clientes, de reportes, generación

de bases de clientes y análisis rutinarios. Y que el esfuerzo se redirija hacia proyectos
de mayor envergadura. A la vez que se vuelva más efectiva y genere conocimiento
aplicable al negocio.
18
Figura 3. Comunicación a clientes campaña “Ahorros CMR”.
Fuente: Información Banco Falabella.
Definición del problema.
El presente proyecto se enfocó en dos funciones del área de Inteligencia de Clientes, la

generación de bases de campaña y el desarrollo de tableros de control que nos ayude
a la gestión de la Cartera de clientes de la Tarjeta CMR.
Es conveniente indicar que cada cliente tiene atributos propios, por ejemplo: edad, sexo,
estado civil, nivel socio económico, rango de ingresos entre otros. Sin embargo, existen
otros atributos que son variables en el tiempo como lo son: su comportamiento crediticio,
hábitos de pago, hábitos de consumo entre otros. Este segundo grupo obedece a un
procesamiento de data para poder ser calculados.
19
Según lo indicado, la definición del problema del presente proyecto es ¿Cómo gestionar
la cartera de clientes eficientemente? Es decir que el área de negocio cuente con
información actualizada de los clientes, a fin de implementar estrategias comerciales
oportunas. Por ejemplo, ¿prevenir la fuga de clientes y fidelizar a la cartera?
Sosteniéndonos en propuestas atractivas del banco hacia los clientes y con campañas
de marketing acertadas y a tiempo.
A fin de terminar de plantear el problema, es conveniente citar algunos puntos:
El área de Inteligencia de clientes, es el único que puede realizar el tratamiento de datos

de los clientes (ampliaciones de líneas de crédito, descuentos en compras para clientes
inactivos) y no clientes (campañas de captación) del Banco Falabella.
El procesamiento de datos es semi automático, usando herramientas de análisis

estadístico como el SPSS (Statistical Package for the Social Sciences), pero limitados
por una extracción de data manual vía SPSS o SQL (Structured Query Language).
El análisis de las áreas de negocio, están supeditadas al envió de los reportes del área
de Inteligencia de clientes para realizar sus propios análisis.
Muchos de los reportes indicados, si bien es cierto cumplen con los parámetros dictados
por el área de negocio, no son versátiles como un Tablero de Control dinámico o
dashboard.
Los reportes enviados pierden vigencia rápidamente, conforme la cartera de clientes se

vuelve más dinámica. Por ejemplo, clientes que entren y salgan de un estado de
inactividad en sus consumos.
A continuación, los diagramas FODA e Ishikawa, que ayudaran en la conceptualización

del problema de forma gráfica, de tal forma que se pueda apreciar claramente en base
al FODA porque se abordó, el problema con esta solución, y los factores que influyeron
en que el problema se presentase, esto último a través del diagrama Ishikawa.
En cuanto al FODA, se puede mencionar, que el área de BI, contaba con el

conocimiento, un DWH implementado y la experiencia de la implementacion de la
herramienta en otra empresa del grupo, pero una capacidad limitada de atención, de
pedidos recurrentes, con poca iniciativa del area de TI, en la generacion de nuevos
esquemas de información, por lo que se opta por una herramienta que brinde el alcance
de las oportunidades, buscando maximisar las fortalezas y reorientar los recursos del
área, hacia funciones que generen mas conocimiento y evitar la rotacion de personal.
20
Problema: Gestión de Cartera inadecuada.
Fortalezas Debilidades
- Conocimiento del negocio financiero y retail - Reportes no versátiles
- Conocimiento técnico - Capacidad operativa limitada
- Conocimiento estadístico - Baja motivación en tareas repetitivas
- Se cuenta con un DWH Falabella - Bases desfasadas (Campañas pierden target)
- Pérdida de know how por rotación de personal
- Proces. semi automático en la generación de bases
- Cuellos de botella, dentro de los procesos de campaña
- Baja respuesta a nuevos requerimientos comerciales
Oportunidades Amenazas
- Se cuenta con gran cantidad de data Sobre carga laboral

- Alto posicionamiento de marca CMR Indicadores de clientes cambiantes
- Posibilidad de alianzas estratégicas Flujo incremental de clientes inactivos
- Referencias de casos similares en el grupo Reportes que pierden vigencia rápidamente
- Existe margen de crecimiento en el market share Variación de indicadores de clientes objetivo
- Ser mas eficiente y liberar carga al equipo BI (time) Poco apoyo en las áreas de TI para crear nuevos indicadores
- Empoderar al área de negocio, incremento operativo
Figura 4. Diagrama FODA del problema.
Fuente: Elaboración propia.
En cuanto al diagrama de Ishikawa, notar la agrupación clasica de Personas, máquina,

materiales, medio ambiente, metodo y medidas (6 M’s), alineadas al escenario del
problema, que nos permite ver que existe una necesidad de hacer las cosas de otra
forma, buscando innovar la metodologia recurrente.
Campañas
Analistas Entorno
Comerciales
Número en aumento De BI - Alta rotación Campañas compra de deuda

Nuevos Formatos Operatividad limitada Cartera altamente dinámica
No planificadas De Negocio – No se involucra Cuellos de botella en BI
Gestión de
Cartera
Inadecuada
Procesamiento clásico Falta de nuevas herramientas Nula generación nuevos indicadores

Reportes Estáticos Procesos semiautomático Indicadores comerciales desfasados
Poco innovador Reportes no versátiles
Herramientas Indicadores
Metodología
de Gestión Comerciales
Figura 5. Diagrama de Ishikawa del problema.

21
Figura 6. Flujo del proceso de una base para campaña de marketing.
Figura 7. Flujo del proceso de análisis de resultados de la campaña.
Figura 8. Flujo del proceso de análisis de un segmento de clientes.
Según lo descrito, el área de Inteligencia de clientes destina recursos para poder cumplir
con la generación de datos y el análisis de los mismos. Muchas veces estas tareas
quedan desfasadas y el análisis se vuelve tardío y precario por la presentación de los
22
informes. Por tanto, es conveniente encontrar la forma de que tareas recurrentes sean
realizadas con procesos automáticos, con reportes que añadan valor y sean lo más
actualizado posible.
2.3 Objetivos.
Dentro de los objetivos que se han definido, está la gestión correcta y oportuna de la
cartera de clientes del Banco Falabella. Para esto se definen los siguientes objetivos:
Objetivo General
Gestionar la Cartera de Clientes, contando con segmentos de clientes e indicadores

actualizados, que ayuden a poder identificar aquellos clientes próximos a caer en
inactividad en un determinado tiempo, así como ofrecer la mejor oferta del banco de
acuerdo a sus características de consumo.
Objetivos Específicos:
Los siguientes:
 Contar con una segmentación de clientes basado en una valoración del

cliente de acuerdo a su potencial y nivel actual de consumo.
 Contar con indicadores de cliente, actualizados que permitan ofrecer una
oferta acorde a las necesidades de este.
 Contar con un Tablero de Gestión, donde se pueda cuantificar ciertos
criterios de selección del analista de negocio, los clientes objetivo y sus
características más importantes.
 Poder seleccionar a estos clientes, de forma rápida y evitar el procesamiento
por parte del equipo de Inteligencia de Clientes, para lanzar campañas de
marketing.
2.4 Justificación.
La identificación oportuna del segmento al que pertenece un cliente, es clave en el

tratamiento de este. Dado que podrá emplearse menor presupuesto en comunicación o
de una oferta específica, antes que cambie de segmento o se encuentre inactivo y
próximo a perderlo.
Las campañas de marketing tienen un costo asociado ya sea física o por email,
contando el recurso de un analista y todo el proceso de desarrollo de la base que ya fue
comentado. Al tener una herramienta que ayude a seleccionar el segmento adecuado,
23
se ahorrara horas hombre en recursos que son limitados y podrá redirigirse para otras
actividades.
Los procesos deben ser automáticos y recurrentes para poder identificar lo antes posible
a aquellos clientes que presentan o ya no una inactividad en compras, este mismo
concepto es aplicado a compras en cualquier formato del retail Falabella. Cabe
mencionar que el Banco Falabella cuenta con un Data Warehouse (DWH), sin embargo,
sumado los tiempos de procesamiento, la data resultante muchas veces deja de estar
actualizada, además dentro del DWH no se encuentran indicadores solicitados por el
área de negocio.
2.5 Alcances y limitaciones.
El presente proyecto solo aplica a la base de clientes del Banco Falabella y dar soporte
a las campañas que podrían iniciarse desde el mismo. No aplica para las campañas de
captación de clientes, dado que esta información no es identificada de forma regular.
El presente proyecto se encuentra limitado por la información proporcionada por el Data

Warehouse del Banco Falabella y los indicadores que hayan sido solicitados por el área
de negocio.
Los segmentos y resúmenes de datos han sido contrastados con los procesos
tradicionales, a fin de validar el procesamiento adecuado de data.
24
CAPITULO III. MARCO TEÓRICO
3.1 Marco legal.
Por el lado de la legislación peruana, el presente proyecto se ciñe a la normativa vigente

de las leyes que enmarcan el sistema financiero, como son:
Ley Nª 26702 – “Ley del sistema financiero y del sistema de seguros y orgánica de la
superintendencia de banca y seguros”
“Publicada el 9 de diciembre de 1996, establece el marco de regulación y supervisión a

que se someten las empresas que operen en el sistema financiero y de seguros, así
como aquellas que realizan actividades vinculadas o complementarias al objeto social
de dichas personas. El objetivo principal de esta ley es propender al funcionamiento de
un sistema financiero y un sistema de seguros competitivos, sólidos y confiables, que
contribuyen al desarrollo nacional. Así como fortalecer y consolidar la Superintendencia
de Banca y Seguros en su calidad de órgano rector y supervisor del sistema financiero
nacional.”
Recuperado de http://www.sbs.gob.pe/publicaciones/normativa-sbs
Ley Nª 29733 – “Ley de protección de datos personales”
“La presente Ley tiene el objeto de garantizar el derecho fundamental a la protección de

los datos personales, previsto en el artículo 2 numeral 6 de la Constitución Política del
Perú, a través de su adecuado tratamiento, en un marco de respeto de los demás
derechos fundamentales que en ella se reconocen.”
Recuperado de https://www.minjus.gob.pe/wp-content/uploads/2013/04/LEY-29733.pdf
Uno de los principales conceptos que se manejan dentro de esta ley es el tratamiento
de los datos personales y a la información de las personas.
3.2 Marco Técnico.
El proyecto se referencia a las ventajas técnicas y del uso que ofrecerá la herramienta
a utilizar para la explotación de datos frente a otras plataformas de Business Intelligence.
Una de las principales ventajas que se tomara en cuenta es que el uso final de la
herramienta no sea dirigido hacia un usuario experto, a diferencia de plataformas de
Business Intelligence de Oracle, SQL, entre otros. Se busca que un usuario no
25
especializado, pueda desarrollar sus propios análisis y resúmenes de datos (self

service).
Basado en la experiencia de profesionales del área de inteligencia de clientes, es

necesario indicar, que los tiempos de respuesta a los pedidos de información cada vez
son más cortos por parte de las áreas de negocio. La necesidad de tener información
actualizada no es un requerimiento sino una necesidad. La misma que un Data
Warehouse ya no es capaz de responder, sumado a eso el cálculo de nuevos
indicadores relevantes para el negocio. En este caso lo mencionado es relevante para
identificar los segmentos de la cartera de clientes que se necesite.
Por ello se busca una herramienta que sumada a la información del Data Warehouse,
se pueda obtener información mucho más ágil, actual y de mayor valor para el negocio.
Como resultado de obtener información con las características mencionadas, se

buscará que los recursos de horas hombre sean re dirigidos hacia funciones más
estratégicas. Tanto por el lado del área de Inteligencia de clientes y sobre todo en el
área de negocios, donde los analistas comerciales podrán hacer foco sobre los
segmentos de clientes a analizar y las estrategias más convenientes para gestionarlos.
3.3 Gestión de Cartera de Clientes.
En el libro escrito por Peppers y Rogers, definen al cliente de la siguiente manera “Para
algunos, el término evocará la imagen mental de los compradores. Para otros, esos
compradores son usuarios finales o consumidores, y los clientes son negocios
ascendentes en la cadena de distribución: las empresas que compran a los productores
y venden directamente a los usuarios finales o fabrican su propio producto.” En otra
línea menciona “Eso significa que la competencia es cualquier cosa que un cliente
pueda optar que impida elegir la organización que está tratando de construir una relación
con ese cliente.” (Don Peppers y Martha Rogers, 2016,p.21). Eso significa que un cliente
debe estar constantemente monitoreado, para ofrecer lo que necesita en el momento
que lo necesite y así evitar lo que normalmente se denomina fuga de clientes o churn.
Uno de los principales atributos de una cuenta o cliente CMR, es la situación, esta indica
si el cliente se encuentra apto para usar la tarjeta o no. En la siguiente tabla, mostramos
la distribución de la cartera del Banco Falabella a inicios del año 2013.
26
Tabla 1: Distribución de la cartera de clientes del Banco Falabella.
Tipos de Cuenta de Tarjeta CMR

Situación de la Cuenta
CMR Visa Clásica Visa Platinum
Normal 22.61% 27.05% 1.09%
Nuevo 3.39% 1.70% 0.04%
Debe Cancelar 2.12% 1.63% 0.03%
Bloqueado 25.25% 2.10% 0.04%
Cerrada 11.39% 1.51% 0.05%
Normal. Clientes que se encuentran aptos para usar su tarjeta.
Nuevo. Clientes que aún no usan su tarjeta por primera vez o aun no la recogen.
Debe Cancelar. Clientes con mora temprana, menor a 60 días
Bloqueado. Clientes que no han usado su tarjeta en los últimos 24 meses o fueron
bloqueados por mora.
Cerrada. Cuentas que ya no tienen contrato vigente con el banco.
La gestión comercial esperada, es reducir los clientes en los segmentos Nuevo (que
pasen a situación normal) y Bloqueados por inactividad (que se activen). El segmento
Debe Cancelar o mora temprana es una gestión de las áreas de cobranzas.
De ahí la importancia de que el área de negocio, cuente con información lo más

actualizada posible, para que los recursos de campañas de activación (Situación 1) o
los de Recuperación (Situación 6) sean lo más eficientes y rentables posibles. Un claro
ejemplo son aquellas cuentas que se tiene identificado una inactividad en un cierto
periodo de tiempo, la idea es que no se bloqueen por inactividad y se recupere su
situación, muchas veces a través de campañas con estímulos comerciales, sin embargo,
serían desperdiciados si lanzamos la campaña a un segmento cuyo uso es cíclico o ya
fue activado sin necesidad de la campaña, pero no fue detectado debido al desfase de
generación de bases de campaña.
A continuación, mostramos una tabla de distribución de la cartera de clientes en

situación 1 (nuevos), para una campaña de activación de cuenta, es decir clientes
nuevos que aún no usan su tarjeta CMR, los parámetros a aplicar son:
Cuentas con antigüedad de hasta seis meses (desde que firmó o acepto el contrato de
la tarjeta CMR) y una línea de crédito a partir de S/. 1,000 (13,886 cuentas a campaña).
27
Tabla 2: Distribución cuentas en Situación 1 (nuevas).
Antigüedad de la Cuenta
Linea Credito CMR Entre 4 y 6 Entre 7 y 9 Entre 10 y 12 Mas de 12
Hasta 3 meses Total
meses meses meses meses
Cero 14 35 33 128 210
Menor a 300 556 192 179 218 453 1,598
300 - 600 9,733 7,760 5,161 4,454 16,337 43,445
600-1000 7,920 5,426 3,491 2,837 11,526 31,200
1001 - 1400 1,948 1,483 1,386 2,085 5,032 11,934
1400 - 3000 4,927 3,947 3,145 2,418 8,091 22,528
3001 - 4000 269 266 256 207 946 1,944
4001 - 5000 225 214 199 150 430 1,218
5001 - 6000 32 34 33 13 161 273
6001 - 7000 33 24 27 19 111 214
7001 - 8000 37 43 39 24 116 259
8001 - 9000 31 40 24 43 79 217
9001 - 10000 84 59 66 21 102 332
10001 - 15000 97 90 103 71 255 616
15001 - 20000 1 2 1 1 24 29
Mayor a 20000 13 13
Total 25,893 19,594 14,145 12,594 43,804 116,030
Estos son atributos de cuentas, las mismas que deben ser correctamente analizadas
para que la comunicación sea en el momento adecuado.
3.4 Sistema Financiero Peruano.
El sistema financiero está regulado por la Superintendencia de Banca, Seguros y AFP’s.

Todos los cuadros que a continuación presentamos son publicados por la SBS al cierre
del ejercicio del 2018 (31 de diciembre).
Tabla 3: Distribución Sistema Financiero Peruano.
SISTEMA FINANCIERO - ESTRUCTURA
Número Activos Créditos Depósitos

Diciembre 2018 de Monto Monto Monto
% % %
Empresas (Miles S/) (Miles S/) (Miles S/)
Banca Múltiple 16 385,343,801 83.3 270,662,412 85.7 243,860,245 81.6
Empresas Financieras 11 14,842,067 3.2 12,882,276 4.1 7,467,336 2.5
Cajas Municipales (Cm) 12 26,727,333 5.8 21,367,823 6.8 21,254,159 7.1
Cajas Rurales De Ahorro Y Crédito (Crac) 6 1,920,784 0.4 1,564,537 0.5 1,331,161 0.4
Edpyme 9 2,487,842 0.5 2,229,945 0.7 - -
Empresas De Arrendamiento Financiero 1 314,853 0.1 244,033 0.1 - -
Banco De La Nación 1 30,101,634 6.5 5,978,304 1.9 24,776,839 8.3
Banco Agropecuario (Agrobanco) 1 686,394 0.1 965,589 0.3 - -
462,424,708 100 315,894,918 100 298,689,740 100
Fuente: Informe SBS al 31 diciembre 2018.

28
El segmento que se analizara es Banca Múltiple, conformada solamente por entidades

bancarias. El tipo de deuda es Consumo en Tarjeta de Crédito para personas naturales.
Según el Reglamento para la Evaluación y Clasificación del Deudor y la Exigencia de
Provisiones (Resolución SBS N° 11356-2008), se define como deuda de consumo a los
créditos otorgados a personas naturales, con la finalidad de atender el pago de bienes
y/o servicios no relacionados con la actividad empresarial.
Las entidades bancarias, diversifican su oferta entre una serie de productos financieros
para personas naturales y jurídicas, entre las que se cuentan créditos efectivos,
vehiculares, hipotecarios, factoring, entre otros. Sin embargo, el Banco Falabella a la
fecha solo participa con productos de crédito de consumo.
Tabla 4: Distribución porcentual de productos financieros.
Estructura de los Créditos Directos por Modalidad y Empresa Bancaria

Al 31 de diciembre de 2018
(En porcentaje)
Total Créditos
Cuentas Tarjetas de Hipotecarios Arrendamient Comercio
Empresas Descuentos Préstamos Fáctoring Otros (En miles de
Corrientes Crédito para Vivienda o Financiero Exterior
nuevos soles)
BCP 0.32 9.03 2.53 54.30 16.10 2.09 6.98 4.51 4.13 91,824,200
BBVA 0.49 5.65 2.30 44.77 23.55 2.36 8.26 10.01 2.61 54,205,749
Scotiabank 0.20 6.29 1.31 54.51 14.96 1.89 7.56 11.06 2.22 46,015,145
Interbank 0.18 15.97 1.54 48.21 19.75 0.95 5.27 6.22 1.92 32,518,012
BanBif 0.24 4.61 3.00 42.80 17.09 1.96 12.89 16.02 1.38 10,110,221
Mibanco - - - 94.92 5.08 - - - - 0.00 9,949,503
B. Pichincha 0.50 6.53 2.70 58.96 13.94 0.29 6.01 10.44 0.62 7,401,273
B. Santander Perú 0.04 - 15.82 52.91 - 0.14 18.18 12.84 0.07 3,937,453
B. GNB 0.00 1.12 0.40 53.85 29.04 - 4.20 6.71 4.68 3,792,447
B. Falabella Perú - 98.06 - 1.83 0.11 - - - - 0.00 3,055,620
Citibank 1.68 0.21 - 60.45 - 7.17 0.26 26.18 4.04 2,745,048
B. Ripley - 46.69 - 53.31 - - - - - 1,911,402
B. de Comercio 0.01 0.20 0.43 87.70 3.69 - 0.69 6.83 0.45 1,469,723
B. Cencosud - 100.00 - - - - - - - 816,226
B. ICBC - - 3.70 88.36 - - 1.80 0.81 5.33 556,553
B. Azteca Perú - 12.75 - 87.25 - - - - - 0.00 353,836
Total Banca Múltiple 0.30 9.31 2.16 52.45 16.73 1.78 6.92 7.63 2.72 270,662,412
Como se puede observar, el mix de productos del Banco Falabella está fuertemente
orientado hacia la Tarjeta CMR, dejando en un menor valor a los créditos de efectivo.
Esta estrategia es empleada sobre todo en la denominada Banca Retail, que al igual
que Falabella, cuentan con una alianza dentro del mismo grupo, como lo son el caso de
Ripley y Cencosud.
29
% Deuda Tarjeta de Crédito por Entidad Bancaria
BCP
100.00
B. Azteca Perú BBVA
80.00
B. ICBC Scotiabank
60.00
B. Cencosud 40.00 Interbank
20.00
B. de Comercio - BanBif
B. Ripley Mibanco
Citibank B. Pichincha
B. Falabella Perú B. Santander Perú

B. GNB
Figura 9. Porcentaje Deuda Tarjeta de Crédito por entidad bancaria.
Para entender mejor el escenario anterior, se muestra el ranking de colocación por

crédito de consumo, para luego desglosarlo por Crédito en efectivo y Crédito en Tarjeta
de Crédito, donde se puede apreciar como el posicionamiento en el sector de retail, es
una ventaja competitiva.
Tabla 5: Distribución de créditos de consumo por entidad financiera.
Ranking de Créditos
(En miles de soles)
Créditos Directos
Participación Porcentaje
Empresas Monto
(%) Acumulado
BCP 91,008,617 33.73 33.73
BBVA 54,205,749 20.09 53.81
Scotiabank 46,015,145 17.05 70.87
Interbank 32,518,012 12.05 82.92
BanBif 10,110,221 3.75 86.66
Mibanco 9,949,503 3.69 90.35
B. Pichincha 7,401,273 2.74 93.09
B. Santander Perú 3,937,453 1.46 94.55
B. GNB 3,792,447 1.41 95.96
B. Falabella Perú 3,055,620 1.13 97.09
Citibank 2,745,048 1.02 98.11
B. Ripley 1,911,402 0.71 98.82
B. de Comercio 1,469,723 0.54 99.36
B. Cencosud 816,226 0.30 99.66
B. ICBC 556,553 0.21 99.87
B. Azteca Perú 353,836 0.13 100.00

30
Como se puede observar en colocaciones de créditos en general, Banco Falabella se

encuentra en décimo lugar, por encima de Ripley y Cencosud. En los siguientes
cuadros, se analizará solo en el segmento de Tarjeta de Crédito, su posición sube a un
cuarto lugar, para estar en un décimo quinto lugar en Crédito Efectivo.
Claramente la estrategia de diferenciación de Falabella, teniendo como punto fuerte al

retail, les ha dado resultado para posicionarse con un 11.9 % de participación del
segmento.
Tabla 6: Distribución de créditos en Tarjeta de Crédito por entidad financiera.
Ranking de Principales Modalidades de Créditos Directos

(En miles de soles)
Tarjetas de Crédito
Empresas Monto
(%) Acumulado
BCP 8,295,980 32.93 32.93
Interbank 5,191,975 20.61 53.53
BBVA 3,061,976 12.15 65.69
B. Falabella Perú 2,996,406 11.89 77.58
Scotiabank Perú 2,894,276 11.49 89.07
B. Ripley 892,453 3.54 92.61
B. Cencosud 816,226 3.24 95.85
B. Pichincha 483,147 1.92 97.77
BanBif 466,255 1.85 99.62
B. Azteca Perú 45,125 0.18 99.80
B. GNB 42,417 0.17 99.97
Citibank 5,666 0.02 99.99
B. de Comercio 2,915 0.01 100.00
Mibanco - - -
B.Santander Perú - - -
B. ICBC - - -

31
Tabla 7: Distribución de créditos en efectivo por entidad financiera.
Préstamos
Empresas Monto
(%) Acumulado
BCP 49,208,641 34.82 34.82
Scotiabank 25,081,460 17.75 52.57
BBVA 24,267,684 17.17 69.74
Interbank 15,677,293 11.09 80.83
Mibanco 9,444,409 6.68 87.52
B. Pichincha 4,364,078 3.09 90.61
BanBif 4,327,211 3.06 93.67
B. Santander Perú 2,083,279 1.47 95.14
B. GNB 2,042,169 1.45 96.59
Citibank 1,659,479 1.17 97.76
B. de Comercio 1,288,980 0.91 98.67
B. Ripley 1,018,949 0.72 99.39
B. ICBC 491,776 0.35 99.74
B. Azteca Perú 308,711 0.22 99.96
B. Falabella Perú 55,924 0.04 100.00
B. Cencosud - - -
Esta ubicación no es solo como monto en colocaciones, sino que también es expresado
en el número de tarjeta habientes, donde ocupa el primer lugar.
Tabla 8: Número de tarjetas de crédito por entidad financiera.
Número de Tarjetas de Crédito por Tipo de Crédito y Empresa Bancaria

Créditos a Créditos a Créditos a

Créditos de Créditos Créditos a
Empresas Grandes Mediana Pequeñas Total
Consumo Corporativos Microempresas
Empresas Empresas Empresas
B. Falabella Perú 1,397,418 - 1 1 - - 1,397,420
B. Ripley 1,207,265 - - - - - 1,207,265
Interbank 922,832 - - 5 - - 922,837

BCP 774,456 1,111 2,930 17,096 52,926 24,341 872,860
B. Cencosud 659,724 - - - - - 659,724
BBVA 614,604 935 4,316 8,973 14,418 5,290 648,536
Scotiabank 451,754 299 493 1,579 304 463 454,892
B. Pichincha 273,554 12 155 388 276 432 274,817
BanBif 96,514 32 207 1,078 999 1,199 100,029
B. Azteca Perú 60,533 - - - - - 60,533
B. GNB 8,410 - - - - - 8,410
Citibank - 495 1,224 104 155 31 2,009
B. de Comercio 1,017 1 1 1 1 3 1,024
Mibanco - - - - - - -
B. Santander Perú - - - - - - -
B. ICBC - - - - - - -
Total Banca Múltiple 6,468,081 2,885 9,327 29,225 69,079 31,759 6,610,356

32
Para culminar con este capítulo, vamos a mostrar algunos indicadores financieros de la
banca múltiple del sistema financiero peruano.
Tarjetas de Crédito (Miles S/)
25,000,000
21,119,152
18,440,531 18,751,268
20,000,000
17,163,687
13,829,219
15,000,000
10,000,000
5,000,000
-
Dic-14 Dic-15 Dic-16 Dic-17 Dic-18
Figura 10. Saldos Tarjeta de Crédito de la Banca Múltiple.
Cartera Tarjetas de Crédito atrasada / Cartera Tarjetas de

Crédito (%)
6.00
5.09
4.78
5.00
4.08 4.08
3.74
4.00
3.00
2.00
1.00
0.00
Dic-14 Dic-15 Dic-16 Dic-17 Dic-18
Figura 11. Morosidad en Tarjeta de Crédito de la Banca Múltiple.

33
Figura 12. Morosidad de Tarjetas de Crédito.
3.5 Business Intelligence.
En la actualidad mucho se hablado de la data que se cuenta a disposición para analizar

y que las empresas en su búsqueda de no quedar rezagadas en el mercado deben
aprovecharla. Sin embargo, esta data sin contar con una estrategia definida de análisis
de negocio, no podrá ser implementada adecuadamente para que se transforme en una
ventaja competitiva frente a las demás.
Crear valor más allá de ser una frase corta, engloba muchos procesos, metodologías y
el uso de herramientas adecuadas para que finalmente la base de datos de una empresa
pueda añadirle valor a esta. Vamos a mencionar algunas definiciones sobre Business
Intelligence o su traducción al español que es Inteligencia de Negocios.
Edinson Medina La Plata (2012). “La capacidad para tomar decisiones de negocio
precisas y de forma rápida se ha convertido en una de las claves para que una empresa
llegue al éxito. Sin embargo, los sistemas de información tradicionales, suelen presentar
una estructura muy inflexible para este fin. Aunque su diseño se adapta en mayor o
menor medida para manejar los datos de la empresa, no permite obtener la información
de los mismos.” (p. 24).
34
Josep Curto Díaz (2011). “Se entiende por Business Intelligence al conjunto de
metodologías, aplicaciones, prácticas y capacidades enfocadas a la creación y
administración de información que permite tomar mejores decisiones a los usuarios de
una organización.” (p. 18).
Muñoz, H. H., Osorio, M. R., & Zúñiga, P.L. (2016). Inteligencia de los negocios. Clave
del Éxito en la era de la información. Revista Clío América, 10 (20). “Se puede decir que
son aquellos recursos administrativos empresariales con los que las organizaciones
actuales y modernas pueden contar para aprovechar al máximo toda la información que
posean tanto de sus clientes como la de sus proveedores y hasta la de sus competidores
inclusive; todo con el fin de lograr ventajas competitivas en un mercado hostil y
demasiado dinámico.” (p. 194).
Todos los anteriores enunciados refieren a conceptos de administrar información y toma

de decisiones. Pero no hay que confundir que solo es administrar información, lo cual
podría guiarnos hacia el error que solo una base de datos podría desempeñar ese rol.
En base a lo anterior, y al expertise del autor, se define a la Inteligencia de Negocios

como la combinación de metodologías de trabajo, procesos y tecnologías, que permiten
transformar datos aislados y no relacionados en información relevante para el negocio,
que usada correctamente generara conocimiento del mismo. Esto sin lugar a dudas lo
convierte en una fuerte ventaja competitiva al estar reconocida dentro de la estrategia
comercial de la empresa.
A continuación, mostramos la conocida pirámide de datos o información, ajustada según

aportes de varios autores, y consolidado en un solo gráfico. Nos dice que los sistemas
transaccionales que generan data todo el día, son el input de los procesos de
Inteligencia de Clientes, pero los sistemas de este nivel, están fuera del enfoque de BI.
Solo a partir del segundo nivel, donde se tiene acceso a decisiones y a una plataforma
pre concebida, se podrá generar información relevante, en base a la data inicial, que
sirva para análisis más robustos de información como, por ejemplo: Cuál es el
acumulado de las ventas y el % de crecimiento respecto a un periodo anterior. Cuáles
son los productos que mejor responden a una campaña comercial o el patrón de
consumo de cierto producto.
35
I Periodo de Analisis Sistemas

N
B T
Accionistas U E Mensual
Directores S L Trimestral Dashboard
I L Anual Reportes Directivos
ESTRATEGIA N I Mediano / Largo Plazo
E G
Gerentes
S E
Jefes de área
S N Semanal DashBoard
Coordinadores
C Mensual Reporting OLAP
TACTICA E Mediano Plazo Data Analysis
Supervisores Diario Sistemas

Personal Operativo Semanal Transaccionales
Corto Plazo Analisis OLTP
OPERATIVA
Figura 13. Pirámide de Gestión de Información.
Fuente: Flores F. (octubre 2018). Implementación de BI. Conferencia presentada en

Sistemas UNI.
3.6 Desarrollo y evolución del Business Intelligence.
A continuación, se indica la evolución de los roles dentro del BI en los últimos años y
como se han creado especializaciones dentro de esta tecnología.
Inteligencia de Análisis de Análisis Inteligente

Negocios Autoservicio (ML / IA))
Aparición 1985 - 2005 2005 - 2015 2015 – 2020 ?
Liderado por analistas / La tecnología ayuda a los

Accesibilidad Liderado por TI / Expertos
usuarios avanzados usuarios emprendedores
Generación de Informes
Preparación de datos Aprendizaje Automático
de Negocios
Facilitadores Dashboard Descubrimiento de Datos Automatización
Scorecards Visualización de datos UI de lenguaje natural
Desafíos
Accesibilidad, Agilidad Gobernanza Confianza, Transparencia
Figura 14. Evolución de BI y Análisis de data.
Fuente: Villanueva F. (enero 2019). Análisis inteligente: De los datos a las decisiones.
Conferencia presentada en CA (https://www.tableau.com/about/blog).
36
Es común escuchar hablar de Business Intelligence (BI), Business Analytics (BA) y

recientemente Big Data, esto en realidad es una evolución del primer término. Dado la
evolución de las tecnologías de información, dio paso a la especialización de los roles
de profesionales de BI.
A continuación, se muestra el resultado de búsqueda en Google Trends, de los términos

referenciados, para el año 2018 en Perú y en USA.
Figura 15. Tendencia Palabras clave Perú 2018.
Fuente: Google Trends.
Figura 16. Tendencia Palabras clave Estados Unidos 2018.
Fuente: Google Trends.
Tomando como referencia a Estados Unidos, Big data es el más destacado, de la misma
forma en Perú. Sin embargo, en cuanto a BI y BA, a nivel local hay una marcada
diferencia a favor del primero, en USA esta desaparece. La razón es debido a que aun
37
en el nivel local el termino de BA, es relativamente nuevo y los profesionales con

experiencia en el área son escasos.
Sin embargo, estos roles siempre han existido, es claro que el profesional de BI, hacia
los roles de analista de información, analista de negocio, analista de procesos, solo que
ahora se tiene claramente identificado su participación en cada fase de los procesos.
Para el profesor Ph.D. Jorge Samayoa (2018), “La Inteligencia de Clientes es el proceso
de analizar y presentar la información de una forma no técnica, y sobre todo útil y de
fácil entendimiento para los tomadores de decisión”. Claro está que el profesor
Samayoa, ha identificado los demás roles en los procesos de BI. A continuación, un
gráfico donde se muestra desde un punto de vista estructurado dichos roles.
Figura 17. Roles de especialistas en una estructura de BI.
Fuente: Samayoa, J. (2018) Estadística aplicada a negocios (Ponencia Programa

MOOC EDX).
Los roles que se despliegan del anterior cuadro son los siguientes:
Data Engineering: Es el que tiene a cargo garantizar la calidad de data, asegurar que
esta se encuentre apta para el procesamiento y la carga en la plataforma de BI.
Normalmente es quien conoce los sistemas transaccionales a un nivel de base de datos
38
y funcionalidad. Los conocimientos requeridos deberían ser: Base de datos,

programación, sistemas operativos y estadística.
Business Intelligence: Responsable de identificar la información más relevante para el

negocio y desarrollar presentaciones o cuadros de mando de alto impacto. Dado que la
presentación de los principales KPI’s ayudaran a gestionar de mejor forma los recursos
de la empresa. Los conocimientos requeridos son: Base de datos, programación,
estadística y manejo de KPI’s.
Business Analytics: Son los que tienen manejo directo con la data, los que realizan
análisis estadísticos y/o matemáticos, a través de análisis estadísticos principalmente.
Sus conocimientos deben ser estadísticos, de programación y manejo de KPI’s.
Data Scientist: Es el profesional que normalmente cruza transversalmente los anteriores

roles. Realizan los llamados modelos predictivos, que son algoritmos estructurados con
una fuerte base estadística, entre los más conocidos son: arboles de decisión, cluster,
segmentación de perfiles, entre otros. Tienen conocimientos en estadística, base de
datos, programación, sistemas operativos y sobre todo investigación.
Para finalizar este punto se indicará algunos ejemplos donde se emplea BI:
En el sector Financiero: Segmentar tu cartera de clientes, de acuerdo a perfiles y ofrecer

el producto más conveniente de acuerdo a la valoración del cliente.
En el sector Retail: Para identificar cuáles son los mix de productos con mayores ventas,
de tal forma la rotación de stock sea más óptima.
En el sector servicios: Identificar consumos atípicos por ejemplo de consumo de energía

eléctrica, que indique una manipulación del sistema de medida.
3.7 Gobierno de Datos.
Los términos Gobierno de Datos y Calidad de Datos, además que son relativamente
nuevos como nombre, siempre han estado o debieron estar presente en cualquier
proceso de generación de data, hablando sobre todo del medio local. Se inicia este
apartado indicando que no son lo mismo, mientras que la Calidad de Datos es un
proceso de refinamiento y control previo al procesamiento, para que el resultado sea el
adecuado, el gobierno de datos asegura una correcta administración de estos, identifica
a todos los responsables dentro de la organización. Tomando en consideración lo ya
mencionado, los datos son un activo de las empresas, entonces es lógico pensar que
se necesita, lineamientos, políticas y controles para asegurar tal bien.
39
Dentro de cualquier organización existe data, generada internamente o adquirida de

fuentes externas, por ejemplo, la morosidad de un cliente en el pago de la tarjeta de
crédito que un banco le ha otorgado, es una data de generación interna, sin embargo la
información de las centrales de riesgos que son adquiridas para realizar campañas de
captación de cuentas o ampliación de la línea de crédito de un producto financiero del
mismo banco es una data adquirida de una fuente externa, o también en cuanto se
refiere a un score de crédito o de riesgo de un grupo de personas es una data de fuente
externa. Siendo así, es necesario definir ciertos canales de recepción de data,
responsables y políticas de administración de datos, así como procesos que aseguren
la integridad de estos, en la adquisición, procesamiento y entrega final.
Vamos a definir el concepto según lo que refiere algunas citas bibliográficas.
Ladley J (2012) “El gobierno de los datos es la organización e implementación de

políticas, procedimientos, estructura, roles y responsabilidades que describen y aplican
las reglas de participación, los derechos de decisión y las responsabilidades para la
gestión eficaz de los activos de información”. (Data Governance: How to Design, Deploy
and Sustain an Effective Data Governance Program Pag.11-12).
El mismo autor nos indica: “La gobernanza de los datos representa el programa utilizado
por una empresa, para administrar los organismos, políticas, principios y calidad de la
organización que garantizará el acceso a datos e información precisos y libres de
riesgos. El gobierno de los datos establecerá estándares, responsables, y garantizará
que el uso de datos e información alcance el máximo valor para la empresa, a la vez
que administra el costo y la calidad del manejo de la información. La gobernabilidad de
los datos hará cumplir el uso coherente, integrado y disciplinado de la información".
(Data Governance: How to Design, Deploy and Sustain an Effective Data Governance
Program Pag.11-12).
Según la definición del autor Gobierno de Datos, es una estrategia que se basa en una
serie de políticas, procedimientos, estándares, identificación de roles, con el único
objetivo de salvaguardar el activo de data de la empresa. Esta puede ser interpretada
como un framework de trazabilidad (planificación, monitoreo y cumplimiento). Pero lo
que no es Gobierno de Datos es una serie de frases en un documento pdf que es
archivado como algo sin importancia, lejos de realizar un seguimiento y una
coordinación vertical hacia toda la empresa. Tiene como fin, garantizar una gestión
adecuada de datos.
40
Un tema relacionado al presente es la Ley de Protección de Datos Personales,

implementada hace unos años en el Perú, la cual obliga a cualquier entidad pública o
privada a gestionar los medios necesarios para salva guardar la información de datos
personales de sus clientes. Esta normativa encauza a que todas las empresas se
alinean hacia un gobierno de datos, dependerá de cada uno de estas, implementarlas
en menor o mayor grado posible.
De acuerdo con la teoría del Gobierno de Datos y lo que nos indica Stephanie Zatyko
(Product Marketing Manager Experian USA), nos habla de tres pilares:
Las personas: Dentro de la organización se debe identificar aquellas que tienen algún
tipo de relación con la data, y encontrando varios roles definidos:
Los propietarios de los datos (Data Owner). Deben asegurar la calidad constante de los
datos, por su posición de cargos de responsabilidad, tienen las formas de seguir los
procesos que correspondan para mantener la calidad en los datos.
Los administradores de datos (Data stewards). Aseguran una correcta administración

de los datos. Son aquellos que aseguran operativamente que se sigan con las normas
establecidas durante las operaciones con datos.
Los consumidores de datos (Data consumers). Aquellos que usan datos durante los
procesos que intervengan. Ellos al trabajar directamente con la data son los primeros
en detectar anomalías en la misma, son los que conocen la data.
Los productores de datos (Data producers) Son los que captan los datos dentro de la
organización, al igual que los consumidores, identifican variaciones en la data y se
alinean con los requisitos indicados para la captación.
Los analistas de datos (Data analysts). Son los responsables de traducir datos en
información, mediante el uso de herramientas para resumirla en dashboard o informes
y así brindar el soporte en la toma de decisiones comerciales.
Los custodios de datos (Data custodians). Son los responsables de mantener los datos
seguros y administrar el sistema de protección en torno a estos.
Los Procesos: Para asegurar la calidad de los datos, se deben implementar ciertos
procesos de control, dentro de los procesos comerciales, tanto en la generación de
nuevos datos o su procesamiento, así como en la entrega y adquisición de los mismos.
Muchas veces estos nuevos procesos podrán tomar recursos para su administración,
41
pero son necesarios, si se quiere llevar un control de calidad. Por ejemplo, una base de
datos, que actualice planillas, datos personales, ingresos, deudas, debe encontrarse
cifrada por temas de seguridad y regulación sobre todo en el sector de banca. Estos
pues quizás no son temas comerciales, pero son normativos y/o de gobierno de datos.
Definir su control y auditoria es el siguiente paso en la construcción de un marco de
gobierno de datos. Cabe mencionar que dentro de estos procesos se deben considerar
los de manejo de riesgos, copias de respaldo y contingencias en caso de pérdidas.
Tecnología: La tecnología por sí sola no configura una política de protección de datos,

como se ha indicado, esta va acompañada de procedimientos, definición de
responsables. Pero se debe seleccionar un marco tecnológico que ayude a optimizar
sus procesos. Las tecnologías de gestión de datos pueden incluir elementos como las
herramientas de verificación, estandarización, monitoreo, colaboración, informes y
resolución de identidades, solo por mencionar algunas.
Los proyectos de Gobierno de Datos, debe implementarse identificando la data más

importante de la empresa, a continuación, se mostrará una técnica de identificación.
Para Richard Wang, un método de identificación de data relevante y su calidad, consta

de tres pasos (asumiendo que la organización conozca cuál es su data más importante):
el primero es realizar una encuesta de calidad de data, entre los ejecutivos de la
empresa muy relacionados al negocio y que conozcan de este. A la par realizar métricas
de calidad sobre la data encuestada, niveles de exactitud, actualización, de perdida de
datos, etc. El segundo paso es contrastar ambos resultados, es decir el subjetivo de la
encuesta versus el objetivo obtenido por las métricas, identificar los puntos discrepantes,
las causas y efectos de estas, el tercer paso es tomar acciones correctivas sobre la data
de mayor impacto. De esta forma se puede comprender que tanto es el conocimiento
de las personas relacionadas con el negocio, identificar la data de alto impacto y sus
niveles de calidad. Con los resultados mencionados, se estructura una matriz para
contrastar ambos resultados y hacer foco sobre la data a iniciar acciones. Es decir, se
cuenta con la percepción baja o alta de los resultados de la encuesta, así como del
resultado de las métricas, ambas forman una matriz de 2 x 2, formando cuatro
cuadrantes: bajo – bajo (primer cuadrante), bajo – alto (segundo cuadrante), alto – bajo
(tercer cuadrante) y alto – alto (cuarto cuadrante). Se entiende que el cuarto cuadrante
es la situación idónea, una alta percepción de los ejecutivos y un alto resultado en las
pruebas, sin embargo, cualquiera de los otros tres cuadrantes, es necesario una
revisión, sobre todo el bajo – bajo, donde la percepción y los resultados son observables.
42
Encuesta de Calidad Métricas de Calidad

de datos Conjunto de Datos
de datos
Resultados Resultados
de encuesta de métricas
Análisis
Comparativo
Discrepancias
Determinar las causas raíz de las

discrepancias
Acciones para incrementar la

calidad de datos
Figura 18. Modelo de Identificación de calidad de data.
Fuente: Wang, R.Y.et al. (2006, p 30) Journey to Data Quality.
Alto
II IV
Evaluación
de
encuestas Bajo
I III
Bajo Alto
Evaluación de métricas
Figura 19. Matriz de resultados del estado de calidad de data.
Fuente: Wang, R.Y.et al. (2006, p 30) Journey to Data Quality.

43
A continuación, se presentará dos enfoques de cómo organizar un Gobierno de Datos

dentro de la empresa, cabe mencionar que esta no es una metodología, y que cada
esquema obedece a entornos, necesidades y marcos legales diferentes, los mismos
que deben ser ajustados en la implementación a medida dentro de una empresa.
En el primer esquema se habla de un CDO (Chief Data Organization) quien define la

estrategia de Gobierno de Datos de la organización y es el principal responsable por
asegurar la calidad de datos en toda la empresa. Como se puede observar el cargo es
de primera línea de jerarquía, completamente empoderado y con capacidad de
decisiones sobre la organización.
Figura 20. Modelo de Gobierno de Datos propuesto por S. Zatyko.
Fuente: Zatyko S. (Product Marketing Manager Experian USA). Recuperado de

https://www.edq.com/blog/building-a-dq-team/
El segundo modelo planteado por John Ladley, define una plataforma más lineal y con
menos roles, tomando la pirámide de datos y su distribución asigna a un rol
administrador o custodio por nivel, es decir desde el operacional con un rol más de
custodio, hacia el estratégico con uno más protagónico.
44
Ejecutivo de Aprueba:
Información: - Toma decisiones.
- Aprueba las políticas de seguridad de información.
- Monitorea información estratégica, de los dashboard.
Administrador Define:
de Información: - Entiende la información de los usuarios y sus riesgos.
- Decide quien y como puede acceder a la información.
- Asegura que la información sea correctamente administrada.
Custodio de Asegura:
Información: - Promueve auditorias de calidad y asegura el cumplimiento de las políticas de seguridad.
- Realiza acciones alineadas con la política y procedimientos de seguridad.
- Coordina la capacitación de los temas de seguridad en toda la empresa.
Pirámide de Datos
Dirección Ejecutiva: Ejecutivo de

Planea y guía. información:
Aprueba
ESTRATEGIA
Dirección Táctica: Administrador

Gestiona de
TACTICA información:
Define
Custodio de la
Dirección Operativa: información:
Monitorea OPERATIVA
Hace cumplir
Usuarios y Gestores
de la Información
Figura 21. Modelo de Gobierno de Datos propuesta por J. Ladley.
Fuente: Ladley, J. Data Governance: How to Design, Deploy and Sustain an Effective
Data Governance Program (2012, p 127).
3.8 Customer Relationship Management CRM.
La Fidelización de los Clientes de una empresa, es quizás la tarea o el objetivo del área
de ventas y marketing más importante, ya que de este depende los ingresos de la
empresa. Aunque tal objetivo es fácil de entender, detrás de este, existen muchos
enfoques para lograrlo, que se han presentado desde hace muchos años. Uno de ellos
es el Customer Relationship Management (CRM) o lo que traducido al español es la
Gestión de las Relaciones con el cliente. Este modelo basa la estrategia de una empresa
hacia la satisfacción del cliente. Pero para poder satisfacer las necesidades de mi
cliente, debo primero identificarlos y tener una oferta adecuada para ellos, es decir ser
45
proactivo con ellos, lo que me ayudara a generar una lealtad hacia la marca, retenerlos
frente a la competencia, implementar estrategias de cross selling y upselling con nuevas
propuestas comerciales. Así como ser eficientes en la administración de los canales de
comunicación con mis clientes, los que vendrían hacer mis canales de venta, ya sea
directa o indirectamente. Estos canales de contacto han aumentado considerablemente
en la última década (redes sociales, web, chat) o lo que se llama en Marketing como el
Momento de la Verdad, son estos los eventos que el CRM te ayuda administrar y a
identificar de mejor forma, por ejemplo, cuantos emails se han enviado a un cliente, de
estos cuantos fueron abiertos, y de estos cuantos llegaron a convertirse en ventas.
Algunos piensan que CRM es una implementación de software, para acelerar los
conceptos mencionados, pero CRM no es solo el software, de nada sirve este, si es que
la estrategia de la empresa no está dirigida correctamente hacia el cliente, no solo las
áreas de marketing y ventas, sino la de servicio post venta, operaciones y todas aquellas
que ayuden a esta estrategia.
Para ayudar a complementar este concepto, se mencionará algunas notas

bibliográficas.
Newell, Frederick (2010) “Algunos piensan que el CRM es solo tecnología. Todavía no
entienden que la construcción de relaciones debe comenzar con un entendimiento de
las necesidades del cliente”. (p.58).
Ayuso & Rodríguez, (2011) “El CRM (Customer Relationship Management) hace
referencia tanto a la estrategia de negocio, enfocada a seleccionar y gestionar una
relación con los mejores clientes para optimizar su valor a largo plazo, como a las
aplicaciones concretas de software necesarias para procesar la información de esos
clientes y desarrollar esa relación. Es frecuente el uso de los términos CRM y marketing
relacional como sinónimos, e incluso hablar de CRM para referirse a la estrategia de
marketing de una compañía claramente orientada a la creación de una relación a largo
plazo con sus clientes”. (p.101).
Bose, (2012) define al CRM como: “La integración de tecnologías y los procesos de
negocios usados para satisfacer las necesidades de los clientes durante cualquier
interacción con los mismos”. (p.13).
Para Oscar Santa Cruz (Gerente General de Creantis – Proveedor de Vtiger CRM), la
implementación de una estrategia de CRM, se basa sobre tres pilares: Procesos
estándares, software CRM y una Cultura orientada al cliente, siendo la primera fase la
46
recopilación organizada de información sobre el cliente, en tres áreas fundamentales

Marketing, Ventas y Servicio Post venta. Lo cual ayudaría aumentar la productividad del
equipo de ventas, aumentar la efectividad de las campañas de Marketing Directo y
atender las solicitudes de servicio con rapidez. Santa Cruz O (2013) CRM Para conocer
mejor a tus clientes. Revista Tech & ROI,13,14-15.
En base a lo mencionado y al expertise del autor, se definirá CRM, como un modelo de

gestión cuyo objetivo es la fidelización de clientes para poder lograr una ventaja
competitiva frente a la competencia, para lograrlo combina una estrategia de negocio
orientada hacia el cliente, una plataforma de software que administre la data, procesos
estandarizados que ayuden a generar información relevante de los clientes y sobre todo
un equipo comprometido con esta estrategia, con ideas innovadoras.
A lo largo de nuestra experiencia como clientes, reiterativamente se recibe ofertas de

productos o servicios que no son necesarios, que además ya han sido indicado en algún
contacto anterior. Cada uno de estos contactos infructuosos (llamadas, emails,
mensajes) con clientes y potenciales clientes, solo hace que la imagen de la empresa
ofertante se deteriore y peor aún se establezca una mala relación.
El CRM habla de administrar relaciones, pero ¿qué es una relación?, un nexo invisible
cuando una persona continuamente compra un mismo producto, esto más puede ser,
porque no tiene otra opción a que responda a un tipo de relación. En el libro de Don
Peppers y Martha Rogers, tratan de enfocar a la relación de clientes como a la
predisposición que tiene este último hacia determinada marca, esta actitud responde a
un mix de acontecimientos vinculantes con la marca, como los comerciales cual fuese
el medio, en noticias o comentarios del círculo de amistades del cliente. Pero este
vínculo no es nada, sino se conoce su existencia, se desarrolla con otras acciones
comerciales, lo que finalmente te lleve a tener relaciones significativas y rentables con
una cartera de clientes segmentada y continuamente identificada. (Don Peppers y
Martha Rogers, 2016,p.20).
Es conocido que la revolución tecnológica, ayudado a empoderar a los clientes, los que
a través de cualquier de los nuevos medios como las redes sociales, pueden ayudar a
levantar una marca o iniciar su declive. Pero esta revolución también ayuda a las
empresas, porque tienen información de primera mano de sus clientes, sus gustos,
preferencias, y opciones, todo es parte de esta revolución tecnológica de un lado, pero
que también es de los clientes. Se sabe que es mucho más rentable conservar tu cartera
de clientes que insertar nuevos a esta, es decir con el pasar de los años un cliente
47
fidelizado genera mayor rentabilidad para la empresa, dado que, al conocer sus gustos,
es menor las fallas en la logística desarrollada para satisfacerlo, lo que conlleva a
mejores procesos y mayores ingresos. De esto se puede mencionar cuatro beneficios
de la importancia de tener fidelizada una cartera de clientes, según Rogers y Peppers:
Beneficio de incrementar las ventas, un cliente fidelizado, incrementara sus compras

con el pasar de los años. Inicio de soltero, pero incrementa sus necesidades con la
familia.
Beneficio de reducir los costos operativos: Clientes fidelizados, saben lo que quieren y
necesitan, lo que ayuda a que los procesos operativos de logística sean más certeros.
Beneficio de Referencia a otros clientes: Menores gastos de publicidad, debido a que

las recomendaciones van de cliente a cliente, lo que se conoce como boca a boca.
Beneficio de la prima de precio: Los nuevos clientes pueden beneficiarse de descuentos

por introducción, mientras que los clientes fidelizados no mostraran tanto interés en
estos, debido a que su interés es recibir lo que ellos esperan.
(Don Peppers y Martha Rogers, 2016,p.32).
Hay que tomar en cuenta que los clientes, deciden qué información comparten y cual
no, por tanto, un cliente que comparte información con la empresa, debe ser analizada
y asegurada en una base de datos, correctamente implementada y con la seguridad
adecuada para que estas no sean usadas de forma inadecuada, puesto que ahora esa
información es un valioso activo de la empresa. Esta parte es donde el CRM se enlaza
con el BI, dado que este último debe brindar la plataforma de almacenamiento
adecuado, a través de un Data Warehouse, y que posteriormente será explotado por
una herramienta de CRM mucho más orientado hacia la administración de este tipo de
información.
Existen muchos tipos de programas de fidelización de clientes, los clásicos son los
sistemas de Puntos, los cuales consisten en acumular puntos conforme un cliente va
realizando compras. Estos puntos serán canjeados finalmente por productos de una
galería determinada, como se ve en este tipo de programas no se logra identificar el
perfil de un cliente y se sigue manejando a la cartera como un todo, sin lograr un
beneficio claro de la segmentación de clientes.
También se tienen los clubes de clientes, donde existe un mayor compromiso entre la
empresa y el cliente, dando una idea de relación mucho más estrecha, en esta se
48
presentan ofertas dirigidas, invitaciones a eventos, degustación de productos, saludos

por cumpleaños o día del padre, por ejemplo, los que comúnmente van acompañados
de invitaciones o descuentos a eventos.
Lo que se tiene que definir al crear una estrategia de fidelización, es seleccionar el

segmento de clientes que uno quiere enfocarse, los más rentables serán los más
importantes sin lugar a duda, sin embargo, no se deben menospreciar aquellos clientes
pequeños y de baja facturación y a los potenciales clientes. Todo será cuestión de cómo
ha sido segmentada e identificada tu cartera de clientes.
Para Stephan Butsher (2017), una segmentación demasiada profunda obedece a que
las características de los clientes no son homogéneas, creándose varios cluster de
análisis, pero una vez más se repite en cómo definir tu grupo objetivo. También
menciona que “Las bases de datos deben verse desde un punto de vista estratégico
más que táctico: sin un conocimiento detallado de sus clientes, ninguna empresa podrá
competir. Un programa de fidelización de clientes es el instrumento ideal para recopilar
datos de la calidad y cantidad correctas de sus clientes más importantes.” Butscher,
Stephan A. Programas de fidelización de clientes y clubes, 2017, p.58)
Esto es correcto, la base de datos que se defina será la base o plataforma, sobre la cual
se exploten las tecnologías que se mencionan en este trabajo, para este ejemplo es el
CRM.
En el siguiente cuadro se muestra las etapas de carga, procesamiento y análisis de una

base de datos implementada para un proyecto de Fidelización de clientes, como se
puede observar, esta es cíclica, en cada loop del ciclo se analiza los resultados de la
campaña anterior, para luego cargar la nueva data, analizada y si es el caso clasificarla
para una nueva campaña. Generando con un adecuado análisis, conocimiento para la
empresa y optimizando los recursos de publicidad y retención.
49
Figura 22. Ciclo de administración de una base de datos de fidelización de clientes.
Fuente: Butscher, S. A. (2017, p 58). Programas de fidelización de clientes y clubes.
Como cierre de este capítulo se puede comentar lo enunciado por Pepers and Rogers:
“De hecho, podríamos decir que administrar la relación con el cliente tiene que ver con
lo que hace la empresa, y la experiencia del cliente es lo que el cliente siente como
resultado. El intercambio entre un cliente y la empresa se vuelve mutuamente
beneficioso, ya que los clientes proporcionan información a cambio de un servicio
personalizado que satisface sus necesidades individuales. Esta interacción forma la
base de la relación de aprendizaje, basada en un diálogo de colaboración entre el cliente
y la empresa, que se vuelve más inteligente con cada interacción sucesiva” (Don
Peppers y Martha Rogers, 2016,p.23). Lo que tratan de decir, es que si no existe una
estrategia enfocada en el cliente, lo que haga una empresa con esta información no va
ser aprovechada correctamente, así mismo este ciclo de aprendizaje es continuo,
creciendo en cada interacción comercial, la misma que beneficiara a esta relación, pero
una vez más, esto debe ser aprovechada mediante estrategias comerciales mucho más
personalizadas en segmentos de clientes reconocidos y hasta un alto nivel de
granularidad. En el siguiente gráfico, se muestra la arquitectura de un programa de
fidelización, desde los grupos objetivos, los beneficios, indicadores financieros y de
gestión, hasta las áreas de operaciones, TI y centros de servicio, es decir una política
integrada, enfocada hacia el cliente y su fidelización.
50
Figura 23. Elementos de un programa de fidelización de cliente.
Fuente: Butscher, S. A. (2017, p 59). Programas de fidelización de clientes y clubes.
3.9 Metodologías de Gestión de Proyectos.
Se puede definir un proyecto como, la suma de actividades interrelacionadas a realizar

con una meta en común, y es la de conseguir un nuevo producto, servicio o cual fuese
el resultado esperado.
“Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto,
servicio o resultado único”. Program Management Institute. Guía de Fundamentos para
la Dirección de Proyectos (6ta edición) Pennsylvania: Guía del PMBOK. (2017, p 4)
Sin embargo, para poder alcanzar el objetivo de un proyecto, se debe seguir una
metodología, la cual te asegure el éxito en la gestión del mismo. Hoy en día es común
hablar de metodologías agiles, para el desarrollo de proyectos. Estos conceptos
contrastan con metodologías como la del PMI. A continuación, se desarrollará una
introducción general y la diferencia entre cada una de ellas.
51
Enfoque del PMBOK.
Creada por el Program Management Institute (PMI), en su primera versión del año 1996,
es el estándar del PMI para la Dirección de Proyectos, esta no es una metodología, sino
una norma de dirección de proyectos. Esta norma o estándar, no está restringida solo
para proyectos de TI, puede ser aplicable a cualquier tipo de proyectos, desde la
construcción de una Central Hidroeléctrica, hasta el plan para construir un nuevo salón
de clases en un colegio. Es así pues que no se trata de una metodología, donde hay
que seguir paso a paso para obtener un resultado, es más bien como ya se ha
mencionado un estándar aplicado a la dirección de proyectos, donde el Director de
Proyectos (cargo clave en esta dirección) deberá de acuerdo a su experiencia
seleccionar dentro de las áreas de conocimiento y sus procesos los que más se adecuen
al logro de su objetivo de proyecto.
El PMBOK se basa en el desarrollo de 10 Áreas de conocimiento donde se distribuyen

todos los aspectos de la Dirección de Proyectos, iniciando desde la Integración del
Proyecto, con el “Acta de Constitución del Proyecto”, y pasando a definir cada acción o
plan en las diversas áreas a través de los 49 procesos, desplegados dentro de los 5
grupos definidos dentro del Ciclo de Vida de la Dirección de Proyectos. Cabe mencionar
que este estándar es aplicable a cualquier industria. A continuación, se mencionará
brevemente cada uno de ellos:
Áreas de Conocimiento:
Gestión de Integración del Proyecto. Esta parte es específica para los directores del
proyecto, es donde se definirán los procesos y actividades de la dirección, entre los
cuales destacan el acta de constitución y el de cierre de proyecto.
Gestión del Alcance del Proyecto. Definir el objetivo del proyecto, así como los procesos
que aseguren lograr con el mismo. Define que incluye y que no incluye el proyecto.
Gestión del Cronograma de Proyecto. Define los procesos requeridos, sus tiempos de
ejecución, secuencias, cronogramas y controles para gestionar el proyecto de forma
óptima y llegar a su fecha de cierre acordada.
Gestión de los Costos de Proyecto. Define principalmente el presupuesto del proyecto,

y como se va gestionar y controlar a lo largo de la ejecución del mismo.
Gestión de la Calidad de Proyecto. Asegura que el resultado desarrollado sea el

esperado. Define los procesos y controles para asegurar lo indicado.
52
Gestión de los Recursos del Proyecto. Asegura que los recursos solicitados, ya sean lo
referido a colaboradores o logísticos, sean los adecuados y estén disponibles en el
momento y lugar idóneo para la ejecución del proyecto.
Gestión de las Comunicaciones del Proyecto. Asegura que la comunicación a lo largo

del desarrollo del proyecto sea la adecuada. Consta principalmente de dos partes:
Desarrollar una estrategia para asegurar que la comunicación sea eficaz para los
interesados, es decir que reciban la información que sea necesaria para cada rol. Y la
segunda Implementar la estrategia de comunicación, a través de los medios y canales
adecuados para el despliegue.
Gestión de los Riesgos del Proyecto. Enfocado en analizar, identificar y monitorear los
riesgos, así como asegurar el plan de implementación de respuestas a cada uno de
ellos. En suma, es asegurar los factores de éxito del proyecto y minimizar los riesgos
del mismo.
Gestión de las Adquisiciones del Proyecto. Se refiere a los procesos para la compra de
productos o servicios necesarios para la culminación del proyecto, los mismos que no
participan del producto final, pero que son necesarios para completar el proyecto. Entre
los cuales están las cotizaciones, identificación de proveedores con experiencia y la
documentación necesaria para legitimar la compra.
Gestión de los Interesados del Proyecto. Es de suma importancia identificar a las

personas que pueden afectar o ser afectados por el proyecto. A estos se les denomina
interesados, dado que de una u otra forma tienen un impacto en el proyecto. Este
proceso debe ser continuo y debe buscar involucrar a los mismos.
Ciclo de Dirección de Proyectos. La dirección de proyectos, está conformada por 49

procesos desplegados en 5 grupos.
Inicio Planificación Ejecución Monitoreo Cierre
Figura 24. Grupos de procesos de la Dirección de Proyectos.

53
Cabe señalar que un proceso es un conjunto de actividades relacionadas con un objetivo

común. Cada proceso dentro del enfoque PMI está conformado por entradas,
herramientas, técnicas y salidas. Los que a su vez pueden interactuar entre sí.
Figura 25. Estructura de un Proceso PMI.
Procesos de Inicio. Sirven para definir el inicio de un nuevo proyecto, o una nueva fase
de uno existente. Constan de 2 procesos
Procesos de Planificación. Establecen el alcance del proyecto, redefinen objetivos, sin

que diste mucho del inicialmente planteado y define el cronograma. Constan de 24
procesos.
Procesos de Ejecución: Procesos que aseguran completar los trabajos definidos para
alcanzar los objetivos del proyecto. Constan de 10 procesos.
Procesos de Monitoreo y Control. Procesos que hacen seguimiento a los trabajos

realizados, asegurando que se encuentren dentro de lo programado en tiempo y
esfuerzo. Identificar las áreas donde se requieran cambios en el plan de acción e
iniciarlos según los planes de respuesta. Consta de 12 procesos.
Procesos de Cierre. Proceso que se encarga de cerrar formalmente el proyecto.

Asegurando que cada proceso, culminó satisfactoriamente. Consta de 1 proceso.
La salida de un proceso por lo general es la entrada de otro, de esta forma los procesos
se encuentran mayormente relacionados entre unos y otros. Así mismo los grupos de
procesos se pueden traslapar a lo largo del desarrollo del proyecto, como se puede
visualizar en el siguiente gráfico.
54
Figura 26. Interacción de los grupos de procesos.
Fuente: Guía de los Fundamentos para la Dirección de Proyectos (6ta edición)

Pennsylvania: Guía del PMBOK (2017, p 555).
A continuación, se muestra la matriz de procesos del PMI, también se adjunta como

anexo N° 3, para facilitar su visualización. Esta matriz muestra la relación entre grupo
de procesos y áreas de conocimiento.
Figura 27. Correspondencia entre Grupos de Procesos y Áreas de conocimiento.

55

Metodología SCRUM.
La primera vez que se cita el termino SCRUM (melé, que hace referencia a una jugada
de rugby), fue en un artículo publicado por la Harvard Business Review, en el año 1986.
Cuyos autores fueron Hirotaka Takeuchi y Ikujiro Nonaka. En dicho artículo, hace
referencia a la nueva visión que se daba en el desarrollo de nuevos productos, dentro
de las empresas de manufactura tecnológica y automotriz japonesas, donde dejan de
lado las clásicas teorías de administración piramidal, secuencial, objetivos duros, para
dar paso a un enfoque de equipos multidisciplinarios, colaborativos y altamente
comprometidos, con objetivos a corto plazo, para entregar los productos de forma más
rápida, en un entorno altamente cambiante. Se citará tres párrafos de dicho artículo, los
cuales nos ayudaran a cimentar el enfoque ágil:
“El enfoque tradicional, secuencial o de "carrera de relevos" para el desarrollo de un

producto, puede entrar en conflicto con los objetivos de inmediatez y flexibilidad. En
cambio, un enfoque holístico o de "rugby", donde un equipo trata de recorrer la distancia
como una unidad, pasando la pelota de un lado a otro, puede servir mejor a los requisitos
competitivos de hoy en día.”
“Un equipo de proyecto, empieza a trabajar como una empresa, cuando esta toma
iniciativa, asume sus propios riesgos y desarrolla una agenda independiente a la unidad
de negocio a la que pertenece. En algún momento el equipo crea su propio concepto de
manejo. De esta forma un equipo posee una capacidad de auto organización cuando
posee tres características: Autonomía, auto transcendencia (se refiere a fijar sus propias
metas) y fertilización cruzada (equipos multidisciplinarios son más apropiados para la
innovación)”.
“Debido a que los miembros de un equipo se encuentran cercanos a fuentes de

información externa, ellos pueden responder rápidamente a cambios en las condiciones
del mercado. Estos equipos comprometidos con procesos constantes de aprendizaje, a
través de pruebas de ensayo error, encuentran la mejor alternativa de solución del
proyecto. El equipo multidisciplinario, adquiere conocimientos y habilidades que les
ayuda a resolver una variedad de problemas rápidamente. Este aprendizaje se
56
manifiesta en varios niveles (individual, grupal y corporativo) y en múltiples funciones, a

lo que denominan el Multi Aprendizaje.”
The New Product Developement Game, por Hirotaka Takeuchi (Hitotsubashi University)
y Ikujiro Nonaka. Harvard Business Review, enero-febrero de 1986.
En el año 1995, durante la Conferencia OOPSLA (Object-Oriented Programming,

Systems, Languages & Applications) organizada por la ACM (Association for Computing
Machinery). Los señores Ken Schwaber y Jeff Sutherland, hicieron publica esta
metodología, refiriéndola inicialmente hacia el ámbito de TI. Su más reciente aporte
hacia esta metodología, de sus autores fue la publicación The Scrum Guide - The
Definitive Guide to Scrum: The Rules of the Game (2017), de donde se extrae dos
conceptos importantes:
“La esencia de Scrum es un pequeño equipo de personas. El equipo individual es

altamente flexible y adaptativo. Estas fortalezas continúan operando en un equipo, en
varios, en muchos y en redes de equipos que desarrollan, liberan, operan y mantienen
el trabajo y los productos de trabajo de miles de personas. Ellos colaboran e interactúan
a través de arquitecturas de desarrollo sofisticadas y ambientes finales de liberación”.
“Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo

asegura que el conocimiento procede de la experiencia y de tomar decisiones
basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para
optimizar la predictibilidad y el control del riesgo”.
Se puede definir entonces a SCRUM como una metodología ágil, aplicable a entornos
altamente dinámicos y complejos, donde es probable que el objetivo pueda cambiar de
su concepción inicial hacia una nueva, debido a la dinámica del mercado o del escenario
donde se desenvuelva este. Esta metodología no es aplicable a escenarios rígidos con
requisitos estables y productos poco innovadores. Se basa en equipos
multidisciplinarios, que se toman como una unidad, altamente comprometidos con el
proyecto, con alta creatividad y su esquema organizativo es lineal, es decir todos tienen
la misma jerarquía.
Una de las principales características de esta metodología, es que trabaja por

interacciones, es decir no es secuencial, siguiendo los valores del Manifiesto Ágil. Las
características del entregable final, son abordados por fases, y en cada una existe un
entregable, que son priorizadas por riesgo y el valor aportante para el negocio. La
57
planificación entre fases puede ser cambiante, he ahí donde radica su principal
diferencia con un enfoque tradicional.
Para ahondar este tema, se abordará el Manifiesto Ágil, documento redactado en el

2001, por 17 expertos en el desarrollo de software, quienes acordaron que las técnicas
hasta ese momento conocidas ya no eran aplicables, debido a su rigidez y a la distancia
que existía con las realidades cambiantes. Dentro de este manifiesto, se proponen 4
valoraciones y 12 principios, las cuales mencionamos:
Valoraciones:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Principios:
Nuestra mayor prioridad es satisfacer al cliente, mediante la entrega temprana y

continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno
y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y

entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma
indefinida.
58
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.
Recuperado de https://agilemanifiesto.org.
Dentro de la metodología existen tres roles, siete actividades y tres artefactos, los cuales
se mencionarán a continuación.
Roles:
Product Owner. Es el que desempeña la voz del cliente dentro del equipo, el cual debe
conocer muy a detalle las características del producto esperado, capaz de priorizar
actividades de desarrollo. Su rol es muy activo y es el nexo entre el equipo de desarrollo
y los stakeholders (los interesados en que el proyecto se realice, pueden ser internos o
externos).
Scrum Master. Líder del equipo, su función principal es ser un facilitador del equipo (no
es un jefe), debe aclarar dudas procedimentales o buenas prácticas de SCRUM y liberar
impedimentos al equipo de desarrollo.
Development Team. Son los responsables de todas las tareas técnicas (diseño,
desarrollo, pruebas), no tienen un rol específico dentro de estas, pero cada uno lo
desempeña de una forma ordenada y específica, sin embargo, su conocimiento es muy
especializado en algún área, sin descuidar las demás dentro del ámbito de TI. Un equipo
puede estar conformado entre 5 y hasta 9 personas, no suelen ser muy grandes.
59
Figura 28. Roles dentro de la Metodología SCRUM.
Fuente: Rubin, K.S. Essential Scrum: A Practical Guide to the Most Popular Agile
Process (2012, p 15).
Actividades: Dentro de esta área se describirá el framework o plataforma general dentro

de un proyecto SCRUM. Partiendo desde la premisa que es el Product Owner, el que
conoce las necesidades del cliente y las clasifica o prioriza según el riesgo o valor de
negocio del cliente, es decir los de mayor impacto.
Sprint. Se denomina al ciclo que forma parte de un proyecto, pero como tal, tiene un
objetivo, un plazo y sobre todo un entregable o lo que se denomina Producto Terminado.
Un sprint puede iniciar un proyecto o continuar cuando finalice con otro sprint, dentro de
la cadena de actividades identificada. Dentro de un Sprint ya iniciado, no puede
cambiarse los objetivos (Sprint Goal) o plazo. Por lo general, estos no duran más de un
mes y se realizan dentro lo que se denomina un Time Box. El sprint, al ser un ciclo, está
compuesto por otras actividades que se seguirá desarrollando.
Sprint Planning. Se desarrolla con la participación de todo el equipo SCRUM, y es el

plan del desarrollo del Sprint, este tiene como máximo 8 horas de duración para un time
box de 1 mes, luego debe ser proporcional. Durante esta `planificación se desarrollan
dos preguntas: ¿Qué puedo hacer durante el Sprint?, se refiere al alcance del Sprint o
mencionado también como el incremento del Producto Terminado; la definición del
mismo, parte del Scrum Master, pero es consensuado por todo el equipo, quienes es
base a los recursos y plazos máximos definirán los elementos del producto a desarrollar
o el Sprint Goal. ¿Cómo conseguiré completar el trabajo seleccionado? El equipo
SCRUM decide el orden del desarrollo de las características seleccionadas, y el plan
para desarrollar, lo que finalmente serán incrementales del producto terminado, a este
60
último se le denomina Sprint Backlog. Cabe mencionar que cada incremental o Sprint
Goal terminado es un entregable al Stakeholder externo y puedo ser implementado en
el negocio.
Daily Scrum. Es una reunión de máximo 15 minutos, donde participa todo el equipo,
todos de pie, y ayuda a dar una revisión del status del proyecto. Normalmente se
responden tres preguntas. ¿Qué hice ayer para ayudar al equipo alcanzar el objetivo?
¿Qué hare hoy para ayudar alcanzarlo? Y ¿Qué impedimentos tengo o avizoro que
impedirán que se alcance el Sprint Goal? Normalmente respondidas por el equipo de
desarrollo. Estas reuniones permiten tener un feedback rápido del estado del proyecto,
por eso se le denominan Ciclos de Inspección y Adaptación, si luego de esto, es
necesario profundizar el tema, será el equipo de desarrollo quien lo lleve a cabo, pero
fuera del Daily Scrum.
Sprint Execution. Se refiere a la ejecución de las actividades para cumplir con las
características a implementar, dentro de este esta las actividades propias de desarrollo:
codificación, pruebas, despliegue. Todo lo referido a la técnica de desarrollo de software.
Sprint Review. Es una reunión con todos los integrantes del equipo SCRUM, junto con
los Stakeholders, en la cual se muestra el producto terminado, a través de una demo,
mostrando haber alcanzado los objetivos del Sprint. En esta reunión se busca la
conformidad por parte del cliente hacia el entregable.
Sprint Retrospective. Son reuniones dentro del equipo de proyecto para analizar el
despliegue que se está llevando a cabo, si es el correcto o es necesario realizar algún
cambio. No se analiza el entregable, sino la planificación de los Sprint o la concepción
del proyecto.
Product Backlog Gromming. Como ya se ha mencionado el Product Owner es quien

conoce y está cerca al cliente y a sus necesidades inmediatas, es así que puede
reorganizar la lista denominada Product Backlog, priorizando actividades.
Cabe mencionar que un Proyecto SCRUM puede estar conformado por varios Sprint,
de hecho, esa es la ventaja de esta metodología, al dividir un objetivo general, en varios
partes, pero que cada una es de rápida aplicación al negocio.
Artefactos: Son representaciones de la gestión realizada por el equipo, se denominan a

todo aquello que ayude a tener la información de una forma transparente y de rápido
entendimiento, que ayude a conseguir el objetivo.
61
Product Backlog. Es la clasificación que realiza el Product Owner, según las

necesidades del cliente en base al valor del negocio o su impacto para el cliente. Se
puede decir que es una lista agrupada de características a desarrollar del producto final,
donde a cada una de ellas, tiene un valor funcional incremental respecto a la anterior.
Esta lista no es estática y puede ir cambiando de acuerdo a las necesidades del cliente
o del escenario del mismo, a esta reclasificación se le denomina Grooming, consiste en
priorizar, desclasificar, desestimar, agrupar o descomponer actividades a desarrollar.
Sprint Backlog. Parte de lo realizado en el Sprint Planning y en su priorización que este

tiene, consiste en que el equipo de desarrollo toma las características a desarrollar y
define un orden y un plan de ejecución calendarizado, de acuerdo al plan y a los tiempos
límite con los que se cuenta.
Potencially shipeable product increment. Es el artefacto terminado, dentro de las

expectativas del Sprint y como ha sido mencionado, se encuentra en un estado que es
perfectamente explotable por el cliente, es decir cumple las características definidas por
el Product Owner, que pueden ser entregadas al cliente e implementadas en un grado
esperado.
Figura 29. SCRUM Framework.
Process (2012, p 17).
Se citará dos conceptos más relevantes de la metodología: El Product Backlog, el cual

conforma la lista de características de la solución final, agrupadas de acuerdo al impacto
que tienen para el cliente y del cual se generan los Sprint. Este Product Backlog, se
encuentra en constante actualización, la misma que responde a cambios en las
62
necesidades del cliente, o de su entorno, cabe mencionar que, dentro de este artefacto,
se encuentra también una estimación de los recursos de tiempo necesarios para su
implementación, los cuales como ya ha sido mencionado, son cortos, no mayor a un
mes.
Figura 30. Product Backlog.
Process (2012, p 19).
El segundo concepto es el de Sprint, que refiere a ciclos que juntos conforman un

proyecto, cada uno de ellos puede ser tomado como una unidad con un objetivo o Sprint
Goal definido, y a la vez cada uno de ellos incrementa funcionalidades del producto final,
pero que son fácilmente implementadas y puestas en producción, siendo estas una
mecánica altamente atractiva para los clientes finales. Como ha sido mencionado cada
Sprint se ciñe a un plazo de tiempo de desarrollo el cual es denominado Time Boxed.
Figura 31. Sprint.
Process (2012, p 21).
63
En muchos libros se refieren a SCRUM como un Framework, es decir una plataforma o

marco de referencia en su traducción del inglés. Quizás la cita de Kenneth S. Rubin, nos
ayude a entenderlo mejor: “Para comprender mejor el concepto de marco, imagine que
el marco Scrum es como los cimientos y las paredes de un edificio. Los valores,
principios y prácticas de Scrum serían los componentes estructurales clave. No puedes
ignorar o cambiar fundamentalmente un valor, principio o práctica sin arriesgar el
colapso. Sin embargo, lo que puede hacer es personalizar dentro de la estructura de
Scrum, agregando dispositivos y características hasta que tenga un proceso que
funcione para usted.” (Essential Scrum: A Practical Guide to the Most Popular Agile
Process - 2013).
3.10 Diferencias entre las PMBOK y SCRUM.
Para definir rápidamente las diferencias entre ambas, se citará nuevamente el

Manifiesto Ágil, donde toman nuevas iniciativas en lugar de las antiguas formas de
manejar proyectos de software, no válidos para el entorno actual. Sin embargo, hay que
aclarar que ambas son válidas, de acuerdo al escenario en el que uno se encuentre. El
estándar PMI donde el nivel de incertidumbre sea bajo y el conocimiento del producto a
desarrollar sea conocido y el SCRUM sobre todo para proyectos donde se necesita
resultados rápidos, un alto nivel de incertidumbre y cambios con alta cuota de
innovación.
Figura 32. SCRUM Vs PMI.

64
3.11 Metodología de Kimball.
Considerado el principal promotor del enfoque dimensional para el diseño de almacenes

de datos. Los sistemas Data Warehouse, son una copia de los datos guardados en los
sistemas transaccionales, pero luego de haber pasado por ciertos procesos que
aseguren su calidad e integridad, son específicamente estructurados para consultas y
análisis del negocio.
A continuación, daremos una introducción a la metodología de desarrollo de Kimball, el

cual se centra en el llamado modelo de ciclo de vida organizacional, basado en el libro
del mismo autor The Data Warehouse Toolkit.
Las cadenas de valor de las organizaciones identifican el flujo natural de sus procesos
de negocios. Por ejemplo, la cadena de valor de un vendedor mayorista pueden ser sus
ventas y son estas las que deben ser almacenadas. Una cadena de valor de una
empresa de transporte de carga, puede ser registrar cada uno de sus viajes, destinos y
carga. Los sistemas de origen transaccional generalmente producen operaciones o
transacciones en cada paso de la cadena de valor. Debido a que cada proceso produce
métricas únicas en intervalos de tiempo, cada proceso típicamente genera al menos una
tabla de hechos atómicos (que son las operaciones detalladas a cierto nivel de
profundidad).
La arquitectura bus de almacenamiento de datos de la empresa, proporciona un enfoque

incremental para construir el sistema DWH (ver anexo 4). Esta arquitectura descompone
el proceso de planificación en partes manejables al centrarse en los procesos de
negocios, al tiempo que ofrece integración a través de dimensiones conformadas
estandarizadas que se reutilizan en todos los procesos. Proporciona un marco
arquitectónico, que descompone el programa para alentar implementaciones ágiles,
manejables correspondientes a las filas en la matriz bus del almacén de datos de la
empresa. La metodología, está basado en cuatro principios:
La solución debe estar centrada en el negocio, para esto debemos asegurarnos de

entenderlo.
Construir una infraestructura de información adecuada, a los requerimientos.
Realizar entregas en incrementos significativos (plazos menores a 12 meses)
Ofrecer la solución completa (almacén de datos, herramientas de consulta, informes y

análisis avanzado, capacitación, soporte, sitio web y documentación).
65
A continuación, indicaremos las etapas de la metodología:
Planificación del Proyecto. Se determina el propósito del proyecto, sus objetivos

específicos y el alcance, los principales riesgos y una aproximación inicial a las
necesidades de información. Los objetivos del proyecto se pueden desarrollar
fácilmente tomando en consideración las necesidades de las áreas de negocio, que
normalmente se hacen estas afirmaciones:
Recopilamos toneladas de datos, pero no podemos acceder a ellos.
Necesitamos dividir y cortar los datos en todas direcciones.
Necesito acceder a los datos fácilmente.
Definición de Requerimientos del Negocio. La definición de requerimientos, es un

proceso de entrevistar al personal de negocio y técnico. Estas son algunas
características que la solución de DWH debe cumplir:
Información accesible, comprensible y oportuna.
La información debe ser consistente y creíble. Estructura adaptable al cambio.
Debe ser una plataforma segura que proteja los activos de información.
Debe ser la base autorizada y confiable para mejorar la toma de decisiones.
Debe ser aceptado por las áreas comerciales para considerarlo exitoso.
Modelado Dimensional. Para desarrollar el diseño dimensional se debe considerar

cuatro etapas:
Elegir el proceso de negocio, consiste en elegir el área a trabajar. Esta decisión es

tomada por la dirección, y depende fundamentalmente del análisis de requerimientos.
Establecer el nivel de granularidad, es decir especificar el nivel de detalle. La elección

de la granularidad depende de los requerimientos del negocio y lo que es posible a partir
de los datos actuales. La sugerencia general es comenzar a diseñar el DW al mayor
nivel de detalle posible, ya que se podrían realizar agrupamientos posteriores, al nivel
deseado.
Elegir las dimensiones, las dimensiones surgen naturalmente de las reuniones del
equipo, y facilitadas por la elección del nivel de granularidad y de la matriz de procesos.
66
Las dimensiones tienen un conjunto de atributos, que brindan una idea del tipo de
análisis que se realizara sobre la tabla de hechos.
Identificar medidas y las tablas de hechos, son las medidas o indicadores que surgen
de los procesos de negocios. Una medida es un atributo que se desea analizar,
sumando o agrupando sus datos a razón de las dimensiones creadas. Estas medidas
son analizadas de acuerdo a la granularidad y se encuentran en las tablas de hechos.
Cada tabla de hechos tiene como atributos una o más medidas de un proceso, de
acuerdo a los requerimientos. Un registro de esta tabla contiene una medida expresada
en números, como cantidad, tiempo, dinero, etc., sobre la cual se desea realizar una
operación de agregación (promedio, conteo, suma, etc.) en función de una o más
dimensiones.
Para esta etapa, se deben realizar talleres colaborativos de modelado dimensional, en

colaboración con expertos en la materia y representantes de la gestión de datos de la
empresa. El modelado debe desplegarse a través de una serie de talleres altamente
interactivos con representantes comerciales. Estos talleres brindan una oportunidad
para desarrollar los requisitos solicitados. Los modelos dimensionales no deben
diseñarse de manera aislada por personas que no entienden completamente el negocio
y sus necesidades.
Los modelos dimensionales implementados en sistemas de administración de bases de

datos relacionales se conocen como esquemas en estrella debido a su parecido con
una estructura similar a una estrella. Los modelos dimensionales implementados en
entornos de bases de datos multidimensionales se denominan cubos de procesamiento
analítico en línea (OLAP), como se ilustra en el anexo 5.
Diseño Físico. En esta etapa, se revisa la plataforma sobre la cual, estará el DWH,
normalmente para diseñarlo, ayuda responder estas preguntas:
¿Determinar la capacidad y escalabilidad del sistema de DWH?
¿Cuáles son los factores que llevarán a una configuración más grande y más compleja?
¿Cuánta memoria y servidores se necesitan? ¿Qué tipo de almacenamiento y

procesadores?
¿Cómo instalar el software en los servidores de desarrollo, prueba y producción?

67
¿Qué necesitan instalar los diferentes miembros del equipo de DWH en sus estaciones
de trabajo?
¿Cómo convertir el modelo de datos lógico en un modelo de datos físicos?
¿Debe usarse la partición en las tablas relacionales?
Diseño e Implementación del subsistema de Extracción, Transformación y Carga (ETL).

Las acciones de Extracción, Transformación y Carga (ETL por sus siglas en inglés) son
los procesos de entrada del Data Warehouse. Se busca que el diseño de esta etapa,
tenga acciones de data cleaning, antes de procesar la información, cabe resaltar que
las fuentes u orígenes de datos, pueden ser variados. Luego de los procesos de
extracción, limpieza, procesamiento, se puede cargar la información al DWH en un
formato acorde para la utilización con las herramientas de análisis.
Implementación. La implementación representa la convergencia de la tecnología, los

datos y las aplicaciones de usuarios finales accesible desde el escritorio del usuario del
negocio. Existen varios factores extras que aseguran el correcto funcionamiento de
todas estas piezas, entre ellos se encuentran la capacitación, el soporte técnico, la
comunicación y las estrategias de feedback del equipo.
Mantenimiento y Crecimiento del Data Warehouse. Para administrar el entorno del

DWH, es importante enfocarse en los usuarios de negocio, los cuales son el motivo del
mismo, además de gestionar adecuadamente las operaciones, medir y proyectar las
operaciones y recibir el feedback de los usuarios. Finalmente, es importante definir las
bases para la escalabilidad del DWH, la clave es manejar el crecimiento utilizando el
Ciclo de Vida propuesto en orden prioritario de la organización.
Especificación de aplicaciones de BI. Se refiere a levantar las necesidades finales y a

elegir la herramienta adecuada de presentación o explotación de datos, según sea las
características y funcionalidades que el usuario final requiera.
Desarrollo de aplicaciones de BI. Las aplicaciones de inteligencia de negocios, son la

cara visible del DWH, son la forma de acceso de los usuarios finales, a través de
informes, dashboard y aplicaciones de análisis, que buscan entregar información útil a
los usuarios. Se puede dividir estas aplicaciones en dos categorías basadas en el nivel
de sofisticación, y les llama: Informes estándar, son informes simples, predefinidos, y
con parámetros de consulta fijos. Aplicaciones analíticas, son más complejas, pueden
68
incluir algoritmos y modelos de minería de datos, que ayudan a identificar

oportunidades.
Diseño de la Arquitectura Técnica. La arquitectura técnica cubre los procesos y

herramientas que se aplican a los datos. En el área técnica existen dos conjuntos que
tienen distintos requerimientos, brindan sus propios servicios y componentes de
almacenaje de datos: El área de soporte es el responsable de la obtención y
preparación de los datos, conocidos como adquisición de datos y el área de explotación
de datos, es responsable de entregar los datos a los usuarios.
Selección de Productos e implementación. Es la implementación final de los procesos

diseñados sobre la plataforma de base de datos definida, con las herramientas de
gestión, explotación y análisis.
69
CAPITULO IV. DESARROLLO DEL PROYECTO
Como se ha mencionado anteriormente, el proyecto nace de una necesidad de contar

con información a primera mano, con ciertos indicadores, que escapaban del alcance
del Data Warehouse ya existente y que necesitaba tiempo de análisis y procesamiento
por parte del área de Inteligencia de Clientes, siendo así, se presentó la solicitud del
proyecto por parte de la gerencia general del banco Falabella, siendo la gerencia de
Inteligencia de Clientes, la que llevaría a cabo dicha solución.
Se escogió al software QlikView como herramienta de explotación, dado que ya existía

experiencia en el grupo Falabella con esta herramienta. Pero dos fueron las
características que llevaron a elegir dicha herramienta:
La primera, fue que contaba con una estructura propia, la carga de archivos la llevaba
a un formato propio de la herramienta, por la cual el tratamiento era más rápido, además
contaba con una herramienta del tipo ETL, la cual era muy potente para llevar a su
propia arquitectura la data a analizar.
La segunda, fue que la interfaz de usuario no era compleja, así como su entorno de
desarrollo, por lo cual se ajustaba a los objetivos del proyecto, de contar con una
herramienta que no fuese especializada y que su posterior mantenimiento pueda
hacerse con personal del staff del área de Inteligencia de Clientes, con un bajo
presupuesto de desarrollo.
Estas dos características, sumadas a la referencia con que se contaba fue determinante
para elegirla como solución definitiva.
El siguiente punto a tratar fue, la empresa a desarrollar el proyecto, para el año 2013,
no había mucho conocimiento de herramientas alternas en explotación de datos y
menos empresas que las desarrollen, de hecho, se encontraba en realce el concepto de
Inteligencia de Clientes o Business Intelligence, como lo es ahora el Big Data o
Analytics. En algunos casos algunos consultores o docentes sugerían suplir al DWH por
una de estas herramientas, sin embargo, como ya ha sido mencionado es un error, dado
que previo al análisis de datos existe un tratamiento o limpieza de data, tal cual lo sugiere
la metodología de Kimball. Siendo así el esquema que proponía el proyecto encajaba
en realizar un mix entre el DWH ya implementado y una herramienta self service de
explotación de data. Tal como lo sugiere Kimball en lo que se refiere al desarrollo de
aplicaciones BI. Se tomó los servicios de la empresa ABC Consultores, dado que ya
70
habían realizado trabajos en otras empresas no necesariamente del rubro, pero si

contaban con el expertise de desarrollo.
4.1 Identificación de Stakeholders.
La distribución de los stakeholders (personas interesadas en que se realice el proyecto)

quedaron de la siguiente manera:
Bruno Funcke Ciriani. Se desempeñó como Gerente General del Banco Falabella Perú,
durante los años 2011 al 2016, siendo el sponsor principal de que se realice el proyecto.
Felipe Venturo. Se desempeñó como Gerente de División de Marketing, bajo su

gerencia se encontraba las gerencias de Publicidad, Productos Financieros, Fidelización
e Inteligencia de clientes, entre otros. Fue la persona quien tenía bajo su alcance el área
del desarrollo del proyecto.
Javier Lugón. Sub Gerente de Gestión de Cartera y Tarjeta de Crédito, estaba a cargo
de llevar el control de la gestión de clientes, reducir la tasa de fuga de clientes, así como
la de inactividad, incrementar los indicadores de cuentas con saldo y activación de
tarjetas de crédito. A través de campañas dirigidas a segmentos objetivos, dependiendo
el target se aplicaban ciertos estímulos comerciales para lograr los objetivos de la
campaña. Por ejemplo, una persona podía haber aceptado la tarjeta de crédito CMR,
por cualquier canal de captación, pero aun no recogía el plástico, por ende, no podía
considerarse un cliente 100% captado, luego habría que asegurar el primer uso de la
tarjeta. Normalmente las campañas de recojo iban de la mano de activación, con ofertas
en el retail Falabella, lo que te aseguraba cierta tasa de respuesta. El interés en este
producto, era tener siempre los indicadores ya mencionados y hacer seguimiento sobre
ellos y tomar acciones sobre segmentos específicos.
Hernando Serna. Sub Gerente de Retail Falabella, la responsabilidad de este cargo, era
asegurar que los clientes de la Tarjeta CMR, usen la tarjeta en el retail Falabella. Este
punto era importante dado que se esperaba que un alto % de tarjeta habientes de la
Tarjeta CMR, la usen en el mismo retail, para crear principalidad en el uso de la CMR y
posteriormente hacia todas las necesidades del cliente y sea la CMR su principal medio
de pago en cualquier establecimiento físico o virtual. El interés de este producto, era
hacer seguimiento al segmento de cuentas con saldo y ver el % de deuda por consumos
en el retail. Para realizar campañas en segmentos que están fugando de alguno de los
formatos (Saga, Tottus, Sodimac) y realizar campañas de reincorporación y evitar
perderlos.
71
José Carlos Castillo. Sub Gerente de Productos Pasivos, era el responsable de llevar
las campañas de colocación de crédito efectivo, en cualquier modalidad, ya sea
supercash, rapicash o compra de deuda, la diferencia de estas campañas, eran el
método de acceso en las dos primeras, mientras que la última era un traslado de deuda.
El interés en este producto, era tener presente el % de colocación de préstamos en
ciertos segmentos de la cartera, para posteriormente realizar campañas en ciertos
segmentos, como, por ejemplo, clientes con muchas transacciones, alta línea de crédito,
pago en cuotas y un segmento de consumo especifico podrían ser candidatos con mayor
probabilidad de tomar un crédito efectivo.
4.2 Alcance del Proyecto.
El proyecto tenía como finalidad, mejorar la administración de la Gestión de Cartera de

clientes, principalmente de la Tarjeta CMR, reducir trabajos recurrentes del equipo de
Inteligencia de Clientes, así como potenciar la labor de los analistas de negocio, con
información y Dash board para una correcta administración de los productos del banco.
Para esto se definieron ciertos alcances que a continuación se indican:
Cargar de forma diaria la cartera de clientes, que se encuentra en el Data Warehouse,

junto a información relevante de la cartera de clientes, datos de identificación personal
(DNI, carne de extranjería), datos de segmentación (edad, genero, ingresos, localidad
de residencia, estado civil, entre otros), información comercial (línea de crédito, saldo
de deuda, rotación de línea de crédito, ticket promedio, entre otros), información
financiera (número de tarjetas de crédito, porcentaje de deuda CMR, respecto al total
de deuda, entre otros). Estas cargas debieran ser diarias y respecto a la información del
DWH, hacia un repositorio donde la nueva herramienta pueda trabajar con esta data.
Calculo de indicadores a medida, por ejemplo, la segmentación de clientes de acuerdo

a un RFM comercial, periodo de inactividad comercial, ticket promedio por formato de
tienda, última fecha de compra, por formato de tienda, entre otros.
La elaboración de uno o más Dashboard, que permita realizar un análisis dinámico de

la cartera de clientes, donde se grafiquen los indicadores mencionados y pueda
realizarse cortes de análisis por determinados segmentos predefinidos.
La posibilidad de extraer clientes segmentados de tal forma, que se agregue valor a

ciertas posiciones como analistas de negocio con un self service de análisis y extracción
de data, reduciendo de esta forma la participación de analistas del área de Inteligencia
de Clientes en estos trabajos de generación de bases de campaña.
72
La solución sea escalable, de acuerdo a nuevas necesidades que se puedan presentar,

la posibilidad de realizar nuevos dash board, para eso se necesitaba que el proyecto
sea desarrollado in house y con un seguimiento cercano del líder de proyecto por parte
del Banco.
La solución sea auditable cada cierto tiempo, para asegurar la integridad de datos y los
niveles de servicio, para esto se validará la extracción y procesamiento de datos, frente
a un procesamiento pre definido por el área de Inteligencia de Clientes, el cual
diagnosticara si existe un % de discrepancias entre ambos análisis conglomerados.
Desarrollar y hacer seguimiento a todos los Jobs que se puedan generar como
solicitudes de servicio al Data Warehouse, como ha sido mencionado esta solución se
alimentara del DWH del Banco Falabella, es necesario asegurar que los Jobs solicitados
sean lo más eficientes posibles de acuerdo a la arquitectura de la solución
implementada.
Un adecuado tiempo respuesta frente a observaciones que se presenten en los primeros

meses de implementación, hasta por seis meses luego de la puesta en marcha del
proyecto.
4.3 Diagrama de secuencia lógica del proyecto.
A continuación, se detalla gráficamente, como se desarrolla una campaña de la gerencia

de Marketing, iniciando desde la emisión del requerimiento, hasta la atención por las
áreas de Inteligencia de Clientes y Publicidad.
Como ya se ha indicado anteriormente, las campañas pueden ser generadas desde la

gerencia de cualquier producto del Banco Falabella, entre las que se presentaban con
mayor frecuencia son las de Ampliación de Línea de crédito de Tarjeta, sobre activación
de cuentas y evitar que sean bloqueadas por inactividad, entre otras.
El objetivo del presente proyecto, es mejorar la gestión de la cartera de clientes del

banco, ayudar en la generación de campañas, siendo más eficientes en la extracción de
la base de clientes objetivo y descongestionar de esta forma los requerimientos dirigidos
hacia el área de Inteligencia de Clientes, tanto en la generación como en el cálculo de
la tasa respuesta de la campaña.
De tal forma que se presenta dos vistas, la primera se refiere al desarrollo del proceso
antes de la implementación del proyecto, en esta se notara una fuerte presencia del
73
área de BI, creando inclusive un cuello de botella para emitir campañas, las mismas que
son respuestas comerciales a determinados segmentos de clientes.
En la segunda vista se mostrará como muchas de los procesos que desarrollaba BI,
ahora son realizados por el área de negocio, apoyado en la herramienta a desarrollar, y
asistido por el área de BI en la generación de consultas en la herramienta del Business
Objects, para que la tasa respuesta sea calculada por el mismo analista. De esta forma
podrá hacerse diferentes corridas para el cálculo de la respuesta de la campaña por el
mismo analista de negocio.
74
Flujo del proceso de una campaña antes del proyecto.
Figura 33. Generación de Campaña antes de implementación.

75
Flujo del proceso de una campaña después del proyecto.
Figura 34. Generación de Campaña Post Implementación.

76
En el siguiente gráfico, se hace énfasis en el cambio realizado, siendo el área

sombreada, las tareas que pasaron hacer desarrolladas por el analista de negocio,
usando la herramienta QlikView.
Figura 35. Nuevas funciones Analista Producto.
A continuación, se muestra el flujo de carga de datos de la base clientes sobre QlikView,

con procesos diarios y automáticos, con la ejecución de los mismos por parte de un
analista del área de operaciones informáticas, quienes son los encargados de realizar
estos procesos en un ambiente controlado.
Figura 36. Carga de datos a Base QlikView.

77
4.4 Equipo y roles
Como se ha mencionado en el capítulo del marco teórico, la metodología empleada en

el desarrollo de sistemas Data Warehouse, es Kimball, debido a su enfoque de ciclo de
vida, y como este aborda recurrente a los procesos de negocio de una empresa y en el
desarrollo de su esquema de datos y la reutilización de dimensiones con otros
esquemas, formando de esta forma una colección de datos organizacional completa o
llamado Data Warehouse. En este proyecto se siguió la metodología desde el punto del
desarrollo de aplicaciones de BI, dado que el DWH ya estaba implementado.
Tomando a Kimball, como referencia, sobre un DWH implementado, era necesario

desarrollar un proyecto de BI o explotación y análisis de datos. Para esto se tenía como
referencia la implementación realizada con un enfoque similar en otra empresa del
Grupo Falabella en Chile. Se indicó también como uno de los puntos del alcance del
proyecto, que durante la etapa del desarrollo, participe una persona del staff del banco
para asegurar la retención del know how y la escalabilidad de la solución, por cuenta del
banco una vez culminado el proyecto. Asegurando que el código y el conocimiento de
la solución quede dentro del área de Inteligencia de Clientes. De esta forma se diseñó
un modelo hibrido de gestión y control de proyectos, entre el estándar del PMI, dado
que se llevaba un control de las operaciones y validación de los mismos, así como era
necesario una participación cercana del usuario durante la implementación del modelo,
como lo sugiere el modelo agile de Scrum.
Para realizar el proyecto se contrató los servicios de la empresa ABC Consultores, que
puso a disposición a full time a un desarrollador y por parte del banco Falabella a dos
personas para asegurar los puntos del alcance, a continuación, se detalla el equipo del
proyecto:
Cesar Armas, Ingeniero Informático, tenía el cargo de Gerente de Fidelización e

Inteligencia de Clientes, fue quien tuvo la responsabilidad de liderar el proyecto desde
un punto de dirección ejecutiva, mantuvo el rol de Gerente de Proyecto.
Pedro Guerrero, Licenciado en Estadística, se desempeñó como Jefe de Inteligencia de

Clientes, y fue quien estuvo a cargo de liderar el proyecto operativamente, encargado
de acumular el know how del desarrollo y hacer seguimiento a la puesta en servicio de
la solución, desempeñándose las veces de un Scrum master.
Miguel Palacios, Bachiller en Ingeniería Informática, a la fecha del proyecto se

desempeñó como Jefe de Gestión de Cartera y Tarjeta de Crédito, fue el encargado de
78
liderar la parte de TI del proyecto, realizar las coordinaciones y asegurar que se cumplan
las tareas requeridas al equipo de Data Warehouse del Banco Falabella. Dar soporte en
el esquema de la solución en cuanto se refiere al modelo a desarrollar del repositorio de
datos, diseño de dashboard, control de pruebas y validación de la solución, dado que
su rol le permitía tener un conocimiento técnico y de negocio dentro del banco Falabella,
Su rol fue la de un Analista de Información y Negocio.
Maruja Vegas, Ingeniero Informático, desempeñaba el rol de Jefe de Data Warehouse,

fue el nexo con la Gerencia de TI, y era el soporte necesario para adecuar y desarrollar
los procesos de carga del DWH hacia la plataforma de QlikView. Su rol fue como
Ingeniero de Desarrollo de Banco Falabella.
Ruiz Huillca, Ingeniero Informático, fue el profesional por parte de la consultora,

encargado de desarrollar el proyecto. Su rol fue la de Ingeniero de Desarrollo. Era quien
conocía la herramienta y tenía el expertise en la herramienta para llevar a cabo el
desarrollo de la solución. Así como la asesoría en el diseño de la solución por parte del
staff de la empresa consultora
Como se puede apreciar el enfoque del proyecto, fue crear un equipo que asegure llevar
a cabo el mismo, estrictamente bajo el enfoque que necesitaba el Banco Falabella, no
es en vano que el equipo por parte de la consultora este 100% en las instalaciones del
banco, la dirección del proyecto estuvo sesgado en un enfoque estadístico e informático,
por un lado se sabía lo que se necesitaba, pero se quería asegurar que este cumpla con
temas técnicos, que permitieran asegurar la eficiencia del proyecto y sobre todo, que el
know how del mismo, pase a convertirse en un activo de la empresa. Logrando de esta
manera su continuidad mediante la actualización de indicadores y dashboard realizados
ya con recursos propios del banco, una vez terminado el proyecto y cuando fuese
necesario ser actualizados o modificados.
79
4.5 Cronograma de actividades
Se adjunta el gantt propuesto para el proyecto, el mismo sufrió algunas modificaciones,

para fines académicos, se muestra lo más relevante. Cabe señalar que el cronograma
fue elaborado entre la empresa consultora y la Gerencia de Inteligencia de Clientes.
Tabla 9: Cronograma del Proyecto.

80
Fuente: Empresa Consultora.
4.6 Arquitectura de QlikView
A continuación, se detalla la estructura del producto QlikView, desde un punto de vista

técnico:
QlikView Developer, es la herramienta que ayuda al desarrollo de scripts para la

extracción y manipulación de datos, para luego explotarlos, generando archivos QVW /
QVD. Es la plataforma donde se desarrollan y diseñan los dashboard.
QlikView Server, se encarga de suministrar acceso cliente servidor a la aplicación, es el

motor analítico en memoria. Almacena los documentos y los pone a disposición de los
usuarios finales. También contribuye a la planificación y organización de las recargas
de datos, aunque dicha planificación es gestionada habitualmente por QlikView
Publisher.
81
QlikView Publisher, recarga de datos y ejecuta las transformaciones, diseñado para

manejar escenarios complejos de despliegue de contenidos. Amplía y mejora las
capacidades de planificación del QlikView Server y proporciona una seguridad adicional
para contenidos QlikView basados en usuarios y grupos de usuarios.
QlikView Access Point, proporciona servicios internos adicionales de soporte, como el

equilibrio de carga entre sesiones de usuarios en múltiples QlikView Servers.
Son dos tipos de archivos principalmente, en los que se basa las aplicaciones de
QlikView.
QVW, son archivos que contienen los informes, gráficos, indicadores, clave, script de
carga, es decir el proyecto y los objetos que lo conforman.
QVD, son los archivos con la data ya importada por el motor de QliView, y en un formato
que se encuentra optimizado para su uso por la herramienta.
Figura 37. Arquitectura QlikView.
Fuente: La Arquitectura del QlikView (Whitepaper Tecnológico sobre QlikView).

82
Figura 38. Ciclo del QilkView.
Figura 39. Funcionalidad del QlikView.

83
4.7 Requerimientos a DWH
Los requerimientos al área de Data Warehouse, fue para crear los Jobs con información
de la base de clientes, estos eran ejecutados de forma diaria, después de cada carga
del repositorio y los archivos con la data eran dejados en un stage pre definido, donde
accedía el QlikView Publisher. Así, esta data pueda ser cargada por el QlikView en los
formatos ya indicados (QVD),
A continuación, se da una muestra clasificada de los datos exportados del DWH.
Data Clientes Data de Consumos Indicadores SBS
• ID Cliente • Consumos Saga • Línea de Tarjeta • Máxima Línea

• Edad Falabella de Crédito RCC
• UBIGEO • Consumos • Deuda de • SOW Tarjeta
Residencia Tottus Tarjeta de Crédito
• UBIGEO Laboral • Consumos Crédito
• Tipo de Cuenta Sodimac • Saturación de
• Situación de • Consumos Línea de Tarjeta
Cuenta Rapicash de Crédito
• Antigüedad de • Consumos • Rango
Cuenta Supercash Behaviour
• Tienda Favorita • Consumos • Habito de pago
Convenios promedio
• Tienda Cercana
• Pago Promedio
Figura 40. Muestra de datos generados por DWH para archivo QVD.
Con esta data podía generarse indicadores adicionales de los clientes, este era el valor
agregado de la solución, dado que tenía información actualizada (consumos, situación
del cliente, entre otros) y generaba indicadores comerciales potentes, con los cuales,
las campañas que podían generarse, además de ser más eficientes en su generación,
lo eran con los segmentos objetivos. Por ejemplo, Una campaña para incentivar clientes
a comprar en un determinado formato del retail Falabella. Se muestra algunos de los
indicadores calculados.
84
Indicadores de Clientes Indicadores de Indicadores SBS

Consumos (promedios
últimos tres semestrales)
•Rango edad •Consumos promedio •Inactividad de Cuenta •Rango Máxima Línea

•Segmento Saga Falabella •Inactividad Saga RCC
demográfico Laboral •Consumos promedio •Inactividad Tottus
Tottus •Rango SOW Tarjeta
•Segmento •Inactividad Sodimac Crédito
demográfico •Consumos promedio
•Inactividad Banco
Residencial Sodimac
•Rango antigüedad de •Consumos promedio
Cuenta Rapicash
•Tiendas próximas •Consumos promedio
•Segmento Retail Supercash
•Segmento RFM •Consumos promedio
Convenios
Figura 41. Muestra de Indicadores generados en QlikView.
4.8 Desarrollo (DashBoard)
El desarrollo del proyecto fue realizado por la empresa desarrolladora ABC Consultores,
quien en forma conjunta con los demás miembros del equipo se diseñó los Tableros de
control, siendo uno de los objetivos, que, al segmentar la cartera de clientes, por
cualquiera de los filtros o indicadores mostrados en las ilustraciones 40 y 41, se pueda
generar la base de clientes de campaña. Cabe resaltar que los dashboard para Saga
Falabella, Hipermercados Tottus, Sodimac, Rapicash, eran estructuralmente similares,
dado que el objetivo era ver el comportamiento de la cartera en cada uno de los formatos
del retail Falabella.
Las siguientes son pantallas de los principales dashboard desarrollados.
La figura 42, nos muestra un primer tablero de control, el cual reflejaba la cartera de
clientes de la tarjeta de crédito CMR y su iteración con el retail. Se contaba con una
segmentación comercial de los clientes en cada tienda de acuerdo a los consumos que
realizaran, el mismo grafico se encuentra como el anexo 06, para una mejor
visualización.
85
Figura 42. Dashboard Integral Falabella.
La estructura del siguiente tablero, muestra información de un producto en particular,

pero a este le suma la variación en compras de los últimos dos semestres. Es decir, se
contaba con una segmentación por recencia y frecuencia de compras, y a la vez
calculaba la variación en montos de compra de los últimos dos semestres comerciales,
el mismo grafico se encuentra como el anexo 07, para una mejor visualización.
Figura 43. Dashboard Gestión de Cartera Rapicash.

86
Figura 44. Flujo de filtrado de Base por variables de negocio.
Fuente: Información Banco Falabella
En la ilustración anterior se muestra el flujo de filtrado de base, ya sea por cualquiera de

las variables de segmentación, para el ejemplo se tomó Situación de cliente, tipo de
cuenta y el rango behaviour (indicador del comportamiento comercial del cliente entre
compras, pagos, mora, etc.). Se puede observar que la selección es intuitiva, se muestra
los filtros seleccionados y que pueden ser corregidos.
Figura 45. Base seleccionada y exportada a MS Excel.

87
Finalmente, como ya se ha mencionado, el objetivo es que la solución ayude en la

generación de la base, omitiendo de esta forma en todo el proceso de generación de
campaña al área de Inteligencia de Clientes.
En la siguiente ilustración se muestra la base exportada a un archivo Excel, en donde

puede ser tratada por el analista de negocio. Y pueda ser calculada la tasa de respuesta
de la campaña, con los archivos de consumos generados en la herramienta business
Objects, de acuerdo a las condiciones comerciales que procedan. De esta forma se
cierra el ciclo de una campaña desde la concepción hasta el cálculo de la tasa respuesta
Figura 46. Base de clientes según los filtros indicados, exportada a excel.
Los costos estimados de la implementación del proyecto, se encuentran en el anexo 8,

los costos de licenciamiento, equipo servidor, costo de consultoría. Así como el impacto
de ahorro operativo de la solución.
88
4.9 Riesgos y planes de acción post implementación.
Es necesario indicar, que la solución desarrollada en QlikView, no era un sistema core

dentro del Banco Falabella, es decir, la inoperatividad de esta, no bloqueaba funciones
claves, dentro de las jefaturas de producto, era sin embargo un sistema de valor
agregado que ayudaba a la Gestión de Cartera de clientes a un mejor desempeño.
Siendo así no era necesario desarrollar esquemas de contingencia que suplan a este
aplicativo, más allá de un sistema clásico de aseguramiento de continuidad de servicio
del servidor de la solución.
Sin embargo, al ser su uso tan importante en las campañas de productos, era necesario
asegurar su buen desempeño y cálculo de indicadores, de esta forma se desarrolló un
procedimiento de validación de data, el cual era ejecutado mensualmente, para detectar
alguna variación en los resultados que mostraba el aplicativo.
Para explicar, esta validación, se detallará una de las pruebas principales que se realizó
a la solución, la de corroborar los datos obtenidos por esta, comparándolo inicialmente
con un proceso semi automático, que había sido el origen de la lógica del proyecto y
que ayudo a la definición de la misma (recencia de consumos).
Es decir, los valores durante el periodo de prueba fueron validados con los obtenidos
por la jefatura del área de Gestión de Cartera, quienes usando el software estadístico
SPSS y SQL Server, lograron realizar un primer barrido según el nuevo enfoque de
análisis (gestión de cartera con la identificación de consumos por tienda retail).
Esta primera validación y que dio luz verde al aplicativo, fue la misma que
posteriormente se ejecutaba a demanda dentro del área de Inteligencia de clientes.
A continuación, se mostrará algunos de los resultados que se obtuvieron, en la primera

validación indicada, así como el flujo de ejecución mensual. Cabe señalar que no se
presentó, variaciones en las pruebas, siendo admitido un margen de variación del 0.1%
de valores totales de clientes en cartera.
89
Tabla 10: Cartera de Clientes CMR - Consumos banco.
General (0,5) Cuentas Distribución ∆ (#; %)

Recencia (meses)ago-12 ago-13 ago-12 ago-13 # Ctas. ∆%
] 00 a 01] 697,981 694,813 66.29% 65.89% -3,168 -0.5%
] 01 a 06 ] 243,949 246,632 23.17% 23.39% 2,683 1.1%
] 06 a 12] 51,300 47,443 4.87% 4.50% -3,857 -7.5%
] 12 a 18] 24,626 21,448 2.34% 2.03% -3,178 -12.9%
] 18 a 24] 13,924 15,406 1.32% 1.46% 1,482 10.6%
] 24 a más] 21,179 28,760 2.01% 2.73% 7,581 35.8%
1,052,959 1,054,502 100% 100% 1,543 0.1%
Tabla 11: Cartera de Clientes CMR - Consumos Saga Falabella.
Saga Falabella Cuentas Distribución ∆ (#; %)

] 00 a 01] 295,231 282,800 28.04% 26.82% -12,431 -4.2%
] 01 a 06 ] 431,094 422,843 40.94% 40.10% -8,251 -1.9%
] 06 a 12] 142,826 145,518 13.56% 13.80% 2,692 1.9%
] 12 a 18] 69,408 68,702 6.59% 6.52% -706 -1.0%
] 18 a 24] 38,301 42,572 3.64% 4.04% 4,271 11.2%
] 24 a más] 76,099 92,067 7.23% 8.73% 15,968 21.0%
1,052,959 1,054,502 100% 100% 1,543 0.1%
Tabla 12: Cartera de Clientes CMR - Consumos Tottus.
Tottus Cuentas Distribución ∆ (#; %)

] 00 a 01] 328,362 337,355 31.18% 31.99% 8,993 2.7%
] 01 a 06 ] 360,855 348,310 34.27% 33.03% -12,545 -3.5%
] 06 a 12] 127,937 127,678 12.15% 12.11% -259 -0.2%
] 12 a 18] 62,439 60,129 5.93% 5.70% -2,310 -3.7%
] 18 a 24] 38,130 42,932 3.62% 4.07% 4,802 12.6%
] 24 a más] 135,236 138,098 12.84% 13.10% 2,862 2.1%
1,052,959 1,054,502 100% 100% 1,543 0.1%

90
Tabla 13: Cartera de Clientes CMR - Consumos Sodimac.
Sodimac Cuentas Distribución ∆ (#; %)
ago-12 ago-13 ago-12 ago-13 # Ctas. ∆%

Recencia (meses)
] 00 a 01] 112,807 119,064 10.71% 11.29% 6,257 5.5%
] 01 a 06 ] 319,156 313,437 30.31% 29.72% -5,719 -1.8%
] 06 a 12] 195,873 191,929 18.60% 18.20% -3,944 -2.0%
] 12 a 18] 113,470 104,931 10.78% 9.95% -8,539 -7.5%
] 18 a 24] 68,904 76,669 6.54% 7.27% 7,765 11.3%
] 24 a más] 242,749 248,472 23.05% 23.56% 5,723 2.4%
1,052,959 1,054,502 100% 100% 1,543 0.1%
Las observaciones que se podían presentar y que ocasionaban diferencias en la cartera

del Data Warehouse y la cargada al QlikView, eran originadas por reprocesos en las
cargas mensuales al DWH, las mismas que una vez detectadas eran corregidas
corriendo nuevamente los procesos de carga.
Figura 47. Flujo de Validación de procesos QlikView.

91
4.10 Capacitación a usuarios.
La capacitación se dio por separado a usuarios de negocio y usuarios del área de

Inteligencia de Clientes, el foco era potenciar en la herramienta a los analistas de
negocio, puestos que ellos iban a usar la herramienta en el día a día.
Se adjunta la siguiente imagen, con una propuesta de acta de capacitación, dado que,
al ser un requisito contractual, hay que dejar constancia de esta. La misma que se
encuentra en el documento como el anexo 09.
Figura 48. Modelo de Ficha de Capacitación.

92
4.11 Gestión del conocimiento
A nivel local, son pocas las veces que se realiza una adecuada gestión del conocimiento,
reduciéndose muchas veces en la entrega de un manual de usuario con documentación
referente a la solución. Sin embargo, la Gestión del conocimiento abarca mucho más.
Por ejemplo, usar la experiencia registrada de proyectos anteriores para mejorar los
resultados del proyecto actual, así mismo registrar los conocimientos adquiridos del
proyecto en ejecución para retroalimentar a futuros proyectos, convirtiéndose todos
estos en activos de la empresa. Uno de los principales problemas en esta tarea es
registrar el conocimiento tácito de los profesionales que participaron en la ejecución,
dado que el conocimiento al ser visto como una ventaja competitiva, existe una reacción
adversa a querer compartirlo, mucho menos registrarlo, es por eso, que este punto se
debe trabajar conjuntamente con el área de recursos humanos o gestión de
colaboradores, dado que son ellos los que a través de técnicas de dirección y
colaboración puedan diseñarse formas de gestionar y registrar entre los profesionales y
la empresa los conocimientos adquiridos.
En el presente proyecto no se presentó un registro de lecciones aprendidas como indica

el estándar del PMBok. Solo un documento funcional con carácter de reservado, que no
será mostrado en el presente proyecto. Sin embargo, se muestra a continuación una
referencia de un proyecto con una gestión similar, aplicada como base para el registro
de Captación de experiencias, relacionadas a proyectos de TI.
Figura 49. Modelo de Base de Gestión de Conocimiento.

93
4.12 Cierre del proyecto.
El cierre del proyecto se dio en base al desarrollo del alcance del mismo, la revisión y
visto bueno de lo desarrollado, estuvo a cargo del Gerente y Jefe del proyecto, quienes
con los demás participantes, validaron las entregas contra lo estipulado en el contrato.
Se adjunta la siguiente imagen, con una propuesta de acta de cierre de proyecto, la

misma que se encuentra como el anexo 10, para una mejor visualización.
Figura 50. Modelo de Ficha de Cierre de Proyecto.

94
CAPITULO V. ANÁLISIS Y RESULTADOS
5.1 Resultados de la implementación del proyecto.
A continuación, se muestran los resultados de las campañas de reactivación de tarjeta

CMR, que estaban a cargo del área de Gestión de Cartera. Los primeros meses del año,
se realizaba la campaña según flujos descritos en la ilustración 33, con una fuerte
participación del área de Inteligencia de Clientes, siendo estos los únicos que generaban
bases de campaña, con las características ya descritas en la definición del problema
(falta de actualización de indicadores de la base de campaña, por ejemplo, situación de
un cliente nuevo o ya activado).
A partir de la campaña de junio 2014, que empieza a gestarse en mayo (posterior a la

puesta en servicio de la aplicación), las bases tienden a mejorar en obtención de cuentas
y gestión por perfiles.
Distribución Campañas de Reactivacion de cuentas

14000
12000
10000
8000 Reactivacion por Campaña

9125
Reactivacion Espontanea
6000 7450 7733 8450
8125 7452
6458
2598
4000 2909
2250 2003
1793
2000 3481
2600 2600 3100
1536 1982 2125 2120 1825 1900 2153 1850
0
ene-14 feb-14 mar-14 abr-14 may-14 jun-14 jul-14 ago-14 sep-14 oct-14 nov-14 dic-14
Figura 51. Campaña de reactivación de Cuentas.
Se puede observar que el impacto en los resultados de campaña son relevantes,

además que el tiempo de generación de la base fue reducido significativamente, esto
ayudaba a que la campaña sea orientado 100% al segmento objetivo, es decir tener una
base de clientes sin consumos en los últimos n meses, y que una semana anterior a la
campaña, no haya reactivado la cuenta por decisión propia, conlleva a que el
presupuesto de la campaña sea más eficiente y que no se envié mensajes de compra
con incentivos comerciales a clientes que ya lo han hecho.
95
Otro de los beneficios que trajo la implementación del proyecto, fue la identificación de
segmentos de consumo antes de que sea inactivo, es decir si un cliente antes, consumía
en un determinado giro de negocio (grifos, restaurantes, discotecas, entre otros), se
podría usar esta información para reactivar a la cuenta en un formato del retail que ya
había dejado de comprar, por ejemplo, en la siguiente campaña, el target es: Clientes
inactivos en Tottus y activos en convenios, la intención es que vuelva a usar la CMR en
Tottus.
Figura 52. Campaña Reactivación Tottus.
Las campañas que antes se realizaban por solicitudes a medida, como, por ejemplo, la
fuga de clientes de un determinado giro de negocio, ahora podía tomarse la información
recurrentemente y lanzar campañas mensuales homologadas o con ciertos cambios que
permitiera el dash board de extracción. Esto ayudaba mucho en el diseño de campaña
y ahorraba mucho tiempo de análisis y generación de bases de campaña.
Para el siguiente caso son clientes que han fugado en rubros como grifos y restaurantes
y son incentivados a usar nuevamente la Tarjeta CMR en los rubros a recuperar.
Se han mencionado algunas de las campañas del área de gestión de cartera, donde el
autor tenia participación directa además de participación en el proyecto. Los resultados
en todas ellas tuvieron un resultado similar, dado que se había reducido el tiempo de
generación de base, así como la brecha de actualización de la misma, respecto a los
cambios en la actualización de la cartera y sus clientes.
96
Figura 53. Campaña de reactivación por giros de negocio.
Otro de los beneficios con la aplicación, fue el cálculo de la tasa de respuesta, dado que,
con los segmentos calculados, podías tener un análisis mucho más profundo dentro de
la base. Además, dentro del nuevo esquema de la solución, esta era calculado por los
analistas de negocio, para esto usaban un query diseñado por el área de Inteligencia de
Clientes, para extraer información del DWH, y en un modelo pre-diseñado pueda ser
actualizado en cualquier momento, sin la necesidad de que el área de Inteligencia de
Clientes pueda intervenir en el cálculo y nuevamente generar un cuello de botella, que
tarde las labores de análisis. Esto también ayudaba si fuera el caso al reforzamiento de
las campañas por mensajes de texto o envió de un email recordatorio. Todos estos
ajustes ayudaron sin duda acelerar la gestión de campañas y por consiguiente mejorar
la gestión de la cartera de clientes del Banco Falabella. A continuación, se muestra un
ejemplo del cálculo de una tasa respuesta, con un nivel de profundidad por
segmentación de inactividad de clientes.
97
Tabla 14: Modelo de Cálculo de Tasa Respuesta de Campaña.

Campañas de Reactivacion
Distancia entre Cliente a Campaña Tottus J01 Campaña Tottus J02 Total
Tiendas Tottus más
próxima (km.) Flag_Compra Flag_Compra Flag_Compra Tasa de Respuesta
,00 1,00 Total ,00 1,00 Total ,00 1,00 Total Tottus Convenios
05. PDA 1,153 832 1,985 1,050 615 1,665 2,203 1,447 3,650 42% 37%
06. DDA 170 160 330 90 60 150 260 220 480 48% 40%
<0-1]
08. Perdidos 690 168 858 840 105 945 1,530 273 1,803 20% 11%
Total 2,013 1,160 3,173 1,980 780 2,760 3,993 1,940 5,933 37% 28%
05. PDA 871 658 1,529 840 720 1,560 1,711 1,378 3,089 43% 46%
06. DDA 100 75 175 120 60 180 220 135 355 43% 33%
< 1 - 1,5 ]
08. Perdidos 562 129 691 615 250 865 1,177 379 1,556 19% 29%
Total 1,533 862 2,395 1,575 1,030 2,605 3,108 1,892 5,000 36% 40%
05. PDA 856 616 1,472 690 420 1,110 1,546 1,036 2,582 42% 38%
06. DDA 97 95 192 75 45 120 172 140 312 49% 38%
< 1,5 - 2 ]
08. Perdidos 563 224 787 345 105 450 908 329 1,237 28% 23%
Total 1,516 935 2,451 1,110 570 1,680 2,626 1,505 4,131 38% 34%
05. PDA 750 468 1,218 750 345 1,095 1,500 813 2,313 38% 32%
06. DDA 69 146 215 30 15 45 99 161 260 68% 33%
< 2 - 2,5 ]
08. Perdidos 465 87 552 225 60 285 690 147 837 16% 21%
Total 1,284 701 1,985 1,005 420 1,425 2,289 1,121 3,410 35% 29%
05. PDA 3,630 2,574 6,204 3,330 2,100 5,430 6,960 4,674 11,634 41% 39%
06. DDA 436 476 912 315 180 495 751 656 1,407 52% 36%
Total
08. Perdidos 2,280 608 2,888 2,025 520 2,545 4,305 1,128 5,433 21% 20%
Total 6,346 3,658 10,004 5,670 2,800 8,470 12,016 6,458 18,474 37% 33%
5.2 Conclusiones
Las conclusiones han sido divididas en dos aspectos, técnicos y de gestión, dado que
ambos son relevantes para el éxito de cualquier proyecto.
Técnicos.
Kimball, es el modelo idóneo para desarrollar soluciones de Data Warehouse, dado la

metodología de ciclo de vida, que se refiere a un modelo recurrente dentro de los
procesos de negocio de la organización a través del modelado dimensional. Pero que
además, te brinda el lado del desarrollo de aplicaciones de Business Intelligence, ya sea
por medio de reportes estructurados pero poco flexibles como los que contaba el Banco
Falabella antes del proyecto, hasta el uso de herramientas para el desarrollo de
dashboard interactivos y otras herramientas de análisis.
El QlikView, es la herramienta de BI, que permitió el desarrollo de estos dashboard,

mostro un buen performance, debido al esquema de la solución, dado que contaba con
una herramienta ETL que ayudaba mucho en el proceso de extracción y refinamiento
de base, además que guardaba su propia arquitectura de archivos de data (QVD) y de
proyecto (QVW), los cuales en conjunto prestaban un alto rendimiento ante grandes
volúmenes de data, asociado a un modelo de datos adecuado.
98
El mix de tecnología que se usó, ayudo mucho a que la información obtenida cumpla
con estándares de integridad. Dado que el DWH aseguraba una integridad de datos, el
QlikView daba su motor de análisis para levantar esta información, procesarla y
mostrarla en un Dashboard, que permita realizar análisis más robustos de información.
Esto podría haber sido un error si se hubiera llevado la data transaccional directamente
al QlikView, que a pesar de contar con mecanismos de ETL, no era una herramienta
creada para este fin.
Como ha sido mencionado la arquitectura propia del QlikView, ayudaba a contar con
procesos recurrentes de carga, explotación y cálculo de indicadores, que fueron clave
para el éxito del proyecto. Dado que no es lo mismo dirigir los recursos de activación de
cuentas, con estímulos comerciales (devolución de un porcentaje de la compra) a una
base de 10,000 clientes, cuando una semana antes 500 o más de ellos ya fueron
activados por voluntad propia.
El soporte post implementación, no era altamente especializado, y se pudo dar

mantenimiento y nuevas implementaciones con la solución inicial, esto hace que el ROI
de la inversión del proyecto sea aún mayor.
De Gestión:
El despliegue del software es intuitivo para el usuario final, rápido y seguro, que son
características que usuarios no técnicos valoran en la solución. Esto ayudo mucho en
vender el proyecto a la gerencia de negocio, dado que como ha sido mencionado, su
participación post proyecto aumento.
El empoderamiento al analista de negocio, ayudo a conseguir más conocimiento de las

ventas de la tarjeta CMR, dado que el analista al interactuar con una herramienta self
service, puede potenciar toda su creatividad de análisis, esto tuvo que ser bien llevado,
para que sea visto como una oportunidad y no una carga para la gerencia de negocio.
Contar con equipos multidisciplinarios, ayuda mucho a abarcar todos los campos que a
primera vista no se detallan en el alcance de un proyecto. Es decir, contar con personas
de TI, involucradas altamente en el negocio como fue el caso, ayudo a tener dashboard
funcionalmente más amigables para los analistas de negocio, ayudo a que las pruebas
que se realicen sean robustas y generen confianza en la herramienta. Así como contar
con administradores con conocimientos en TI, ayuda a que los procesos y soluciones
planteadas sean potenciadas más rápidamente.
99
A continuación, se presentará un cuadro comparativo, entre tres herramientas de

análisis de datos, basándonos en el expertise del autor, así como recopilaciones de
personas con experiencia en las mismas. Aunque cabe mencionar que el proyecto fue
realizado años atrás, se tomara en cuenta las características actuales de dichas
herramientas.
Tabla 15: Comparativo entre herramientas BI.
Característica QlikView Tableau Power Bi

Arquitectura definida *** ** *
Carga de datos (grandes volumenes) *** ** *
Manipulacion de Datos *** * *
Creacion de dashboard ** *** **
Conectividad con otras fuentes de datos *** *** ***
Nùmero de usuarios conectados a data *** *** **
Arquitectura definida.
QlikView, consolida a través de capas escalables, labores especializadas según la

demanda del proyecto, genera sus propios archivos de data a través de los archivos de
extensión QVD, que hacen el acceso más rápido.
Tableau, maneja una arquitectura similar a la de QlikView: Tableau Desktop, interfaz

donde se realiza el análisis y explotación de datos a través de cuadros de mando.
Tableau Server y Online son los productos de Tableau diseñados para distribuir los
reportes de manera segura dentro (Tableau Server) y fuera de la red corporativa
(Tableau Online).
Power BI, su estructura es más enfocado al usuario final y con un almacenamiento local
y en la nube, con diferencias sobre todo en el licenciamiento, en las versiones Pro y
Premium.
Carga de datos.
QlikView, la carga de datos es óptima, dado que, al generar archivos bajo su

arquitectura, logra consolidar su plataforma. Cabe mencionar que la carga de data en el
proyecto fue masiva, no solo como número de registros sino como volumen total
(campos de tabla), obteniendo resultados favorables en tiempo de respuesta.
Tableau, está preparado para cargar grandes volúmenes de datos, aunque no presenta
archivos de datos como el caso de QlikView.
100
Power BI, en cuanto a la carga de datos, se ha visto que esta puede encontrase un poco
limitada, cuando se trate de grandes tablas o bases de datos, como es el caso del
proyecto.
Manipulación de datos.
QlikView, en esto es donde hace la diferencia, tiene una interfaz que hace las veces de
ETL, pudiendo procesar los datos origen y transformarlos.
Tableau / Power BI, es recomendable que la data haya sido trabajada en otra
herramienta y llegue a estas para ser explotada.
Creación de dashboard.
QlikView, la creación de gráficos de análisis es rápida y amigable.
Tableau, la visualización de data es quizás su punto más fuerte, altamente intuitivo y

una variedad de gráficos disponibles para implementar dashboard.
Power BI, tiene a disposición una gran variedad de gráficos, de manipulación intuitiva.
Conectividad con otras fuentes de datos.
En los tres casos cuentan con una gran variedad de conexiones a otras fuentes de datos.
Número de usuarios.
QlikView, a través de los servicios Server y aún más especializado con Publisher, la
administración de accesos es segura. Permitiendo la conexión de muchos usuarios
simultáneamente.
Tableau, a través del servicio Server, brinda accesos y controla los mismos a cientos de
usuarios.
Power Bi, el número de usuarios se definirá según el tipo de licenciamiento adquirido.
En conclusión, la elección de QlikView como software de explotación de datos o de

Inteligencia de Negocios, se dio, porque en el momento que se realizó el proyecto, era
el que se tenía más documentación y casos desarrollados. Así mismo era el que
operativamente se adaptaba mejor a las necesidades del proyecto (generación de
trabajos programados), hoy en día las diferencias se han acortado respecto a Tableau,
siendo junto a Power BI herramientas dirigidas más para el análisis y la visualización de
datos.
101
5.3 Recomendaciones
Entre las recomendaciones que se pueden extraer como parte del expertise del
desarrollo del proyecto se mencionan las siguientes:
Los modelos de negocio varían unos de otros, no solo como concepción del core
business, sino por las distintas características en modelado de datos. Sera necesario
identificar una vez construido la solución de DWH, cual es el modelado más
conveniente, de acuerdo a la carga de información y al procesamiento de esta respecto
a la implementación de un modelo de análisis de datos para BI.
Buscar un alto compromiso entre las personas que integran el equipo de proyecto, esto,
aunque recurrente, es vital para el éxito del mismo. Además, hacer una correcta
identificación de los interesados del proyecto y vender la idea o el alcance del mismo de
la mejor manera, como ya ha sido mencionado, en este caso, la idea fue potenciar a los
analistas de negocio en post de un mejor entendimiento de las oportunidades que
ofrecía una correcta y mejorada gestión de cartera de clientes. En lugar de dejar la
sensación que se estaba trasladando funciones de un área a otra.
La gestión del conocimiento en cualquier proyecto es sumamente necesaria, y esta no

se reduce a un manual de usuario o a la documentación técnica del proyecto. Va más
de eso, por el lado del cliente, en este caso el Banco Falabella que es la posición que
nos concierne, debe ser llevado por el líder del proyecto o asignado a alguien que tenga
experiencia en el tema.
Dado que las lecciones aprendidas dentro de las etapas de análisis, diseño, elaboración
y puesta en servicio de la aplicación, no son normalmente documentadas, debe tratarse
de llevar una metodología de la mano del área de colaboradores o RRHH y hacer
reuniones del tipo agile de propuestas por cada etapa, a manera de incentivar compartir
las experiencias entre los participantes del equipo y los usuarios líderes, que
participaron en el proyecto.
102
5.4 Referencias bibliográficas
A Guide to the Project Management Body of Knowledge PMBOK® Guide – Sixth Edition
(2017)
Bose, R. (2002). Customer relationship management: key components for IT success.

Industrial Management & Data Systems, 102(2),
Caralt, J. C., & Díaz, J. C. (2012). Introducción al Business Intelligence: Editorial UOC,
S.L.
Highsmith J, Schwaber K, Sutherland J (2001) Manifesto for Agile Software

Development
Informe Banco Falabella Perú S.A. (28 marzo 2019) realizado por Equilibrium
Clasificadora de Riesgo S.A.
Información Estadística de Banca Múltiple al 31 diciembre 2018, Superintendencia de

Banca, Seguros y AFP República del Perú
Información proporcionada por especialistas de QlikView, 2010 QlikTech International
Información proporcionada por especialistas de Tableau, 2003-2019 Tableau Software
Ken Schwaber and Jeff Sutherland (2017) The Scrum Guide The Definitive Guide to
Scrum: The Rules of the Game
Kenneth S. Rubin (2012) Essential Scrum: A Practical Guide to the Most Popular Agile
Process, Addison-Wesley Professional.
Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit : The Definitive Guide to
Dimensional Modeling. New York, UNITED STATES: John Wiley & Sons,
Incorporated.
Ladley, J. (2012). Data Governance : How to Design, Deploy and Sustain an Effective
Data Governance Program. San Francisco, UNITED STATES: Elsevier Science
& Technology.
Lee, Y. W., Funk, J. D., Pipino, L. L., & Wang, R. Y. (2006). Journey to Data Quality.
Cambridge, UNITED STATES: MIT Press.
Medina, E. (2012). Business Intelligence como propuesta de valor en las organizaciones.

En Medina, E., Business Intelligence: Una guía práctica 2ª ed . Lima: Universidad
Peruana de Ciencias Aplicadas.
Memoria anual 2017, Banco Falabella Perú S.A (15 marzo 2018)
Muñoz-Hernández, H., Osorio-Mass, R. C., & Zúñiga-Pérez, L. M. (2016). Inteligencia

de los negocios. Clave del éxito en la era de la información. Clío América, 10(20),
194-211
103
Newell, F. (2010). Why CRM Doesn't Work: How to Win by Letting Customers Manange
the Relationship. 1 Edición Bloomberg Press
Peppers, D., Rogers, M., & Kotler, P. (2016). Managing Customer Relationships : A
Strategic Framework. Somerset, UNITED STATES: John Wiley & Sons,
Incorporated.
Samayoa J (2018), Estadística aplicada a los negocios. Universidad Galileo. EDX
Santa Cruz O (2013) Tech and Roi Año 2 Edición 13, CRM Para conocer mejor a tus
clientes.
Stephan A. Butscher (2017). Customer Loyalty Programmes and Clubs 2nd Edición.
Routledge
Takeuchi, H., & Nonaka, I. (1986). The new product development game. Harvard
Business Review.
Zatyko S, Askham N (2017) Proactive data governance: Getting ahead of the game
2014-2019 Experian
104
5.5 Anexos
Anexo 1 – Reseña histórica del Banco Falabella
BANCO FALABELLA
1996
Se crea Financiera CMR
1997
En enero se inicia la captación

de clientes con la Tarjeta CMR
1999
Se lanza el primer producto
pasivo Ahorro Plazo Fijo 2001
Apertura del primer centro
financiero en provincia: Piura
2004
Lanzamiento de los productos

Programa CMR Puntos, Crédito
Efectivo y Crédito Vehicular 2007
En Febrero se recibe la
autorización de la SBS para
iniciar operaciones como Banco
Falabella.
Se lanzan los productos pasivos:
Ahorro Clásico, Ahorro
Programado y CTS.
Se continua con el crecimiento
de nuevas sucursales en
2008 provincia.
Se lanzan al mercado las
Tarjetas Visa Clásica y Visa
Platinum. 2010
Con la ayuda del ingreso de los

formatos Tottus y Sodimac.
Falabella se convierte en el
principal emisor de tarjetas de
2012 crédito del sistema peruano.
Se lanza el producto Cuenta
Sueldo. Se inicia las
operaciones de Banca por
Internet . 2015
Se lanzan campañas agresivas

de los productos Cuenta Sueldo
y CTS, logrando captar clientes
fuera de la corporación
2017 Falabella
Se cuenta con presencia en las

principales ciudades. Se lidera
el ranking de emisores de
tarjetas de crédito
Fuente: Pagina web Banco Falabella (www.bancofalabella.pe).

Directorio
Comité de Auditoria
Auditoria Interna
Comité de Riesgos
Oficialía de Cumplimiento
Comité de Activos y Pasivos
Comité de Prevención de
Lavado de Activos Cumplimiento Normativo
Anexo 2 – Organigrama de la empresa
Comité de Directores
Gerencia General
Fuente: Memoria Anual 2017 Banco Falabella.

Comité de Créditos
Gerencia Legal
Comité de Recuperaciones
Planeamiento y Control de
Gestión
Gerencia de Operaciones y Gerencia de Negocios Gerencia de Negocios Tarjeta Gerencia de Administración y

Gerencia de Gestión Humana Gerencia Comercial
Sistemas Productos Financieros de Crédito Finanzas
Gerencia de Inteligencia de
Gerencia de Canales Gerencia de Riesgos Gerencia de Tesoreria
Clientes
105
106
Anexo 3. Matriz de Procesos de la Guía del PMBOK sexta edición.

107
Anexo 4. Metodología Kimball.
Diseño de la Selección de
arquitectura productos e Crecimiento
técnica implementación
Diseño e
Definición de
Planificación de Modelado Implementación
Requerimientos Diseño Físico Implementación
Proyecto Dimensional del Sub Sistema
del Negocio
ETL
Especificación de Desarrollo de
Mantenimiento
Aplicaciones de BI Aplicaciones de BI
Administración del Proyecto DWH / BI
Diagrama del Ciclo de Vida de la Metodología de Kimball.

Fuente: Kimball, R., & Ross, M. (2013) p.404
Bus Matrix Dimensiones

Métricas
Macroproceso Proceso de Negocio Tiempo Entidad Producto Persona
Analizar las tendencias y cambios de Saldo de deuda X X
comportamientos de clientes Contador de clientes X X
Saldo de deuda X X X X
Marketing Elaborar Campañas de Marketing Contador de clientes X X X X
Saldo de linea en tarjeta de credito X X X X
Analizar consumos de productos de Sistema Saldo de deuda X X X X
Financiero Contador de clientes X X X X
Diagrama de la Matriz Bus de la empresa.

108
Anexo 5. Modelo de dimensión estrella de Kimball.
Diagrama del Modelo estrella.
DimAccount
AccountKey
ParentAccountKey
AccountCodeAlternat...
ParentAccountCodeAl...
AccountDescription
AccountType
Operator
CustomMembers
ValueType
FactFinance DimDate
DimDepartmentGroup FinanceKey DateKey
DepartmentGroupKey
DateKey FullDateAlternateKey
ParentDepartmentGroupKey
OrganizationKey DayNumberOfWeek
DepartmentGroupName
DepartmentGroupKey EnglishDayNameOfWeek
ScenarioKey SpanishDayNameOfWeek
AccountKey FrenchDayNameOfWeek
Amount DayNumberOfMonth
DayNumberOfYear
WeekNumberOfYear
EnglishMonthName
SpanishMonthName
FrenchMonthName
DimOrganization
OrganizationKey
ParentOrganizationKey
PercentageOfOwnersh...
DimScenario
OrganizationName ScenarioKey
CurrencyKey ScenarioName
Diagrama del Modelo estrella aplicado en una estructura de datos.

109
Anexo 6. Dashboard Integral Falabella.

110
Anexo 7. Dashboard Gestión de Cartera Rapicash.

111
Anexo 8. Costos de implementación de la solución e impacto en las actividades a

suplir.
Servidor (1 licensia)
Developer (1 licensia)
Clientes
(6 licensias por ejemplo)
(que acceden a los dashboard)
Costo de Licensiamiento ( 1 server ) +( 1 desktop) +( 10 Document CAL)$ 37,863

1 Licensia de Servidor $ 33,250
1 Licensia del dearrollador $ 1,283
10 Licensia de usuario final $ 333.00 (costo por licensia) $ 3,330
Costo de Servidor $ 23,890
Costo de consultoria $ 20,000
Total Solucion $ 81,753
Horas Hombre Analista de BI TC 2.77

Gastos % time Gastos
Analistas Sueldo Total Anual S/. Anual $
RRHH (40%) destinado RRHH
3 5,000 15,000 21000 50% 10,500 S/126,000 $ 45,487
Impacto por campaña

Campañas Registros x Cash back % registros registros ppto out
Anual S/. Anual $
al mes campaña max x reg out target out target target
4 5,000 S/50 2% 100 S/5,000 S/60,000 $ 21,661
Costos reducidos anuales ($) $ 67,148
Como se puede apreciar el 82% del costo de implementación, puede ser recuperado
en un año. Cubriendo en 15 meses el costo total de la aplicación.
112
Anexo 9. Acta de Capacitación.
Proyectos de Desarrollo BI
GERENCIA DE CONSULTORIA
INFORME DE CAPACITACION
INFORME DE CAPACITACION
Nro.
Cliente Banco Falabella 01 de 03
Sesión
Fecha 23/04/2014 Lugar Instalaciones Banco Falabella
Proyecto Gestión de Cartera de Clientes Banco Falabella
Capacitador Ruiz Huillca – ABC Consultores
Participantes:
Rol Asistencia Hora
Nombres y Apellidos Empresa Abreviatura (P= Participante,, I= (S,N) Llegada

Invitado, L=Líder,
R=Referido)
1 Objetivos de la Sesión
1. Conocer la estructura de los dashboard desarrollados

2. Trabajar con los datos mostrados, filtros, selección, exportación de datos.
3. Identificar principales indicadores desarrollados
2 Temario
1. Iniciar sesión en QlikView, modo usuario

2. Revisión de los dashboard desarrollados por área
3. Aplicar filtros, seleccionar data, extraer clientes
4. Revisar etiquetas de segmentación
5. Explicar indicadores y sus usos
6. Resolución de consultas
Archivo : C:\Proyectos\BFalabella\Gestion de
Cartera\Documentacion\Actas\BF Informe de Capacitación 01 Fecha de creación: 26/11/2012
Página 1 de 1
230414.docx Fecha actualización: 09/05/2013
Versión: 1
En caso de no existir comentario u observación antes del 30/04/2014 a la 01:00 p.m., el acta se dará por aceptada
113
Anexo 10. Acta de cierre de proyecto.
Proyectos de Desarrollo BI
GERENCIA DE CONSULTORIA
ACTA DE CIERRE
Información de la Reunión
Cliente Banco Falabella
Instalaciones Banco Falabella – Oficina

Fecha 30/04/2014 Lugar
principal
Hora Inicio 09:00 Hrs Hora Fin 09:30 Hrs
Proyecto Gestión de Cartera de Clientes Banco Falabella
Objetivo Acta de Cierre de Proyecto
Elaborado por David Saldarriaga – ABC Consultores
Participantes:
Rol Asistencia Hora
Nombres y Apellidos Empresa Abreviatura (P= Participante,, I= (S,N) Llegada

Invitado, L=Líder,
R=Referido)
Temas tratados
1. Cierre de proyecto de Implementación de Gestión de Cartera de clientes con QlikView:
1.1. Se da por concluido la implementación de la Solución denominada Gestión de Cartera de clientes con QlikView para Banco
Falabella, realizado por la empresa ABC Consultores, luego de expresada la conformidad por parte de los usuarios líderes de acuerdo
al siguiente detalle:
Item Descripción
1. Dashboard de Cartera de Clientes.
2. Dashboard de clientes x empresa retail (Saga Falabella – Tottus - Sodimac)
3. Dashboard de Convenios.
4. Dashboard de Rapicash.
114
1.2. Se ha realizado la entrega, validación y aprobación de los siguientes objetos los cuales dan soporte a los reportes de la Solución
listados en el punto 1.1:
- Reporte de Especificaciones Funcionales (REF).
- Reporte de Especificaciones Técnicas (RET).
- Documento de Mapeo de datos.
- Manual de Usuario.
- Objetos para pase a producción: Scripts de generación de estructura, scripts del ETL, reportes QlikView.
1.3. Se han concluido satisfactoriamente y a tiempo todas las actividades programadas para este proyecto, según el detalle del
cronograma entregado a los participantes.
1.4. Se hace entrega en un medio digital (CD) todos los objetos de la Solución, tanto documentos como programas y reportes.
2. Período de Garantía del desarrollo entregado.
2.1. En el caso que alguno de los reportes entregados se presente alguna observación que el usuario no haya detectado a la fecha
del cierre del proyecto, estas deberán ser atendidas y resueltas inmediatamente por el equipo de ABC Consultores sin incurrir en
costo alguno para El Cliente. Si las observaciones se refieren a funcionalidad nueva o fuera de los alcances iniciales del proyecto,
éstas se considerarán como adicionales y se presupuestarán en coordinación con el Área Usuaria.
2.2. La garantía de la Solución se extenderá por un período de seis (06) meses a partir de la fecha de la firma de esta Acta y cubrirá
toda la funcionalidad detallada en la Reporte de Especificaciones Funcionales (REF) aprobada por el usuario. Una vez vencido ese
período y de no existir un contrato de Mantenimiento, el tratamiento de observaciones y nuevos requerimientos deberán de pasar por
un proceso de Servicio tal como cualquier desarrollo nuevo.
2.3 La Consultora guardará una copia de las últimas versiones de todos los objetos entregados a El Cliente en calidad de custodia.
La garantía se extiende sobre dichos objetos considerados como entregables (punto 1.2).
2.4. Al tratarse de una Solución de Business Intelligence, el tiempo máximo para el primer contacto con el usuario, luego de recibida
la notificación de una observación es de 2 horas, contadas a partir de la recepción del e-mail por parte de Banco Falabella (dentro
del horario de lunes a viernes 9am – 6pm en días laborables). En este primer contacto se definirá la criticidad del problema (Alta,
Media, Baja) y su tipificación (error, observación, control de cambios). Cuando se trate de un Error u Observación, el tiempo máximo
de diagnóstico será de 4 horas para las incidencias de criticidad alta, 6 horas para las medias y 8 horas para las bajas. Con el
diagnostico se indicará el tiempo aproximado que tomará solucionar el problema.
2.5. En el caso de que El Cliente requiera hacer el uso de horas de Consultoría en Business Intelligence y no haya firmado un Contrato
de Mantenimiento sobre este proyecto, estas horas se facturarán de acuerdo al siguiente detalle:
Lunes a viernes de 9am a 6pm
Hora US$ XX.00
Día: US$ XXX.00
Otro horario
Hora US$ XX.00
Se considerarán Horas de Consultoría Business Intelligence al tiempo que se emplee para cualquiera de las siguientes actividades:
- Modificación del ETL, la estructura de las tablas de la solución, los reportes en QlikView o la documentación del proyecto.
- Desarrollo de reportes nuevos o cualquier componente de la Solución.
115
- Modificación de las reglas de negocio aprobadas en el documento REF.

- Revisión de la solución a solicitud del usuario que concluya en un problema de definición no expresada en el REF,
información mal registrada en los sistemas utilizados como origen de información o por el mal uso de la solución.
- Capacitación en el uso de la herramienta o de los reportes.
2.6. Los datos de contacto para hacer uso de la garantía del desarrollo son:
Nombre: David Saldarriaga Castillo
Cargo: Director
Celular: 993 494 658
Correo: dsaldarriaga@abcconsultores.com.pe
Nombre: Juan Luyo Lazo
Cargo: Gerente de Consultoría
Celular: 997 500 475
Correo: dluyo@abcconsultores.com.pe
Firmas:
Nombres y Apellidos Firma
Pedro Guerrero
Banco Falabella
Cesar Armas
Banco Falabella
Juan Luyo
ABC Consultores
David Saldarriaga
ABC Consultores
Archivo : C:\Proyectos\BFalabella\Gestion de Cartera

Fecha de creación: 25/06/2012
\Documentacion\Actas\BF Acta de Cierre 300414.docx Página 3 de 3
Fecha actualización: 09/07/2013
Versión: 1

2019 Palacios Navarro

Cargado por

Información del documento

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

2019 Palacios Navarro

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

Carrera de Ingeniería Informática y de Sistemas

GESTIÓN DE CARTERA DE CLIENTES DE UNA

Trabajo de Suficiencia Profesional para optar el Titulo

MIGUEL ENRIQUE PALACIOS NAVARRO

Esto va para ellos…

CAPITULO 1. GENERALIDADES DE LA EMPRESA ...................................... 10

1.1 Datos Generales ............................................................................. 10

1.2 Nombre o razón social de la empresa. ............................................ 10

1.3 Ubicación de la empresa................................................................. 10

1.4 Giro de la empresa. ........................................................................ 11

1.5 Tamaño de la empresa. .................................................................. 11

1.6 Breve reseña histórica de la empresa. ............................................ 12

1.7 Organigrama de la empresa. .......................................................... 12

1.8 Misión, Visión de la empresa. ......................................................... 13

1.9 Productos y clientes. ....................................................................... 13

1.10 Premios y Certificaciones ............................................................ 14

1.11 Relación de la empresa con la sociedad. ..................................... 14

CAPITULO II. PLANTEAMIENTO DEL PROBLEMA ....................................... 16

2.1 Características del área en que se participó. .................................. 16

2.2 Antecedentes y Definición del problema ......................................... 17

2.3 Objetivos ......................................................................................... 22

2.4 Justificación .................................................................................... 22

2.5 Alcances y limitaciones ................................................................... 23

CAPITULO III. MARCO TEÓRICO .................................................................. 24

3.1 Marco legal ..................................................................................... 24

3.2 Marco Técnico ................................................................................ 24

3.3 Gestión de Cartera de Clientes ....................................................... 25

3.4 Sistema Financiero Peruano ........................................................... 27

3.5 Business Intelligence ...................................................................... 33

3.6 Desarrollo y evolución del Business Intelligence ............................. 35

3.7 Gobierno de Datos .......................................................................... 38

3.8 Customer Relationship Management CRM ..................................... 44

3.9 Metodologías de Gestión de Proyectos........................................... 50

3.10 Diferencias entre las PMBOK y SCRUM...................................... 63

3.11 Metodología de Kimball ............................................................... 64

CAPITULO IV. DESARROLLO DEL PROYECTO ........................................... 69

4.1 Identificación de Stakeholders. ....................................................... 70

4.2 Alcance del Proyecto. ..................................................................... 71

4.3 Diagrama de secuencia lógica del proyecto. ................................... 72

4.4 Equipo y roles ................................................................................. 77

4.5 Cronograma de actividades ............................................................ 79

4.6 Arquitectura de QlikView ................................................................. 80

4.7 Requerimientos a DWH .................................................................. 83

4.8 Desarrollo (DashBoard) .................................................................. 84

4.9 Riesgos y planes de acción post implementación. .......................... 88

4.10 Capacitación a usuarios. ............................................................. 91

4.11 Gestión del conocimiento ............................................................ 92

4.12 Cierre del proyecto. ..................................................................... 93

CAPITULO V. ANÁLISIS Y RESULTADOS .................................................... 94

5.1 Resultados de la implementación del proyecto. .............................. 94

5.2 Conclusiones .................................................................................. 97

5.3 Recomendaciones .........................................................................101

5.4 Referencias bibliográficas ..............................................................102

5.5 Anexos ...........................................................................................104

Figura 1. Mapa de ubicación de la empresa. ................................................................. 11

Figura 34. Generación de Campaña Post Implementación. ......................................... 75

Tabla 1: Distribución de la cartera de clientes del Banco Falabella.............................. 26

El objetivo del proyecto que se plasmara en el presente informe, es gestionar

de las herramientas ya indicadas, en este caso el QlikView, y su funcionalidad en la

Se dará un soporte procedimental, de gestión y el marco teórico que obedece al

El presente trabajo comprende en el primer capítulo las generalidades de la empresa,

En el segundo capítulo, se mencionará los antecedentes del proyecto, lo que fue el

Durante el siguiente capítulo, se revisará el marco teórico, se comentará en base a la