Proyecto Final V-1.0

UNIVERSIDAD CENTRAL DE VENEZUELA
DIPLOMADOS ON-LINE
BUSINESS INTELLIGENCE (BI)
Proyecto Final
V-1.0
Participante:
Ángel A. Silva R CI: V-17.207.074
Marelvys Graterol CI: V-12.284.935
Caracas, Julio de 2015

Modelo de Transacciones para Banco
Documento Final | V-1.0 | 2015 Página 2
Resumen
El documento a presentar tiene como objetivo primordial elaborar un plan de
gestión de proyecto de Inteligencia de Negocios (BI) para analizar los datos transaccionales
de procesos críticos en las entidades financieras y transformarlos en información
consistente y exacta, que permita tomar decisiones y aplicar correctivos, de esta forma los
tomadores de decisiones pueden reaccionar en el menor tiempo posible ante los cambios
incesantes del mercado y así responder a estas demandas sin dejar de lado la necesidad de
desarrollar una actividad rentable con un crecimiento eficiente en torno a volumen y
calidad de negocios determinados, dando paso a la atención comercial y de relación con el
cliente.
Los datos que se usaran provienen de las transacciones bancarias realizadas
diariamente por los clientes o aplicadas por los diversos procesos del negocio a los clientes
del Banco “Ejecutivos D. Ragot, C. A”. Se mantendrá un histórico diario de los
movimientos bancarios de los clientes por los diversos canales y productos y se adaptará a
una plataforma de BI, donde están presentes: El Presidente del Banco, el usuario funcional
de la Gerencia de Servicios Centralizados del Banco, usuario de la Gerencia de Sistemas
del Banco, usuario de la Unidad de Procesos del Banco, usuario de Seguridad de la
Información del Banco y todos los demás entes u organismos que de forma indirecta
interactúen en los procesos que se llevaran a cabo.
Es de hacer notar, que el presente documento permitirá realizar los estudios que
sean necesarios en fin de certificar que la Gerencia de Servicios Centralizados del Banco
funcione adecuadamente y pueda atender las exigencias de los clientes así como también
dar respuesta al Directorio del Banco y a los organismos externos que rigen las normas en
las instituciones bancarias.
Cabe destacar, que en cuanto a los datos en un principio se pretendía acceder a toda
la información de las transacciones del banco, sin embargo, las personas a cargo accedieron
a prestar los datos de forma parcial, excluyendo toda la información referente a los cheques,
haciendo énfasis en la importancia de mantener la confidencialidad de los mismos y que
fueran utilizados exclusivamente para fines académicos.

Contenido
Resumen .................................................................................................................................2
Tabla de Figuras .....................................................................................................................5
Introducción............................................................................................................................6
1. Presentación del Caso de Estudio:...................................................................................7
1.1. Situación/ Problema..............................................................................................7
2. Marco conceptual ............................................................................................................9
2.1.1. Inteligencia de Negocios...................................................................................9
2.2. Tecnologías.........................................................................................................10
2.2.1. Pentaho ...........................................................................................................10
2.2.2. PDI (Pentaho Data Integrator) ........................................................................11
2.2.3. Saiku ...............................................................................................................12
2.2.4. Schema Workbench........................................................................................13
2.2.5. Arquitectura Pentaho Analysis Services.........................................................13
2.2.6. PostgreSQL.....................................................................................................14
3. Marco Metodológico:....................................................................................................15
3.1. Kimball...............................................................................................................15
4. Marco Aplicativo:..........................................................................................................17
I. Visión del Sistema.........................................................................................................17
Características del Sistema ............................................................................................18
Beneficios del Sistema: .................................................................................................19
Capacidades...................................................................................................................19
Limitaciones ..................................................................................................................20
II. Planificación del Proyecto .........................................................................................21
Evolución del Proyecto..................................................................................................22

Organización de los Equipos de Trabajo. ......................................................................22
III. Especificación de Requerimientos del Sistema (ERS) ..............................................26
Propiedad Intelectual.....................................................................................................30
IV. Diseño de la Arquitectura ..........................................................................................30
Modelo del Negocio ......................................................................................................30
Modelo del Sistema .......................................................................................................31
V. Análisis Dimensional.................................................................................................32
Dimensiones ..................................................................................................................32
Facts...............................................................................................................................32
Facts vs. Dimensiones ...................................................................................................33
Conclusiones.........................................................................................................................34
Bibliografía ...........................................................................................................................36

Tabla de Figuras
Anexo 1; Modelo Conceptual Kettle ....................................................................................12
Anexo 2; Método Kimball....................................................................................................16
Anexo 3; Documentos Referenciales....................................................................................17
Anexo 4; Capacidades ..........................................................................................................20
Anexo 5; Requerimientos .....................................................................................................20
Anexo 6; Alcances................................................................................................................22
Anexo 7; Equipo de Trabajo.................................................................................................23
Anexo 8; Herramientas de desarrollo ...................................................................................24
Anexo 9; Planificación .........................................................................................................26
Anexo 10; Indicador .............................................................................................................26
Anexo 11; Medidas...............................................................................................................27
Anexo 12; Referencia Dimensional......................................................................................27
Anexo 13; Frecuencia de actualización ................................................................................28
Anexo 14; Comparables .......................................................................................................28
Anexo 15; Modelo de presentación......................................................................................29
Anexo 16; Propiedad Intelectual ..........................................................................................30
Anexo 17; Modelo de Negocio.............................................................................................31
Anexo 18; Modelo de Sistema..............................................................................................31
Anexo 19; Dimensiones........................................................................................................32
Anexo 20; Fact vs Dimensiones ...........................................................................................33

Introducción
En el día a día del Banco “Ejecutivos D. Ragot, C. A” como en otros bancos, se
realizan incontables transacciones de diferentes tipos, por diferentes razones y en diferentes
ubicaciones, estas transacciones pueden ser: depósitos, retiros, solicitudes de crédito, pago
de servicios, entre otros.
Para una toma de decisiones efectiva, se pueden realizar estudios en base a estas,
tomando en cuenta los diferentes factores que pueden influir según sea el caso, hoy en día,
esto es más que común por las continuas varianzas de leyes o reglamentos que surgen y que
pueden desestabilizar el funcionamiento de una sucursal, de una Base de datos, y hasta del
mismo banco en general, ocasionando estragos en los usuarios finales.
Fácilmente un estadista puede tomar datos y proyectar comportamientos, pero esto
será posible, siempre y cuando el estadista tenga los datos correctos, para esto se cuenta con
un Departamento de analistas (Comúnmente denominado Warehouse) donde se pueden
generar reportes, según sean las necesidades de los usuarios, y es así como se llevan los
reportes; un usuario pide un reporte, y el analista obtiene la solicitud y la gestiona lo más
rápido posible a fin de satisfacer las necesidades del usuario, la mayoría de las veces esto
funciona, pero de manera lenta e ineficiente, afectando muchas veces en la toma de
decisiones por un query mal hecho, o una idea mal entendida, esto puede ocasionar desde
molestias hasta pérdidas multimillonarias.
En el siguiente Documento se plantea la solución a esta situación de manera
efectiva, empleando la metodología Kimball, especial para este tipo de requerimientos y
contando con las mejores prácticas que este contiene.

1. Presentación del Caso de Estudio:
1.1. Situación/ Problema
El Banco EDR, es un Banco Microfinanciero venezolano de capital privado
dedicado al sector microempresario, que tiene como objetivo principal la bancarización
rentable y responsable de los empresarios y hogares de bajos recursos en el país.
Banco EDR está conformado por varias Gerencias, cada una de las cuales cuenta
con diversos Sistemas de Información y herramientas para realizar sus procesos de negocio,
las mismas generan y almacenan información en diferentes formatos y en gran volumen.
A esto se debe agregar, que la mayoría de las partes no cuenta con un sistema
generador automático de informes, y que los mismos son preparados periódicamente de
forma manual, muchas veces apoyándose en las herramientas de ofimática disponibles en el
mercado.
Actualmente, la Gerencia de Servicios Centralizados del Banco EDR recibe
diariamente archivos en formatos de texto generados por el core bancario (COBIS), donde
se almacenan los movimientos diarios de las transacciones realizadas por los clientes, por
ende estos archivos se procesan de forma manual para generar la información requerida
para la toma de decisiones.
El proceso diario que se lleva a cabo en la Gerencia de Servicios Centralizados
consiste en buscar en una carpeta compartida ubicada en un Servidor del Banco los
archivos que le corresponden analizar, los cuales tienen nombres distintos de acuerdo al
tipo de transacción (transferencias, depósitos, retiros, entre otros), algunos están
clasificados por agencias (Centro Lido, Maracay, Valencia, La Castellana, entre otras), de
igual manera deben ser clasificados por fecha, a fin de generar reportes en periodos
distintos y no generar inconsistencia en los mismos.
La Gerencia de Servicios Centralizados cuenta con poco personal para realizar este
trabajo de procesamiento de los archivos, por lo cual se genera gran cantidad de datos
acumulados, lo cual no representa necesariamente una gran cantidad de información, y que
la misma sea relevante o no para el banco, depende en gran medida de la forma y calidad en
la que esta llegue a los tomadores de decisiones.

Además, es importante destacar que existe un directorio y entes externos al banco
que periódicamente requieren de información muy rápida que no está predefinida en la lista
de reportes diarios que se generan, lo que repercute en un esfuerzo extra para poder
suministrar la información solicitada en el momento oportuno, acotando que muchas veces
se debe recurrir a la Gerencia de Sistemas para solicitar datos que no se tienen, por ejemplo,
datos históricos.
Esta problemática arroja inconsistencias en datos, requerimientos no atendidos por
falta de datos, archivos eliminados o solapados, información duplicada, imposibilidad de
atender las exigencias de los clientes, deficiencia para establecer estrategias de crecimiento
eficiente del negocio, entre muchos otros problemas.
El reto de este proyecto consiste en brindar una solución de BI capaz de transformar
los datos en información útil y confiable, de manera que los gerentes y directores puedan
utilizar dicha información para incrementar la rentabilidad del banco, haciendo posible la
diferenciación y personalización de la oferta de servicios financieros hacia una masa de
clientes y corporaciones cada vez más exigente, además de unificar e integrar la totalidad
de la información de sus sistemas y dedicarse a los procesos de gestión administrativa en
torno de la atención de los clientes. Brindándoles un soporte en el cual respaldar la toma de
decisiones estratégicas.

2. Marco conceptual
2.1.1. Inteligencia de Negocios
Como definición universal, Business Intelligence no posee un consenso. No
obstante, la conceptualización aportada por Hugh J. Watson es muy útil para los fines de
este trabajo: “Business Intelligence (BI) representa una amplia categoría de aplicaciones,
tecnologías y procesos que tienen como fin recopilar, almacenar, acceder y analizar datos
para ayudar a los usuarios a tomar mejores decisiones” (Watson, 2009).
Esta definición resalta la recolección de información desde distintas fuentes de datos
(por ejemplo, ERP y sistemas operacionales departamentales), el almacenamiento de los
datos (por ejemplo, en un almacén de datos corporativo, data warehouse, o en un data
mart), y el acceso y análisis de dichos datos por medio de tecnologías y aplicaciones de BI
para alcanzar un objetivo de negocio.
En este caso, una aplicación de BI podría ser un sistema de gestión del rendimiento
corporativo que se construye con base en una tecnología como puede ser Pentaho Business
Intelligence. En cuanto a los procesos, podemos encontrar diferentes opciones en un
entorno BI. Desde el muy conocido proceso de extracción, carga y almacenamiento de
datos (extract-transform-load, ETL) vinculado al 10 Guía Didáctica Comprometidos con el
desarrollo de tu perfil profesional contexto de los almacenes de datos (DW), hasta los
procesos asociados para priorizar proyectos BI (Wixom y Watson, 2010).
De esta forma, los sistemas de BI combinan la obtención y almacenamiento de
datos con herramientas analíticas que presentan información compleja y competitiva a los
decisores. Implícitamente, estos sistemas proporcionan información sobre la que se puede
actuar, distribuida en el momento y lugar adecuado, así como en el formato correcto para
asistir a los decisores. El objetivo es mejorar la oportunidad y calidad de las entradas del
proceso de decisión, facilitando, por tanto, el trabajo directivo (Negash y Gray, 2003). Se
puede decir que los sistemas BI buscan ayudar a las organizaciones a iniciar la transición
desde una situación de abundancia en datos y pobreza, en información al estado de riqueza,
en información con capacidad para ofrecer una mejor toma de decisiones basada en hechos
(Abukari y Jog, 2003).
Con este podemos:

 Generar reportes globales o por secciones.
 Crear una base de datos de clientes.
 Crear escenarios con respecto a una decisión.
 Hacer pronósticos de ventas y devoluciones.
 Compartir información entre departamentos.
 Análisis multidimensionales.
 Generar y procesar datos.
 Cambiar la estructura de toma de decisiones.
 Mejorar el servicio al cliente.
2.2. Tecnologías
2.2.1. Pentaho
La plataforma Open Source Pentaho Business Intelligence cubre muy amplias
necesidades de Análisis de los Datos y de los Informes empresariales. Las soluciones de
Pentaho están escritas en Java y tienen un ambiente de implementación también basado en
Java. Eso hace que Pentaho sea una solución muy flexible para cubrir una amplia gama de
necesidades empresariales – tanto las típicas como las sofisticadas y especificas al negocio.
Los módulos de la plataforma Pentaho BI son:
a) Reporting
Un módulo de los informes ofrece la solución adecuada a las necesidades de los
usuarios. Pentaho Reporting es una solución basada en el proyecto JFreeReport y permite
generar informes ágil y de gran capacidad. Pentaho Reporting permite la distribución de los
resultados del análisis en múltiples formatos – todos los informes incluyen la opción de
imprimir o exportar a formato PDF, XLS, HTML y texto. Los reportes Pentaho permiten
también programación de tareas y ejecución automática de informes con una determinada
periodicidad.
b) Análisis
Pentaho Análisis suministra a los usuarios un sistema avanzado de análisis de
información. Con uso de las tablas dinámicas (pivot tables, crosstabs), generadas por
Mondrian y JPivot, el usuario puede navegar por los datos, ajustando la visión de los datos,

los filtros de visualización, añadiendo o quitando los campos de agregación. Los datos
pueden ser representados en una forma de SVG o Flash, los dashboards widgets, o también
integrados con los sistemas de minería de datos y los portales web (portlets). Además, con
el Microsoft Excel Analysis Services, se puede analizar los datos dinámicos en Microsoft
Excel (usando la conexión a OLAP server Mondrian).
c) Dashboards
Todos los componentes del módulo Pentaho Reporting y Pentaho Análisis pueden
formar parte de un Dashboard. En Pentaho Dashboards es muy fácil incorporar una gran
variedad en tipos de gráficos, tablas y velocímetros (Dashboard widgets) e integrarlos con
los Portlets JSP, en donde podrá visualizar informes, gráficos y análisis OLAP.
d) Data Mining
Análisis en Pentaho se realiza con una herramienta WeKa.
e) Integración de Datos
Se realiza con una herramienta denominada Kettle ETL (Pentaho Data Integration)
que permite implementar los procesos ETL. Últimamente Pentaho lanzó una nueva versión
– PDI 3.0 – que marcó un gran paso adelante en OSBI ETL y que hizo Pentaho Data
Integration una alternativa interesante para las herramientas comerciales.
2.2.2. PDI (Pentaho Data Integrator)
La suite de inteligencia de negocios Pentaho, entre las distintas soluciones que
ofrece cuenta con la herramienta de Integración de data (Pentaho Data Integration) mejor
conocida como Kettle cuyo nombre es un acrónimo recursivo de “Kettle Extraction
Transformation Transportation & Loading Environment”. Dicha herramienta permite
realizar operaciones de ETL (Extraction, Transformation and Load), sobre diversas fuentes
de datos y con múltiples opciones para ello.

Anexo 1; Modelo Conceptual Kettle
2.2.3. Saiku
Saiku es un excelente visor OLAP que proporciona al usuario final una magnifica
herramienta para realizar análisis de forma fácil e intuitiva.
Pero Saiku no es sólo eso, es un buen ejemplo de cómo un proyecto Open Source
puede ofrecer soluciones de excelente calidad a la vanguardia de la tecnología y delicada
experiencia de usuario.
Afortunadamente Saiku es un proyecto muy joven hecho con paciencia y cabeza, lo
cual lo dota con una arquitectura técnica que le permite ser muy flexible y versátil.
Además, Saiku como tal, es el segundo intento, el bueno. Tras una primera versión, PAT
que ha servido para encontrarse con todos los problemas que había que encontrarse
decidieron volver a empezar de nuevo "haciendo las cosas bien". Y lo han hecho Excelente:
 Puedes utilizar saiku sólo si quieres realizar análisis OLAP. Es un servidor
independiente.
 Puedes embeberlo en un servidor Pentaho como un plugin de forma fácil y sencilla.
Es un plugin de Pentaho,

 Puedes utilizarlo como origen de datos. Es un backend. Y puedes, por ejemplo
construir tu propia interfaz de usuario como han hecho en Inovia.fr, que han hecho
una interfaz PHP.
2.2.4. Schema Workbench
En lo referente al análisis dimensional, Pentaho nos proporciona en su plataforma
BI una solución ROLAP a través de lo que llaman Pentaho Analysis Services. PAS está
basado en Mondrian, que es el corazón de este, y en Jpivot, que es la herramienta de
análisis de usuario, con el que realizamos la navegación dimensional sobre los cubos desde
la plataforma BI y visualizamos los resultados de las consultas. Estas son ejecutadas por
Mondrian, que traduce los resultados relacionales a resultados dimensionales, que a su vez
son mostrados al usuario en formato HTML por Jpivot.
2.2.5. Arquitectura Pentaho Analysis Services
Tal y como vemos en la imagen, donde se representa la arquitectura de Pentaho
Analysis Services, el elemento principal del sistema son los ficheros XML donde se
representan los esquemas dimensionales. Para construir estos ficheros XML, podríamos
utilizar cualquier editor de texto o XML, o bien la herramienta que nos ofrece Pentaho, que
se llama Schema Workbench. Pentaho Schema Workbench es la herramienta gráfica que
permite la construcción de los esquemas de Mondrian, y además permite publicarlos al
servidor BI para que puedan ser utilizados en los análisis por los usuarios de la plataforma.
En los ficheros de esquema XML, se describen las relaciones entre las dimensiones y
medidas del cubo (modelo multidimensional) con las tablas y campos de la base de datos, a
nivel relacional. Este mapeo se utiliza para ayudar la traducción de los querys MDX (que es
el lenguaje con el que trabaja Mondrian), y para transformar los resultados recibidos de las
consultas SQL a un formato dimensional. Vamos a ver a continuación como utilizar PSW
para definir los esquemas de nuestro proyecto y publicar los resultados en el servidor BI.
Más adelante veremos cómo funciona Jpivot a nivel de frontend, para sacarle todo el
partido a los análisis.

2.2.6. PostgreSQL
Es un potente sistema de base de datos objeto-relacional de código abierto. Cuenta
con más de 15 años de desarrollo activo y una arquitectura probada que se ha ganado una
sólida reputación de fiabilidad e integridad de datos. Se ejecuta en los principales sistemas
operativos que existen en la actualidad como:
 Linux.
 UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64).
 Windows.
Es totalmente compatible con ACID, tiene soporte completo para claves foráneas,
uniones, vistas, disparadores y procedimientos almacenados (en varios lenguajes). Incluye
la mayoría de los tipos de datos del SQL 2008, incluyendo INTEGER, numérico,
BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, y TIMESTAMP. También soporta
almacenamiento de objetos binarios grandes, como imágenes, sonidos o vídeo. Cuenta con
interfaces nativas de programación para C / C + +, Java. Net, Perl, Python, Ruby, Tcl,
ODBC, entre otros, y la documentación que actualmente existe es realmente excepcional.

3. Marco Metodológico:
La implementación de un proyecto de Data Warehouse/Business Intelligence
(DW/BI), puede seguir el mismo ciclo de desarrollo que cualquier otro proyecto de
desarrollo de software (requerimientos, análisis, diseño, construcción, pruebas e
implantación), pero las mejores prácticas en esta área las tiene la Metodología Kimball.
3.1. Kimball
Es una metodología empleada para la construcción de un almacén de datos (data
warehouse, DW) que no es más que, una colección de datos orientada a un determinado
ámbito (empresa, organización, entre otros), integrado, no volátil y variable en el tiempo,
que ayuda a la toma de decisiones de la entidad en la que se utiliza.
La metodología propuesta por Ralph Kimball favorece lo que muchos describen
como enfoque bottom-up (desde abajo hacia arriba), es decir, construir data marts para cada
destinatario dentro de la empresa y luego, combinarlos para formar un data warehouse para
toda la empresa. Kimball sugiere que, en primer lugar, es necesario centrarse en la propia
empresa. Construir data marts más pequeños y que cada uno se centre en un tema particular
dentro de la empresa ayudando a limitar la tarea a algo más manejable y a mantener la
empresa (no el data warehouse final) más firmemente en mente. Recomienda construir data
marts no respecto a unidades de negocios, sino de procesos de negocios, tales como
pedidos, envíos, pagos, entre otros.
Esta metodología se basa en lo que Kimball denomina Ciclo de Vida Dimensional
del Negocio (Business Dimensional Lifecycle o KLC), donde el adecuado desarrollo de
cada una de las fases que se plantea asegura el correcto proceso del desarrollo del proyecto,
así como también da una garantía de la calidad del producto. Este ciclo de vida del proyecto
de DW, está basado en cuatro principios básicos:
 Centrarse en el negocio.
 Construir una infraestructura de información adecuada.
 Realizar entregas en incrementos significativos (este principio consiste en crear el
almacén de datos (DW) en incrementos entregables en plazos de 6 a 12 meses, en
este punto, la metodología se parece a las metodologías ágiles de construcción de
software).

 Ofrecer la solución completa (En este se punto proporcionan todos los elementos
necesarios para entregar valor a los usuarios de negocios, para esto ya se debe tener
un almacén de datos bien diseñado, se deberán entregar herramientas de consulta ad
hoc, aplicaciones para informes y análisis avanzado, capacitación, soporte, sitio web
y documentación).
La construcción de una solución de DW/BI (Datawarehouse/Business Intelligence)
es sumamente compleja, y Kimball nos propone una metodología que nos ayuda a
simplificar esa complejidad. Las tareas de esta metodología (ciclo de vida) se describen a
continuación:
Anexo 2; Método Kimball

4. Marco Aplicativo:
I. Visión del Sistema
Documentos Relacionados con el desarrollo del sistema son:
Título Fecha Organización
Identificador del
documento
Ley Orgánica del
Sistema Financiero
Nacional (LOSFIN)
16/06/2010 Órgano Superior
del Sistema
Financiero
Nacional (OSFIN)
Ley de Instituciones
del Sector Bancario
(LISB)
21/12/2010 Gaceta Oficial
Extraordinaria No.
6.015
Ley General de
Bancos y Otras
Instituciones
Financieras
03/11/2001 Decreto N° 1.526
Visión del Sistema 24/06/2015 Estudiantes
Diplomado BI
P1.001
Anexo 3; Documentos Referenciales
El objetivo primordial es elaborar un plan de gestión de proyecto de Inteligencia de
Negocios (BI) para analizar los datos transaccionales de procesos críticos en las entidades
financieras y transformarlos en información consistente y exacta, que permita tomar
decisiones y aplicar correctivos necesarios antes que se conviertan en problemas, de esta
forma los tomadores de decisiones pueden reaccionar en el menor tiempo posible ante los
cambios incesantes del mercado y así responder a estas demandas sin dejar de lado la

necesidad de desarrollar una actividad rentable con un crecimiento eficiente en torno a
volumen y calidad de negocios determinados, dando paso a la atención comercial y de
relación con el cliente.
Los datos provienen de las transacciones bancarias realizadas diariamente por los
clientes o aplicadas por los diversos procesos del negocio a los clientes del Banco
“Ejecutivos D. Ragot, C. A”. Se mantendrá un histórico diario de los movimientos
bancarios de los clientes por los diversos canales y productos y se adaptará a una
plataforma de BI, donde están presentes: El Presidente del Banco, el usuario funcional de la
Gerencia de Servicios Centralizados del Banco, usuario de la Gerencia de Sistemas del
Banco, usuario de la Unidad de Procesos del Banco, usuario de Seguridad de la
Información del Banco y todos los demás entes u organismos que de forma indirecta
interactúen en los procesos que se llevaran a cabo.
Se realizaran los estudios necesarios en fin de certificar que la Gerencia de Servicios
Centralizados del Banco funcione adecuadamente y pueda atender las exigencias de los
clientes así como también dar respuesta al Directorio del Banco y a los organismos externos
que rigen las normas en las instituciones bancarias.
La solución propuesta en vías de resolver la problemática planteada es desarrollar
un Datamart aplicable a una Solución de BI para la Gerencia de Servicios Centralizados del
Banco EDR, que permita automatizar el procesamiento de los datos para convertirlos en
información y de esta forma obtener como beneficio una aplicación de consulta eficiente
que ahorre tiempo en entrega y búsqueda de información.
La solución de BI va dirigida a todos los Analistas y Gerente Ejecutivo de Servicios
Centralizados del Banco EDR, tales como:
 Gerente Ejecutivo de Servicios Centralizados.
 Analista de Transacciones por Canales de Venta.
 Analista de Cheques.
 Analista de Cuentas Bancarias.
Características del Sistema
Según se ha visto, el universo de soluciones y componentes de los proyectos de
inteligencia de negocio es muy amplio, y es complicado establecer características comunes

entre ellos, por eso acuerdo a los requisitos exigidos por la Coordinación Académica del
Diplomado en Inteligencia de Negocios y de conformidad con la Gerencia de Servicios
Centralizados del Banco EDR se acordó que para el inicio y desarrollo se utilizará:
 Uso de diversas herramientas de Tecnologías de Información.
 Software Libre.
 PostgreSQL 9.4 como gestor de base de datos.
 Pentaho como plataforma de BI para manejar la inteligencia empresarial.
Beneficios del Sistema:
 Mejorar el acceso a los datos a través de consultas, análisis o reportes de los
analistas de la Gerencia de Servicios Centralizados.
 Obtener información actualizada y precisa.
 Mejorar la toma de decisiones, realizándola de forma más rápida y acorde a
resultados.
 Conseguir ventajas competitivas.
 Mayor integración de la información.
 Menor dependencia de los analistas de la Gerencia de Sistemas.
 Dar soporte a las estrategias.
 Reducir el tiempo de lanzamiento de nuevos productos o servicios.
 Identificar clientes rentables en segmentos no rentables.
Capacidades
Necesidades del Cliente:
● Automatización de la gestión de la información
de la Gerencia de Servicios Centralizados.
● Producción de Información para la toma de
decisiones.
● Llevar un control histórico de las Transacciones
Bancarias.
● Mejorar la exactitud y disponibilidad de la
información.
● Reducir costes y mejorar la eficiencia.

Macro-Características del
Sistema
● Procesamiento automatizado de los datos.
● Resultados en tiempo real.
● Eficiente, íntegro, centralizado y orientado a
inteligencia de negocio.
Anexo 4; Capacidades
Limitaciones
Basadas en costos, no deberíamos tener inconvenientes con el software, ya que va a
ser open Source y referente al hardware, que a pesar de no ser libre de costos, porque se
requiere de equipos que soporte el desarrollo del proyecto, en nuestro caso el Banco EDR
dispone de un Servidor que nos facilitara para la realización del proyecto.
Requerimiento Ambiental Descripción
Hardware Disponer de los recursos (equipos)
necesarios para la implementación del
sistema.
Oficina Disponer de oficinas acondicionados para la
instalación de los equipos computacionales.
Personal Personal capacitado (no necesario
conocimientos expertos de computación)
para la manipulación del sistema
Personal capacitado Personas capacitada en el área de la
computación para el mantenimiento y
recuperación del sistema en caso de fallas.
Anexo 5; Requerimientos

II. Planificación del Proyecto
El objetivo primordial elaborar un plan de gestión de proyecto de Inteligencia de
Negocios (BI) para analizar los datos transaccionales de procesos críticos en las entidades
financieras y transformarlos en información consistente y exacta, que permita tomar
decisiones y aplicar correctivos necesarios antes que se conviertan en problemas, de esta
forma los tomadores de decisiones pueden reaccionar en el menor tiempo posible ante los
cambios incesantes del mercado y así responder a estas demandas sin dejar de lado la
necesidad de desarrollar una actividad rentable con un crecimiento eficiente en torno a
volumen y calidad de negocios determinados, dando paso a la atención comercial y de
relación con el cliente.
Se debe desarrollar una solución de Inteligencia de Negocios para la Gerencia de
Servicios Centralizados del Banco EDR. Este Proyecto debe ser capaz de cumplir con
actividades, tales como:
 Identificar las fuentes u orígenes de los datos que se van a analizar para convertirlos
en información y finalmente general conocimiento.
 Recopilar todos los datos en un único repositorio de datos y mantenerlos
actualizados.
 Generar reportes con indicadores que satisfagan las necesidades de información de
la Gerencia de Servicios Centralizados del Banco EDR.
 Adiestrar a los analistas tanto del área funcional como del área de Sistemas para que
desarrollen nuevos reportes.
Los alcances y posibles amenazas del mismo son:
En el Alcance Fuera del Alcance
Planificación del proyecto Se encuentra bajo el alcance
Definición de Requerimientos del Negocio Se encuentra bajo el alcance
Crear un ODS (PostgreSQL) Se encuentra bajo el alcance
Modelo Dimensional. Creación del modelo Se encuentra bajo el alcance

lógico de un DW de los procesos de SC.
Extracción y carga de BD Oracle (Core del
Banco) a BD PostgreSQL
Se encuentra bajo el alcance
Aplicar las reglas del Negocio y certificar
las cifras en conjunto con estadistas y
gerencia.
El alcance dependerá del tiempo que nos
lleve la culminación de las actividades antes
mencionadas.
Implementación de un DW/BI Granularidad Detallada.
Análisis usando la herramienta Pentaho BI Reporte de la situación. Se analizará la data
de prueba.
Anexo 6; Alcances
Durante la realización del proyecto, podemos conseguir:
 Limitaciones tales como tiempos de entregas.
 Limitaciones en la información requerida.
Evolución del Proyecto
El proyecto está dividido en cuatro (4) fases, cada una establecida en la
planificación y en las cuales se cuentan con los recursos, tanto humanos como de activos
informáticos y tiempo que podrá desempeñar de manera efectiva el alcance de lo
planificado.
El diseño y desarrollo del proyecto se encuentran avanzando a la par con los artefactos que
en esta Metodología exige.
Organización de los Equipos de Trabajo.
A continuación se describen las principales responsabilidades de cada uno de los
puestos en el equipo de desarrollo durante las fases, de acuerdo con los roles que se
desempeña.
Puesto Responsabilidad
Administración del
Proyecto / Sponsor
Es el responsable de la gestión del día a día de tareas y actividades
del proyecto, incluyendo la coordinación de recursos, seguimientos
de estados, y la comunicación de los avances y problemas del
proyecto.

Requerimientos
Son los encargados de impulsar el proyecto. Son capacitados para
tomar decisiones difíciles, están capacitados y deben estar
comprometidos con el proyecto.
Consultoría y dominio
experto
Es el equipo que conoce tanto del negocio como de la Base de
datos, sabe dónde buscar la información relevante según sean los
requerimientos y está en la capacidad de tomar decisiones para
mitigar el impacto en la planificación según sea necesario.
Analista del Negocio
Es el responsable de dirigir las actividades de los requerimientos
del negocios y luego de representar los requerimientos, desarrollar
el modelo dimensional.
Analista QA
El analista de control de calidad de almacén de datos, asegura que
los datos cargados en el almacén sean exactos. Esta persona
identifica posibles errores de datos y los lleva a la resolución. El
analista es a veces también el responsable de verificar la integridad
de las aplicaciones de usuario final pre-diseñadas.
Desarrolladores
Construcción de prototipos. Colaboración en la elaboración de las
pruebas funcionales, modelo de datos y en las validaciones con el
usuario.
Arquitecto ETL's
El diseñador del sistema es el responsable del diseño del proyecto,
se encarga del proceso de extracción, transformación y carga de los
datos en preparación del almacén de datos.
Desarrollador ETL's
El programador ETL se encarga de construir y automatizar los
datos de los procesos realizado por el diseñador del sistema. En
condiciones óptimas, este recurso tiene un conocimiento del
sistema, así como conocimiento y comprensión de los modelos
multidimensionales.
Anexo 7; Equipo de Trabajo

Y de las Herramientas de Desarrollo y colaboración tenemos:
Herramienta Fuente Cantidad Estado Comentarios
Materiales de
Entrenamiento
Diplomado on Line de
http://learningplatform.dipl
omadosonline.com/
1 1 Libros y recursos
digitales.
Estaciones de
Trabajo para
Desarrollo
Cada integrante, dispone
de su computador
personal.
Al menos
3
Sin definir Utilización de
computadores
personales.
Licencias de
IDE
Open Source Open
Source
Open
Source
Utilización de
herramientas de
Software libre
Licencias de
Herramientas
para Pruebas
Open Source Open
Source
Open
Source
Utilización de
herramientas de
Software libre
Anexo 8; Herramientas de desarrollo
A continuación se presentará una tabla discreta donde se muestra un resumen de lo
planificado:
Disciplinas / Artefactos / Acciones Comienzo Fin
TRX- Banco EDR
Asignación de integrantes y elección del proyecto 24/06/2015 24/06/2015
Identificación del Problema 25/06/2015 25/06/2015
Levantamiento de información y análisis de involucrados 26/06/2015 26/06/2015
Asignación de Roles 27/06/2015 27/06/2015
Planificación del Proyecto/Recurso/Tiempo 28/06/2015 28/06/2015
ARTEFACTOS
Artefacto 1
Recolección de Información 28/06/2015 28/06/2015
Creación del Documento 29/06/2015 29/06/2015
Revisión y Ajustes 30/06/2015 30/06/2015

Artefacto 2
Artefacto 3
Artefacto 4
Artefacto 5
Artefacto 6
Documento Final
INFRAESTRUCTURA
Instalación y configuración de BD Oracle 12/07/2015 12/07/2015
Instalación y configuración de BD PostgreSQL 13/07/2015 13/07/2015
Instalación y configuración de Pentaho 14/07/2015 14/07/2015
Instalación y configuración de Saiku 15/07/2015 15/07/2015
Instalación y configuración de Ketle 16/07/2015 16/07/2015
Instalación y configuración de IDE's 17/07/2015 17/07/2015
DISEÑO
Diseño del Modelo de Negocios del Banco 17/07/2015 17/07/2015
Diseño del Modelo de Negocios del Sistema 18/07/2015 18/07/2015
DESARROLLO
ETL's de Extracción y Transformación de BD Oracle a BD
PostgreSQL
18/07/2015 18/07/2015
Ketle Pasar de tablas intermedias a tablas de Hechos 19/07/2015 19/07/2015
Pentaho Ajustar o pulir datos y formulas 20/07/2015 20/07/2015
Saiku Creación de Dashboard referenciales 21/07/2015 21/07/2015
PRUEBAS/CERTIFICACIONES
Se informa e inician pruebas 21/07/2015 21/07/2015

Validaciones y correcciones en el modelo 22/07/2015 22/07/2015
QA
Se informa e inician pruebas 23/07/2015 23/07/2015
Validacionesy correccionesenel modelo 23/07/2015 23/07/2015
CertificadoyListopara Pase a producción 27/07/2015 27/07/2015
Anexo 9; Planificación
III. Especificación de Requerimientos del Sistema (ERS)
Logrará facilitar la información referente a las transacciones en 3 ámbitos básicos,
como lo son: Sucursales o Agencias, Canales de Operación y Tipo de Operación. De esta
forma, se cumple con los estándares básicos para la banca a consideraciones explicitas del
área de gerencia, con el fin de realizar mejores proyecciones para una toma de decisiones
más asertiva.
Se considera entonces estos parámetros, con los cuales se podrán analizar por
ejemplo, La cantidad de Transacciones en un Canal de Operación X con un detalle de
granularidad hacia una sucursal X en un día X. Para esto se toman referencias de medidas
establecidas con las cuales se podrán generar Dashboard para próximos estudios.
ID del Indicador: 001
Reporte Analítico Transacciones Banco - 001
Área Gerencia en Banca
Proceso Trx_bank
Objetivo Estratégico
Obtener cantidad de transacciones por canales de operación,
sucursales, tipo de transacción, etc.
Definición
Validar cantidad y tipo de transacciones para una región X y una
sucursal X en una Fecha X.
Anexo 10; Indicador

Indicadores / Medidas a visualizar
Indicador/
Medida
Descripción Criterio de Obtención
Fuente de
Información
Unidad
SUCURSALES
Validar la cantidad de
transacciones por Sucursal
Todos los movimientos
aplican
BD Banco N/A
CANAL
transacciones por Canal de
Operación
aplican
BD Banco N/A
TIPO DE
OPERACIÓN
transacciones por Tipo de
Operación
aplican
BD Banco N/A
Anexo 11; Medidas
Niveles de Consolidación / Agrupación
Dimensión Fuente
D_CANAL BIB_T_INT_DCANAL
D_CONTRATO BIB_T_INT_DCONTRATO_PASIVO
D_MONEDA BIB_T_INT_DMONEDA
D_OFICINA BIB_T_INT_DOFICINA
D_PERSONA BIB_T_INT_DPERSONA
D_PRODUCTO BIB_T_INT_DPRODUCTO
D_CAUSA_TRANSACCION BIB_T_INT_DCAUSA_TRANSACCION
D_TIPO_TRANSACCION BIB_T_INT_DTIPO_TRANSACCION
D_TIPO_OPERACION BIB_T_INT_DTIPO_OPERACION
D_TIEMPO BIB_T_INT_DTIEMPO
Anexo 12; Referencia Dimensional

Frecuencia de Actualización Frecuencia de Análisis
Defina la frecuencia con la que
va a ser cargada la
información:
Defina la frecuencia con la que
va a ser solicitado / analizado el
reporte:
Mensual Mensual
Anexo 13; Frecuencia de actualización
Comparabilidad
Transacciones a comparación con:
 Años anteriores
 Meses Anteriores
 Sucursales
 Canales
 Tipo de transacción
 Tipo de Operación
 Entre Otras
Historia de la Data
Clientes del Reporte y Número de
Usuarios
Mínimo 1 mes de historia. Junta Directiva (5) Gerencia de Proyectos
(10) Gerencia de Tecnología (5) Gerencia
de Banca (10)
Valores de Alerta o Semáforos
No Aplica
Requerimientos y comentarios adicionales
Se debe tomar como referencia que del modelo se pueden generar varias Fact Tables y tablas
resumen que ayudaran a la toma decisiones, siempre y cuando se sepa modelar el negocio con
las herramientas le facilita, este tiene un mínimo detalle de granularidad (Macros) para fijar la
atención en la toma de decisiones por estadísticas netas tomando en cuenta las variables más
relevantes.
Anexo 14; Comparables

Formato de Presentación
Transacciones Por Agencia
Desarrollo en sucursales
Anexo 15; Modelo de presentación

Propiedad Intelectual
Componente Dueño Licencia Estado Comentarios
Base de Datos PostgreSQL Libre - Sin Novedades
Google Drive Google Libre - Sin Novedades
Business
Intelligence
PentahoBI Libre - Sin Novedad
Business
Intelligence
Saiku Libre - Sin Novedad
Business
Intelligence
Kettle Libre - Sin Novedad
Anexo 16; Propiedad Intelectual
IV. Diseño de la Arquitectura
Modelo del Negocio
La Data se encuentra en una Base de Datos Sysbase debido a que el CORE del
Negocio (COBIS) así lo requiere, de allí se generan archivos planos, los cuales se colocan
en un Servidor donde cada usuario accede a ellos de acuerdo a la permisología que tiene
asignada, luego los analistas generan los reportes que publicaran en un directorio especifico
y lo comparten con los usuarios finales. Siempre generan reportes nuevos y se maneja por
medio de Scripts a la BD Sysbase.

Anexo 17; Modelo de Negocio
Modelo del Sistema
La Data se encuentra en una Base de Datos Sysbase debido a que el CORE del
Negocio (COBIS) así lo requiere, de allí se extrae la información y se carga en tablas en
una BD ORACLE, de esta se generan los procesos ETL que cargan los datos a la BD
PostgreSQL, desde donde se montaran las herramientas de creación y gestión del
SCHEMA o modelo lógico para el Modelo de Transacciones del Banco EDR, se crearán
las consultas y Dashboard, para qué posteriormente se definan los indicadores para la
generación de reportes que el mismo usuario podrá desarrollar de acuerdo a sus
requerimientos de información.
Anexo 18; Modelo de Sistema
Se desea analizar las transacciones realizadas por los diversos canales de
operaciones que tiene disponible el banco EDR para sus clientes:
 Monto Total de Transacciones.
 Monto de Transacciones en Efectivo.
 Monto de Transacciones en Cheque.
 Cantidad de Transacciones.
Con estos volúmenes de transacciones se pretende proyectar la rentabilidad de los
canales y los productos y de esa forma tomar decisiones sobre nuevos estrategias a aplicar.

V. Análisis Dimensional
Dimensiones
Las dimensiones que conforman el Data Mart de Transacciones del Banco EDR son:
N° Dimensiones
1 Canal
2 Moneda
3 Oficina
4 Producto
5 Causa transacción
6 Tipo Transacción
7 Tipo Operación
8 Tiempo
9 Contrato
10 Persona
Anexo 19; Dimensiones
Facts
A continuación se indican las Facts que componen cada uno de los temas.
N° Tema Fact
1 Transacciones Estimación de volumen de transacciones

Facts vs. Dimensiones
Facts
Dimensiones
Fact1
Fact2
Canal 
Moneda 
Oficina 
Producto 
Causa transacción 
Tipo Transacción 
Tipo Operación 
Tiempo 
Contrato 
Persona 
Anexo 20; Fact vs Dimensiones

Conclusiones
Una vez finalizado el proyecto, se tienen como conclusiones más importantes las
descritas a continuación:
Las organizaciones deben organizar sus datos de manera que no hayan
inconsistencias entre ellos, puesto que en el momento de la implementación de la
herramienta de BI la consistencia de los datos es uno de los puntos más importantes, ya que
en este radica el éxito o fracaso de la herramienta, debido a que si no se tiene una buena
consistencia en los datos los informes no podrán reflejar la información que es requerida.
Se deben implementar los paquetes o las funcionalidades de la herramienta que el
usuario necesita, no es recomendable implementar funcionalidades que no serán utilizadas
por el usuario, ya que estas últimas pueden llevar a una pérdida de tiempo tanto de los
usuarios como de los desarrolladores o personas que implementaron la herramienta.
Es importante reconocer que un proyecto de BI no se debe tratar como un proyecto
de TI, ya que BI es un proyecto de negocio y las tecnologías de información se convierten
en un habilitador para conseguir los objetivos trazados. Debido a esto, un proyecto de BI
puede tener un mayor nivel de éxito cuando un área de negocio diferente al área de
tecnología es la que reconoce la necesidad de desarrollar un proyecto de este tipo.
El desarrollo de las metodologías de implementación de BI son diferentes a las
metodologías tradicionales, puesto que estas últimas generalmente son requeridas por un
área o cumplen un objetivo específico de la organización o de un área de negocio, mientras
que las metodologías utilizadas para el desarrollo de BI son pensadas para implementar
proyectos que abarquen todo el negocio y sus diferentes áreas y procesos.
En cuanto a la cultura organizacional se deben hacer campañas de información y se
debe dar a entender a los usuarios la importancia de la implementación de este proyecto, los

beneficios en cuanto a costos y tiempos y además capacitarlos para manejarla, ya que esto
proporcionara una mayor aceptación por parte de los usuarios y analistas al momento de la
implementación.

Bibliografía
 DIPLOMADOSONLINE (2015),“Guía Didáctica – Fundamentos de BI”,pp. 42-44.
 NEGASH, S., y GRAY, P. (2003), “Business intelligence”, Proceedings of the Ninth
Americas Conference on Information Systems,pp. 3190-3199.
 WATSON,H. J. (2009), “Tutorial: Business intelligence – past, present, and future”,
Communications of the Association for Information Systems, 25: 487-510.
 WIXOM, B., y WATSON,H. (2010), “The BI-based organization”, International Journal of
Business Intelligence Research,1: 13-21.
 ABUKARI,K.,y JOB,V. (2003), “Business intelligence in action”, CMA Management,
77(1): 15-18.
 BOUMAN,R. y Dongen J. (2009), “Business Intelligence and Data Warehousing with
pentaho and MySQL”, 96-318.
 KIMBALL,Ralph. “The Data Warehouse Life Cycle Toolkit”.


Proyecto Final V-1.0

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Proyecto Final V-1.0

Similar a Proyecto Final V-1.0 (20)

Proyecto Final V-1.0