Proyecto Final V-1.0

UNIVERSIDAD CENTRAL DE VENEZUELADIPLOMADOS 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

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.

Documento Final | V-1.0 | 2015 Página 2


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............................................................................................19

Beneficios del Sistema:..................................................................................................19

Capacidades...................................................................................................................20

Limitaciones..................................................................................................................20

II. Planificación del Proyecto.........................................................................................21

Evolución del Proyecto..................................................................................................22



Organización de los Equipos de Trabajo.......................................................................23

III. Especificación de Requerimientos del Sistema (ERS)..............................................26

Propiedad Intelectual.....................................................................................................30

IV. Diseño de la Arquitectura..........................................................................................31

Modelo del Negocio......................................................................................................31

Modelo del Sistema.......................................................................................................32

V. Análisis Dimensional.................................................................................................33

Dimensiones..................................................................................................................33

Facts...............................................................................................................................33

Facts vs. Dimensiones...................................................................................................34

Conclusiones.........................................................................................................................34

Bibliografía...........................................................................................................................34



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......................................................................................................21

Anexo 6; Alcances................................................................................................................22

Anexo 7; Equipo de Trabajo.................................................................................................24

Anexo 8; Herramientas de desarrollo....................................................................................24

Anexo 9; Planificación..........................................................................................................26

Anexo 10; Indicador..............................................................................................................27

Anexo 11; Medidas...............................................................................................................27

Anexo 12; Referencia Dimensional......................................................................................28

Anexo 13; Frecuencia de actualización................................................................................28

Anexo 14; Comparables........................................................................................................29

Anexo 15; Modelo de presentación......................................................................................30

Anexo 16; Propiedad Intelectual...........................................................................................31

Anexo 17; Modelo de Negocio.............................................................................................32

Anexo 18; Modelo de Sistema..............................................................................................32

Anexo 19; Dimensiones........................................................................................................33

Anexo 20; Fact vs Dimensiones............................................................................................34



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ónIdentificador 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 ReferencialesEl 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 lógico de un DW de los procesos de SC.

Se encuentra bajo el alcance

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; AlcancesDurante 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 FinTRX- Banco EDR

Asignación de integrantes y elección del proyecto 24/06/2015 24/06/2015Identificación del Problema 25/06/2015 25/06/2015Levantamiento de información y análisis de involucrados 26/06/2015 26/06/2015Asignación de Roles 27/06/2015 27/06/2015Planificación del Proyecto/Recurso/Tiempo 28/06/2015 28/06/2015ARTEFACTOSArtefacto 1Recolección de Información 28/06/2015 28/06/2015Creación del Documento 29/06/2015 29/06/2015Revisión y Ajustes 30/06/2015 30/06/2015Artefacto 2



Recolección de Información 30/06/2015 30/06/2015Creación del Documento 01/07/2015 01/07/2015Revisión y Ajustes 02/07/2015 02/07/2015Artefacto 3Recolección de Información 02/07/2015 02/07/2015Creación del Documento 03/07/2015 03/07/2015Revisión y Ajustes 04/07/2015 04/07/2015Artefacto 4Recolección de Información 04/07/2015 04/07/2015Creación del Documento 05/07/2015 05/07/2015Revisión y Ajustes 06/07/2015 06/07/2015Artefacto 5Recolección de Información 06/07/2015 06/07/2015Creación del Documento 07/07/2015 07/07/2015Revisión y Ajustes 08/07/2015 08/07/2015Artefacto 6Recolección de Información 08/07/2015 08/07/2015Creación del Documento 09/07/2015 09/07/2015Revisión y Ajustes 10/07/2015 10/07/2015Documento FinalRecolección de Información 10/07/2015 10/07/2015Creación del Documento 11/07/2015 11/07/2015Revisión y Ajustes 12/07/2015 12/07/2015INFRAESTRUCTURAInstalación y configuración de BD Oracle 12/07/2015 12/07/2015Instalación y configuración de BD PostgreSQL 13/07/2015 13/07/2015Instalación y configuración de Pentaho 14/07/2015 14/07/2015Instalación y configuración de Saiku 15/07/2015 15/07/2015Instalación y configuración de Ketle 16/07/2015 16/07/2015Instalación y configuración de IDE's 17/07/2015 17/07/2015DISEÑODiseño del Modelo de Negocios del Banco 17/07/2015 17/07/2015Diseño del Modelo de Negocios del Sistema 18/07/2015 18/07/2015DESARROLLOETL'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/2015Pentaho Ajustar o pulir datos y formulas 20/07/2015 20/07/2015Saiku Creación de Dashboard referenciales 21/07/2015 21/07/2015PRUEBAS/CERTIFICACIONESSe informa e inician pruebas 21/07/2015 21/07/2015Validaciones y correcciones en el modelo 22/07/2015 22/07/2015QA



Se informa e inician pruebas 23/07/2015 23/07/2015Validaciones y correcciones en el modelo 23/07/2015 23/07/2015Certificado y Listo para 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égicoObtener cantidad de transacciones por canales de operación,

sucursales, tipo de transacción, etc.

DefiniciónValidar 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/ Descripción Criterio de Obtención Fuente de Unida



Medida Información d

SUCURSALESValidar la cantidad de

transacciones por Sucursal

Todos los movimientos

aplicanBD Banco N/A

CANAL

Validar la cantidad de

transacciones por Canal de

Operación


aplicanBD Banco N/A

TIPO DE

OPERACIÓN

Validar la cantidad de

transacciones por Tipo de

Operación


aplicanBD 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_PA

SIVO

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_TRANSA

CCION

BIB_T_INT_DCAUSA_TRANS

ACCION

D_TIPO_TRANSACCI

ON

BIB_T_INT_DTIPO_TRANSAC

CION

D_TIPO_OPERACION

BIB_T_INT_DTIPO_OPERACI

ON

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 DataClientes 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ónTransacciones Por Agencia

Desarrollo en sucursales

Anexo 15; Modelo de presentación



Propiedad Intelectual

Componente Dueño Licencia Estado ComentariosBase de Datos PostgreSQL Libre - Sin NovedadesGoogle Drive Google Libre - Sin NovedadesBusiness 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

Fact

1

Fact

2

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”.


Documents

Proyecto Final V-1.0