proyecto final v-1.0
TRANSCRIPT
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
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 3
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 4
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 5
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 6
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 7
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 8
Modelo de Transacciones para Banco
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:
Documento Final | V-1.0 | 2015 Página 9
Modelo de Transacciones para Banco
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,
Documento Final | V-1.0 | 2015 Página 10
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 11
Modelo de Transacciones para Banco
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,
Documento Final | V-1.0 | 2015 Página 12
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 13
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 14
Modelo de Transacciones para Banco
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).
Documento Final | V-1.0 | 2015 Página 15
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 16
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 17
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 18
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 19
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 20
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 21
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 22
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 23
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 24
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 25
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 26
Modelo de Transacciones para Banco
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
Todos los movimientos
aplicanBD Banco N/A
TIPO DE
OPERACIÓN
Validar la cantidad de
transacciones por Tipo de
Operación
Todos los movimientos
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
Documento Final | V-1.0 | 2015 Página 27
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 28
Modelo de Transacciones para Banco
Anexo 14; Comparables
Formato de PresentaciónTransacciones Por Agencia
Desarrollo en sucursales
Anexo 15; Modelo de presentación
Documento Final | V-1.0 | 2015 Página 29
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 30
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 31
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 32
Modelo de Transacciones para Banco
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
Documento Final | V-1.0 | 2015 Página 33
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 34
Modelo de Transacciones para Banco
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.
Documento Final | V-1.0 | 2015 Página 35
Modelo de Transacciones para Banco
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”.
Documento Final | V-1.0 | 2015 Página 36