S Elecci On Core

PONTIFICIA UNIVERSIDAD CATLICA DEL ECUADOR
FACULTAD DE INGENIERIA
ESCUELA DE SISTEMAS
DISERTACIN PREVIA A LA OBTENCIN DEL TTULO DE

INGENIERO DE SISTEMAS
DESARROLLO DE UNA METODOLOGIA PARA LA

IMPLANTACIN DE UN CORE BANCARIO
AUTOR:
RENE ANTONIO ALVAREZ HIDALGO
DIRECTOR: ING. OSWALDO ESPINOSA.
QUITO, 2016 / Abril / 05

DEDICATORIA
Dedico este proyecto a mi familia: Yasmn, Adrin y Alejandra.

AGRADECIMIENTO
Agradezco a Dios por haberme dado el tiempo necesario para poder expresar en este
trabajo la experiencia adquirida y en espera que la misma sea de provecho y utilidad para
quienes desean involucrarse en proyectos de misin crtica.

Desarrollo de una metodologa para la implantacin de un Core Bancario 4
TABLA DE CONTENIDO
1. CAPITULO 1: CORE BANCARIO ....................................................................................... 11
1.1. QU ES UN CORE BANCARIO ....................................................................................... 11
1.2. EVOLUCIN DE LAS APLICACIONES BANCARIAS ............................................................. 13
1.3. OBJETIVO DE UN CORE BANCARIO ............................................................................... 16
1.4. MOTIVOS PARA UN CAMBIO DE CORE BANCARIO ........................................................... 16
1.5. CARACTERSTICAS DE UN CORE BANCARIO .................................................................. 17
2. CAPTULO 2: COMPONENTES DE UN CORE BANCARIO ............................................. 19
2.1. ARQUITECTURA........................................................................................................... 19
2.1.1. IMPORTANCIA DE LA ARQUITECTURA DE SOFTWARE.................................................... 20
2.1.2. CLASIFICACIN DE LA ARQUITECTURA ....................................................................... 21
2.1.2.1. ARQUITECTURA CLIENTE-SERVIDOR ...................................................................... 21
2.1.2.2. ARQUITECTURA DE TRES CAPAS............................................................................. 22
2.1.2.3. ARQUITECTURA ORIENTADA A SERVICIOS (SOA).................................................... 24
2.1.3. EJEMPLO DE UNA ARQUITECTURA UTILIZADA POR UN CORE BANCARIO ....................... 26
2.1.3.1. CARACTERSTICAS DE LA ARQUITECTURA DEL CORE BANCARIO ............................... 27
2.2. FACTORES CLAVES PARA EL XITO EN LA IMPLANTACIN DE UN CORE BANCARIO. ........... 28
2.3. PRINCIPALES MDULOS DE UN CORE BANCARIO ........................................................... 30
3. CAPTULO 3: METODOLOGA PARA IMPLANTAR UN CORE BANCARIO................... 36
3.1. INTRODUCCIN ........................................................................................................... 36
3.2. GESTIN DEL PROYECTO ............................................................................................ 37
3.2.1. ENFOQUE ................................................................................................................ 37
3.2.2. METODOLOGA DE GESTIN DE PROYECTOS .............................................................. 38
Ren Alvarez
3.2.2.1. INICIO DEL PROYECTO ........................................................................................... 39
3.2.2.1.1. ENTREGABLES DE INICIO: ................................................................................... 39
3.2.2.2. PLANIFICACIN ..................................................................................................... 40
3.2.2.2.1. ENTREGABLES DE LA PLANIFICACIN .................................................................. 40
3.2.2.3. EJECUCIN ........................................................................................................... 41
3.2.2.3.1. ENTREGABLES DE EJECUCIN ............................................................................ 41
3.2.2.4. SEGUIMIENTO Y CONTROL ..................................................................................... 42
3.2.2.4.1. ENTREGABLES DE SEGUIMIENTO Y CONTROL ...................................................... 44
3.2.2.4.1.1. INFORME DE AVANCE DEL PROYECTO ............................................................... 44
3.2.2.4.1.2. REUNIONES DE SEGUIMIENTO .......................................................................... 45
3.2.2.5. GESTIN DE LA COMUNICACIN ............................................................................. 46
3.2.2.5.1. COMIT DIRECTOR:............................................................................................ 47
3.2.2.5.2. ENTREGABLES DE GESTIN DE LA COMUNICACIN .............................................. 47
3.2.2.6. GESTIN DEL ALCANCE ......................................................................................... 48
3.2.2.6.1. VERIFICACIN DEL ALCANCE .............................................................................. 49
3.2.2.6.2. CONTROL DEL ALCANCE ..................................................................................... 50
3.2.2.6.3. CONTROL DE CAMBIOS ....................................................................................... 50
3.2.2.6.3.1. IDENTIFICAR CAMBIOS ..................................................................................... 51
3.2.2.6.3.2. FORMALIZAR CAMBIOS .................................................................................... 52
3.2.2.6.3.3. ANLISIS DE IMPACTO Y COSTOS ..................................................................... 52
3.2.2.6.3.4. APROBAR CAMBIOS ........................................................................................ 53
3.2.2.6.3.5. PLANIFICAR Y EJECUTAR EL CAMBIO ................................................................ 53
3.2.2.6.3.6. ENTREGABLES DEL CONTROL DE CAMBIO ........................................................ 54
3.2.2.7. GESTIN DE RIESGOS ........................................................................................... 54

Ren Alvarez
3.2.2.7.1. MATRIZ DE PROBABILIDAD-IMPACTO .................................................................... 56
3.2.2.7.2. IDENTIFICACIN Y REGISTRO, MONITOREO Y CONTROL DE LOS RIESGOS.............. 58
3.2.2.8. GESTIN DEL CRONOGRAMA.................................................................................. 58
3.2.2.9. GESTIN DE LA CALIDAD ........................................................................................ 59
3.2.2.10. CIERRE DEL PROYECTO ...................................................................................... 60
3.2.2.10.1. ENTREGABLES DE CIERRE DEL PROYECTO ........................................................ 61
3.2.2.11. LINEAMIENTOS GENERALES DURANTE LA VIDA DEL PROYECTO ............................... 61
3.2.2.12. FORMULARIOS PARA LA GESTIN DE PROYECTOS ................................................. 62
3.3. IMPLANTACIN DE CORE BANCARIO ............................................................................. 63
3.3.1. ANLISIS PRELIMINAR .............................................................................................. 63
3.3.1.1. PRINCIPALES FORMULARIOS DE LA FASE DE ANLISIS PRELIMINAR.......................... 65
3.3.2. ANLISIS DE REQUERIMIENTOS ................................................................................. 66
3.3.2.1. PREPARACIN DEL PROCESO DE ANLISIS DE REQUERIMIENTOS .............................. 66
3.3.2.1.1. RECOPILACIN DE INFORMACIN PARA EL ANLISIS DE REQUERIMIENTOS ............. 67
3.3.2.1.2. DEFINICIN DE PROCESOS Y REQUERIMIENTOS POR MDULO ............................... 67
3.3.2.2. EJECUCIN DEL PROCESO DE ANLISIS DE REQUERIMIENTOS .................................. 67
3.3.2.2.1. ANLISIS DE REQUERIMIENTOS ........................................................................... 67
3.3.2.2.2. NEGOCIACIN DE GAPS O REQUERIMIENTOS ........................................................ 68
3.3.2.3. ENTREGABLES DEL ANLISIS DE BRECHA ................................................................ 69
3.3.2.4. FORMULARIOS DEL ANLISIS DE BRECHAS ............................................................. 69
3.3.3. DISEO DE REQUERIMIENTOS ................................................................................... 70
3.3.3.1. ENTREGABLES: ..................................................................................................... 70
3.3.3.2. FORMULARIOS DEL DISEO TCNICO ..................................................................... 70
3.3.4. DESARROLLO / PERSONALIZACIN ............................................................................ 71

Ren Alvarez
3.3.4.1. ENTREGABLES DE LA PERSONALIZACIN: ............................................................... 72
3.3.4.2. FORMULARIOS DE LA ETAPA DE PERSONALIZACIN.................................................. 72
3.3.5. CONVIVENCIA .......................................................................................................... 72
3.3.5.1. ENTREGABLES DE LA ETAPA DE CONVIVENCIA ........................................................ 73
3.3.5.2. FORMULARIOS DE LA ETAPA DE CONVIVENCIA......................................................... 74
3.3.6. PARAMETRIZACIN................................................................................................... 74
3.3.6.1. ENTREGABLES DE LA ETAPA DE PARAMETRIZACIN ................................................. 74
3.3.6.2. FORMULARIOS DE LA ETAPA DE PARAMETRIZACIN ................................................. 75
3.3.7. ROLES Y SEGURIDADES ........................................................................................... 75
3.3.7.1. ENTREGABLES DE LA ETAPA DE ROLES Y SEGURIDADES ......................................... 76
3.3.7.2. FORMULARIOS DE LA ETAPA DE ROLES Y SEGURIDADES.......................................... 76
3.3.8. MIGRACIN DE DATOS .............................................................................................. 76
3.3.8.1. ENTREGABLES DE LA ETAPA DE MIGRACIN DE DATOS ............................................ 77
3.3.8.2. FORMULARIOS DE LA ETAPA DE MIGRACIN DE DATOS ............................................. 77
3.3.9. PREPARACIN Y EJECUCIN DE PRUEBAS................................................................. 78
3.3.9.1. FASES DE LA METODOLOGA DE PRUEBAS .............................................................. 79
3.3.9.1.1. ELABORACIN DEL PLAN DE PRUEBAS ................................................................ 79
3.3.9.1.2. CREACIN DE CASOS DE PRUEBA ....................................................................... 79
3.3.9.1.3. EJECUCIN DE PRUEBAS DEL SISTEMA ............................................................... 79
3.3.9.1.4. GESTIONAR RESULTADOS DEL PROCESO DE PRUEBAS (EVALUACIN) ................... 80
3.3.9.2. ENTREGABLES DE LA ETAPA DE PREPARACIN Y EJECUCIN DE PRUEBAS............... 81
3.3.9.3. FORMULARIOS DE LA ETAPA DE PREPARACIN Y EJECUCIN DE PRUEBAS ............... 81
3.3.10. DOCUMENTACIN .................................................................................................. 81
3.3.10.1. ENTREGABLES DE LA ETAPA DE DOCUMENTACIN ................................................ 82

Ren Alvarez
3.3.10.2. FORMULARIOS DE LA ETAPA DE DOCUMENTACIN................................................. 82
3.3.11. CAPACITACIN....................................................................................................... 83
3.3.11.1. MATERIALES ....................................................................................................... 83
3.3.11.2. ENTREGABLES DE LA ETAPA DE CAPACITACIN..................................................... 84
3.3.11.3. FORMULARIOS DE LA ETAPA DE CAPACITACIN ..................................................... 84
3.3.12. ESTRATEGIA DE SALIDA A PRODUCCIN .................................................................. 84
3.3.12.1. ENTREGABLES DE LA ETAPA DE ESTRATEGIA DE SALIDA A PRODUCCIN ................ 86
3.3.13. CERTIFICACIN / QA IFI ......................................................................................... 86
3.3.13.1. ENTREGABLES DE LA ETAPA DE CERTIFICACIN .................................................... 86
3.3.14. PREPARACIN PARA SALIR A PRODUCCIN ............................................................. 87
3.3.14.1. ENTREGABLES DE LA ETAPA DE PREPARACIN PARA SALIR A PRODUCCIN ........... 88
3.3.14.2. FORMULARIOS DE LA ETAPA DE PREPARACIN PARA SALIR A PRODUCCIN ........... 88
3.3.15. PILOTOS / PARALELOS............................................................................................ 89
3.3.15.1. ENTREGABLES DE LA ETAPA DE PILOTOS O PARALELOS ........................................ 89
3.3.16. ESTABILIZACIN ..................................................................................................... 90
3.3.16.1. ENTREGABLES DE LA ETAPA DE ESTABILIZACIN................................................... 91
4. CAPTULO 4: CONCLUSIONES Y RECOMENDACIONES .............................................. 92
4.1. CONCLUSIONES .......................................................................................................... 92
4.2. RECOMENDACIONES ................................................................................................... 93
4.3. BIBLIOGRAFA ............................................................................................................. 95
Ren Alvarez
NDICE DE FIGURAS
FIGURA 1-01: EVOLUCIN DE LAS APLICACIONES BANCARIAS, (PLA GONZALEZ, 2013) ........................... 14
FIGURA 1-02: ESTRATEGIAS DE SERVICIOS A CLIENTES, (BUPARTECH, 2006).................................... 15
FIGURA 2-03: ARQUITECTURA CLIENTE-SERVIDOR, (BOLO, 2011) ........................................................ 21
FIGURA 2-04: ARQUITECTURA DE TRES CAPAS, (GONZALEZ QUIROGA, 2011) ....................................... 23
FIGURA 2-05: ARQUITECTURA ORIENTADA A SERVICIOS SOA, (BOLO, 2011) ..................................... 25
FIGURA 2-06: ARQUITECTURA EJEMPLO DE UN CORE BANCARIO, (MAIATECH, 2011) .......................... 27
FIGURA 2-07: MDULOS DE UN CORE BANCARIO, (MAIATECH, 2011) ................................................ 34
FIGURA 3-08: METODOLOGA DE IMPLANTACIN DE UN CORE BANCARIO, (BUPARTECH, 2005) .......... 37
FIGURA 3-09: GOBERNABILIDAD DEL PROYECTO, (BUPARTECH, 2005) .............................................. 38
FIGURA 3-10: PROCESOS DE GESTIN DEL ALCANCE DEL PROYECTO, (CORON, 2013) ......................... 48
FIGURA 3-11: PROCESOS DE CONTROL DE CAMBIOS, (FLEITAS, 2015) ................................................. 51
FIGURA 3-12: ETAPAS DE LA GESTIN DE RIESGOS, (LLARDA, 2013) ................................................... 54
FIGURA 3-13: ETAPA DE ANLISIS DE BRECHAS, (BUPARTECH, 2006) ............................................... 66
FIGURA 3-14: METODOLOGA DE PRUEBAS, (MAIATECH, 2011) ......................................................... 78
Ren Alvarez
NDICE DE TABLAS
TABLA 1. ANLISIS CUANTITATIVO ........................................................................................................ 56
TABLA 2. MATRIZ DE VALORES DE PROBABILIDAD E IMPACTO ................................................................. 56
TABLA 3. PROBABILIDAD X IMPACTO EN FORMA GRFICA ....................................................................... 57
TABLA 4. FORMULARIOS PARA LA GESTIN DE PROYECTOS ................................................................... 62
TABLA 5. FORMULARIOS DE LA FASE DE ANLISIS PRELIMINAR.............................................................. 65
TABLA 6. FORMULARIOS DEL ANLISIS DE BRECHAS ............................................................................. 70
TABLA 7. FORMULARIOS DEL DISEO TCNICO..................................................................................... 71
TABLA 8. FORMULARIOS DE LA ETAPA DE PERSONALIZACIN ................................................................. 72
TABLA 9. FORMULARIOS DE LA ETAPA DE PARAMETRIZACIN ................................................................. 75
TABLA 10. FORMULARIOS DE LA ETAPA DE ROLES Y SEGURIDADES ....................................................... 76
TABLA 11. FORMULARIOS DE LA ETAPA DE MIGRACIN DE DATOS ......................................................... 78
TABLA 12. FORMULARIOS DE LA ETAPA DE PREPARACIN Y EJECUCIN DE PRUEBAS ............................ 81
TABLA 13. FORMULARIOS DE LA ETAPA DE DOCUMENTACIN ................................................................ 82
TABLA 14. FORMULARIOS DE LA ETAPA DE CAPACITACIN .................................................................... 84
TABLA 15. FORMULARIOS DE LA ETAPA DE SALIDA A PRODUCCIN ......................................................... 88
Ren Alvarez
1. CAPITULO 1: CORE BANCARIO
Este captulo nos da una visin de lo que es un Core Bancario y para que lo utilizan las
Instituciones Financieras, los mdulos que lo componen, cmo han ido evolucionando a
travs del tiempo tanto funcional como tcnicamente y sobre todo nos da una idea clara de
las principales razones por la cual una Institucin Financiera decide cambiar o actualizar su
Core Bancario el cual debe cumplir al menos ciertas caractersticas principales.
1.1. Qu es un Core Bancario
Core Bancario se refiere al negocio que desarrolla una institucin bancaria, pero se ha
difundido a cualquier institucin financiera, Cooperativa de Ahorro y Crdito, Sociedad
Financiera, Mutualista, Cajas de Ahorro o Bancos, es decir, es el core de negocio de una
Institucin Financiera o IFI1 y normalmente se entiende como las operaciones de depsitos
(captaciones) y de prstamos (colocaciones) con todos sus servicios relacionados.
En la actualidad las IFIs utilizan aplicaciones de Core Bancario para gestionar sus
operaciones, accediendo en lnea y tiempo real, a travs de cualquier canal (sucursales,
agencias, ATMs2, kioscos, IVRs3, POS4, Banca por internet, dispositivos mviles) a una
1
IFI: Institucin Financiera
2
ATM: Cajero Automtico o Automated Teller Machine
3
IVR: Sistema telefnico que es capaz de recibir una llamada e interactuar con el humano a travs de
grabaciones de voz y el reconocimiento de respuestas, en ingls: Interactive Voice Response
4
POS: Punto de Venta o en ingls Point Of Sale
Ren Alvarez
fuente de datos centralizada, de tal forma que cualquier transaccin es reflejada
inmediatamente en los sistemas y bases de datos de la IFI. (Diccionario , 2013)
Es as que las soluciones de Core Bancario combinan la tecnologa de las
comunicaciones y la tecnologa de la informacin, para satisfacer las necesidades bsicas
de una IFI, dichas soluciones administran y controlan los procesos y actividades de las
IFIs, entre las ms importantes se destacan:
Clientes y Firmas digitalizadas
Contabilidad
Productos Activos (Colocaciones)
Productos Pasivos (Captaciones)
Servicios Bancarios
Tesorera
Home banking (Banca por internet para segmento consumo o personal)
Cash Management (Banca por internet para segmento corporativo)
Cajas o Taquillas
Reportes Operativos y Regulatorios
Prevencin de fraude y lavado de activos
Las buenas aplicaciones de Core Bancario por lo general son modulares, paramtricas,
basadas en una plataforma con enfoque gradual y estratgico cuyo objetivo es permitir a
las IFIs mejorar sus operaciones y servicios, reducir costos, facilitar la interoperabilidad y
apoyar el crecimiento institucional.
Por tanto, el Core Bancario representa el corazn de la operacin de una IFI, y la
decisin de seleccionar e implantar una plataforma de ltima generacin, representa un
Ren Alvarez
reto en trminos de flexibilidad, escalabilidad, funcionalidad e inversin, que est
totalmente alineada a la estrategia de negocio y que asegure un soporte operativo a
mediano y largo plazo.
1.2. Evolucin de las aplicaciones bancarias
Los sistemas o aplicaciones bancarias han venido evolucionando junto con la tecnologa
de la poca correspondiente, pues deben estar a tono con lo que el negocio busca, que es
ofrecer ms y mejores productos y servicios a menores costos. Esta evolucin ha sido ms
evidente desde el ao 1990, en que se ha notado grandemente al desarrollo de las
aplicaciones bancarias, pues han pasado desde la operacin manual, al desarrollo propio o
interno aprovechando la disminucin de costos, entrando en la moda de la reingeniera de
procesos para volverlos ms eficientes, mientras aparecan casas de software que
decidieron apostar por la tecnologa IFI / Servidor y bases de datos distribuidas para el
desarrollo de aplicaciones bancarias, aun en la actualidad existen instituciones en la regin,
que mantienen el desarrollo interno y la tecnologa IFI / Servidor. Con la llegada de
internet, otros paradigmas son rotos y otros aceptados y las aplicaciones empiezan a ser
migradas hacia estas nuevas tecnologas generndose aplicaciones: IFI / Servidor con
interface Web, aplicaciones Smart-Client, aplicaciones web, aplicaciones full web que en
la actualidad pueden ser ejecutadas por cualquier dispositivo mvil (responsive), adems
de permitir la interoperabilidad a travs del uso de tecnologa SOA5, llegando actualmente
a los conceptos de multi-canalidad y omni-canalidad. (ISSUU, 2012)
5
SOA: Arquitectura Orientada a Servicios o en ingls Service Oriented Architecture.
Ren Alvarez
Otro enfoque de la evolucin es que las aplicaciones bancarias automatizadas iniciaron
siendo transaccionales y hoy en da estn migrando hacia la orientacin a procesos, a
travs de la utilizacin de herramientas BPMS6.
Figura 1-01: Evolucin de las aplicaciones bancarias, (Pla Gonzalez, 2013)
La realidad actual es que las organizaciones deben ser ms eficientes y centradas en el
IFI, lo que significa que deben actualizar sus estrategias para no ceder participacin de
mercado y apoyarse en la tecnologa para brindar mejores y ms eficientes servicios a sus
Clientes.
6
BPMS: Suite para la gestin de procesos de negocio o en ingls, Business Process Management Suite.
Ren Alvarez
Figura 1-02: Estrategias de servicios a Clientes, (BUPARTECH, 2006)
Uno de los principales factores que apoyan fuertemente el objetivo de las IFIs de lograr
esta eficiencia tan necesaria y la posibilidad de brindar mejores productos y servicios
reduciendo costos, es contar con un Core Bancario.
En el Ecuador principalmente y en general en Latinoamrica, todava existen
instituciones financieras que administran su informacin de forma manual, otras utilizan
aplicaciones que se ejecutan en main frames, otras ya sea por desarrollo propio o por que
han adquirido soluciones mantienen la tecnologa IFI/servidor y unas pocas han
evolucionado o migrado hacia tecnologa web o full web o mantienen aplicaciones mixtas,
todo esto implica que en el corto o mediano plazo, las instituciones que an no lo han
hecho debern actualizarse tecnolgicamente de una u otra manera (cambio de core
bancario, adquisicin de nuevos mdulos para ampliar canales, funcionalidades, productos
o servicios, actualizacin tecnolgica del front-end manteniendo el back-end, actualizacin
tecnolgica orientada a procesos (BPM), entre otras).
Ren Alvarez
Todo proceso de cambio de core bancario (total o parcial) o actualizacin tecnolgica
que deba hacerse en una IFI necesariamente debe basarse en buenas prcticas, en una
metodologa, que permita poner orden y ejecutar de una manera controlada la gran
cantidad de tareas que deben realizarse.
1.3. Objetivo de un Core Bancario
El objetivo principal de la implantacin de un Core Bancario busca contribuir a una
mayor productividad, eficiencia y rentabilidad de una IFI. Dicho cambio debe entenderse
como la plataforma donde se combinan la tecnologa de la comunicacin y la tecnologa de
la informacin para satisfacer las necesidades de clientes cada vez ms exigentes, las
necesidades del negocio y las de la industria bancaria y sus rganos de control.
1.4. Motivos para un cambio de Core Bancario
Son diversos los factores que motivan un cambio de Core Bancario, entre los
principales se encuentran:
La obsolescencia tecnolgica del hardware y/o del software.
Falta de integracin entre sus mdulos y componentes.
Cambios en los requerimientos del negocio junto con observaciones o no
conformidades dados por los organismos de control, especialmente los dados por la
Superintendencia de Bancos.
Crecimiento desordenado de sus sistemas.
Altos costos de soporte y mantenimiento.
Necesidad de una solucin que acompae el crecimiento del Banco.
Disponibilidad de la informacin que aumenta el riesgo operacional, entre otros
factores que obstaculizan la plena satisfaccin del IFI.
Ren Alvarez
Desalineacin en la integridad y disponibilidad de la informacin, la cual aumenta
el riesgo operacional.
Automatizacin de actividades en lugar de intervencin manual
Rediseo, mejoramiento y automatizacin de procesos
Mejorar tiempos de respuesta
Disminucin de riesgos operativos
Mayor productividad, eficiencia y rentabilidad
1.5. Caractersticas de un Core Bancario
A continuacin, se describen algunas de las caractersticas principales que todo Core
Bancario en la actualidad al menos debera cumplir:
Confiabilidad: Un Core Bancario deber estar pensado para soportar volmenes
exigentes y de alta carga transaccional (millones de transacciones diarias).
Disponibilidad: Los clientes de un banco deben tener la posibilidad de acceder a sus
servicios financieros las 24 horas del da, los 365 das del ao.
Accesible: Los distintos productos y servicios deben estar disponibles para usuarios y
clientes a travs de cualquier canal (multicanalidad).
Escalable: debe estar preparado para crecer junto con la IFI, ya sea que se trate una
institucin con una pequea red de oficinas o una institucin con una extensa red de
oficinas y atencin al IFI a travs de mltiples canales.
Arquitectura SOA: permitir la interoperabilidad usando estndares de la industria
como servicios web.
Seguridad: Permitir que los clientes y los usuarios de las aplicaciones del Core
Bancario realicen sus transacciones de manera segura y a su vez cumplan con los
lineamientos dados por los organismos de control

Ren Alvarez
IFI nico: El Core Bancario debe mantener una base de datos nica de IFI, el cual
tiene un identificador nico y a su vez permita una vista 360 grados del IFI.
Parametrizable y Flexible: Mientras ms parametrizable es la aplicacin o el mdulo,
menor tiempo es necesario para sacar nuevos productos y servicios al mercado (time to
market) y menos dependencia del rea de TI de la IFI.
Experiencia del Usuario: Busca una percepcin positiva de un producto, servicio o
dispositivo. Por ejemplo, a nivel de usuario del Banco o IFI del mismo, facilidad para
cambiar el look and feel de las aplicaciones; si soy IFI: poder escoger las opciones de
men que quiero que aparezcan en mi interface de usuario, inclusive poder cambiar las
etiquetas, por ejemplo, en lugar que la opcin de men diga: retiro de dinero en
efectivo cambiarlo por sacar plata.
En lnea y tiempo real: Disponer de la informacin actualizada en lnea y tiempo real
al instante en cualquier lugar y donde la necesite. (GesFor, 2014)
Ren Alvarez
2. CAPTULO 2: COMPONENTES DE UN CORE BANCARIO
Bsicamente un Core Bancario est compuesto por la arquitectura tcnica que lo soporta
y las aplicaciones, mdulos o funcionalidades construidas sobre dicha arquitectura y que
soportan el negocio de una IFI.
A continuacin, se explica de manera general los tipos de arquitecturas que soportan la
mayora de core bancarios del mercado y los mdulos o funcionalidades que soportan el
negocio.
2.1. Arquitectura
En trminos de software cada vez es ms comn escuchar la palabra arquitectura, la
cual se refiere a la estructuracin del sistema que, por cuestiones lgicas se va creando en
etapas previas al desarrollo del mismo. Esta estructuracin representa un diseo de alto
nivel del sistema que tiene dos propsitos fundamentales:
1. Satisfacer los atributos de calidad garantizando la seguridad del proyecto.
2. Servir como gua en el desarrollo del proyecto (LLorente & Oliveras, 2011).
Al igual que en la ingeniera civil, en el mundo del software informtico, el diseo de
una buena arquitectura debe hacerse desde el inicio, antes de cualquier desarrollo, es la
diferencia entre el xito y el fracaso de una aplicacin de core bancario que pretenda
desarrollarse e implantarse sea a nivel local, regional o mundial. Es por ello que la
arquitectura de software juega un papel fundamental dentro de la creacin de un Core
Bancario o cualquier sistema de misin crtica en general (LLorente & Oliveras, 2011).
Ren Alvarez
2.1.1. Importancia de la arquitectura de software
En la actualidad la arquitectura de software es la base de cualquier aplicacin bancaria,
es la manera en que se estructura el sistema y permitir su evolucin a travs del tiempo,
posee un impacto directo sobre la capacidad final de satisfacer los trminos de calidad de
core bancario.
Algunos de los atributos que puntualiza la arquitectura y que miden la calidad del
sistema son:
El desempeo, que tiene que ver directamente con el tiempo de respuesta del
sistema a las peticiones que le hace el usuario.
La usabilidad, que no es ms que el nivel de sencillez de realizar operaciones con
el sistema para los usuarios.
La modificabilidad, que no es ms que la simpleza de poder introducir cambios en
el sistema (LLarda, 2013).
La arquitectura utilizada en un core bancario es directamente proporcional a la calidad
del mismo, por tanto, la arquitectura y los atributos de calidad son parte de los
requerimientos no funcionales del core bancario que una IFI debe evaluar antes de su
adquisicin y verificar que est alineada con su estrategia tecnolgica y con su plan
estratgico.
Es importante considerar que la arquitectura del core bancario seleccionado por la IFI,
pueda ser reutilizada para crear otras funcionalidades o mdulos o sistemas, de una forma
gil, permitiendo reducir costos, aprovechar el time to market, y sobre todo, acompaar a
la IFI en su crecimiento.
Ren Alvarez
2.1.2. Clasificacin de la arquitectura
Las aplicaciones bancarias actuales en su gran mayora estn basadas en una de las
siguientes arquitecturas:
Cliente - Servidor.
Modelo tres capas.
Orientado a servicios.
2.1.2.1.Arquitectura Cliente-Servidor
Desde el punto de vista funcional, se puede definir el modelo Cliente-Servidor como
una arquitectura distribuida que permite a los usuarios finales obtener acceso a la
informacin en forma transparente incluyendo entornos multiplataforma.
Su funcionamiento consiste en que el Cliente enva un mensaje solicitando un
determinado servicio a un servidor (hace una peticin) y este enva uno o varios mensajes
con la respuesta (provee el servicio). En un sistema distribuido cada mquina puede
cumplir el rol de servidor y de Cliente en dependencia de la tarea que desarrolla.
Figura 2-03: Arquitectura Cliente-Servidor, (Bolo, 2011)
Ren Alvarez
Las funciones que lleva a cabo el proceso Cliente se plantean en los siguientes puntos:
Administrar la interfaz de usuario.
Interactuar con el usuario.
Procesar la lgica de la aplicacin y hacer validaciones locales.
Generar requerimientos de bases de datos.
Recibir resultados del servidor.
Formatear resultado s (F., 2014).
Las funciones que lleva a cabo el sistema de servidor se plantean en los siguientes
puntos:
Aceptar los requerimientos de bases de datos que hacen los Clientes.
Procesar requerimientos de bases de datos.
Formatear datos para trasmitirlos a los Clientes.
Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases de dato s
(F., 2014).
2.1.2.2.Arquitectura de tres capas
La arquitectura por capas se define como un estilo de programacin cuyo objetivo
esencial es la separacin de la capa de presentacin, capa de negocios y la capa de datos.
De esta manera, si existe algn cambio, no es necesario interactuar con todas las capas y
por tanto con todo el cdigo, solo en la capa donde existe el problema o donde se requiere
hacer los cambios (Mrquez Gmez, 2010).
Ren Alvarez
Figura 2-04: Arquitectura de tres capas, (Gonzalez Quiroga, 2011)
Esta arquitectura es muy utilizada en la actualidad, producto de su evolucin desde la
arquitectura IFI servidor, varios core bancarios del mercado han evolucionado hacia esta
arquitectura total o parcialmente. Las principales caractersticas de las capas que la
componen se muestran a continuacin:
1. Capa de Presentacin o Interfaz de Usuario: Capa que interacta directamente con
el usuario, conformada por una interfaz grfica, la cual debe ser muy intuitiva y amigable.
2. Capa de Negocios: Lgica del Negocio o Reglas del Negocio: Como su nombre lo
especfica, en esta capa se realizan y se establecen todas las reglas que deben cumplirse en
el negocio, diseando y atendiendo a las necesidades del core bancario. Esta capa se
encuentra conectada a la capa de presentacin, puesto que recibe las solicitudes por parte
de los clientes y las procesa, con la necesidad de obtener la informacin archivada en la
capa de datos, a la cual tambin est conectada.
3. Capa de Datos: Es la capa en la cual se encuentran almacenados los datos y su
funcin especfica es que las dems capas tengan el total acceso a stos. La misma puede
estar formada por uno ms Sistemas de Gestin de Base de Datos (SGBD), para realizar
los procesos de administracin de la informacin que se encuentra alojada en ella
(Mrquez Gmez, 2010).
Ren Alvarez
2.1.2.3.Arquitectura Orientada a Servicios (SOA)
SOA es la arquitectura de software enfocada en proyectos que definen servicios para dar
soporte a los requerimientos del core bancario y/o la IFI. Esta arquitectura permite crear
sistemas altamente escalables, que pueden ayudar a las organizaciones a impulsar el
rendimiento y al mismo tiempo, reducir costos y mejorar la flexibilidad en los procesos del
negocio (Villz, 2011).
SOA proporciona una metodologa y un marco de trabajo para documentar las
capacidades de negocio, dando soporte a las actividades de integracin y consolidacin de
los datos de cualquier organizacin.
Caractersticas fundamentales:
Servicios de datos escalables y flexibles.
Servicios de infraestructura para la autentificacin, el control de acceso y el
registro.
Permite crear, leer y actualizar datos de todas las formas de sistemas, incluidos
datos estructurados, no estructurados, semi-estructurados, de mainframe y en la
nube.
Servicios de integracin para ofrecer todas las propuestas para datos, como el
acceso, el perfilado, la transformacin, la calidad y la entrega de los mismos.
Servicios de metadatos para gestionar y utilizar metadatos tcnicos y de negocio
para la deteccin, la auditora, el linaje y el anlisis de impacto (Villz, 2011).
La figura que se muestra a continuacin muestra los servicios de una arquitectura SOA,
la cual est formada por un conjunto de funciones y de calidad de servicios.
Ren Alvarez
Figura 2-05: Arquitectura Orientada a Servicios SOA, (Bolo, 2011)
Las funciones principales estn formadas por:
1. Transporte: Mecanismo utilizado para trasladar las peticiones desde el IFI hasta el
proveedor de servicio y viceversa.
2. Protocolo de comunicacin: Es el sistema de comunicacin entre el IFI y el
proveedor de servicios.
3. Descripcin de servicios: Esquema utilizado para describir de qu tipo de servicio se
est en presencia y de esta manera como se le puede invocar y cules son los datos que se
necesitan para realizar esta invocacin.
4. Servicios: Es la implementacin como tal de cada uno de los servicios ya diseados.
5. Proceso de negocio: Coleccin de servicios, invocados en una determinada
secuencia, con un conjunto particular de reglas para satisfacer un requisito de negocio.
6. Registro de servicios: Repositorios de servicios y datos, usados por los proveedores
de servicios para publicar los servicios y para los clientes donde buscarlos (Jason, 2013).
La calidad del servicio se identifica por:
Ren Alvarez
1. Poltica: Conjunto de reglas bajo las cuales, un proveedor de servicios hace que el
mismo est disponible para los clientes.
2. Seguridad: Conjunto de reglas que podran ser aplicadas en la identificacin,
autorizacin y control de acceso a los servicios por parte del IFI.
3. Transaccin: Conjunto de atributos que podran ser aplicados sobre un grupo de
servicios para devolver un conjunto de datos consistentes.
4. Administracin: Conjunto de atributos que podran ser aplicados para gestionar los
servicios proporcionados (Jason, 2013).
Esta arquitectura establece un marco de diseo de manera tal que se integren las
aplicaciones independientes, con el objetivo que desde la red se pueda acceder a las
funcionalidades publicadas y ofrecidas como servicios. La versin ms utilizada para
desarrollarla es a travs de servicios web, una tecnologa basada en estndares de forma
independiente.
La arquitectura SOA en las aplicaciones de Core Bancario define y proporciona la
infraestructura necesaria para desarrollar o personalizar un proyecto de forma que los
procesos de negocio se lleven a cabo con total independencia de la plataforma hardware-
software sobre la que trabajan: sistema operativo, lenguaje de programacin, base de datos,
caractersticas de los equipos, etc. (Jason, 2013).
2.1.3. Ejemplo de una Arquitectura utilizada por un Core Bancario
La arquitectura utilizada en un core bancario debe ser robusta, con una estructura
tecnolgica consistente, que permita el incremento de la productividad, reducir costos a
travs de mayor eficiencia, facilidad de interoperabilidad, ser independiente para aadir
nuevas funcionalidades rpidamente disminuyendo costos de mantenimiento y mejorando
el Time To Market, que permita una implantacin que respete alcance, tiempo y costo
Ren Alvarez
contratado por la IFI. A continuacin, se muestra a manera de ejemplo, la arquitectura de
una aplicacin bancaria ecuatoriana.
Figura 2-06: Arquitectura ejemplo de un Core Bancario, (MAIATECH, 2011)
2.1.3.1.Caractersticas de la arquitectura del Core Bancario
Interfaz web amigable, parametrizable.
Arquitectura Open source
Multiplataforma: Windows, Unix o Linux.
Independencia real de la base de datos.
IFI ligero (se ejecutar sobre un navegador o browser).
Desarrollado en java utilizando la especificacin JEE6.
Herramienta BPM (Business Process Management) integrada
Herramienta de gestin documental (ECM) integrada
Ren Alvarez
Facilidades de integracin con otras aplicaciones.
Multi-usuario, multi-compaa, multi-moneda, multi-idioma.
Componentes Open Source:
- Sistema Operativo: Linux o cualquier versin de Unix
- Base de Datos: Postgres, MySQL
- Frameworks:
1. JPA (Java Persistence API)
2. DOJO
3. AJAX
- Application Server: JBOSS
- Herramienta BPM: JBPM
- Herramienta para reportes: IREPORTS, JASPER REPORTS
- IDEs de desarrollo:
1. Eclipse
2. Jdeveloper
3. NetBeans
2.2. Factores claves para el xito en la implantacin de un core bancario.
Compromiso permanente de los altos ejecutivos de la IFI y su participacin
oportuna durante todo el proyecto de seleccin, evaluacin e implantacin.
Fuerte liderazgo en trminos de visin, conocimiento y experiencia.
Toma oportuna de decisiones a todo nivel.
Involucrar los mejores recursos de las reas de sistemas, procesos, negocios y
funcionales.
Seleccionar el proveedor y el producto adecuado a la realidad de la IFI.
Ren Alvarez
Utilizar las mejores prcticas y metodologas de implantacin (Acompaamiento
metodolgico).
Definicin clara de los objetivos, alcance y restricciones.
Nivelacin en el conocimiento del grupo del proyecto.
Manejo adecuado y oportuno de los compromisos.
Manejo adecuado de la presin del tiempo durante el proceso de implantacin.
Siendo la metodologa de implantacin de core bancario uno de los principales factores
que facilitan el xito de un proyecto de esta naturaleza, este trabajo se centra en describir
dicha metodologa.
Varios core bancarios del mercado que desde los noventas nacieron con una
arquitectura IFI-servidor, en el transcurso de estos aos algunos han evolucionado hacia las
nuevas arquitecturas y tecnologas, otros han mantenido su arquitectura original en el back-
end aunque han evolucionado el front-end o capa de presentacin hacia la web y otros an
mantienen las arquitecturas con la cual nacieron; existen varios core bancarios en
Latinoamrica implantados en los bancos de la regin, entro los ms conocidos estn:
COBIS
TEMENOS
Arango Software
Fit Bank
Fisa
Topaz
Byte
Bantotal
Ren Alvarez
eIBS
MAIA CB
Financial
Denarios
2.3. Principales mdulos de un Core Bancario
Una aplicacin bancaria contiene mdulos o funcionalidades que permiten cubrir la
operativa de una IFI de tal forma que permita brindar productos y servicios bancarios a sus
clientes y a la vez cumplir con todas las normas legales.
Estas funcionalidades estn englobadas dentro de los principales mdulos que encierran
un Core Bancario, los cuales son accesibles desde cualquiera de las sucursales bancarias o
canales electrnicos.
A continuacin, se describe los principales mdulos que componen un core bancario:
Generales: Administra parmetros generales utilizados en la aplicacin. Ejemplo:
pases, ciudades, provincias, cantones, sucursales, oficinas, monedas, tipos de
crdito, bases de clculo, etc. Algunos Core, presentan facilidades para la
modificacin y creacin de nuevas pantallas y transacciones a travs de
parametrizacin o configuracin.
Seguridades: Componente que se basa en la parametrizacin de usuarios, perfiles,
transacciones, montos autorizados, horarios de trabajo, etc., normalmente regulado
por los entes de control en lo que se relaciona con permisos de acceso.
Clientes: Mdulo que administra la informacin de clientes naturales y jurdicos
con sus distintos niveles de informacin, que incluye sus firmas, sellos y fotografa;
los ms actualizados cuentan con informacin biomtrica (huella digital, iris del
ojo) para control de acceso y permisos de ejecucin de transacciones.

Ren Alvarez
Contabilidad: Permite realizar el registro, control y seguimiento de todos los
procesos contables. La mayora de core bancarios soportan contabilizacin
automtica de los distintos productos bancarios, en algunos casos dicha
contabilidad se realiza en batch y en otros se realiza en lnea.
Tarifarios: Permite administrar centralizadamente y de forma paramtrica, las
tarifas / costos tales como: cargos, impuestos, comisiones, tasas, etc., que sern
aplicados a los productos bancarios.
Originacin de Crdito: Registra a travs de flujos de procesos paramtricos, los
procesos de pre-calificacin, anlisis y aprobacin de solicitudes de crdito hasta
llegar a su instrumentacin, permitiendo obtener indicadores de gestin de los
distintos procesos. Algunas aplicaciones actuales cuentan ya con herramientas
BPM y gestin documental integradas.
Prstamos: Administra las operaciones activas de la institucin financiera,
parametrizable, facilidad para crear distintas lneas de crdito y distintos tipos de
prstamos: consumo, comerciales, hipotecarios, prendarios, micro-crditos.
Garantas: Administra varios tipos de garantas asociadas a clientes, las cuales
pueden respaldar una o varias operaciones de crdito.
Cuentas a la vista: Administra en lnea y tiempo real las Cuentas Corrientes y
Cuentas de Ahorro de la institucin. Parametrizable, se puede crear productos
diferenciados en distintas monedas, registra y administra sus movimientos y saldos.
Firmas Electrnicas: Mdulo que permite la digitalizacin de las firmas y/o sellos
de los clientes de la institucin, para su posterior consulta por parte de otros
mdulos del sistema.
Depsitos a Plazo: Registra y administra las inversiones a plazo fijo de los clientes
de la institucin.
Ren Alvarez
Branch / Cajas: Registra las transacciones ejecutadas por los clientes sobre los
distintos productos bancarios. Algunas aplicaciones manejan el concepto de caja
mltiple: se permiten varios orgenes de fondos, para varios destinos desde una
misma pantalla. Permite la apertura y cierre de cajas y de sucursales, manejo de
blindados, etc.
Reportes a Entidades de Control: Mdulo que permite emitir en forma gil y
segura las distintas estructuras y reportes que solicitan las diferentes entidades de
control.
Banca Virtual: Mdulo que a travs de internet permite a las personas naturales de
la institucin realizar transacciones financieras como consultas de saldos,
transferencias, pago de prstamos, pago de servicios, etc.
Adicionalmente a estos mdulos que por lo regular conforman una aplicacin de Core
Bancario, las IFIs necesitan algunas otras soluciones o sistemas que les permiten
completar toda su operacin, dependiendo del tipo de Banco o hacia donde enfoquen su
negocio. Algunas soluciones de core bancario, pocas en realidad, ofrecen una suite
completa que incluye los mdulos antes mencionados y todos o algunos de los que se
mencionan a continuacin.
Riesgos: Suite de mdulos que permiten una mejor gestin, administracin y toma
de decisiones estratgicas sobre los riesgos, por lo general deben cumplir las
normas de Basilea.
o Riesgo Financiero: Riesgo de Crdito, Mercado, Liquidez y Tasa.
o Riesgo Operativo: controlar la posibilidad de ocurrencia de prdidas
financieras, que pueden originare por fallas de procesos, personas, sistemas
Ren Alvarez
internos, tecnologa, inclusive por el aparecimiento de eventos externos
imprevistos.
Inteligencia de Negocios (BI): Herramienta que a travs de informacin
multidimensional (cubos) facilita el anlisis de informacin de clientes, productos,
servicios y sucursales.
Comercio Exterior: Mdulo que permite la administracin de Cartas de Crdito de
Importacin (CCI), Cartas de Crdito de Exportacin (CCE), Cartas de Crdito
domsticas (CCD), Garantas bancarias y Stand By, Avles bancarios entre otras.
Prevencin de Fraude y Lavado de Activos: Normalmente conocida como
herramienta de AML (Anti Money Laundry), podra apoyar o potenciar el
conocimiento del IFI (KYC), debiendo ajustarse a las leyes vigentes en cada pas y
las normas internacionales.
Mobile: Nuevo canal que permite acceso a los servicios bancarios en cualquier
momento y en cualquier lugar a travs de dispositivos mviles.
Cash Management: Mdulo que a travs de internet permite a las personas
jurdicas de la institucin realizar transacciones financieras como consultas de
saldos, transferencias, pago de prstamos, pago de servicios, pago de nmina, pago
de proveedores, etc., con los permisos adecuados para carga y autorizacin de
transacciones.
Tesorera: Mdulo que permite administrar la liquidez, manejar el riesgo y
gestionar negocios complejos con instrumentos financieros, algunas
funcionalidades son: cambio de divisas, mercado de dinero, prstamos entre
instituciones financieras, seguimiento a traders, entre otras.
Ren Alvarez
El conjunto de mdulos por los que est compuesto un Core Bancario, son aplicaciones
con funcionalidades especficas, que trabajan sobre una plataforma de manera ntegra,
permitiendo un enfoque estratgico que tiene por objetivo permitir a las IFIsmejorar las
operaciones, reducir costos y prepararse para el crecimiento como institucin.
Seguidamente se muestra una imagen donde se agrupan todos estos conceptos.
Figura 2-07: Mdulos de un Core Bancario, (MAIATECH, 2011)
El Core Bancario representa el corazn de la operacin de una IFIs, la decisin de
seleccionar una plataforma de ltima generacin, representa un reto importante en trminos
de flexibilidad, escalabilidad, funcionalidad e inversin, la cual debe estar totalmente
alineada a la estrategia de negocio y que asegure un soporte operativo a mediano y largo
plazo.
Una vez seleccionada la solucin bancaria a implantar, es necesario considerar el
acompaamiento metodolgico de una firma especializada, pues el Banco conoce de su
Ren Alvarez
negocio y el proveedor del core bancario seleccionado es experto en su solucin como tal,
por lo tanto, una firma que realice el aseguramiento de la calidad del proyecto y/o el
acompaamiento metodolgico de la implantacin, ser una de los factores que coadyuven
a garantizar el xito
Ren Alvarez
3. CAPTULO 3: METODOLOGA PARA IMPLANTAR UN CORE

BANCARIO
La metodologa que se plantea a continuacin inicia una vez que la solucin de Core
Bancario ha sido seleccionada y adquirida por la IFI, es decir, se han firmado los contratos
correspondientes que por lo general son dos: contrato de licencias y contrato de servicios
para la implantacin; el contrato de licencias normalmente contiene las condiciones de
soporte y mantenimiento.
3.1. Introduccin
El presente captulo expone la metodologa a ser utilizada en un proyecto de
implantacin de una solucin de core bancario en una IFI, esta metodologa es indistinta de
la solucin de core bancario a implantar, hace mucho nfasis en llevar a cabo procesos
participativos entre el personal de la IFI y del proveedor del Core Bancario.
La implantacin de una solucin de misin crtica amerita especial atencin por parte de
los altos ejecutivos de la IFI, por cuanto implica una importante inversin econmica y de
tiempo por parte del personal que la IFI debe destinar para el proyecto, es recomendable
que se asignen los mejores recursos humanos de la IFI al proyecto de implantacin del core
bancario, las funciones de estos recursos deben ser cubiertas por otro personal que la IFI
debe prever antes de iniciar el proyecto, al igual que la infraestructura tcnica y fsica en
donde se desarrollar el proyecto, entonces la inversin en el core bancario no implica
nicamente el valor referente al core bancario, sino tambin, el personal adicional,
infraestructura tcnica y fsica e inclusive algunas instituciones contratan un tercero, el
cual se encargar de la gobernabilidad y/o aseguramiento de la calidad del proyecto. Puede
Ren Alvarez
tambin contratarse una empresa experta en control de calidad de software para reforzar el
equipo de pruebas de la IFI.
A continuacin, se puede observar la metodologa de implantacin para un core
bancario, la cual tiene dos grandes procesos: la gestin del proyecto y la implantacin del
core bancario como tal, las dos de vital importancia para el xito del proyecto, la
metodologa de implantacin se basa en la definicin de etapas las mismas que son
ejecutadas en paralelo y / o en forma serial.
Figura 3-08: Metodologa de Implantacin de un Core Bancario, (BUPARTECH,
2005)
3.2. Gestin del Proyecto
3.2.1. Enfoque
La complejidad de un proyecto de implantacin de una solucin de core bancario, exige
que las IFIs cuenten con una adecuada administracin de estas complejas actividades. Las
estadsticas muestran que slo el 16% de los proyectos se entregan a tiempo y 53% de los
Ren Alvarez
proyectos culminan con retrasos, sobrepasados de presupuesto o con un alcance reducido,
debido principalmente a una inadecuada gestin del proyecto. Es recomendable utilizar una
metodologa de gestin de proyectos, preferiblemente basada en las mejores prcticas del
PMBOK del PMI; con esto en mente, se adaptan algunos de los puntos de dicha
metodologa por ser considerados de mayor relevancia para la gestin de un proyecto de
implantacin de un core bancario.
3.2.2. Metodologa de gestin de proyectos
La metodologa de gestin del proyecto est enfocada en orquestar las actividades de
cada uno de los grupos de procesos establecidos en el PMBOK del PMI, los cuales son:
Inicio, Planificacin, Ejecucin, Seguimiento y Control y Cierre del proyecto. Poniendo
especial nfasis en las reas del conocimiento consideradas las ms crticas para este tipo
de proyectos, como son: gestin del alcance, gestin de riesgos, gestin de la
comunicacin.
Figura 3-09: Gobernabilidad del Proyecto, (BUPARTECH, 2005)
Ren Alvarez
3.2.2.1.Inicio del Proyecto
Son todos aquellos procesos que se realizan para definir un nuevo proyecto o una nueva
fase de un proyecto ya existente, los mismos que buscan obtener autorizacin para iniciar
dicho proyecto o fase.
Los principales procesos a considerar en el Inicio del Proyecto son:
Elaboracin del acta de constitucin del proyecto: Documento mediante el cual se
asigna al gerente la responsabilidad de la ejecucin del proyecto, se establecen las
responsabilidades de los distintos miembros del equipo y se definen los lineamientos y
principales premisas sobre las cuales se va a realizar la ejecucin del proyecto.
Conformacin del equipo del proyecto: Esto incluye la asignacin del gerente del
proyecto y su equipo de trabajo, identificacin de necesidades de capacitacin.
Identificacin de los principales interesados y personas que con su autoridad pueden
influir positiva o negativamente en el proyecto.
Reunin de kick-off del proyecto: Reunin inicial del proyecto en la que se presenta la
organizacin del proyecto, los miembros del equipo de trabajo y cuyo principal
objetivo es lograr el compromiso y colaboracin por parte de los principales
interesados del proyecto.
3.2.2.1.1. Entregables de Inicio:
Acta de constitucin del proyecto
Reunin de kick-off.
Ren Alvarez
3.2.2.2.Planificacin
Dentro de la Planificacin del proyecto se desarrollan los procesos tendientes a
establecer claramente los objetivos, el alcance y el esfuerzo necesario para desarrollar el
proyecto, as como definir el plan de trabajo necesario para alcanzar esos objetivos. Las
principales actividades de la planificacin del proyecto son:
Definicin del alcance del proyecto.
Planificar la gestin del alcance.
Desarrollar el cronograma del proyecto.
Desarrollar el plan de recursos humanos.
Planificar la gestin de riesgos.
Planificar las comunicaciones.
3.2.2.2.1. Entregables de la Planificacin
Los principales entregables de la Planificacin son el plan integral del proyecto que
incluye el cronograma del proyecto, en donde se resumen los resultados de la fase de
Planificacin.
Apoyado en las mejores prcticas de gestin de proyectos (PMI), el proveedor del core
bancario en conjunto con la IFI elaborarn y mantendrn actualizado el plan integral de
proyecto, el cual debe estar conformado por los siguientes planes subsidiarios:
Plan de alcance
Plan de gestin de cambios
Plan de comunicacin
Plan de calidad
Ren Alvarez
Plan de recursos humanos
Plan de administracin de riesgos
Plan de adquisiciones
3.2.2.3.Ejecucin
Las actividades de Ejecucin del proyecto tienen por objetivo la asignacin de los
recursos para la realizacin del trabajo planificado. Estas actividades implican la
coordinacin de las personas y recursos para dar cumplimiento al plan integral de proyecto
establecido en la fase de Planificacin.
Los principales procesos de la Ejecucin son:
Dirigir y gestionar la ejecucin del proyecto.
Realizar el aseguramiento de calidad.
Desarrollar y dirigir el equipo del proyecto: Mejorar las competencias y el ambiente de
trabajo para lograr un mejor desempeo del equipo. Monitorear el desempeo del
equipo, resolver problemas que se pueden presentar al interior del equipo.
3.2.2.3.1. Entregables de Ejecucin
Los entregables de la Ejecucin son los productos generados como resultado de la
realizacin de las tareas asignadas al equipo de trabajo, adems de las actas de reuniones
realizadas, especialmente cuando en stas se hayan tomado decisiones importantes para el
proyecto. Es una tarea de especial atencin por parte del gerente de proyecto, la generacin
de los entregables de la Ejecucin y la gestin para la aprobacin de dichos entregables.
Ren Alvarez
La aprobacin de los entregables de Ejecucin se formaliza mediante la firma de
aceptacin por parte de la IFI, esta firma de aprobacin puede realizarse de las siguientes
formas:
Mediante firma en el documento: Cuando se trata de un documento individual o
cuando el volumen de documentos a aprobar es pequeo, se consigna la firma
directamente en el documento.
Mediante la firma de un acta de aceptacin: Cuando el nmero de documentos a
aprobar es alto o los entregables generados no son necesariamente documentos (por
ejemplo, en el caso de entrega de programas), se genera y firma un acta de
aceptacin en la que se detallan todos y cada uno de los documentos y entregables
aprobados.
El uso de una u otra alternativa de aprobacin de documentos debe ser consensuado y
aprobado previamente con la IFI.
3.2.2.4.Seguimiento y Control
El Seguimiento es un aspecto de la direccin del proyecto que se realiza de forma
iterativa a lo largo de todo el proyecto. Consiste en recopilar, medir y distribuir la
informacin relativa al desempeo, evaluar las mediciones y tendencias que permitirn
efectuar mejoras en el desarrollo del proyecto; monitorear e identificar riesgos. El
seguimiento continuo proporciona al equipo de direccin del proyecto conocimientos sobre
la salud del proyecto y permite identificar las reas susceptibles de requerir una atencin
especial.
El Control consiste en determinar acciones preventivas o correctivas o en modificar los
planes de accin y hacer un seguimiento de los mismos a fin de determinar si las acciones
Ren Alvarez
emprendidas permitieron resolver los problemas de desempeo presentados, caso contrario
definir nuevas estrategias.
Las principales actividades de Seguimiento y Control del proyecto son:
Comparar el desempeo real del proyecto con respecto a la lnea base establecida.
Evaluar el desempeo para determinar la necesidad de acciones preventivas o
correctivas.
Identificar riesgos y monitorear los riesgos existentes.
Proporcionar la informacin necesaria para sustentar el informe de seguimiento, la
medicin del avance y las proyecciones.
Proporcionar proyecciones que permitan actualizar la informacin relativa al costo y
cronograma actuales.
Monitorear la implementacin de los cambios aprobados.
Generar issues cuando la situacin lo amerite.
El Seguimiento y Control del proyecto se lo realiza a travs de la elaboracin y entrega
de informes de avance del proyecto y de la realizacin de reuniones peridicas de
seguimiento (se sugiere al menos periodicidad quincenal).
El Seguimiento y Control del proyecto es responsabilidad de los siguientes roles e
instancias del Proveedor del core bancario y de la IFI.
Gerente de proyecto de Proveedor del core bancario: Es el principal responsable
designado por el Proveedor del core bancario para dirigir todas y cada una de las fases del
proyecto: Inicio, Planificacin, Ejecucin, Control y Seguimiento y Cierre del proyecto.
Ren Alvarez
Siendo una de sus principales responsabilidades realizar el Seguimiento y Control para
garantizar la calidad de los entregables a lo largo de todo el proyecto.
Comit de Seguimiento de Proyectos (interno del Proveedor del core bancario):
Este Comit debera estar conformado como mnimo (pero no restringido a): Responsable
de operaciones, el responsable de los proyectos de TI, responsable de producto y el gerente
de proyecto asignado a la IFI. Se encargar de dar seguimiento quincenal a los proyectos
en marcha para garantizar la calidad del proyecto, validando el cumplimiento de las
metodologas establecidas, identificar riesgos. Para lograr este seguimiento el Comit se
reunir con todos y cada uno de los gerentes de proyecto, revisar el informe de avance y
los indicadores del proyecto y definir acciones correctivas y preventivas en los principales
aspectos de gestin del proyecto:
Gestin del alcance.
Gestin del cronograma.
Gestin de la calidad.
Gestin de riesgos.
Cualquier otro aspecto adicional que se considere necesario.
Comit de Gerencia de Proyecto: Definido en la seccin 3.2.2.5.1 de este documento.
Comit Director: Definido en la seccin 3.2.2.5.2 de este documento.
3.2.2.4.1. Entregables de Seguimiento y Control
3.2.2.4.1.1.Informe de avance del proyecto
El informe de avance contiene como mnimo (pero no se limita a) la siguiente
informacin:
Ren Alvarez
Resumen del proyecto, principales indicadores de avance.
Tareas en curso.
Anlisis de problemas presentados.
Entregables generados.
Anlisis de riesgos.
Seguimiento de compromisos y acuerdos establecidos.
Anlisis de avance del cronograma.
Conclusiones.
Controles de cambio.
El informe de avance debe ser elaborado quincenalmente por el gerente de proyecto del
Proveedor del core bancario y sirve como insumo para realizar el seguimiento en los
distintos comits mencionados ms anteriormente.
3.2.2.4.1.2.Reuniones de seguimiento
En las reuniones de seguimiento el gerente de proyecto presentar el informe de avance
al respectivo comit de acuerdo al tipo de reunin: Comit de Gerencia, Comit Director y
los dems que se definan con la IFI.
En estas reuniones se tomarn las decisiones y acciones necesarias para corregir
posibles desviaciones y garantizar el mejor desempeo del proyecto, estas acciones pueden
ser:
Modificacin de fechas de cumplimiento de acuerdos y compromisos.
Generacin de nuevos acuerdos y compromisos.
Definicin de acciones correctivas para tareas con retraso.
Ren Alvarez
Definicin de acciones preventivas para riesgos identificados
Inclusin de nuevos riesgos en la matriz de riesgos del proyecto.
Generacin de documentos de solicitudes de cambios.
Aprobacin o rechazo de solicitudes de cambio.
El entregable de cada reunin ser el acta de reunin.
3.2.2.5.Gestin de la comunicacin
La gestin de las comunicaciones del proyecto incluye las actividades requeridas para
garantizar que la generacin, recopilacin y distribucin de la informacin del proyecto
sean adecuadas y oportunas. Una comunicacin eficaz crea un puente entre los diferentes
interesados involucrados en el proyecto, lo que permite mantener una visin comn de los
objetivos y de la salud del proyecto a todo nivel y a lo largo de todo el proyecto.
Las principales actividades de la gestin de la comunicacin del proyecto son:
Identificar los interesados y sus necesidades de comunicacin.
Definir la estrategia de comunicacin tanto para interesados externos como
internos.
Definicin de la matriz de comunicacin en la que se detalla la informacin a ser
comunicada, los interesados responsables de generar y recibir la comunicacin y la
periodicidad de la misma (Herranz de la Casa, 2012).
Como parte de la metodologa de trabajo del proveedor del core bancario se recomienda
agrupar a los principales patrocinadores del proyecto en los siguientes comits para
facilitar la comunicacin:
Comit de Gerencia del Proyecto
Ren Alvarez
Objetivo: Reportar y controlar el avance del proyecto, gestionar riesgos y eventos
crticos, escalar al Comit Director.
Participantes: Gerente de proyecto del Proveedor del core bancario, Gerente de
proyecto designado por la ms alta autoridad de la IFI, gerentes de proyectos de los
diferentes frentes de trabajo, en definitiva, corresponde a la Direccin General del proyecto
por parte de la IFI.
Frecuencia de reunin: Quincenal, a travs de las reuniones de seguimiento, no ms de
dos horas por reunin.
3.2.2.5.1. Comit Director:
Objetivo: Revisin del avance del proyecto, apoyo en la resolucin en temas escalados
por los comits internos y de proyecto, ltima instancia en la toma de decisiones.
Participantes: Gerentes de Proyecto del Proveedor del core bancario y de la IFI,
Gerencia General y staff de la IFI (VPs de operaciones, comercial, mercadeo,
administracin, finanzas, legal, sucursales, canales electrnicos, entre otros).
Frecuencia de reunin: Mensual, a travs de presentacin del estado del proyecto y
necesidades de definicin o toda de decisiones.
3.2.2.5.2. Entregables de Gestin de la Comunicacin
Matriz de roles y responsabilidades (parte del plan integral del proyecto).
Matriz de comunicacin (parte del plan integral del proyecto).
Comunicaciones generadas a lo largo del proyecto siguiendo los lineamientos de la
matriz de comunicacin.
Ren Alvarez
3.2.2.6.Gestin del alcance
La Gestin de Alcance incluye los procesos requeridos para asegurar que el proyecto de
implantacin del core bancario incluya el trabajo necesario, para su ejecucin exitosa. Es
importante definir y controlar lo que se incluye y lo que no se incluye en el proyecto.
Los principales procesos de Gestin de Alcance dentro del ciclo de vida del proyecto se
muestran en la siguiente figura:
Figura 3-10: Procesos de Gestin del Alcance del Proyecto, (Coron, 2013)
Es importante que el equipo de trabajo del Proveedor del core bancario tenga presente,
que no pueden realizar acuerdos extra contractuales con el personal de la IFI, todo acuerdo
al que se llegue debe siempre estar formalizado y previamente aprobado por el gerente de
proyecto del Proveedor del core bancario, el mismo que, previo a dicha aprobacin, deber
analizar si dichos acuerdos tienen o no implicaciones legales, en caso de dudas, deber
pedir asesoramiento al departamento legal de la empresa.
Ren Alvarez
En la etapa de Iniciacin se hace una primera definicin de alto nivel del alcance del
proyecto y su definicin detallada se hace en la etapa de Planificacin y en la etapa de
Anlisis de Brechas o comnmente conocida como Definicin Detallada de
Requerimientos o Gap Anlisis o Levantamiento Detallado de Requerimientos o
Confirmacin de Requerimientos. Las etapas de Planificacin y Definicin del alcance se
encuentran detalladas ms adelante en este documento, siendo las mismas de vital
importancia para el xito del proyecto.
3.2.2.6.1. Verificacin del Alcance
La Verificacin del Alcance consiste en formalizar la aceptacin de los entregables del
proyecto, para lo cual se deben seguir los procedimientos descritos en el contrato firmado
con la IFI, el cual debe incluir:
Notificacin por escrito por parte de la Proveedor del Core Bancario a la IFI de la
entrega de los productos y solicitud de recepcin.
Plazo para la recepcin por parte de la IFI (generalmente quince das laborables)
despus de recibida la comunicacin. Dentro de ese trmino la IFI podr negarse a
realizar la recepcin, sealando correctamente las razones que tuviese para su
negativa.
Recepcin presunta: Si la IFI no formulare ningn pronunciamiento ni iniciase la
recepcin dentro del trmino sealado, se considera que tal recepcin se ha
efectuado.
Observaciones a los productos y servicios entregados: La IFI realizar una
verificacin e inspeccin de los productos entregados. Si el resultado de la
Ren Alvarez
inspeccin es positivo de suscribir el acta de entrega recepcin correspondiente
(Valdez, 2014).
Este procedimiento se seguir tanto para los entregables parciales, como para la entrega
final del producto.
3.2.2.6.2. Control del Alcance
El control del alcance permite monitorear el estado del alcance del proyecto y del
producto y gestionar los cambios en la lnea base del alcance. El control del alcance del
proyecto asegura que todos los cambios solicitados o las acciones preventivas o correctivas
recomendadas se canalicen a travs del proceso de control de cambios. Debido a que los
cambios son inevitables, el control del alcance tambin es til para gestionar los cambios
reales cuando stos suceden (Project Management Institute, Inc, 2011).
El control del alcance se realizar a travs de las reuniones de seguimiento del proyecto
de Comit de Gerencia; en estas reuniones se analizarn los indicadores de desempeo del
proyecto respecto de la lnea base, si se encontraran desviaciones, ser necesario identificar
las causas y las posibles acciones correctivas, previo a ejecutar el proceso de control de
cambios el cual especifica que todo cambio debe ser documentado, evaluado y aprobado
por las instancias correspondientes del proyecto antes de ser ejecutado.
El detalle del proceso de control de cambios se especifica a continuacin.
3.2.2.6.3. Control de cambios
El proceso de Control de Cambios proporciona un esquema ordenado para administrar
las modificaciones sobre la lnea base del proyecto, a nivel de:
Alcance
Ren Alvarez
Cronograma (tiempo)
Costos
Cualquier modificacin que impacte sobre una de estas tres variables fundamentales del
proyecto debe ser documentada, analizada y aprobada antes de ser incluida en los planes de
trabajo para su posterior ejecucin. En la siguiente figura se muestra el proceso de Control
de Cambios.
Figura 3-11: Procesos de Control de Cambios, (Fleitas, 2015)
3.2.2.6.3.1.Identificar Cambios
La identificacin de cambios es una actividad que la realizan todos los involucrados en
el proyecto, ya que cualquier miembro del equipo o patrocinador del proyecto puede
detectar y/o solicitar la introduccin de un cambio en el mismo.
Los cambios pueden ser generados por factores externos al proyecto, por ejemplo:
cambios en regulaciones emitidas por entes de control, nuevas orientaciones en la poltica
de la Institucin, etc.; as como tambin por factores internos al proyecto como pueden ser
Ren Alvarez
retrasos por actividades bloqueadas, nuevas definiciones en los requerimientos o en las
soluciones propuestas para los mismos.
Una vez identificado el cambio, ste debe ser documentado por el Gerente de Proyecto
del Proveedor del core bancario.
3.2.2.6.3.2.Formalizar Cambios
Una vez identificados los cambios estos deben ser formalizados, es decir, deben ser
documentados por escrito de una manera clara y precisa indicando los motivos del cambio
y su importancia para el proyecto, para lo cual se utilizar el formato de control de cambio
establecido en la metodologa.
Es probable que durante las reuniones de seguimiento del proyecto se detecten posibles
cambios, en este caso quedar registrada en los compromisos del acta de la reunin la
solicitud de documentacin del cambio.
3.2.2.6.3.3.Anlisis de Impacto y Costos
Una vez que el documento de solicitud de cambio est listo, debe ser enviado al Gerente
de Proyecto del Proveedor del core bancario quien es el responsable (junto con su equipo
de trabajo) de realizar el anlisis de impacto en trminos de alcance, tiempo y costo.
Este anlisis implica la revisin de la factibilidad de realizar el cambio tomando en
cuenta la carga de trabajo que representa aplicar el cambio, el impacto en requerimientos
ya realizados, aspectos de rendimiento de la solucin, entre otros y si este representa un
costo o tiempo adicional.
Ren Alvarez
Este anlisis se debe llevar a la siguiente reunin de seguimiento y su importancia
radica en que permitir al Comit de Gerencia tener elementos para realizar un anlisis
costo/beneficio de la realizacin del cambio.
3.2.2.6.3.4.Aprobar Cambios
El Comit de Gerencia del proyecto a travs de las reuniones de seguimiento
respectivas, ser el encargado de aprobar los cambios, para lo cual realizar un anlisis
costo/beneficio con base a la informacin entregada por el Proveedor del core bancario.
La aprobacin de cambios que impliquen modificaciones en la lnea base del proyecto
que afecten directamente al tiempo de entrega o a los costos contractuales deber ser
escalada al Comit Director para su respectiva aprobacin.
Los cambios aprobados se enviarn al Gerente de Proyecto del Proveedor del core
bancario y de la IFI, para su correspondiente planificacin y ejecucin.
3.2.2.6.3.5.Planificar y Ejecutar el Cambio
El Gerente de Proyecto del Proveedor del Core Bancario ser el encargado de planificar,
asignar recursos y dar seguimiento a la ejecucin de los cambios aprobados, as como de
actualizar el cronograma, enunciado del alcance del proyecto y cualquier otro documento
de la lnea de base del proyecto que se haya visto modificado con la introduccin del
cambio.
Una vez registrado el cambio en el cronograma el monitoreo de la ejecucin se realizar
en el proceso normal de seguimiento del proyecto.
Ren Alvarez
Todo cambio que implique modificacin al plazo contractual y /o costo del proyecto,
ser recomendable que se firme un contrato modificatorio o adenda, que formalice dichos
acuerdos.
3.2.2.6.3.6. Entregables del Control de Cambio
Oficio de Control de Cambios.
Documento de definicin de control de cambios.
Acta de aprobacin de control de cambios.
Adenda o contrato modificatorio
3.2.2.7.Gestin de riesgos
La gestin de riesgos que establezca el Proveedor del Core Bancario dentro de sus
proyectos contemplar al menos:
Figura 3-12: Etapas de la Gestin de Riesgos, (LLarda, 2013)
Ren Alvarez
Identificar: Peridicamente buscar y localizar riesgos antes de que se conviertan
en problemas.
Transformar: Transformar datos de los riesgos en informacin para la toma de
decisiones. Evaluar impacto, probabilidad y tiempo, clasificar riesgos y priorizar
riesgos.
Planificar: Traducir informacin de riesgos en decisiones y acciones (presentes y
futuras) e implementar las acciones.
Hacer Seguimiento: Monitorear los indicadores de riesgos y las acciones de
mitigacin
Controlar: Si existe una accin de mitigacin, se actualiza los planes de trabajo
para tener en cuenta el tiempo imprevisto y los recursos dedicados a la reduccin y
eliminacin.
Comunicar: Proveer informacin continua y feedback interno o externo al
proyecto sobre los riesgos (Galvz, 2011).
La administracin de riesgos comprende los procesos de:
Planificar la gestin de riesgos: Definir como realizar las actividades de gestin de
riesgos para el proyecto.
Identificar los riesgos: Determinar los riesgos que puedan afectar al proyecto y
documentar sus caractersticas.
Realizar el anlisis cualitativo: Priorizar los riesgos evaluando y combinando la
probabilidad de ocurrencia y el impacto de los mismos.
Realizar el anlisis cuantitativo: Analizar numricamente el efecto de los riesgos
identificados sobre los objetivos generales del proyecto.
Ren Alvarez
Planificar la respuesta a los riesgos: Desarrollar opciones y acciones para mejorar
las oportunidades y reducir las amenazas a los objetivos del proyecto.
Monitorear y controlar: Implementar planes de respuesta de riesgos, monitorear
riesgos identificados, identificar nuevos riesgos y evaluar la efectividad del proceso
de gestin de riesgos. (Project Management Institute, Inc, 2011).
3.2.2.7.1. Matriz de probabilidad-impacto
Para definir el nivel de riesgo se utilizar un anlisis cualitativo a travs de la matriz de
probabilidad-impacto, en base a los siguientes parmetros:
Probabilidad Impacto
Valor Descripcin Valor Descripcin
1 Baja 1 Baja
2 Media 2 Media
3 Alta 3 Alta
Tabla 1. Anlisis cuantitativo
Al combinar los valores de probabilidad e impacto se obtienen la siguiente matriz:
Impacto
Probabilidad
1 2 3
1 1 2 3
2 2 4 6
3 3 6 9
Tabla 2. Matriz de valores de probabilidad e impacto
Ren Alvarez
La cual se puede resumir de forma grfica de la siguiente manera:
Probabilidad Impacto Nivel de riesgo
1 - Baja 1 - Bajo 1
1 - Baja 2 - Medio 2
1 - Baja 3 - Alto 3
2 - Media 1 - Bajo 2
2 - Media 2 - Medio 4
2 - Media 3 - Alto 6
3 - Alta 1 - Bajo 3
3 - Alta 2 - Medio 6
3 - Alta 3 - Alto 9
Tabla 3. Probabilidad x impacto en forma grfica
Nomenclatura:
Riesgo de nivel alto: Requieren establecer acciones preventivas y correctivas,
seguimiento continuo y estrategias de respuesta adecuadas. (Se recomienda reuniones
diarias de seguimiento).
Riesgo de nivel medio: Aunque son menor prioridad que los anteriores, requieren
establecer acciones preventivas y correctivas, seguimiento continuo y estrategias de
respuesta adecuadas. (Se recomienda reuniones de seguimiento semanal).
Ren Alvarez
Riesgo de nivel bajo: Pueden no necesitar una accin de gestin proactiva aunque
es importante llevar un registro de los mismos y monitorear posibles cambios de
probabilidad o impacto.
3.2.2.7.2. Identificacin y Registro, Monitoreo y Control de los Riesgos
La identificacin y registro, y el monitoreo y control de riesgos se realizan utilizando el
formulario de seguimiento de riesgos (FOR-DES-SDR-075), en el cual se establecen las
acciones preventivas y correctivas ante la posibilidad de ocurrencia del riesgo. Este
formulario debe ser llenado por el gerente de proyecto en el momento de la identificacin
del riesgo y actualizado antes de cada una de las reuniones de seguimiento de Comit de
Gerencia.
El estatus actual del riesgo se analiza en la respectiva reunin de seguimiento del
proyecto en la que se toman decisiones respecto a:
Incluir nuevas acciones preventivas o correctivas.
Cerrar acciones preventivas o correctivas.
Modificar el nivel de probabilidad, impacto y exposicin del riesgo.
Escalar a Comit Director.
3.2.2.8.Gestin del cronograma
La Gestin del Cronograma es vital para el xito del proyecto y es responsabilidad del
Gerente de Proyecto del Proveedor del core bancario, quien es el encargado de realizar la
planificacin del proyecto y dar seguimiento semanal a la ejecucin de dicha planificacin,
as como de levantar los riesgos, problemas y alertas referentes a la ejecucin del
cronograma y reportarlos como parte del informe de avance del proyecto.
Ren Alvarez
En las distintas instancias de las reuniones de seguimiento, se realiza la revisin del
avance del cronograma en funcin de la informacin entregada por el Gerente de Proyecto
del Proveedor del core bancario y de la IFI, en donde se definen las acciones correctivas y
preventivas necesarias, as como la necesidad de introducir controles de cambio (de ser el
caso), escalar los problemas a instancias superiores o gestionar la modificacin de los
plazos de ejecucin del proyecto.
3.2.2.9.Gestin de la calidad
El Gerente de Proyecto del Proveedor del core bancario es el principal responsable de la
gestin de calidad del proyecto. Para esto, como parte de la planificacin del proyecto,
debe definir los mecanismos a seguir para garantizar la calidad de los entregables del
proyecto, estos mecanismos pueden ser (pero no se limitan a):
Definicin de estndares para la documentacin y para los dems productos
generados en el proyecto.
Inspecciones de la documentacin generada.
Ejecucin de pruebas de control de calidad de los productos generados (control de
calidad del software).
La gestin de la calidad del proyecto se hace a travs de las reuniones se seguimiento
respectivas. Como parte del informe de seguimiento, el gerente de proyecto debe presentar
las mtricas de calidad obtenidas. En el caso de presentarse problemas en la calidad de los
productos generados, es necesario realizar un anlisis de la causa raz de estos problemas,
el cual es responsabilidad del Gerente de Proyecto del Proveedor del core bancario y debe
ser presentado y revisado en la reunin del Comit de Seguimiento de Proyectos del
Proveedor del core bancario, donde se deben definir las acciones correctivas necesarias
Ren Alvarez
para solventar estos problemas. Es importante que se haga una adecuada gestin de estos
problemas de calidad antes de que los productos sean entregados a la IFI de manera que se
minimice el nmero de incidencias de calidad reportadas por la IFI.
Para el control de calidad se establecen los siguientes indicadores:
Nmero de incidencias / nmero de requerimientos.
Nmero de incidencias por tipo (DFR, DTR, Programacin, Documentacin).
3.2.2.10. Cierre del Proyecto
A travs de los procesos de Cierre se formaliza la culminacin administrativa y
contractual del proyecto o de una fase del mismo. Las principales actividades para el
Cierre del Proyecto son:
Elaboracin y firma del acta de aceptacin del producto y/o servicio.
Generacin de las facturas correspondientes segn la fase del proyecto culminada.
Gestin para el levantamiento de garantas asociadas.
Firma de acuerdos de garanta tcnica y contratos de soporte/mantenimiento.
Firma del certificado de ejecucin del proyecto por parte del IFI.
Ejecucin de reunin de lecciones aprendidas, generacin de documento de lecciones
aprendidas.
Completar encuestas de satisfaccin por parte de la IFI.
Actualizacin de la carpeta electrnica de la documentacin del proyecto (subir o
completar la informacin en el gestor documental correspondiente, como por ejemplo:
Share-Point, Alfresco).
Ren Alvarez
Actualizacin de la carpeta fsica de la documentacin del proyecto la cual debe ser
entregada al rea de operaciones del proveedor del core bancario, para su archivo y
custodia correspondiente.
3.2.2.10.1. Entregables de Cierre del Proyecto
Acta de aceptacin y cierre del proyecto
Lecciones aprendidas
Certificado de ejecucin del proyecto firmado por el IFI.
Encuesta de satisfaccin de la IFI.
Carpeta fsica y electrnica del proyecto actualizada.
3.2.2.11. Lineamientos generales durante la vida del proyecto
Para una buena gestin del proyecto, es importante que todo el personal del Proveedor
del Core Bancario tenga presente los siguientes lineamientos generales durante toda la vida
del proyecto:
Mantener actualizada la carpeta fsica y electrnica del proyecto.
Seguimiento y control semanal del time-report de todos los recursos del proyecto.
Mantener siempre una relacin cordial, atenta y respetuosa con el personal de la IFI,
cuidando siempre los intereses de la IFI.
Ser formal en todas las acciones relacionadas con el proyecto (puntualidad en
reuniones, puntualidad en la entrada al trabajo, cumplir lo que se ofrece, vestimenta
apropiada).
No hacer acuerdos informales o extracontractuales con la IFI.
Tener siempre en mente los compromisos contractuales y manejarlos formalmente.
Buscar superar las expectativas de la IFI.

Ren Alvarez
3.2.2.12. Formularios para la gestin de proyectos
A continuacin, se detallan en una matriz, los principales formularios o plantillas a ser
utilizadas en la fase de Gestin de Proyectos:
Etapa Documento Nombre Descripcin

Documento interno de la
planificacin inicial del
Acta de constitucin del
Inicio FOR-DES-PCH-011 proyecto, compromisos
proyecto
contractuales y personal
asignado.
Documento de planificacin
FOR-DES-PPR-012 Plan de proyecto del proyecto para entrega a
Planificacin la IFI.
FOR-DES-CRO-013 Cronograma del proyecto Cronograma de proyecto.
Detalle de la ejecucin del
Ejecucin FOR-DES-ADR-015 Acta de reunin
proyecto.
Documento que indica el
FOR-DES-IAV-014 Informe de avance
Seguimiento y status del proyecto
Control Compromisos de cada
FOR-DES-ADR-015 Acta de reunin
reunin
Documento de planificacin
Gestin de la
FOR-DES-PPR-012 Plan de proyecto del proyecto para entrega al
comunicacin
IFI.
Documento que indica el
Gestin de alcance FOR-DES-IAV-014 Informe de avance
status del proyecto.
Oficio Controles de Solicitud de cambios al
FOR-DES-OCC-017
cambio proyecto.
Control de Documento de Definicin Detalle de los cambios
FOR-DES-CCA-065
cambios de Control de Cambios solicitados al proyecto.
Acta de aprobacin de Aceptacin de los cambios
FOR-DES-ACC-066
control de cambios solicitados al proyecto.
Informe de avance del Documento que indica el
FOR-DES-IAV-014
proyecto estatus del proyecto.
Documento en el que se
Gestin de riesgos describe las acciones,
FOR-DES-SDR-075 Seguimiento de Riesgos responsables y fechas de
cumplimiento para gestionar
los riesgos.
Documento que registra la
Acta de Aceptacin y finalizacin del proyecto y
FOR-DES-AAP-018
Cierre del Proyecto la entrega del Producto o
Servicio
Detalle de todas las
Cierre del
FOR-DES-LAP-019 Lecciones aprendidas variancias que se generan en
proyecto
los proyectos.
Documento en el que se
Encuesta de Satisfaccin a solicitan elementos para
FOR-DES-ESC-020
ser completada por la IFI validar la satisfaccin de la
IFI.
Tabla 4. Formularios para la gestin de proyectos
Ren Alvarez
3.3. Implantacin de Core Bancario
3.3.1. Anlisis Preliminar
Llegar a esta etapa implica que la IFI se encuentra realizando un proceso de seleccin
de core bancario, para lo cual previamente defini en su plan estratgico la necesidad del
cambio de core bancario, debi tambin levantar sus procesos y haber definido claramente
sus productos y servicios bancarios actuales y futuros, habiendo generado una matriz de
requerimientos funcionales y tcnicos que la solucin de core bancario seleccionada deber
cumplir, en definitiva, levant sus necesidades, las cuales se las entreg a los proveedores
de core bancario para que realicen sus respectivas propuestas tcnicas y econmicas, una
vez recibidas dichas propuestas, en un proceso de evaluacin selecciona la solucin que
mejor se apegue a sus necesidades funcionales, operativas, tcnicas y presupuestarias.
Para poder elaborar la propuesta tcnica y econmica solicitada por la IFI, es necesario
realizar esta etapa de Anlisis Preliminar, es decir, revisar detenidamente el RFP 7(Request
For Proposal) solicitado por la IFI y completar el anlisis con sesiones de entendimiento a
realizarse entre la IFI y el proveedor del core bancario, podramos llamarlo como el primer
levantamiento de las necesidades de la IFI, la cual tiene como objetivo, obtener una visin
de alto nivel de dichas necesidades y los productos y servicios requeridos por la IFI, lo que
permitir realizar la planificacin inicial del proyecto (1ra. Estimacin) y de esta forma
presentar la oferta respectiva. Las actividades principales a ejecutarse en esta etapa son:
Revisar la informacin entregada por la IFI.
7
RFP: Requerimiento de propuesta tcnica y econmica o en ingls, Request For Propousal
Ren Alvarez
Entendimiento de las necesidades de la IFI.
Anlisis macro de los procesos involucrados.
Definicin de la situacin esperada por la IFI con la realizacin del proyecto.
Preparar oferta tcnica y econmica usando la 1ra. Estimacin.
Estas actividades se realizan a travs de una serie de reuniones con los principales
interesados en el proyecto designados por la IFI, para lo cual se requiere que se genere una
agenda de reuniones que permita realizar un trabajo planificado durante esta etapa.
Como resultado del anlisis preliminar se tiene una visin general de los requerimientos
de la IFI, lo cual permite hacer un primer desglose del trabajo a realizar y una primera
estimacin del esfuerzo y recursos requeridos para realizar este trabajo.
En esta etapa se elabora los documentos que permiten definir los lineamientos generales
para abordar el proyecto, el alcance de los productos o servicios esperados con el proyecto
y la primera estimacin del trabajo a realizar, todo esto queda plasmado en la propuesta
tcnica y econmica a ser entregada a la IFI.
Como resultado de esta etapa se obtiene la Propuesta Tcnica y Econmica a ser
presentada a la IFI para la implantacin del Core Bancario, la misma que incluye:
Un resumen ejecutivo
Objetivo de la solucin propuesta
Alcance de la solucin propuesta
Arquitectura de la solucin propuesta
Metodologa de implantacin del core bancario
Plan de preliminar de Proyecto (Project Plan), que permite delinear el marco para la
ejecucin del proyecto propuesto.

Ren Alvarez
Cronograma de alto nivel del proyecto "Primera Estimacin": Detalle de tareas con fechas de
ejecucin de todas las fases del proyecto.
Recursos propuestos para el proyecto
Esquema de gobernabilidad del proyecto
Premisas o supuestos sobre los que se asienta la propuesta
Responsabilidades de la IFI
Responsabilidades del proveedor del core bancario
Inversin econmica
Informacin del proveedor del core bancario: quines somos, productos y servicios,
casos xito, clientes, participacin en el mercado, certificaciones, premios, entre otros.
3.3.1.1.Principales Formularios de la Fase de Anlisis Preliminar
Documento Nombre Descripcin Formato de Nombre Sugerido

FOR-DES-AGR-022 Agenda de Calendario de Agenda_[Siglas de la IFI]_[Siglas del
reuniones reuniones a realizarse Proyecto]_[Fecha Formato
en el Anlisis aaaammdd]_[Breve Descripcin de la
Preliminar. Agenda]
Ejemplo:
Agenda_SBS_INT_20130925_Agenda
deReuniones
FOR-DES-PPR-012 Plan de Documento de ProjectPlan_[Siglas del IFI]_[Siglas
Proyecto planificacin del del Proyecto]_[Fecha Formato
proyecto para entrega aaaaddmm].
al IFI. Ejemplo:
ProjectCharter_SBS_INT_20132509
FOR-DES-CRO-013 Cronograma Cronograma Primera [Siglas del
del proyecto Estimacin Proyecto]_Cronograma_[Estimacion]_
[Fecha Formato
ddMesAo]_[Versin].
INT_Cronograma_3raEstimacion_28O
ct2013_v1
Tabla 5. Formularios de la Fase de Anlisis Preliminar
Ren Alvarez
3.3.2. Anlisis de Requerimientos
En el siguiente diagrama se muestra un esquema general de las actividades que se
contemplan dentro de la fase de anlisis de requerimientos o gap analisys o anlisis de
brechas o confirmacin de requerimientos.
Figura 3-13: Etapa de Anlisis de Brechas, (BUPARTECH, 2006)
3.3.2.1.Preparacin del proceso de anlisis de requerimientos
El proceso de anlisis de requerimientos es el proceso en el cual se determina las
necesidades de la IFI para ser plasmadas en la solucin ofrecida por el Proveedor del Core
Bancario. Es de todas las fases de la implantacin, la ms importante, es en donde se
definen loa planos de la casa a construir. Es de vital importancia que los principales
interesados en el proyecto, delegados por la IFI, participen activamente durante este
proceso y especifiquen detallada y correctamente la funcionalidad necesaria para asegurar
y optimizar su operatividad.
Es recomendable que los mejores usuarios, con suficiente poder de decisin sean
asignados a esta fase.
Ren Alvarez
Para la preparacin del proceso de anlisis de requerimientos se consideran las
siguientes etapas:
3.3.2.1.1. Recopilacin de informacin para el anlisis de requerimientos
Revisin de los Requerimientos.
Recopilacin de documentacin de procesos existentes.
Recopilacin y anlisis de las regulaciones vigentes relacionadas con los procesos
de negocio a implementar.
Recopilacin y anlisis de los reportes operativos, de control y para la toma de
decisiones que actualmente se emiten.
Revisin del sistema actual y estructuras de datos relacionados con este proyecto.
Revisin de proyectos o desarrollos en curso sobre el sistema actual.
3.3.2.1.2. Definicin de procesos y requerimientos por mdulo
Definicin de alto nivel de los procesos a implementar, incluyendo las mejoras u
optimizaciones que se pretende alcanzar con el nuevo sistema.
Revisin de los productos y servicios actuales y futuros.
Definicin de los objetivos de negocio por mdulo.
3.3.2.2.Ejecucin del proceso de anlisis de requerimientos
Para la ejecucin del proceso de anlisis de brechas se consideran las siguientes etapas y
sus respectivas actividades:
3.3.2.2.1. Anlisis de requerimientos
Instalacin de la versin base del core bancario contratado.
Ren Alvarez
Revisin detallada de la funcionalidad y procesos ofrecidos por el core bancario
contratado, es importante que la IFI trate de adoptar y no adaptar la solucin de core
bancario, puesto que dicha solucin ya trae las mejoras prcticas de negocio.
Documentacin detallada de los requerimientos de usuario, tanto funcionales como no
funcionales.
Valoracin de alternativas. Se deber establecer cules son los costos y los beneficios
de las alternativas de solucin frente a los requerimientos de los usuarios.
Elaborar propuesta de solucin.
3.3.2.2.2. Negociacin de gaps o requerimientos
La negociacin de gaps o requerimientos tiene por objetivo que el Proveedor del Core
Bancario ajuste el esfuerzo necesario para la implantacin del core al presupuesto realizado
en la primera estimacin con la cual se realiz el contrato. Es decir, varios gaps o
requerimientos sern atendidos por este proyecto y varios gaps o requerimientos quedarn
fuera del alcance de este proyecto.
Es recomendable que la IFI cuando elabora su presupuesto de proyecto de cambio de
core bancario, presupueste un valor de ajuste que le permita sortear este tipo de situaciones
ahora o en el futuro.
Anlisis y revisin de propuestas de solucin a cada gap.
Frente a cada requerimiento, se establecer la opcin que brinde una mejor relacin
costo-beneficio.
Negociacin y aprobacin de la solucin para cada requerimiento por parte del Equipo
Directivo de la IFI.
Ren Alvarez
Elaboracin y firma del Documento Final de Requerimientos (DFR), el cual contiene
tambin el cronograma de trabajo con la segunda estimacin para la personalizacin
de las soluciones.
3.3.2.3.Entregables del anlisis de brecha
Inventario de gaps levantados priorizando los que sern atendidos por el proyecto
de implementacin y los que no sern parte del alcance de este proyecto.
Especificaciones Funcionales de Requerimiento (DFR)
Revisiones de Diseo Funcional
Cronograma Segunda estimacin
3.3.2.4.Formularios del Anlisis de Brechas

FOR-DES-DFR-023 DFR_Gener Documento DFR-[IFI]-[Mdulo]-[Submdulo]-
acin de Funcional de [Secuencial]
Archivos Requerimientos de DFR-SBS-SEO-MAN-001
generacin de
archivos.
FOR-DES-DFR-024 DFR_Proces Documento DFR-[IFI]-[Mdulo]-[Submdulo]-
os Batch Funcional de [Secuencial]
Requerimientos para DFR-SBS-SEO-MAN-001
procesos batch.
FOR-DES-DFR-025 DFR_Pantall Documento DFR-[IFI]-[Mdulo]-[Submdulo]-
as de Funcional de [Secuencial]
Consulta Requerimientos para DFR-SBS-SEO-MAN-001
documentar pantallas
de consulta
FOR-DES-DFR-026 DFR_Pantall Documento DFR-[IFI]-[Mdulo]-[Submdulo]-
as de Ingreso Funcional de [Secuencial]
/ Requerimientos para DFR-SBS-SEO-MAN-001
Mantenimie documentar pantallas
nto de que permitan ingresar
Informacin datos, modificarlos o
eliminarlos.
FOR-DES-DFR-027 DFR_Gener Documento DFR-[IFI]-[Mdulo]-[Submdulo]-
acin de Funcional de [Secuencial]
Reportes Requerimientos para DFR-SBS-SEO-MAN-001
generacin de
reportes
FOR-DES-MRO-028 Matriz de Matriz que permite MRO-[IFI]-[Siglas del Proyecto]-
Roles establecer todas las [Versin]
opciones del mdulo MRO-SBS-INT-V1
y los perfiles
Ren Alvarez

definidos para el
mismo de tal forma
que se identifique las
opciones asignadas a
cada mdulo
FOR-DES-CRO-013 Cronograma Cronograma Segunda [Siglas del
de proyecto. Estimacin Proyecto]_Cronograma_[Estimacin]_
[Fecha Formato
ddMesAo]_[Versin].
INT_Cronograma_2daEstimacion_28
Oct2013_v1
Tabla 6. Formularios del Anlisis de Brechas
3.3.3. Diseo de Requerimientos
En base al Documento Final de Requerimientos (DFR), resultado de la etapa de Anlisis
de Requerimientos detallado, los especialistas procedern a traducir el requerimiento del
usuario en un diseo que soporte los desarrollos planificados del sistema y se proyecte a
las nuevas funcionalidades a futuro, de tal manera que opere conforme a lo solicitado
enmarcado en la arquitectura de la aplicacin y en los estndares del Proveedor del Core
Bancario, generando un documento tcnico denominado DTR (Definicin Tcnica de
Requerimientos). Generalmente un DFR est asociado a un DTR.
Para la realizacin de esta etapa ser necesaria en algunos casos desarrollar prototipos
de las funcionalidades ms complejas, de tal forma que el usuario observe como quedar la
aplicacin y apruebe el desarrollo respectivo.
3.3.3.1.Entregables:
Definiciones tcnicas de requerimientos(DTR)
Actas de aceptacin de prototipos realizados previamente acordados
3.3.3.2.Formularios del Diseo Tcnico
Formulario Nombre Descripcin Formato de Nombre
Ren Alvarez
Formulario Nombre Descripcin Formato de Nombre

FOR-DES-DTR-030 DTR_Estruc Documento Tcnico DTR-[IFI]-[Mdulo]-[Submdulo]-
turas de Requerimientos [Secuencial]
para generacin de DTR-SBS-SEO-MAN-001
archivos.
FOR-DES-DTR-031 DTR_Gener DTR para DTR-[IFI]-[Mdulo]-[Submdulo]-
al documentar en forma [Secuencial]
general una DTR-SBS-SEO-MAN-001
especificacin
tcnica.
FOR-DES-DTR-032 DTR_Gener Documento Tcnico DTR-[IFI]-[Mdulo]-[Submdulo]-
acin de de Requerimientos [Secuencial]
Reportes para generacin de DTR-SBS-SEO-MAN-001
reportes.
Tabla 7. Formularios del Diseo Tcnico
3.3.4. Desarrollo / Personalizacin
Los documentos funcionales de requerimientos (DFRs) y documentos de definiciones
tcnicas de requerimientos (DTRs) constituyen una gua de trabajo para que un
desarrollador del Proveedor del Core Bancario, pueda realizar eficientemente los
desarrollos de las funcionalidades que conlleven a cumplir el diseo tcnico / funcional
aprobado por la IFI. El mismo desarrollador procede a realizar las pruebas tcnicas
unitarias del cdigo programado, dejando la evidencia y la documentacin pertinente de las
pruebas realizadas.
El cdigo generado por los desarrolladores ser supervisado por el rea de control de
calidad del Proveedor del Core Bancario, de acuerdo a su organizacin y procesos internos,
por ejemplo, el jefe de desarrollo o desarrollador senior, realizar peridicamente
revisiones e inspecciones de cdigo a los productos generados por el equipo de desarrollo;
al igual que el equipo de aseguramiento de calidad se asegurar que los productos que
estn siendo desarrollados cumplen con lo especificado en los DFRs y y DTRs, de tal
forma que se identifiquen incidentes con antelacin a la ejecucin de las pruebas con el
cliente.
Ren Alvarez
3.3.4.1.Entregables de la personalizacin:
Funcionalidad desarrollada en la aplicacin de acuerdo a lo aprobado en los
DFRs y DTRs
Cdigo fuente del sistema, si el contrato lo especifica as.
Manuales
o Manual de Usuario
o Manual de Instalacin de Aplicaciones
o Manual de Tcnico de Navegacin
o Manual de Parametrizacin
o Modelo de Datos/Diccionario de datos
Los entregables de esta etapa pueden ser aplicables todos o no, dependiendo del
tipo de aplicacin o del mdulo a desarrollar o personalizar.
3.3.4.2.Formularios de la etapa de personalizacin

Acta de entrega ADR-[IFI]-[Mdulo]-
FOR-DES-ADR- Acta de
del sprint [Submdulo]-[Secuencial]
015 reunin
desarrollado ADR-SBS-SEO-MAN-010
Tabla 8. Formularios de la etapa de personalizacin
3.3.5. Convivencia
Esta etapa, si amerita, comprende el desarrollo de los programas necesarios que
permitan realizar principalmente dos grandes grupos de tareas:
La convivencia entre los mdulos del nuevo core que saldrn en produccin en una
primera fase y que deben convivir con los mdulos del core actual que seguirn en
produccin hasta que sean reemplazados en una siguiente fase.
Ren Alvarez
El desarrollo de las interfaces entre el nuevo core bancario con otros sistemas
satlites que tenga la IFI como pueden ser: sistemas de prevencin de fraude y
lavado de activos, ERP, BI, banca virtual u online, entre otros; y las interfaces
entre el nuevo core con aplicaciones de entidades externas, como son: VISA,
MASTERCARD, SRI, IESS, pagos de servicios pblicos y privados entre otros.
En donde ser necesaria la participacin de los proveedores de cada una de estas
aplicaciones.
Las principales actividades a considerar en esta etapa son las siguientes:
Realizar la convivencia temporal o permanente de los sistemas actuales de la IFI
con los de la solucin final a implantarse, este esfuerzo se determinar una vez que
se haya definido la estrategia de salida en produccin de los diferentes aplicativos
o funcionalidades, durante la etapa de Levantamiento de Requerimientos.
Ajustes o creacin de programas de interfaces con sistemas externos o de entes
externos a la de la IFI y que pertenecen a terceros, si amerita. Ejemplo (empresas
de servicios pblicos, privados, redes de cajeros o tarjetas de crdito. Se conocer
en la etapa de anlisis).
La coordinacin para pruebas con entes externos la debe ejecutar la IFI.
3.3.5.1.Entregables de la etapa de Convivencia
Plan de desarrollo de convivencia e interfaces con entes externos.
Informes de avance y terminacin de la programacin de convivencia e interfaces
con entes externos.
Ren Alvarez
3.3.5.2.Formularios de la etapa de Convivencia
Los formularios de esta etapa sern los mismos de la etapa de desarrollo o
personalizacin.
3.3.6. Parametrizacin
La parametrizacin es el proceso mediante el cual se definen todos los valores bsicos
para el funcionamiento de un mdulo, se definen caractersticas que permiten que la
aplicacin desarrollada no dependa de cambios a nivel de cdigo fuente para tener un
nuevo comportamiento con el uso de nuevos valores. Estos valores son definidos por el
usuario y pueden ser modificados en cualquier momento utilizando las opciones que
proporciona el sistema.
Tareas generales a cubrir:
Tareas desarrolladas por el Proveedor del Core Bancario
o Preparacin de talleres de parametrizacin
o Dictado de talleres de parametrizacin
Tareas desarrolladas por la IFI
o Definicin e identificacin de parmetros
o Ingreso de parmetros al sistema
o Certificacin de la parametrizacin
o Elaboracin de scripts de carga
3.3.6.1.Entregables de la etapa de parametrizacin
Acta de taller de parametrizacin
Manual de parametrizacin preliminar
Ren Alvarez
3.3.6.2.Formularios de la etapa de Parametrizacin

FOR-DES-MPA- Manual de Manual en el que MPA-[IFI]-[Mdulo]-
039 Parametriz se especifica las [Submdulo]-[Secuencial]
acin tablas de MPA-SBS-SEO-MAN-001
parametrizacin
del sistema
comunes tales
como parmetros
o catlogos o no
como tablas
especficas de la
aplicacin
Tabla 9. Formularios de la etapa de parametrizacin
3.3.7. Roles y Seguridades
Durante esta etapa se definen las transacciones o funcionalidades que un determinado
rol o perfil tendrn asociadas, para luego proceder a la asociacin de este rol a los
funcionarios correspondientes, esta etapa define el control de accesos al sistema.
Tareas a Cubrir:
Tareas desarrolladas por la Proveedor del Core Bancario
o Taller de Roles y Seguridades
o Generacin de Matriz de roles y seguridades
o Generacin de scripts de carga.
Tareas desarrolladas por el IFI
o Definicin de funcionalidades o servicios
o Definicin de roles
o Asignacin de funcionalidades o servicios a roles
o Identificacin de usuarios
o Asociacin de usuarios a roles
Ren Alvarez
3.3.7.1.Entregables de la etapa de Roles y Seguridades
Acta de taller de Roles y Seguridades
Matriz de Roles y Seguridades
3.3.7.2.Formularios de la etapa de Roles y Seguridades

FOR-DES-MRO-028 Matriz de Matriz que permite MRO-[IFI]-[Siglas del Proyecto]-
Roles establecer todas las [Versin]
opciones del mdulo MRO-SBS-INT-V1
y los perfiles
definidos para el
mismo de tal forma
que se identifique las
opciones asignadas a
cada mdulo
Tabla 10. Formularios de la etapa de Roles y Seguridades
3.3.8. Migracin de datos
En la etapa de migracin de datos, se extrae la informacin disponible de los sistemas
actuales de la IFI y se realiza la conversin de la informacin, para registrarla en el
formato requerido por el nuevo core bancario.
En caso de ser necesario se aadir la informacin no disponible, en cuyo caso la IFI
definir los valores default a ser registrados en el nuevo sistema.
Igualmente, de ser necesario, la IFI definir procedimientos operativos para el ingreso
de informacin indispensable para el funcionamiento del aplicativo y que no pudo ser
migrada o definida por default, por falta de informacin en el sistema actual o nuevas
definiciones.
La estrategia de migracin debe quedar debidamente formalizada en el Documento de
Migracin de Datos Final (DMDF), el cual parte de mapear la informacin que necesita el
nuevo sistema versus las estructuras del core actual.

Ren Alvarez
Dependiendo de la calidad de la data a ser migrada, podr ser necesario realizar
procesos de captura y/o depuracin, cuyo proceso estar a cargo de la IFI (Acosta Ramirez,
20111).
Tareas a cubrir:
Tareas realizadas por Proveedor del Core Bancario
o Preparar taller de Migracin
o Dictado del taller
o Desarrollo de programas de carga al nuevo core
Tareas realizadas por el IFI
o Elaboracin del DMDF Documento de Migracin de Datos Final
o Desarrollo de programas de extraccin, validacin y cuadre de data desde
el sistema core actual
o Depuracin de data
o Migracin de datos
o Cuadre y balance
o Certificacin de la informacin migrada
3.3.8.1.Entregables de la etapa de migracin de datos
Acta de talleres de migracin
DMDF Documento de Migracin de Datos Final.
Acta de entrega de programas de carga de datos al nuevo core
3.3.8.2.Formularios de la etapa de migracin de datos

FOR-DES-DFM-080 Documento Formulario en donde DFM-[IFI]-[Siglas del Proyecto]-
Final de se debe detallar el [Versin]
Ren Alvarez

Migracin mapeo de los campos DFM-SBS-INT-V1
a ser migrados, datos
default, datos a ser
completados.
Tabla 11. Formularios de la etapa de Migracin de Datos
3.3.9. Preparacin y Ejecucin de Pruebas
La etapa de preparacin y ejecucin de pruebas utiliza un enfoque de gestin de calidad
basado en procesos, que abarca la mayor cantidad de casos y escenarios del negocio de la
IFI, consiguiendo una alta calidad del sistema y disminuyendo significativamente la
ocurrencia de incidentes en produccin, mediante una metodologa ordenada basada en
guas propias e internacionales como ISTQB (International Software Testing
Qualilfication Board). La metodologa de pruebas debe estar respaldada en alguna
herramienta de gestin de pruebas. A continuacin, se esquematiza la metodologa de
pruebas:
Figura 3-14: Metodologa de Pruebas, (MAIATECH, 2011)
Ren Alvarez
3.3.9.1.Fases de la Metodologa de pruebas
La IFI deber elaborar el Plan de Pruebas para la aplicacin, para lo cual, la IFI debe
contar con un equipo de pruebas o QA asignado al proyecto.
Planificacin de pruebas, creacin de casos de prueba.
Ejecucin de las pruebas funcionales del sistema.
Gestionar resultados del proceso de pruebas (Evaluacin).
3.3.9.1.1. Elaboracin del Plan de Pruebas
Las actividades en esta etapa incluyen:
Definir la estrategia, alcance y prioridades de las pruebas.
Establecer el calendario de ejecucin de las pruebas.
Definir criterios de aceptacin.
Definir recursos, funciones y responsabilidades.
3.3.9.1.2. Creacin de Casos de Prueba
Definicin de los procesos, condiciones y casos de prueba.
Creacin de los casos de prueba y planificacin de la ejecucin utilizando una
herramienta de gestin de pruebas.
Preparacin de datos de prueba.
3.3.9.1.3. Ejecucin de Pruebas del Sistema
Ejecucin de los casos de prueba y registro de la evidencia de ejecucin
utilizando una herramienta de gestin de pruebas.
Ren Alvarez
Reporte y gestin de las incidencias encontradas a travs de la herramienta.
Seguimiento del avance de las pruebas sobre la base de lo planificado.
3.3.9.1.4. Gestionar resultados del proceso de pruebas (Evaluacin)
Generacin de reportes estadsticos que sirvan como una herramienta de
apoyo en la toma de decisiones del avance de las pruebas: Informes de
planificacin y avance de pruebas, de incidencias generadas por tipo,
prioridad, etc.
Anlisis de la informacin generada: El Gerente de Proyecto de Proveedor del
Core Bancario debe realizar un anlisis de causa raz de las incidencias
encontradas en la ejecucin de pruebas y documentar los resultados de ese
anlisis en el informe de seguimiento de tal manera que sean analizados en la
reunin de Comit de Seguimiento interno del proyecto por parte del
Proveedor del Core Bancario. El anlisis de causa raz servir para definir las
acciones correctivas a implementar a fin de evitar que se sigan presentando
las incidencias encontradas. El seguimiento a la realizacin de las acciones
correctivas y preventivas se lo realiza a travs de las reuniones establecidas en
la Metodologa de Administracin del Proyecto.
Es importante que las acciones correctivas mencionadas en el prrafo anterior sean
implementadas lo antes posible y que las incidencias sean corregidas antes de pasar a una
nueva etapa o ciclo de pruebas, de manera que se garantice que los productos finales
entregados a la IFI tengan la mayor calidad posible.
Ren Alvarez
3.3.9.2.Entregables de la etapa de Preparacin y Ejecucin de Pruebas
Incidentes reportados referentes al core bancario, debidamente solucionados
3.3.9.3.Formularios de la etapa de Preparacin y Ejecucin de Pruebas
Los formularios para la preparacin y ejecucin de pruebas realmente dependen de la
herramienta que se utilice para la gestin de dichas pruebas, puesto que tanto la
planificacin (condiciones, guiones, casos, datos de entrada, datos de salida y ciclos de
pruebas) como la ejecucin (incidentes, responsables, estadsticas) debern ser ingresados
en la herramienta de gestin de pruebas que la IFI proporcione para tal efecto. Toda la
planificacin de pruebas, puede ser usada como base para la etapa de Certificacin del
sistema. A manera de ejemplo se proporciona un formulario para el registro de casos de
prueba.

FOR-CON-RCP-043 Reporte de Formulario que RCP-[IFI]-[Siglas del Proyecto]-
Caso de permite detallar los [Versin]
Prueba casos de prueba a ser RCP-SBS-INT-V1
utilizados para probar
un mdulo del core
bancario, cuando se
utiliza un esquema
manual.
Tabla 12. Formularios de la etapa de Preparacin y Ejecucin de Pruebas
3.3.10. Documentacin
En la etapa de Documentacin el Proveedor del Core Bancario deber entregar la
documentacin a la que se haya comprometido contractualmente y que mnimamente
corresponder a:
o Manual de Usuario
o Manual Tcnico de Navegacin
Ren Alvarez
o Manual de Instalacin
o Modelo de datos y Diccionario de datos
Sin embargo, la IFI debe preocuparse por generar documentacin que le servir para
facilitar la salida a produccin, reforzar la capacitacin y el soporte a la operacin del
nuevo core bancario, entre otros se debe mencionar:
o Actualizacin a los manuales de procesos y procedimientos
o Actualizacin a las polticas de la IFI
o Nuevos formularios, contratos, slips, etc.
3.3.10.1. Entregables de la etapa de Documentacin
Manual de Instalacin
Manual Usuario
Manual de Tcnico de Navegacin
Modelo de datos y Diccionario de datos
3.3.10.2. Formularios de la etapa de Documentacin

FOR-DES-MFU-035 Manual de Manual en donde se MFU-[IFI]-[Mdulo]-[Submdulo]-
Usuario describe el uso de la [Secuencial]
aplicacin MFU-SBS-SEO-MAN-001
FOR-DES-MNA-036 Manual Manual en el que se MNA-[IFI]-[Mdulo]-[Submdulo]-
Tcnico de describe la [Secuencial]
Navegacin interaccin entre las MNA-SBS-SEO-MAN-001
pantallas, mens y
opciones de la
aplicacin
FOR-DES-MDD-037 Modelo de Se describe cada MDD-[IFI]-[Mdulo]-[Submdulo]-
Datos campo y tabla [Secuencial]
definido en la base de MDD-SBS-SEO-MAN-001
datos para que sea el
soporte de la BDD.
Tabla 13. Formularios de la etapa de Documentacin
Ren Alvarez
3.3.11. Capacitacin
Todos los talleres que dicte el Proveedor del Core Bancario debern ser terico-
prcticos, enfocados en entrenar a los usuarios de la IFI en la funcionalidad y operacin del
nuevo core bancario; mientras que a los tcnicos de la IFI se les capacitar en la
arquitectura y modelo de datos de nuevo core bancario de tal forma que puedan dar soporte
tcnico de primer nivel al interior de la IFI. Lo ms aconsejable es capacitar al personal de
la IFI a medida que se va demostrando cada tcnica, habilidad, funcionalidad o uso de una
herramienta.
Realmente la capacitacin es constante durante todo el plazo de ejecucin del proyecto,
por esto es imprescindible que la IFI asigne su mejor personal a tiempo completo para la
implantacin del core bancario, estas personas sern los que soporten la IFI con la nueva
solucin en produccin. El proveedor del Core Bancario se encargar de entrenar a los
capacitadores de la IFI, de tal forma que sern estos capacitadores los encargados de
masificar el conocimiento a todo el personal de la IFI.
3.3.11.1. Materiales
Talleres de capacitacin Funcional y Tcnico por cada mdulo
Manuales de usuario y presentaciones enfocadas al uso del sistema
Modelo de datos
Core Bancario funcionando
Para la capacitacin en primera instancia se crea un temario de capacitacin que permite
planificar este proceso de forma adecuada y ordenada, en donde se definirn temas como
asistentes, das de capacitacin, temas de capacitacin, materiales e insumos.
Ren Alvarez
Adicional a la capacitacin que brinda el proveedor del core bancario, la misma que
estar orientada al uso del nuevo sistema, la IFI debe prever capacitaciones adicionales
previo a la salida en produccin, estas capacitaciones adicionales estn relacionadas con:
Modificacin en los procesos de la IFI
Nuevos procesos
Cambio en la estructura organizacional
Nuevos productos o servicios
Cambios en las polticas internas de la IFI
3.3.11.2. Entregables de la etapa de Capacitacin
Calendario de capacitacin
Taller de capacitacin funcional de cada mdulo a los capacitadores de la IFI
Taller de arquitectura del core bancario a los tcnicos de la IFI
Taller de capacitacin tcnica de cada mdulo a los tcnicos de la IFI
3.3.11.3. Formularios de la etapa de Capacitacin

FOR-DES-TCA- Temario Documento que TCP-[IFI]-[Siglas del Proyecto]-
040 de define el marco [Tipo de capacitacin]-
Capacitaci para el proceso de [Modulo]-[Versin]
n Tcnica capacitacin TCP-SBS-INT-FUN-SEO-V1
Tabla 14. Formularios de la etapa de Capacitacin
3.3.12. Estrategia de Salida a Produccin
La definicin de la Estrategia de Salida a Produccin por lo general se la hace en
paralelo a la etapa de Anlisis de Brechas, en esta etapa se define en trminos generales la
manera en que se pondr en produccin el nuevo Core Bancario una vez est listo, es decir,
si la salida ser big bang todo el core bancario en una fecha determinada se apaga el
Ren Alvarez
anterior y se prende el nuevo; o si la salida ser por fases, como por ejemplo: primera fase,
salir con los mdulos de clientes y contabilidad, segunda fase, salir con los mdulos de
activas y tercera fase, salir con los mdulos de pasivas y banca en lnea. Las decisiones que
se deben tomar para definir la estrategia de salida en produccin dependen de varios
factores, entre ellos:
o La capacidad presupuestaria y/o de trabajo de la IFI para afrontar varios frentes en
paralelo: oficinas para la ejecucin del proyecto, infraestructura de hardware,
software y comunicaciones, salas de reuniones y sobre todo el personal que la IFI
debe destacar para el proyecto.
o Cantidad de sistemas a ser migrados al nuevo core, no es lo mismo si una IFI tiene
por ejemplo un sistema de clientes que atiende a su core actual, a que tenga dos,
tres o ms sistemas de clientes que deben migrarse al nuevo core bancario.
o La calidad de la informacin almacenada en las bases de datos, puede afectar
seriamente los tiempos definidos para la salida en produccin, se han dado casos en
que solo la etapa de depuracin de datos puede ser ms extensa que la etapa de
Personalizacin del mdulo respectivo.
o Esfuerzo necesario para desarrollar la convivencia.
La Estrategia de Salida a Produccin por lo general es revisada en cada reunin de
Comit de Director a manera de recordatorio, en donde conforme avanza el proyecto se la
va ratificando o si al descubrirse riesgos o problemas se debern plantear alternativas para
que se tomen las acciones necesarias.
Durante esta etapa debe tambin determinarse y acordarse con la IFI el perodo que el
Proveedor del Core Bancario deber dar soporte post-produccin o estabilizacin al
mdulo o grupo de mdulos que salgan en produccin.

Ren Alvarez
3.3.12.1. Entregables de la etapa de Estrategia de Salida a Produccin
Documento de Estrategia de Salida a Produccin
Actualizaciones a la Estrategia de Salida a Produccin
3.3.13. Certificacin / QA IFI
La etapa de certificacin o Control de Calidad de la IFI se refiere a las pruebas
funcionales finales que debern realizar los usuarios funcionales de la IFI para certificar
que los mdulos cumplen con la funcionalidad deseada, se cumple con lo definido en la
Estrategia de Salida a Produccin y en la definiciones de la Convivencia y Migracin, para
lo cual debern haber preparado la prueba de certificacin en base a la metodologa propia
de la IFI y podrn usar como base los sets de pruebas elaborados en la etapa de
Preparacin y Ejecucin de Pruebas, estas pruebas se harn con informacin de datos
migrados, la parametrizacin real y definitiva y la carga de los usuarios y roles definitivos
tambin.
3.3.13.1. Entregables de la etapa de Certificacin
Plan de certificacin
Acta de certificacin de cada mdulo
Acta de certificacin del proceso de migracin del mdulo
Acta de certificacin del proceso de parametrizacin del mdulo
Acta de certificacin de roles y seguridades
Documento de aprobacin para paso a produccin
Ren Alvarez
3.3.14. Preparacin para Salir a Produccin
El proceso de salida en produccin consiste en definir, preparar y realizar todas las
tareas necesarias para asegurar la correcta instalacin del nuevo sistema en los ambientes
de produccin de la IFI, la logstica necesaria para que el plan de salida se cumpla, lo que
incluye: contingencias, comunicaciones, atencin al cliente, personal de soporte, atencin
agencias, etc.; y por ltimo la planificacin y coordinacin para cargar la parametrizacin
definitiva en caso de ser necesario y sobre todo la migracin de datos definitiva con todos
sus procesos de cuadre. Considerando los lineamientos dados en la etapa en que se defini
la estrategia de salida a produccin y las fechas previstas para el efecto, pues para la
salida en produccin es muy importante considerar los tiempos de migracin y cuadre, por
lo general las IFIs seleccionan un feriado largo como fechas adecuadas para realizar el
cambio del core bancario o los mdulos que vayan a salir en produccin, dependiendo si la
salida en produccin es por fases o todo el core de una vez.
Tareas a cubrir:
Tareas desarrolladas por Proveedor del Core Bancario y la IFI
o Revisin de la Estrategia de Salida a Produccin
o Preparacin del plan de salida de produccin
Tareas desarrolladas por la IFI
o Verificar y Certificar infraestructura de hardware, software y comunicaciones
del sistema central
o Verificar y certificar instalacin del aplicativo
o Verificar y certificar parametrizacin cargada
o Verificar y certificar datos migrados, cargados y cuadrados
Ren Alvarez
o Elaboracin de procesos y procedimientos operativos y tcnicos para
convivencia solo en caso que aplicasen.
o Manejo del Cambio
o Preparar plan de contingencia
o Preparar plan de atencin al cliente y a las agencias y usuarios
o Comunicacin a entes reguladores y otros entes externos
o Definir personal de soporte
3.3.14.1. Entregables de la etapa de Preparacin para Salir a Produccin
Plan de puesta en produccin
Plan de contingencia
Check List detallado de tareas a realizar por la IFI y por el Proveedor del Core
Bancario
Plan de atencin al cliente, sucursales y usuarios
Plan de personal de soporte
3.3.14.2. Formularios de la etapa de Preparacin para Salir a Produccin

FOR-DES-PPP- Plan de Documento que PPP-[IFI]-[Proyecto]-[Fecha
076 puesta en define los Formato: aaaammdd]
producci lineamientos para
n la puesta en
produccin de
una aplicacin.
FOR-DES-PSP- Checklist Documento que PSP-[IFI]-[Proyecto]-[Fecha
041 Paso a permite tener un Formato: aaaammdd]
Producci checklist para PSP-SBS-20130911
n salida a
produccin
Tabla 15. Formularios de la etapa de salida a produccin
Ren Alvarez
3.3.15. Pilotos / Paralelos
Un Paralelo normalmente es utilizado para asegurar que los resultados que arroja el
nuevo core bancario son similares a los que est obteniendo el core bancario que ser
reemplazado, un ejemplo tpico es la planificacin del paralelo para el mdulo de
contabilidad, en donde debe definirse qu das se realizar el paralelo y el alcance del
mismo, todo el Banco o ciertas sucursales con todos o ciertos productos. Durante el
paralelo, los usuarios definidos para esta tarea, debern ingresar en el core bancario actual
y en el nuevo, el movimiento del da o los das definidos en el alcance, con el objetivo de
analizar los resultados obtenidos y tener la certeza que el nuevo core bancario arrojar
resultados similares e inclusive podra llegar a cuadrarse los aplicativos.
El piloto permite simular la salida a produccin con un alcance pre determinado, por
ejemplo, simular la salida a produccin de un grupo de agencias con los nuevos mdulos
de activas en donde se probar adems de los aplicativos, toda la infraestructura de
produccin y comunicaciones, parametrizacin, migracin de datos y los nuevos procesos
y procedimientos.
Se puede organizar en conjunto o por separado el paralelo y el piloto del mdulo o
grupos de mdulos a ser analizados, para lo cual es necesario realizar una planificacin
detallada y pormenorizada, pues implica mucho trabajo adicional al da a da, de todas las
reas de la IFI.
3.3.15.1. Entregables de la etapa de Pilotos o Paralelos
Plan de Piloto
Plan de Paralelo
Informe de resultados del Piloto
Ren Alvarez
Informe de resultados del Paralelo
3.3.16. Estabilizacin
O tambin llamado soporte post-produccin, implica las tareas a realizar para estabilizar
la aplicacin una vez el nuevo core bancario, total o parcialmente, haya salido en
produccin, es decir, el nuevo core bancario es el que est atendiendo la operacin del
Banco desde el da 1, para lo cual, debe organizarse y coordinarse el trabajo entre la IFI y
el proveedor del core bancario, es una etapa muy importante de la metodologa, puesto que
todo incidente de prioridad alta que se reporte, debe ser corregido inmediatamente para no
afectar al normal desenvolvimiento de las actividades de la IFI y sobre todo el impacto que
esto pueda causar a sus clientes.
El tiempo de estabilizacin por lo general est acordado previamente en la Estrategia de
Salida a Produccin.
Tareas que debe considerar la IFI:
o Previo a la salida a produccin, comunicar a todas las reas afectadas, los esquemas
de soporte y reporte de incidentes y el plan de salida a produccin.
o Estructurar u organizar un rea de soporte funcional de primer nivel, tanto para uso
del aplicativo como de procesos o procedimientos.
o Definir esquema de reporte de incidentes por parte de usuarios y clientes
o Coordinacin con el equipo tcnico del Proveedor del Core Bancario.
Tareas que debe considerar el Proveedor del Core Bancario
o Estructurar el equipo que dar soporte tcnico y funcional de segundo nivel al
mdulo o grupo de mdulos que se colocaron en produccin.
Ren Alvarez
o Llevar el registro y control de los niveles de servicios acordados contractualmente.
3.3.16.1. Entregables de la etapa de Estabilizacin
Reporte de incidentes atendidos por mes
Acta de cierre de la estabilizacin
Ren Alvarez
4. CAPTULO 4: CONCLUSIONES Y RECOMENDACIONES
4.1. Conclusiones
Como resultado de esta investigacin se puede concluir que, aunque una
metodologa es simplemente una secuencia de pasos para llevar a cabo un
determinado trabajo, la metodologa planteada en este documento junta dos grandes
mundos que no deberan vivir el uno sin el otro, como son: la gestin del proyecto
y la implantacin de un core bancario en una institucin financiera, van a ir siempre
juntas, la una no se puede ejecutar sin la otra por lo que sus etapas, actividades y
entregables debern ser considerados en la planificacin de este tipo de proyectos
de misin crtica para lograr el xito deseado. Esta metodologa puede adaptarse
fcilmente a la implementacin de otros productos en las instituciones financieras,
como son un ERP, un CRM entre otros.
La mayora de las aplicaciones bancarias al igual que la mayora de las aplicaciones
para el resto de industrias en el mundo, ha ido evolucionando de acuerdo a la
tecnologa disponible en el momento, tal es as que existen ahora bancos
completamente digitales, es decir, han eliminado en sus sucursales el uso del papel
y los puestos de atencin son ahora tablets, como es el caso de Bankinter en Espaa
o el BBVA alrededor del mundo o bancos que en su filosofa actual est el de
operar sin sucursales fsicas; o, el concepto de omnicanalidad para los servicios
financieros, en donde son los clientes quienes controlan los canales que quieren
utilizar; la omnicanalidad aporta una experiencia consistente a lo largo de los
canales (la nueva sucursal, web, mvil, medios sociales, ATMs, Kioscos, tablets)
para ofrecer a los clientes un acceso fluido a productos y servicios financieros en
donde quieran y cuando los necesiten.
Ren Alvarez
La implementacin de un core bancario supone un proyecto complejo de mediano
alcance, de uno a tres aos, dependiendo del tamao y tipo de institucin
financiera, del grado de madurez del core bancario seleccionado y del nivel de
compromiso y conocimiento del personal tanto de la IFI como del proveedor del
core a ser asignado a dicho proyecto.
4.2. Recomendaciones
Antes de iniciar un proyecto de implementacin de un core bancario es
recomendable que tanto la IFI como el proveedor del core bancario a implantarse y
si existe, la empresa consultora a cargo de la gobernabilidad y/o aseguramiento de la
calidad del proyecto, revisen, acuerden y afinen la metodologa a utilizarse durante
todo el proyecto, dejando claramente establecidas las reglas de juego, entregables y
criterios de aceptacin; puede usarse el material detallado en este documento como
base para iniciar los acuerdos entre las partes.
Una IFI antes de entrar en un proceso de seleccin de core bancario, debe tener
claramente identificado en su plan estratgico, el modelo de institucin financiera
que quiere llegara ser y de este modo definir el modelo de core bancario que
necesita para apoyar las iniciativas de dicho plan estratgico, pensando en el punto
de vista funcional como tcnico y de arquitectura.
La metodologa para la implantacin de un core bancario debe contar con el
respaldo total de la alta direccin de la institucin, puesto que no se trata de un
proyecto aislado o la iniciativa de un rea en particular, se trata de un proyecto
institucional de mediano plazo, si pensamos en la implantacin (inversin
significativa) y a largo plazo si pensamos en la explotacin de la plataforma (retorno
sobre la inversin).
Ren Alvarez
Al planear la compra de un core bancario, la IFI debe considerar en su presupuesto
no solo las licencias y servicios del core bancario, sino tambin, la infraestructura
necesaria para alojar al personal de la IFI, del proveedor del core bancario y de
terceros que sern necesarios para la ejecucin del proyecto, adems del hardware y
software adicional para estructurar varios ambientes de desarrollo, pruebas,
certificacin, preproduccin y produccin segn la planificacin macro que se
tenga.
Uno de los factores que hacen la diferencia entre el xito y el fracaso de un proyecto
de implantacin de un core bancario, es la asignacin de personal a tiempo completo
por parte de la IFI al proyecto, y que este personal tenga el suficiente conocimiento,
experiencia y poder de decisin para avanzar adecuadamente segn la planificacin
que se acuerde, se estima que al menos el 3.5 al 4 por ciento del personal que trabaja
en la IFI, deber ser asignado a tiempo completo al proyecto de implantacin del
core bancario.
Es recomendable que una IFI que entra en un proceso de seleccin y luego
implantacin de la solucin del core bancario seleccionado, busque apoyo en
empresas especializadas en seleccin, gobernabilidad y/o acompaamiento
metodolgico para la implantacin del core bancario, empresas que aportarn
metodologas como las planteadas en este documento, herramientas de apoyo y
personal con experiencia en este tipo de proyectos y soluciones.
Es importante tambin que la IFI considere un esquema de comunicacin a todo el
personal para explicarles las mejoras y los posibles efectos que este proceso tendr
en beneficio de la IFI y de sus clientes (Gestin del Cambio).
Ren Alvarez
Vital importancia tiene el proceso de capacitacin interna tanto al personal
funcional, como tcnico y administrativo, pues solo as se garantizar la efectividad
de uso del core bancario y esto se evidenciar en mejoras en los indicadores de los
procesos administrativos, tecnolgicos y de productividad de la organizacin, la
capacitacin debe ser constante y permitir medir el grado de uso del core bancario,
muchas veces sucede que por desconocimiento se dejan de usar funcionalidades que
el core brinda y los usuario tienden a crear procesos o procedimientos o
herramientas manuales para suplir lo que creen que el core no tiene; un ejemplo que
clarifica esto es que el uso de Word o Excel por parte de la mayora de usuarios no
llega al 25% de todo lo que estas herramientas realmente pueden hacer.
4.3. Bibliografa
Acosta Ramirez, M. (20111). Estrategia de migracin a datos como opcin. Catalunya,
Espaa: Universidad de Catalunya.
Alondro, M. (2014). Gestin de Procesos de Negocio. Arquitectura Orientada a Servicios
y web 2.0. Chile.
Avila Mojica, J. A., & Bustacara Medina, C. J. (2014). BLACKBOARD LEARNING
SYSTEM. Bogot, Colombia: Universidad Pontificia Javeriana.
Bolo, M. (2011). Arquitectura de Integracin orientada a Servicios. IBM Software Group.
BUPARTECH. (2006). Estrategias de Fidelizacin de clientes. Panam: BUPARTECH.
Chirino, A. (2013). Estrategia de salida a produccin como mejor opcin.
Ren Alvarez
Coron, A. J. (2013). Gestin de proyectos. Unin Europea: Escuela de organizacin
industrial.
Diccionario . (2013). Retrieved from
http://diccionario.sensagent.com/CORE%20BANCARIO/es-es/
Espinosa Daz, E. d. (2010). Propuesta de implantacin de la Arquitectura BPM/SOA para
agilitar la gestion comercial en la gestion comercial en la CNT. Quito, Ecuador:
Universidad San Francisco de Quito.
F., A. (2014). L MODELO CLIENTE/SERVIDOR EN SISTEMAS DISTRIBUIDOS.
Segovia: Universidad de Valladolid.
Fleitas, M. (2015). Plan de seguimiento y control. Toledo.
Flores, C., & Alarcn, C. (2015). Indicadores de Acceso y Uso a Servicios bancarios.
Chile.
Fuentes, N. (2010). Metodologa de implementacin de Core Bancario.
Galvz, F. (2011). Etapas de gestin de riesgos. Chile.
Garca, E. (2014). La programacin complementaria. Colegio Marcelino Catrn.
Gartner. (2012). Elegir un Core Bancario: Cmo alcanzar la inlcusin financiera.
GesFor. (2014). Retrieved from http://www.gesfor.com.mx/core-bancario
Gonzalez Quiroga, M. (2011). ESTUDIO DE ARQUITECTURAS DE REDES
ORIENTADAS A SERVICIOS. Catalunya, Espaa.: Universidad Politcnica de
Catalunya.
Ren Alvarez
Herranz de la Casa, J. M. (2012). La gestin de la comunicacin como elemento generador
de transparencia en las organizaciones no lucrativas. Espaa: CIRIEC.
ISSUU. (2012). Retrieved from
https://issuu.com/alide_publicaciones/docs/inclusi__n_financiera_2014/92
Jason, E. (2013). Arqiutectura Orientada a Servicios. Gua prctica para cuatificar el
retorno de la inversin. IBM Institute for Business Value.
Len Duarte, J. A. (2013). METODOLOGA PARA LA DETECCIN DE
REQUERIMIENTOS SUBJETIVOS EN EL DISEO DEL PRODUCTO. Barcelona,
Espaa: Universidad Politcnica de Catalunya.
LLarda, C. (2013). La arquitectura de software. Buenos Aires: Universidad de Buenos
Aires.
LLorente, M., & Oliveras, J. (2011). Introduccin a la arquitectura. Conceptos
fundamentales. Espaa: UPC.
Maestro, J. A., & Garcia, J. (2010). La etapa de cierre de proyecto. Universidad Antonio
de Nebrija.
MAIATECH. (2011). ARQUITECTURA MAIA CORE BANKING. Quito Ecuador.
MAIATECH. (2011). MAIA CB. Quito.
Mantilla, F. (2012). Arquitectura de la informacin para web sites. Quito: Universidad del
Ecuador.
Ren Alvarez
Mrquez Gmez, J. J. (2010). Arquitectura en tres niveles. Panam: Universidad de
Panam.
Merino, J. S. (2010). Calidad de los servicios bancarios. Madrid, Espaa: Universidad
Complutense de Madrid.
(2010). Metodologa de implementacin.
Pla Gonzalez, C. M. (2013). Evolucin de aplicaciones bancarias. Buenos Aires,
Argentina.
Project Management Institute, Inc. (2011). A Guide to the Project Management Body of
Knowledge. Pennsylvania, USA: Project Management Institute, Inc.
Stein Milln, A., & Zamoszczyk, C. (2012). SOA, la era de la integracin.
Tolosa, R. P. (2013). SOA. Principales servicios. Cubecorp.
Torres Albornoz, L. G. (2013). EVALUACIN DE HERRAMIENTAS EN ENTORNO
SAAS, PARA OPTIMIZAR LA GESTIN DE LAS COOPERATIVAS PEQUEAS
EN EL ECUADOR. Quito Ecuador: UNIVERSIDAD ANDINA SIMN
BOLVAR.
Valdez, A. (2014). Control y validacin de alcance de un proyecto. Espaa: Tecnolgico
de Monterey.
Vera, M. (2015). El ABC de la banca. Guayaquil, Quito.
Villz, P. (2011). Arquitectura Orientada a Servicios. Cmo reformular la Arquitectura
Corporativa. Paraguay.
Ren Alvarez
Wallace, W. (2014). Gestin de proyectos. Ediburgh Business school.
Ren Alvarez

S Elecci On Core

Cargado por

Copyright:

Formatos disponibles

S Elecci On Core

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

S Elecci On Core

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD CATLICA DEL ECUADOR

DISERTACIN PREVIA A LA OBTENCIN DEL TTULO DE

DESARROLLO DE UNA METODOLOGIA PARA LA

DIRECTOR: ING. OSWALDO ESPINOSA.

QUITO, 2016 / Abril / 05

Dedico este proyecto a mi familia: Yasmn, Adrin y Alejandra.

quienes desean involucrarse en proyectos de misin crtica.

1. CAPITULO 1: CORE BANCARIO ....................................................................................... 11

1.1. QU ES UN CORE BANCARIO ....................................................................................... 11

1.2. EVOLUCIN DE LAS APLICACIONES BANCARIAS ............................................................. 13

1.3. OBJETIVO DE UN CORE BANCARIO ............................................................................... 16

1.4. MOTIVOS PARA UN CAMBIO DE CORE BANCARIO ........................................................... 16

1.5. CARACTERSTICAS DE UN CORE BANCARIO .................................................................. 17

2. CAPTULO 2: COMPONENTES DE UN CORE BANCARIO ............................................. 19

2.1.1. IMPORTANCIA DE LA ARQUITECTURA DE SOFTWARE.................................................... 20

2.1.2. CLASIFICACIN DE LA ARQUITECTURA ....................................................................... 21

2.1.2.1. ARQUITECTURA CLIENTE-SERVIDOR ...................................................................... 21

2.1.2.2. ARQUITECTURA DE TRES CAPAS............................................................................. 22

2.1.2.3. ARQUITECTURA ORIENTADA A SERVICIOS (SOA).................................................... 24

2.1.3. EJEMPLO DE UNA ARQUITECTURA UTILIZADA POR UN CORE BANCARIO ....................... 26

2.1.3.1. CARACTERSTICAS DE LA ARQUITECTURA DEL CORE BANCARIO ............................... 27

2.2. FACTORES CLAVES PARA EL XITO EN LA IMPLANTACIN DE UN CORE BANCARIO. ........... 28

2.3. PRINCIPALES MDULOS DE UN CORE BANCARIO ........................................................... 30

3. CAPTULO 3: METODOLOGA PARA IMPLANTAR UN CORE BANCARIO................... 36

3.1. INTRODUCCIN ........................................................................................................... 36

3.2. GESTIN DEL PROYECTO ............................................................................................ 37

3.2.1. ENFOQUE ................................................................................................................ 37

3.2.2. METODOLOGA DE GESTIN DE PROYECTOS .............................................................. 38

3.2.2.1. INICIO DEL PROYECTO ........................................................................................... 39

3.2.2.1.1. ENTREGABLES DE INICIO: ................................................................................... 39

3.2.2.2. PLANIFICACIN ..................................................................................................... 40

3.2.2.2.1. ENTREGABLES DE LA PLANIFICACIN .................................................................. 40

3.2.2.3. EJECUCIN ........................................................................................................... 41

3.2.2.3.1. ENTREGABLES DE EJECUCIN ............................................................................ 41

3.2.2.4. SEGUIMIENTO Y CONTROL ..................................................................................... 42

3.2.2.4.1. ENTREGABLES DE SEGUIMIENTO Y CONTROL ...................................................... 44

3.2.2.4.1.1. INFORME DE AVANCE DEL PROYECTO ............................................................... 44

3.2.2.4.1.2. REUNIONES DE SEGUIMIENTO .......................................................................... 45

3.2.2.5. GESTIN DE LA COMUNICACIN ............................................................................. 46

3.2.2.5.1. COMIT DIRECTOR:............................................................................................ 47

3.2.2.5.2. ENTREGABLES DE GESTIN DE LA COMUNICACIN .............................................. 47

3.2.2.6. GESTIN DEL ALCANCE ......................................................................................... 48

3.2.2.6.1. VERIFICACIN DEL ALCANCE .............................................................................. 49

3.2.2.6.2. CONTROL DEL ALCANCE ..................................................................................... 50

3.2.2.6.3. CONTROL DE CAMBIOS ....................................................................................... 50

3.2.2.6.3.1. IDENTIFICAR CAMBIOS ..................................................................................... 51

3.2.2.6.3.2. FORMALIZAR CAMBIOS .................................................................................... 52

3.2.2.6.3.3. ANLISIS DE IMPACTO Y COSTOS ..................................................................... 52

3.2.2.6.3.4. APROBAR CAMBIOS ........................................................................................ 53

3.2.2.6.3.5. PLANIFICAR Y EJECUTAR EL CAMBIO ................................................................ 53

3.2.2.6.3.6. ENTREGABLES DEL CONTROL DE CAMBIO ........................................................ 54

3.2.2.7. GESTIN DE RIESGOS ........................................................................................... 54

3.2.2.7.1. MATRIZ DE PROBABILIDAD-IMPACTO .................................................................... 56

3.2.2.7.2. IDENTIFICACIN Y REGISTRO, MONITOREO Y CONTROL DE LOS RIESGOS.............. 58

3.2.2.8. GESTIN DEL CRONOGRAMA.................................................................................. 58

3.2.2.9. GESTIN DE LA CALIDAD ........................................................................................ 59

3.2.2.10. CIERRE DEL PROYECTO ...................................................................................... 60

3.2.2.10.1. ENTREGABLES DE CIERRE DEL PROYECTO ........................................................ 61

3.2.2.11. LINEAMIENTOS GENERALES DURANTE LA VIDA DEL PROYECTO ............................... 61