Propuesta de una arquitectura empresarial para la

gestión de venta proactiva en agencias bancarias

Item Type info:eu-repo/semantics/bachelorThesis

Authors Dávila Pino, Carlos Jharek; Quintana Murillo, Omar Julio

Publisher Universidad Peruana de Ciencias Aplicadas (UPC)

Rights info:eu-repo/semantics/embargoedAccess

Download date 19/11/2021 03:27:14

Link to Item http://hdl.handle.net/10757/621775

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

FACULTAD DE INGENIERÍA

DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS

CARRERA DE INGENIERÍA DE SISTEMAS

PROPUESTA DE UNA ARQUITECTURA

EMPRESARIAL PARA LA GESTIÓN DE VENTA
PROACTIVA EN AGENCIAS BANCARIAS

PROYECTO PROFESIONAL PRESENTADO POR:

CARLOS JHAREK DÁVILA PINO
OMAR JULIO QUINTANA MURILLO

PARA OPTAR POR EL TÍTULO DE INGENIERO DE SISTEMAS

ASESORES:
SAMANTHA LÓPEZ
DANIEL SUBAUSTE
JAVIER LACHERRE
EDUARDO MENDÍVIL

Lima, marzo de 2017

 DEDICATORIA
A nuestros familiares y amigos, por el soporte, apoyo y paciencia durante
este periodo, y por no dejar de creer en nuestras competencias para alcanzar
los resultados.

2
 AGRADECIMIENTOS

A los profesores y compañeros, por su asesoría y orientación durante las diferentes etapas
académicas, y a la UPC por darnos herramientas y valores para ser mejores profesionales y
personas.

3
 RESUMEN

El presente trabajo profesional plantea una propuesta de arquitectura empresarial para uno de
los procesos críticos del BBVA Continental, empresa líder del sistema financiero peruano.

El BBVA Continental tiene objetivos estratégicos retadores para los próximos años, los
cuales apuntan a realizar cambios disruptivos en la manera que entregan la experiencia a sus
clientes durante los diferentes puntos de contacto. Bajo este contexto, es que nace la
necesidad de transformar el proceso de venta de productos financieros en agencias, el cual
más allá de mejoras puntales, no ha sufrido cambios que apalanquen fuertemente mayores
ingresos para la organización.

Por otro lado, otro punto importante del que parte esta iniciativa, es que a pesar de los
esfuerzos de la organización porque los clientes cuenten con canales alternativos a las
agencias para que realicen sus operaciones, en la actualidad no ha podido reducir
considerablemente el número de clientes o no clientes que visitan, por ello existe la necesidad
de aprovechar este flujo constante de manera que agregue valor y sume a los ingresos de la
organización.

Proponer una arquitectura empresarial para gestionar la venta proactiva en agencias,

aprovechando las capacidades actuales de la organización bajo un marco de trabajo
estructurado y alineada a los objetivos estratégicos, con el fin de que sea implementada en el
futuro, es el objetivo central considerado en este trabajo. Asimismo, de manera específica se
analizará la situación actual de la arquitectura empresarial del proceso en investigación,
identificarán las brechas entre la situación actual y propuesta, y se presenta un modelo de
desarrollo de software que permite responder a los cambios rápidamente, mejorando así el
time-to-market de la organización.

Al describir a la organización en el primer capítulo, se identifican los principales

componentes del plan estratégico de la empresa desde la misión y visión, hasta los objetivos
estratégicos, claves para la definición de la propuesta. Así es que en el segundo capítulo, al
desarrollar la arquitectura empresarial, bajo el marco de trabajo TOGAF, se obtienen 18

4
brechas en los diferentes dominios, las cuales son resueltas principalmente por un proyecto de
software denominado Gestor Móvil.

Para el proyecto en mención, en el tercer capítulo, se realizó un análisis del entorno y grupo
de trabajo para la adopción de un nuevo método de desarrollo, luego de esto se define utilizar
el framework SCRUM, y bajo tal es que se presenta una dinámica de trabajo que consiste en
ejecutar seis ciclos de desarrollo para ir brindando entregables paulatinos con valor agregado
de cara al cliente interno, además de diferenciar la propuesta en el uso de job stories, demos
streaming y una planificación trimestral general.

El cuarto capítulo, se investiga la gestión de servicios de TI, se analizan cinco procesos

basados en el marco ITIL tanto a nivel del servicio generado por el desarrollo, como a nivel
de procedimientos generales para la organización. Por otro lado, en el quinto capítulo se
integra y da forma a la propuesta, relacionando los diferentes elementos revisados en
capítulos previos.

Finalmente, se brindarán algunas conclusiones que servirán como colofón al documento y

que responderán a los principales hallazgos producto de la investigación.

5
ÍNDICE

INTRODUCCIÓN ................................................................................................................... 14
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS ...................................................................... 17
MARCO TEÓRICO............................................................................................................. 17
ARQUITECTURA EMPRESARIAL (AE) ..................................................................... 17
TOGAF® – THE OPEN GROUP ARCHITECTURE FRAMEWORK ......................... 20
MODELOS PRESCRIPTIVOS DE DESARROLLO ..................................................... 25
MODELOS ÁGILES DE DESARROLLO ..................................................................... 28
GESTIÓN DE SERVICIOS EN TI - ITIL ...................................................................... 38
OBJETO DE ESTUDIO ...................................................................................................... 47
ORGANIZACIÓN OBJETIVO ....................................................................................... 47
OBJETIVOS ESTRATÉGICOS ...................................................................................... 49
ORGANIGRAMA ........................................................................................................... 50
ALCANCE DEL PROYECTO ........................................................................................ 51
OBJETIVOS DEL PROYECTO ..................................................................................... 52
BENEFICIOS DEL PROYECTO.................................................................................... 53
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL ............................................................. 54
INTRODUCCIÓN ............................................................................................................... 54
ALCANCE ........................................................................................................................... 54
PRELIMINAR ..................................................................................................................... 56
Principios de Arquitectura ............................................................................................... 56
Petición de Trabajo de la Arquitectura ............................................................................ 68
VISIÓN DE LA ARQUITECTURA ................................................................................... 77
Declaración de Trabajo de Arquitectura .......................................................................... 77
ARQUITECTURAS (AS IS / TO BE) ................................................................................ 91
ARQUITECTURA AS-IS ............................................................................................... 91
FUNDAMENTACIÓN Y JUSTIFICACIÓN DE LA ARQUITECTURA PROPUESTA
........................................................................................................................................ 108

6
 ARQUITECTURA TO-BE ............................................................................................ 109
ANÁLISIS DE BRECHAS................................................................................................ 125
EVALUACIÓN DE IMPACTO ........................................................................................ 134
OPORTUNIDADES Y SOLUCIONES ............................................................................ 136
CONCLUSIONES ............................................................................................................. 139
CAPÍTULO 3. MÉTODOS ÁGILES PARA EL DESARROLLO DE SOFTWARE .......... 140
INTRODUCCIÓN ............................................................................................................. 140
OBJETIVOS ...................................................................................................................... 140
Objetivo general ............................................................................................................. 140
Objetivos específicos ..................................................................................................... 141
IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES ........................................... 141
DIAGNÓSTICO DEL GRUPO ......................................................................................... 143
COMPOSICIÓN DE LOS GRUPOS DE TRABAJO ....................................................... 145
IDENTIFICACIÓN DE LAS DINÁMICAS Y DEFINICIÓN DE LAS HERRAMIENTAS
A UTILIZAR ..................................................................................................................... 153
Herramientas Ágiles....................................................................................................... 153
CRONOGRAMA TENTATIVO TRABAJO .................................................................... 190
CONCLUSIONES ............................................................................................................. 191
CAPÍTULO 4. GESTIÓN DE SERVICIOS EN TI............................................................... 193
INTRODUCCIÓN ............................................................................................................. 193
EVALUACIÓN ESTRATÉGICA ..................................................................................... 193
Estrategia de Negocio .................................................................................................... 193
Estrategia de TI .............................................................................................................. 195
PLANIFICACIÓN ESTRATÉGICA ................................................................................ 198
SERVICIOS INTERNOS, EXTERNOS Y DE SOPORTE .......................................... 198
REQUERIMIENTO DEL SERVICIO IDENTIFICADO ............................................. 209
EVALUACIÓN FINANCIERA .................................................................................... 211
EVALUACIÓN DE RIESGOS ..................................................................................... 214
DISEÑO DEL SERVICIO ............................................................................................. 215
TRANSICIÓN DEL SERVICIO ................................................................................... 219
PROCESOS ITIL ............................................................................................................... 221
PROCESO DE GESTIÓN DEL PORTAFOLIO DEL SERVICIO .............................. 221

7
 PROCESO DE GESTIÓN DEL NIVEL DEL SERVICIO ........................................... 232
PROCESO GESTIÓN DE CAMBIOS .......................................................................... 241
PROCESO ACTIVOS DEL SERVICIO Y GESTIÓN DE LA CONFIGURACIÓN .. 248
PROCESO DE GESTIÓN DE INCIDENTES .............................................................. 257
CONCLUSIONES ............................................................................................................. 266
CAPÍTULO 5: ESTRUCTURA PROPUESTA .................................................................... 267
INTRODUCCIÓN ............................................................................................................. 267
ELEMENTOS A CONSIDERAR ..................................................................................... 267
ORGANIZACIÓN OBJETIVO ..................................................................................... 268
ARQUITECTURA EMPRESARIAL ............................................................................ 269
MÉTODOS ÁGILES PARA EL DESARROLLO ........................................................ 270
GESTIÓN DE SERVICIOS DE TI ............................................................................... 271
DIAGRAMA DE RELACIÓN ENTRE ELEMENTOS ................................................... 272
CONCLUSIONES ............................................................................................................. 275
CONCLUSIONES ................................................................................................................. 277
GLOSARIO DE TÉRMINOS................................................................................................ 279
SIGLARIO ............................................................................................................................. 283
ANEXOS ............................................................................................................................... 289

8
Índice de tablas

Tabla 1: Principales Frameworks Arquitectura Empresarial ................................................... 19

Tabla 2: Dominios de la Arquitectura Empresarial ................................................................. 19
Tabla 3: Objetivos estratégicos ................................................................................................ 49
Tabla 4: Matriz de objetivos versus macroprocesos ................................................................ 50
Tabla 5: Periodos de revisión de iniciativas y proyectos ......................................................... 69
Tabla 6: FODA general BBVA Continental ............................................................................ 74
Tabla 7: Actividades procedimiento de cambios al alcance proyecto de arquitectura ............ 79
Tabla 8: Roles procedimiento de cambios al alcance proyecto de arquitectura ...................... 80
Tabla 9: Roles, responsabilidades y entregables del proyecto de arquitectura ........................ 84
Tabla 10: Criterios de aceptación de arquitectura empresarial ................................................ 85
Tabla 11: Listado y análisis de interesados.............................................................................. 89
Tabla 12: RACI Diagrama de actividades AS-IS .................................................................... 95
Tabla 13: Descripción modelo de datos físico ......................................................................... 98
Tabla 14: Descripción Aplicaciones ...................................................................................... 102
Tabla 15: Componentes de tecnología y aplicaciones AS-IS ................................................ 104
Tabla 16: Plataforma de Tecnología y Descomposición AS-IS ............................................ 105
Tabla 17: Ambientes y Ubicaciones de Tecnología AS-IS ................................................... 106
Tabla 18: RACI Diagrama de Actividades TO-BE ............................................................... 112
Tabla 19: Descripción modelo de datos físico proceso seleccionado TO-BE ....................... 115
Tabla 20: Descripción aplicaciones proceso seleccionado TO-BE ....................................... 119
Tabla 21: Componentes de tecnología y aplicaciones TO-BE .............................................. 122
Tabla 22: Plataforma de Tecnología y Descomposición TO-BE........................................... 123
Tabla 23: Ambientes y Ubicaciones de Tecnología TO-BE .................................................. 124
Tabla 24: Matriz de Riesgos Identificados ............................................................................ 135
Tabla 25: Cuadro resumen plan de migración ....................................................................... 137
Tabla 26: Cuadro Debilidad – Problema – Acción ................................................................ 145
Tabla 27: Composición Roles Grupo Trabajo ....................................................................... 149

9
Tabla 28: Costeo grupo de trabajo ......................................................................................... 150
Tabla 29: Product Backlog..................................................................................................... 163
Tabla 30: Servicios de negocio ofrecidos .............................................................................. 195
Tabla 31: Servicios Identificados........................................................................................... 196
Tabla 32: Priorización estratégica .......................................................................................... 197
Tabla 33: Ficha de Alcance de Servicio Gestor Móvil .......................................................... 211
Tabla 34: Flujo económico Gestor Móvil .............................................................................. 212
Tabla 35: VAN Gestor Móvil ................................................................................................ 213
Tabla 36: TIR Gestor Móvil .................................................................................................. 213
Tabla 37: Evaluación de Riesgos Gestor Móvil .................................................................... 214
Tabla 38: Objetivos estratégicos BBVA (propuesta)............................................................. 269
Tabla 39: Piloto beneficios económicos ................................................................................ 274
Tabla 40: Cálculo beneficios económicos esperados............................................................. 275

10
Índice de figuras

Ilustración 1: El Ciclo del Método del Desarrollo de la Arquitectura ..................................... 21

Ilustración 2: Fases Modelo Desarrollo Cascada ..................................................................... 27
Ilustración 3: Fases Modelo Desarrollo Incremental ............................................................... 28
Ilustración 4: Comparativo resultados Modelo Ágil vs Cascada ............................................. 31
Ilustración 5: Flujo de Trabajo Programación Extrema ........................................................... 32
Ilustración 6: Proceso desarrollo con Scrum ........................................................................... 34
Ilustración 7: Marco Cynefin ................................................................................................... 36
Ilustración 8: Gestión de Servicios en TI ................................................................................. 40
Ilustración 9: Macroprocesos BBVA ....................................................................................... 48
Ilustración 10: Organigrama BBVA ........................................................................................ 51
Ilustración 11: Oficinas BBVA en Lima ................................................................................. 71
Ilustración 12: Oficinas BBVA en provincias ......................................................................... 72
Ilustración 13: Participación BBVA en sistema financiero ..................................................... 72
Ilustración 14: Participación de mercado por tipo de crédito .................................................. 73
Ilustración 15: Procedimiento de cambios al alcance .............................................................. 78
Ilustración 16: Cronograma propuesta de arquitectura empresarial ........................................ 87
Ilustración 17: Diagrama de actividades AS-IS proceso venta en agencias ............................ 94
Ilustración 18: Modelo de datos físico proceso seleccionado AS-IS ....................................... 97
Ilustración 19: Matriz de datos vs procesos de negocio .......................................................... 99
Ilustración 20: Diagrama de Aplicaciones ............................................................................. 101
Ilustración 21: Matriz aplicaciones versus macroprocesos AS-IS ......................................... 103
Ilustración 22: Mapa BBVA Ambientes y Ubicaciones ........................................................ 106
Ilustración 23: Diagrama de Comunicaciones Físicas - AS-IS .............................................. 107
Ilustración 24: Diagrama de actividades TO-BE proceso venta en agencias ........................ 111
Ilustración 25: Modelo de datos físico proceso seleccionado TO-BE ................................... 114
Ilustración 26: Matriz de datos TO-BE vs procesos de negocio ............................................ 116
Ilustración 27: Diagrama de aplicaciones TO-BE ................................................................. 117

11
Ilustración 28: Matriz aplicaciones versus macroprocesos TO-BE ....................................... 120
Ilustración 29: Diagrama de Comunicaciones Físicas – TO-BE ........................................... 124
Ilustración 30: Análisis brechas procesos de negocio AS-IS vs TO-BE ............................... 125
Ilustración 31: Análisis brechas arquitectura de datos AS-IS vs TO-BE .............................. 128
Ilustración 32: Análisis brechas arquitectura de aplicaciones AS-IS vs TO-BE ................... 130
Ilustración 33: Análisis brechas arquitectura tecnológica AS-IS vs TO-BE ......................... 132
Ilustración 34: Matriz de Probabilidad e Impacto .................................................................. 134
Ilustración 35: Escalas de Probabilidad e Impacto ................................................................ 134
Ilustración 36: Importancia de los Riesgos ............................................................................ 135
Ilustración 37: EDT................................................................................................................ 136
Ilustración 38: Diagrama de Beneficios ................................................................................. 138
Ilustración 39: Applicaciòn Agile Planning ........................................................................... 154
Ilustración 40: Sprint 0........................................................................................................... 165
Ilustración 41: Sprint Backlog Del Sprint 0 ........................................................................... 166
Ilustración 42: Sprint 1........................................................................................................... 167
Ilustración 43: Sprint Backlog del Sprint 1............................................................................ 168
Ilustración 44: Tablero Scrum del Sprint 0 ............................................................................ 172
Ilustración 45: Tablero Scrum del Sprint 1 ............................................................................ 174
Ilustración 46: Tablero Scrum ............................................................................................... 176
Ilustración 47: Modelo BurnDown ........................................................................................ 177
Ilustración 48: BurnDown Propuesto..................................................................................... 178
Ilustración 49: Streaming ....................................................................................................... 182
Ilustración 50: Dinámica de Retrospectiva ............................................................................ 184
Ilustración 51: Dinámica de Retrospectiva 2 ......................................................................... 187
Ilustración 52: Diagrama de Flujo del Proceso de Gestión de Portafolio de Servicio ........... 231
Ilustración 53: Diagrama de Flujo del Proceso de Gestión de Nivel de Servicio .................. 233
Ilustración 54: Diagrama de Flujo del Proceso de Gestión de Cambios................................ 242
Ilustración 55: Sistema CA Service Desk Manager ............................................................... 247
Ilustración 56: Diagrama del Proceso de Activos del Servicio y Gestión de Configuración 250
Ilustración 57: Diagrama de Infraestructura Propuesta BBVA ............................................. 255
Ilustración 58: Lista de CI's de Software ............................................................................... 256
Ilustración 59: Lista de CI's de Hardware .............................................................................. 256

12
Ilustración 60: Diagrama de Flujo del Proceso de Gestión de Incidentes ............................. 259
Ilustración 61: Elementos utilizados en la propuesta ............................................................. 268
Ilustración 62: Diagrama de relación entre elementos de la propuesta ................................. 272

13
INTRODUCCIÓN

La actualidad plantea a las organizaciones nuevos retos de cara al futuro, reinventarse y

adaptarse rápidamente a los cambios de las necesidades de sus clientes y entorno no es una
decisión opcional, sino una realidad en la cual desarrollan sus negocios. El BBVA no es
ajeno a esta realidad, como organización global, y líder en el sistema financiero, ha estado
liderando diferentes cambios durante los últimos años para convertirse en una organización
más eficiente y orientada al cliente.

Así, en los últimos años, se inició con proyectos de Lean Manufacturing a través de los cuales
se buscaba reducir los desperdicios en los procesos, haciéndolos más simples y livianos de
cara al cliente; posteriormente, vino la modernización de las agencias, el desarrollo de nuevos
productos y alianzas con otros socios estratégicos, lo que permitió un nuevo posicionamiento
en la mente de los consumidores; y hoy el foco está en convertir al BBVA Continental en un
banco digital, haciendo que la tecnología esté presente en todos sus procesos críticos de cara
al cliente, incrementando la conveniencia y agilidad.

En este contexto es que se desarrolla el presente trabajo profesional, para el cual se tomó uno
de los procesos tácticos con mayor impacto en los objetivos estratégicos, y la gestión de las
colocaciones; y luego de identificar cuáles eran los canales que lo ejecutaban de cara al
cliente con mayores oportunidades desde el punto de vista tecnológico, fue que se seleccionó
el subproceso de venta en las agencias, con foco en la contratación sencilla de productos de
venta corta (tarjetas y préstamos personales).

El proceso en mención, a pesar de todos los cambios en la organización, no ha sufrido

mayores variaciones en el tiempo; en el fondo, más allá de las herramientas, sigue siendo un
proceso reactivo y pasivo, que sigue haciendo de las agencias un lugar para principalmente
transaccionar.

Una propuesta de arquitectura, que transforme este proceso, para generar uno alternativo que
agregue valor a los Ejecutivos y clientes, debe considerar el entorno antes mencionado. Por

14
ello, la finalidad de este trabajo es proponer una arquitectura empresarial para la gestión de
venta proactiva en agencias, que permita contextualizar las ofertas de productos financieros a
través de las visitas de los clientes en las agencias; en caso se realice, la implementación de
este nuevo proceso, que complementa y reinventa el proceso actual, debe considerar la
necesidad de salir al mercado rápidamente, por ello también se propondrá métodos de
desarrollo ágiles a fin de generar entregables en corto tiempo. Por otro lado, la propuesta
también abarcará el soporte de servicios de TI, basados en las buenas prácticas de ITIL.

El presente documento está organizado por capítulos, en el primero se describen los

fundamentos teóricos, principales fuentes de conocimiento académico-profesional que
permitió realizar la investigación; y la organización objetivo, el BBVA Continental. En el
segundo se aborda todo lo referido a la arquitectura empresarial en las siguientes fases:
Preliminar, Visión de la Arquitectura, Arquitectura de Negocio, Arquitectura de Sistemas,
Arquitectura Tecnológica y Oportunidades y Soluciones; desde la presentación de la
arquitectura de la línea base o AS-IS, hasta la arquitectura destino o TO-BE, identificando
cuáles son las brechas entre ambas y las iniciativas o proyectos necesarios para su
implementación.

En el tercero, se realiza la evaluación y análisis para proponer un método ágil de desarrollo

para construir el software propuesto como proyecto en las brechas mencionadas en el capítulo
anterior, para ello se profundiza en los en las fortalezas y debilidades de la organización, un
diagnóstico del grupo de trabajo, así como la definición de las dinámicas y herramientas
consideradas para ejecutar de la mejor manera el proyecto.

En el cuarto capítulo, se realiza un análisis del entorno interno y externo basado en ITIL para
determinar el estado actual de la organización y establecer las recomendaciones que debe
tomar en cuenta para mejorar los servicios prestados por el área Digital. Asimismo, se detalla
el portafolio de servicios ofrecidos y los términos y condiciones de nivel de servicios
ofrecidos para el proceso de gestión de colocaciones del Banco.

Finalmente, en el quinto capítulo se presenta la propuesta de solución integrada para cubrir

las brechas encontradas, haciendo uso de todos los conocimientos adquiridos en el presente

15
trabajo; además de conclusiones y recomendaciones del desarrollo del presente trabajo
profesional.

16
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS

MARCO TEÓRICO
La presente sección tiene como finalidad describir los fundamentos académicos y
profesionales utilizados para preparar la propuesta de arquitectura. Inicialmente, se
presentarán conceptos relacionados al marco de trabajo de arquitectura empresarial utilizado,
TOGAF, su evolución y aplicación.

Así, el estándar ISO/TEC 42010:2010, define que una arquitectura como “la organización
fundamental de un sistema, compuesta por sus componentes, las relaciones entre ellos y su
entorno, así como los principios que gobierna su diseño y evolución”. Este concepto es clave
para entender cómo se desarrollará la propuesta de arquitectura empresarial en el presente
trabajo.

ARQUITECTURA EMPRESARIAL (AE)

Existen diferentes conceptos relacionados a la Arquitectura Empresarial, Gartner Group por
ejemplo la define como: “…el proceso de traducir la visión de negocio y la estrategia en un
cambio efectivo de la empresa para crear, comunicar y mejorar los principios y modelos
clave que describen el estado futuro de la empresa y permiten su evolución…”1. Por otro
lado, Lankhorst et al., presenta una definición que se acerca a la anterior y también permite
entender su significancia: “La arquitectura empresarial es un conjunto coherente de
principios, métodos y modelos que se utilizan en el diseño y la realización a nivel empresarial
de la estructura organizacional, los procesos de negocio, los sistemas de información y la
infraestructura”.

Sin embargo, más allá de los conceptos, quien da origen a la Arquitectura Empresarial como
tal, fue J. Zachman en una publicación en el diario IBM Systems en 1987 titulada “A

1
[5] Gartner 2016

17
framework for Information Systems Architecture”, donde menciona los desafíos que
representaba gestionar el incremento de sistemas de información. Según señala, la
dependencia de las empresas hacia los sistemas requería de disciplina y enfoque adecuados
para poder administrarla. Pasaron los años, y fue el Departamento de Defensa de los Estados
Unidos, uno de los primeros que tomó estas ideas y lo convirtió en un marco de trabajo en
1994, el cual fue llamado “Technical Architecture Framework for Information
Management”, el objetivo inicial era simple, poder ejecutar proyectos de manera más
eficiente alineados a las necesidades de la organización. Posteriormente, vinieron
actualizaciones y nuevos frameworks que se detallaran en los siguientes párrafos.

Es importante que antes de mencionar los diferentes frameworks de AE, se entienda qué son,
también llamados marcos de trabajo, en este contexto se podrían definir como la estructura
que permite almacenar y comunicar los diferentes elementos de la arquitectura de empresa
(González, Bas, & García, 2005). También se presentan como una estructura lógica para
clasificar y organizar las representaciones descriptivas de una empresa, las cuales son
significativas tanto para la dirección y control de la organización, como para el desarrollo de
sus sistemas de información (Zachman, 1987). 2

La siguiente tabla presenta los frameworks de AE más difundidos:

Framework Nombre Referencia

ZACHMAN Zachman Framework for Enterprise http://www.zifa.com/

Architecture

TOGAF The Open Group Architecture http://www.opengroup.org/togaf/

Framework

2
[30] Cfr. ARANGO, LONDOÑO y ZAPATA 2010

18
Framework Nombre Referencia

E2AF Extended Enterprise Architecture http://www.enterprise-

Framework architecture.info/

GEAF Gartner Enterprise Architecture http://www.gartner.com

Framework

FEAF Federal Enterprise Architecture http://www.cio.gov

Framework US.

Tabla 1: Principales Frameworks Arquitectura Empresarial

Fuente: http://www.scielo.org.co/pdf/rium/v9n16/v9n16a09.pdf

Los diferentes frameworks representan la arquitectura a través de dimensiones o perspectivas

que corresponden a los componentes principales de la organización.

ARQUITECTURA DE NEGOCIO

ARQUITECTURA DE INFORMACIÓN

ARQUITECTURA DE SISTEMAS

ARQUITECTURA TECNOLÓGICA

Tabla 2: Dominios de la Arquitectura Empresarial

Fuente: http://www.scielo.org.co/pdf/rium/v9n16/v9n16a09.pdf

La arquitectura de negocio, señalan los expertos, viene a ser el más importante de los
dominios. Su input principal vendría a ser el plan estratégico de la organización, los
lineamientos, valores, misión, visión y objetivos. Bajo esta perspectiva, se deben describir
los macroprocesos de negocio, y la relación con los diferentes actores del proceso y los
productos y servicios que se generan. La búsqueda de procesos con óptimos indicadores de
desempeño alineados a la estrategia de la organización es la clave de esta arquitectura.

19
La arquitectura de información, presenta el activo más importante de la organización, la
información; describe los activos lógicos y físicos de los datos, y cómo están siendo
utilizados estos recursos. El objetivo de esta arquitectura, radica principalmente, en garantizar
la calidad de los datos, y poder contar con información precisa y oportuna cuando así se
requiera, asimismo debe facilitar la gestión del conocimiento en la organización.

La arquitectura de sistemas, incorpora las diferentes aplicaciones que dan soporte al negocio,
e identifica aquellos componentes o servicios que puedan ser reutilizados de acuerdo a las
necesidades. En esta arquitectura, es importante definir la criticidad de las aplicaciones para
la organización, y en qué procesos participan.

Finalmente, la arquitectura tecnológica, define los componentes involucrados en la

infraestructura de la organización, así como las plataformas y bases de datos que deben dar
soporte a las soluciones de negocio (descritas en la arquitectura de sistemas). Asimismo, debe
considerar los mecanismos de comunicación, redes, centros de procesamiento y servicios
integrados de la tecnología.

TOGAF® – THE OPEN GROUP ARCHITECTURE FRAMEWORK

Para el presente trabajo, se tendrá como referencia el marco de trabajo TOGAF®, el cual es
desarrollado y mantenido por el Foro de Arquitectura de The Open Group. La primera
versión de este framework fue desarrollada en 1995, y a la fecha de presentación de este
trabajo se encuentra en la versión 9.1, la que puede ser consultada en su sitio web, donde
albergan todas las versiones desde su fundación.

Este es un marco de referencia de arquitectura, una herramienta para asistir en la aceptación,

creación, uso y mantenimiento de arquitecturas, el cual está basado en un modelo iterativo de
procesos apoyado por las mejores prácticas y un conjunto reutilizable de activos
arquitectónicos existentes (Togaf® Versión 9.1, Guía de Bolsillo).

TOGAF cubre las dimensiones de arquitectura mencionadas en párrafos anteriores, aunque es

usual que la arquitectura de información, se nombre como arquitectura de datos en este
framework.

20
TOGAF se basa en un enfoque incremental para el desarrollo de una AE y utiliza el Método
de Desarrollo de la Arquitectura (ADM), la cual cuenta con varias fases que se desplazan
iterativamente a través de una serie de perspectivas. A continuación se presentan las fases
principales del ADM.

Ilustración 1: El Ciclo del Método del Desarrollo de la Arquitectura

Fuente: Togaf® Versión 9.1, Guía de Bolsillo

La siguiente descripción de las fases presentadas en la ilustración, ha sido tomada del

documento Togaf® Versión 9.1, Guía de Bolsillo3:

Fase Preliminar

3
[7] The Open Group 2013

21
Prepara una organización para emprender proyectos de Arquitectura Empresarial de manera
exitosa. Su objetivo es el de determinar las Capacidades Arquitectónicas deseadas por la
organización. Entre sus salidas principales está la Petición de Trabajo de Arquitectura.

Fase A: Visión de la Arquitectura

Esta fase aborda el establecimiento del proyecto e inicia una iteración del ciclo de desarrollo
de la arquitectura, estableciendo el alcance, limitaciones y expectativas de la iteración. Se
validará el contexto del negocio y como salida se tiene la Declaración de Trabajo de la
Arquitectura aprobada.

Fase B: Arquitectura de Negocio

Aborda el desarrollo de una Arquitectura de Negocio que apoye la Visión de la Arquitectura

y las preocupaciones de los interesados. Entre sus objetivos está desarrollar la arquitectura
destino describiendo cómo debe operar la empresa para alcanzar los objetivos de negocio,
asimismo identificar los componentes candidatos para el Plan de Itinerario de Arquitectura
basándose en las brechas identificadas entre la línea base y destino. Se genera una versión
preliminar del Documento de Definición de la Arquitectura.

Fase C: Arquitectura de Sistemas de Información

Aborda la documentación de la organización fundamental de los sistemas de TI de una

empresa, representada por los principales tipos de sistema de información y aplicaciones que
los utilizan. En esta fase se verifica la Arquitectura de Datos y la Arquitectura de Aplicación.
Se actualiza el Documento de Definición de la Arquitectura. Al igual que en la Arquitectura
de Negocio, se debe identificar la arquitectura destino y brechas.

22
Fase D: Arquitectura Tecnológica

Aborda la documentación de la organización esencial en lo correspondiente a hardware,

software y comunicaciones. Actualiza el Documento de Definición de la Arquitectura.

Fase E: Oportunidades y Soluciones

Esta es la primera fase que directamente se refiere a la implementación. Describe el proceso

de identificación de medios de entrega (portafolio de proyectos o programas) que
proporcionan la Arquitectura de Destino identificada en las fases anteriores. Se busca generar
el Plan de Itinerario de Arquitectura o Plan de Migración, basado en el análisis de las brechas
de cada una de los dominios de arquitecturas revisados.

Fase F: Planificación de la migración

Aborda cómo debe moverse desde la Arquitectura de la Línea Base a la Arquitectura de

Destino finalizando un Plan de Implementación y Migración a detalle. En esta fase se busca
asegurar que el valor del negocio y los costos de los paquetes de trabajo y arquitecturas de
transición sean entendidos por los interesados; asimismo el alineamiento del plan en mención
al enfoque de la empresa para la gestión e implementación de cambios organizacionales.

Fase G: Gobierno de la Implementación

Define cómo la arquitectura delimita los proyectos de implementación, la supervisa al mismo

que se le construye, produciendo un Contrato de Arquitectura firmado. Uno de los objetivos
que resalta, es el de asegurar la conformidad con la arquitectura destino a través de los
proyectos de implementación definidos; asimismo, realizar las funciones de gobierno
necesarias para la solución y las solicitudes de Cambio de la Arquitectura impulsadas por la
implementación.

23
Fase G: Gestión de Cambios de la Arquitectura

Esta fase debe asegurar que los cambios en la arquitectura se gestionen de manera controlada.
Como salidas puede generar actualizaciones en los diferentes entregables de las fases.

Gestión de requerimientos

Como se puede apreciar en la ilustración, se relaciona con todas las fases del ADM. Es un
proceso dinámico que aborda la identificación de las necesidades de la empresa,
almacenándolos y gestionándolos en las entradas y salidas de las fases. La capacidad de hacer
cambios a los requerimientos es crucial para el proceso de ADM, dado que por la naturaleza
de la arquitectura, la incertidumbre y el cambio están siempre presentes.

Como referencia se ha incluido en el Anexo 4 una tabla que relaciona los entregables con vs
las fases.

24
MODELOS PRESCRIPTIVOS DE DESARROLLO
Para comenzar a definir los modelos prescriptivos y, en general, las siguientes secciones
donde se mencionarán temas relacionadas al proceso de desarrollo de software, es necesario
que se realicen algunas definiciones previas respecto a este concepto.

Para comenzar, es necesario definir qué es el software, para ello la IEEE4 brinda una de las
definiciones que podrían considerarse más acertadas en el estándar 729: “es el conjunto de
los programas de cómputo, procedimientos, reglas, documentación y datos asociados, que
forman parte de las operaciones de un sistema de computación”. Tomando este concepto,
queda claro que se mencionan diversos componentes lógicos, intangibles, los cuales deben
ser desarrollados o construidos.

De acuerdo a la norma ISO 90015, un proceso es un “conjunto de actividades relacionadas o

que interactúan, las cuales transforman elementos de entrada en resultados”, la construcción
de software es un proceso, y como tal se enmarca en esta definición; es por ello que durante
años muchas organizaciones o personas han buscado hacer de este proceso, uno mejor, lo
cual se evidencia en la diferente literatura que se puede encontrar al respecto.

Roger S. Pressman6, en “Ingeniería de Software, Un enfoque práctico”, señala que un proceso

de software es un marco de trabajo para las tareas que se requieren para poder construir un
software de alta calidad. Adicionalmente, se indican cinco grandes actividades que se pueden
aplicar de manera genérica:

Comunicación: colaboración y comunicación con los clientes.

Planeación: define las tareas a realizarse, riesgos, recursos y entregables.

Modelado: creación de modelos o plantillas que permitan comprender adecuadamente los

requerimientos.

4
www.ieee.org
5
www.iso.org
6
[15] PRESSMAN 2005

25
Construcción: generación de código y realización de pruebas para detectar errores.

Despliegue: entrega al cliente del producto total o incremental.

Y así es que se llega a los modelos de proceso, y hubo algunos que han ido intentando
resolver el caos alrededor del desarrollo de software, estos fueron los llamados Modelos
Prescriptivos. Se propuso este nombre, porque prescriben un conjunto de elementos
necesarios para llevar a cabo el proceso de desarrollo, asimismo se define un flujo del trabajo
a través del cual los diferentes componentes interactúan entre sí.

Si bien las estructuras alrededor de estos modelos han otorgado una base razonable sobre la
cual se pueden gestionar los proyectos de software, como indica Nogueira, J., C. Jones y Luqi
aún se está al borde del caos7.

Entre los modelos prescriptivos más conocidos y que destacan están el modelo en cascada y
el modelo incremental:

Modelo en cascada
De los primeros en ser definidos, se caracteriza por contar con un modelo secuencial de
actividades. Fue introducido en un primer momento por el Dr. Winston W. Royce en los años
70s, por lo que si bien ha sido muy aceptado durante mucho tiempo, aunque posteriormente
se han ido generando críticas relacionadas con su eficacia, básicamente por lo siguiente según
Pressman:

 Es raro que proyectos reales sigan el flujo secuencial planteado.

 Para el cliente es difícil establecer todos los requisitos de manera explícita.

 La paciencia es crítica, se requiere de un buen avance para recién obtener resultados

tangibles.

7
Cfr [15] PRESSMAN 2005

26
En complemento a lo indicado, autores que documentan el modelo ágil, que será revisado
posteriormente, también mencionan algunos puntos relacionados, así en Diseño Ágil con
TDD, Carlos Ble Jurado menciona que, este modelo se basa en el ciclo convencional de
ingeniería y que solo se debe seguir una secuencia de fases8. Por otro lado, en Flexibilidad
con Scrum, de Juan Palacio, se menciona que los desarrollos secuenciales puros suelen ser
más teóricos que prácticos, y que lo que sucede en la realidad es que las fases se terminan
solapando, es decir que una fase puede comenzar sin que la anterior haya concluido9.

En general, los diferentes autores coinciden en que se trata de un modelo sencillo, que puede
ser útil si se presentan requerimientos fijos; sino en ciertos puntos podrían darse estados de
bloqueo.

Ilustración 2: Fases Modelo Desarrollo Cascada

Fuente: https://upload.wikimedia.org/

Modelo incremental
Este modelo combina elementos del modelo en cascada de forma iterativa, es decir de manera
formal traslapa las distintas fases que se presentan, presentando incrementos paulatinos al
software.

Por lo general, cuando se desarrolla bajo este modelo, se busca que los primeros
“incrementos” incorporen los requerimientos básicos, para luego ir montando funcionalidad
complementaria, también podrían realizarse mejoras sobre las fases anteriores.

8
[23] BLE 2010

27
 Ilustración 3: Fases Modelo Desarrollo Incremental
Fuente: Ingeniería de Software, Un enfoque práctico (Roger S. Pressman)

MODELOS ÁGILES DE DESARROLLO

Standish Group publicó en 1994 el estudio "CHAOS Report"6 donde se encontró los
siguientes indicadores de éxito, tasa de éxito en los proyectos de desarrollo de software en
general10:

 31.1% es cancelado en algún punto durante el desarrollo del mismo

 52.7% es entregado con sobrecostos, en forma tardía o con menos funcionalidades de las
inicialmente acordadas

 16.2% es entregado en tiempo, dentro de los costos y con las funcionalidades

comprometidas

Martín Alaimo, en una investigación para Kleer, señala que a partir de esta publicación, se
generan nuevos modelos intentan resolver esta problemática, donde se muestra como factores

9
[18] PALACIO 2007
10
https://www.infoq.com/articles/standish-chaos-2015

28
críticos el involucramiento del usuario y el empleo de periodos de tiempo más cortos11. Así es
que nacen los modelos en espiral, iterativos y ágiles.

De acuerdo a la Agile Alliance12, a principios del 2001 es que el término ágil, orientado al
desarrollo de software, cobra vida. Fueron 17 profesionales los que se reunieron en Utah para
determinar los valores y principios de software a partir de los cuales los equipos de desarrollo
podrían cumplir de manera más acertada las necesidades del cliente y responder mejor a los
cambios.

De esta reunión es que nace el manifiesto ágil (http://www.agilemanifesto.org) el cual se

compone de 4 valores y 12 principios que a continuación se detallan:

Manifiesto Ágil

Estamos descubriendo mejores formas de desarrollar software tanto por

nuestra propia experiencia como ayudando a terceros.
A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas
Software que trabaja sobre una amplia documentación
Colaboración con el cliente sobre negociación de contratos
Respondiendo al cambio sobre seguir un plan
Es decir, mientras que hay valor en los elementos de la derecha, valoramos
los elementos de la izquierda más.

Los principios que se generaron fueron:

 Nuestra mayor prioridad es satisfacer al cliente a través de entregas tempranas y

frecuentes de software con valor.

 Aceptar el cambio incluso en etapas tardías del desarrollo. Los procesos ágiles
aprovechan los cambios para darle al cliente ventajas competitivas.

 Entregar software funcionando en forma frecuente, desde un par de semanas a un par de

meses, prefiriendo el periodo de tiempo más corto.

11
[17] ALAIMO 2013
12
www.agilealliance.org

29
 Expertos del negocio y desarrolladores deben trabajar juntos diariamente durante la
ejecución del proyecto.

 Construir proyectos en torno a personas motivadas, generándoles el ambiente necesario,

atendiendo sus necesidades y confiando en que ellos van a poder hacer el trabajo.

 La manera más eficiente y efectiva de compartir la información dentro de un equipo de

desarrollo es la conversación cara a cara.

 El software funcionando es la principal métrica de progreso.

 Los procesos ágiles promueven el desarrollo sostenible. Los sponsors, desarrolladores y

usuarios deben poder mantener un ritmo constante indefinidamente.

 La atención continua a la excelencia técnica y buenos diseños incrementan la agilidad.

 La simplicidad –el arte de maximizar la cantidad de trabajo no hecho- es esencial.

 Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto-

organizados.

 A intervalos regulares, el equipo reflexiona acerca de cómo convertirse en más efectivos,

luego mejora y ajusta su comportamiento adecuadamente.

De acuerdo a Pressman, la ingeniería de software ágil combina filosofía y directrices de

desarrollo, mientras la filosofía busca la satisfacción del cliente y la entrega temprana de
software incremental; las directrices resaltan la entrega sobre cualquier otra fase tradicional
de desarrollo. Alistair Cockburn, menciona que los modelos prescriptivos presentados en la
sección anterior no consideran la fragilidad de las personas que construyen el software; por
ello es que métodos o modelos muy estructurados terminan fallando cuando se carece de la
disciplina necesaria para adoptar los componentes definidos13.

Ahora, los modelos ágiles no significan desorden, el autor señala que lo que hacen estos
modelos es agregar una tolerancia realista, lo cual da un mayor y más amplio campo de
acción, haciendo que los equipos de desarrollo se adapten casi naturalmente, haciéndolos
menos dependientes del proceso. Cockburn supone que estas prácticas podría ser menos

13
[16] COCKBURN 2006

30
productivas, sin embargo esta afirmación es debatible, bien llevado podría ser muy eficiente y
con mejores resultados. Adicionalmente, señala que la clave del desarrollo ágil se encuentra
en las personas, y cuales son aquellos talentos y habilidades, por ello el proceso sobre el cual
se soporta se adapta en estas y no al revés.

Al inicio de esta sección se presenta un resumen de una investigación realizada por el

Standish Group en 1994, en el 2015 una nueva publicación permite hacer una comparación
entre el desempeño de un modelo Ágil versus un modelo Cascada:

Ilustración 4: Comparativo resultados Modelo Ágil vs Cascada

Fuente: https://www.infoq.com/articles/standish-chaos-2015

Los resultados de este informe señalan que los modelos Ágiles están teniendo mejores
resultados visibles versus los modelos en Cascada, mucha más notoria en proyectos de
tamaño medio.

Durante este tiempo se han venido generando diferentes modelos ágiles de proceso, algunos
de los cuales serán mencionados a profundidad en el presente trabajo profesional: Extreme
Programming o Programación extrema, Scrum, Desarrollo Adaptativo de Software y Cristal.

31
A continuación se detalla las dos que se consideran más conocidas o relevantes.

Extreme Programming (XP)

Si bien nace en los 80s, la publicación donde mejor se desarrolla este modelo lo escribe Kent
Beck en 1999 con Programming Explained: Embrace Change. Este modelo, como se indica
en la web www.extremeprogramming.org, destaca la satisfacción del cliente, y en lugar de
entregar un paquete completo en una fecha lejana, entrega partes cuando se necesitan.
Adicionalmente, busca mejorar un proyecto a través de cinco maneras esenciales:
comunicación, sencillez, retroalimentación, respeto y valor.

De acuerdo a lo desarrollado por Pressman, actualmente es uno de los procesos ágiles más
utilizados, y se organiza con cuatro actividades como marco de trabajo, planeación, diseño,
codificación y pruebas. A continuación se presenta un gráfico que resume el flujo de trabajo

Ilustración 5: Flujo de Trabajo Programación Extrema

Fuente: Ingeniería de Software, Un enfoque práctico (Roger S. Pressman)

Scrum
En la Guía SBOK (Scrum Body of Knowledge) se detalla brevemente la historia respecto al
nacimiento de Scrum, así fueron Hirotaka Takeuchi y Ikujiro Nonaka quienes definen en los

32
80s una estrategia de desarrollo flexible gestionada a través de un equipo de trabajo que
funciona como una unidad; fue Jeff Sutherland quien aplica este modelo en su empresa en
1993 y posteriormente, junto a Ken Schwaber, publican las prácticas que ejecutaba como
proceso formal en su compañía. Ambos fueron firmantes del Manifiesto Ágil que se incluye
en la sección previa14.

Martin Alaimo15 define a este modelo como un marco de trabajo que encuentra prácticas
emergentes en dominios complejos (ver Cynefin). Asimismo, señala que no se trata de una
metodología, por cuanto tampoco ofrece un proceso completo; lo que ofrece es un contexto
relacional e iterativo, que permita a los involucrados generar un proceso adaptado a las
necesidades, eso sí, brinda una base que debe ser seguida ya que sino no se podría definir
como un proyecto Scrum.

En esta misma entrega, se señalan los valores sobre los que Scrum se soporta y que
constituyen la base que deben seguir:

 Foco: concentración en un grupo de características a la vez.

 Coraje: asumir compromisos desafiantes que permitan crecer.

 Apertura: transparencia y discusión abierta de problemas.

 Compromiso: el control sobre las actividades genera una mayor responsabilidad.

 Respeto: el trabajo conjunto, donde se dan éxitos y fracasos, requiere el fomento del
respeto.

En las secciones del capítulo 3 del presente trabajo profesional se profundiza en varios de los
conceptos principales de Scrum, sin embargo a continuación se brindará algunos
componentes clave para un mejor entendimiento. En la siguiente ilustración se puede
visualizar el proceso macro de Scrum donde se detallará cada elemento que se muestra:

14
[20] SCRUMstudy™ 2016
15
[17] ALAIMO 2013

33
 Ilustración 6: Proceso desarrollo con Scrum
Fuente: https://platzi.com/blog/guia-scrum

En las diferentes literaturas que mencionan a Scrum se definen los roles, elementos y
dinámicas base del marco de trabajo, en realidad no se encuentra mayores diferencias en las
definiciones por lo que bastará mencionar algunas de las características señaladas en la Guía
SBOK.

Roles

Product Ower: Responsable de maximizar el valor de negocio y representante de la voz del

cliente, articula los requisitos y mantiene la justificación del negocio. Puede participar en uno
o más proyectos.

Scrum Master: Facilita e imparte las prácticas de Scrum a todos los miembros del equipo,
además de eliminar cualquier impedimento o circunstancia que afecte el avance. Es distinto al
director o gerente de proyecto, jerárquicamente no es superior a cualquier otro miembro del
equipo. Puede estar en una cartera de proyectos donde interactúe con otros Scrum Master.

Equipo de desarrollo: Es un grupo de personas, que deben comprender los requerimientos,

encargarse de la estimación y de construir los entregables. La clave del equipo de desarrollo
es que sea un grupo auto-organizado como menciona Juan Palacio.

34
Elementos

Product Backlog: Es el inventario de características que el propietario del producto desea

obtener, ordenado por orden de prioridad. Se trata de un documento “vivo”. El responsable de
este elemento es el Product Owner.

Sprint Backlog: Es la lista de trabajos que se realizará durante el Sprint para generar el
incremento del producto. El equipo de desarrollo se compromete a terminarlo de acuerdo a la
estimación.

Dinámicas (se mencionan algunas, ya que se detallan en el capítulo 3)

Sprint: Se refiere a las iteraciones de Scrum, en general se recomienda que tenga una
duración corta, entre 1 y 4 semanas, siendo 2 a 3 semanas lo más habitual según señala
Martín Alaimo. Todos los Sprints de un proyecto deben tener la misma duración, es decir,
una vez establecida no cambia, esto permite mayor ritmo y previsibilidad. La fecha de
entrega no es modificable, lo único que se puede ajustar es el alcance a través de más o
menos PBIs.

Planificación de Sprint: Es una reunión en la cual se generan los acuerdos y compromisos

entre el equipo de desarrollo y Product Owner respecto del alcance Sprint. Usualmente se
divide en dos partes, en la primera se indica el “qué se hará” y en la segunda el “cómo se
hará”.

Como conclusión de las menciones a las teorías predictivas y ágiles, Juan Palacio 16 señala
con acierto algunas diferencias a través de una analogía relacionada con un viaje, y luego
esboza cómo es que no se debe definir a una como buena o como mala. Así por ejemplo, si
para un viaje de negocios se requiere ajuste y previsión, se requerirá un modelo predictivo, si
por el contrario, se trata de un viaje de turismo donde se busca descubrir rutas nuevas, y
cambiar rápidamente debido a las condiciones, se debe gestionar con un modelo adaptable,
como ágil.

16
[18] PALACIO 2007

35
Cynefin
Se trata de un framework que comienza a trabajar Dave Snowden en 1999, en IBM. Ofrece
distintos contextos o escenarios a partir de los cuales se pueden tomar decisiones.

Ilustración 7: Marco Cynefin

Fuente: http://www.martinalaimo.com/es/blog/cynefin

Martin Alaimo, ofrece algunas definiciones prácticas para cada uno de los escenarios en
Proyectos Ágiles con Scrum, basado en la entrega de Snowden & Boone, A Leader’s
Framework for Decision Making17:

Dominio simple: Fácil de identificar causas y sus efectos, la respuesta correcta es clara e
indiscutible. Aquí se encuentran las mejores prácticas, es decir soluciones conocidas. Un
ejemplo de este dominio es la construcción en serie o la instalación de un sistema en clientes
similares.

Dominio complicado: Hay múltiples soluciones correctas para una misma problemática, se
requiere de expertos para poder identificarlas. Problemas de sincronización de semáforos o de
performance de base de datos podrían recaer en este concepto.

Dominio complejo: Los resultados son impredecibles, no existen mejores prácticas

catalogadas para estas situaciones. Al tomar una decisión es necesario, evaluar los resultados

17
Cfr [17] ALAIMO 2013

36
y adaptarse. Requerirá de altos niveles de innovación, comunicación e interacción. Nuevos
productos o la incorporación de nuevas características recaen en este escenario.

Dominio caótico: Requieren de una respuesta inmediata, la situación es de crisis y se debe

restablecer el orden. Se necesita de alguien que tome el control y mover la situación fuera del
caos. Es un escenario de improvisación pura, con poco tiempo para las técnicas. Por ejemplo
la caída del sistema de tarjetas de crédito.

Dominio desordenado: No es posible reconocer en qué dominio se está, es difícil medir la

situación o determinar la forma de actuar, generalmente puede pasar que las personas actúen
en base a preferencias personales, lo que puede conllevar a error.

37
GESTIÓN DE SERVICIOS EN TI - ITIL
La gestión de servicios de tecnologías de la información (en inglés IT Service Management,
ITSM) es una disciplina basada en procesos, enfocada en alinear los servicios de TI
proporcionados con las necesidades de las empresas, poniendo énfasis en los beneficios que
puede percibir el cliente final. GSTI propone cambiar el paradigma de gestión de TI, por una
colección de componentes enfocados en servicios de punta a cabo usando distintos marcos de
trabajo con las "mejores prácticas", como por ejemplo la Information Technology
Infrastructure Library (ITIL) (Wikipedia).

Historia ITIL
En un mundo de constantes cambios y donde el cliente cada vez es más exigente, se han
venido llevando a cabo muchas herramientas, metodologías y buenas prácticas para lograr
mejoras en la organización y obtener una ventaja competitiva en el rubro de la empresa. En el
sector bancario la competencia ha sido veros y con el transcurso de los años el foco a ido
migrando a el área de TI, la cual debe dar soporte a el negocio de la mejor manera.

Las entidades bancarias cada vez dependen más de la las herramientas informáticas para
llevar a cabo su trabajo diario. Este trabajo además está gestionado y controlado a través de
otros sistemas informáticos, pudiendo estar éstos a su vez dentro de una red controlada por
otros sistemas y así sucesivamente. Por tanto la complejidad de estos procesos hizo crecer la
demanda y necesidad de las entidades (públicas o privadas) de disponer de un modelo que les
permitiera gestionar su infraestructura TI más fácilmente y que pudieran dar soporte a los
objetivos de negocio.

ITIL nació en la década de 198018, a través de la Agencia Central de Telecomunicaciones y

Computación del Gobierno Británico (Central Computer and Telecomunications Agency -
CCTA), que ideó y desarrollo una guía para que las oficinas del sector público británico
fueran más eficientes en su trabajo y por tanto se redujeran los costes derivados de los
recursos TI. Sin embargo esta guía demostró ser útil para cualquier organización, pudiendo

18
[30] Biable Management, 2014

38
adaptarse según sus circunstancias y necesidades. De hecho resultó ser tan útil que
actualmente ITIL recoge la gestión de los servicios TI como uno de sus apartados,
habiéndose ampliado el conjunto de “buenas prácticas” a gestión de la seguridad de la
información, gestión de niveles de servicio, perspectiva de negocio, gestión de activos
software y gestión de aplicaciones. Estas buenas prácticas provienen de las mejores
soluciones posibles que diversos expertos han puesto en marcha en sus organizaciones a la
hora de entregar de servicios TI, por lo que en ocasiones el modelo puede carecer de
coherencia.

Librerías de ITIL
IT Infrastructure Library(ITIL) al igual que el PMBOOK es un marco de trabajo que agrupa
las mejores prácticas que se han ido llevando a cabo durante los últimos años pero a
diferencia del PMBOOK no son prácticas referentes a la gestión de proyectos sino a la
gestión de servicios de TI. Como todo marco e trabajo va evolucionando después de cierto
tiempo, para el presente documento la versión a utilizar será la ITIL V3.

19
ITIL intenta respaldar mas no fijar los procesos de negocio de una organización. En este
contexto, la Oficina de Comercio Gubernamental (OGC) no aprueba el término
"Cumplimiento con ITIL". El papel del marco de trabajo de ITIL es describir los enfoques,
las funciones, los roles y procesos en los que las organizaciones pueden basar sus propias
prácticas. El rol de ITIL es brindar orientación en el nivel organizacional más bajo que pueda
aplicarse. Debajo de ese nivel, para implementar ITIL en una organización se requieren los
conocimientos específicos de sus procesos de negocio para ajustar ITIL a fin de lograr una
eficacia óptima.

Como lo menciona la OGC, las librerías de ITIL no pretenden ser un estándar y guía al pie de
la letra para que las empresas lo apliquen y garanticen su correcto funcionamiento, lo más
común es que las empresas adapten los procesos de ITIL a las áreas de TI con un diferente
contexto, pudiendo obviar o aumentar procedimientos que se identifiquen en el camino de la
implementación.

19
[32] IT GOVERNANCE INSTITUTE, 2008

39
A continuación se mostrará la actual biblioteca oficial de ITIL, la cual tiene 5 fases.

Ilustración 8: Gestión de Servicios en TI

Fuente: Fundamentos de ITIL v3

Service Strategy - Estrategia de Servicios (SE)

Es la fase más importante del ciclo de vida del servicio, tiene como principal objetivo lograr
que la Gestión del Servicio sea un activo para el banco.

Diseña el plan de acción que permitirá desarrollar una estrategia en el banco en cuanto a las
Tecnologías de la Información. Se enfoca en las siguientes areas: Estrategia general,
competitividad y posicionamiento de mercado, tipos de proveedores de servicio, gestión del
servicio como un factor estratégico, diseño organizacional y estratégico, procesos y
actividades clave, gestión financiera, gestión de la demanda, y responsabilidades y
responsabilidades clave en la estrategia de servicios.

Service Design - Diseño de servicios (SD)

En este volumen se desarrollan los conceptos relativos al diseño de Servicios TI, como diseño
de arquitecturas, procesos, políticas, documentación. Se adentra además en la Gestión de

40
niveles de servicio, diseño para gestión de capacidad, continuidad en los servicios TI, gestión
de proveedores, y responsabilidades clave en diseño de servicios.

En este fase se debe llegar a tener el mayor detalle posible cuando se hagan los análisis
financieros porque es ahí donde se pueden tener las mejores proyecciones de cuan rentable
resultara el servicio.

Service Transition - Transición de Servicios (ST)

La fase de transición del servicio tiene como objetivo hacer que los servicios definidos en la
fase de diseño del servicio se implementen en el ambiente de producción y sean accesibles a
los usuarios finales, los cuales tengan permisos.

Algunos de los puntos que aborda este libro son: la gestión de la configuración y servicio de
activos, la planificación de la transición y de apoyo, gestión y despliegue de los Servicios TI,
Gestión del Cambio, Gestión del Conocimiento, y por último las responsabilidades y las
funciones de las personas que participen en el Cambio o Transición de Servicios

Service Operation – Operaciones de Servicios (SO)

En la fase de operaciones, se exponen las mejores prácticas a poner en marcha para conseguir
ofrecer un nivel de servicio de la organización acorde a los requisitos y necesidades de los
clientes (establecimiento del SLA – Service Level Agreement o Acuerdo de Nivel de
Servicio).

41
Los temas incluyen objetivos de productividad/beneficios, gestión de eventos, gestión de
incidentes, caso de cumplimiento, gestión de activos, servicios de help desk, técnica y de
gestión de las aplicaciones, así como las principales funciones y responsabilidades para el
personal de servicios que llevan a cabo los procesos operativos.

Continual Service Improvement - Mejora Continua de Servicios (CSI)

En la última fase de ITIL se definen los temas relacionados a la transición de En este
volumen se explica la necesidad de la mejora continua como fuente de desarrollo y
crecimiento en el Nivel de Servicio de TI, tanto interno como con respecto al cliente. De
acuerdo con este concepto, las entidades han de estar en constante análisis de sus procesos de
negocio, y poner en marcha actuaciones una vez detectadas las necesidades con respecto a las
TI de manera que estas sean capaces de responder a los objetivos, la estrategia, la
competitividad y la gestión de la estructura y organización de las organizaciones que
dispongan de infraestructura TI. De esta manera se trata de estar al tanto de los cambios que
se producen en el mercado y de las nuevas necesidades de este también en cuanto a las TI.

A continuación se muestran los procesos que se encuentran en cada ciclo de vida de ITIL:

1. Estrategia del Servicio

- Gestión Financiera

- Gestión del Portafolio

- Gestión de la Demanda

- Gestión de la Estrategia

- Gestión de Relaciones con el Negocio

2. Diseño del Servicio

- Gestión del Catálogo de Servicios

- Gestión de Niveles de Servicios

- Gestión de la Disponibilidad

- Gestión de la Capacidad

- Gestión de la Continuidad de los Servicios de TI

42
 - Gestión de Proveedores

- Gestión de la Seguridad de Información

- Coordinación del Diseño

3. Transición del Servicio

- Gestión de la Configuración

- Gestión del Cambio

- Gestión del Conocimiento

- Planeación de la transición y Soporte

- Gestión de entrega y Despliegue

- Validación del Servicio y Pruebas

- Evaluación del Cambio

4. Operación del Servicio

- Gestión de Incidencias

- Gestión de Problemas

- Gestión de Requerimientos

- Gestión de Eventos

- Gestión de Accesos

Adicionalmente se cuenta con las siguientes funciones:

- Centro de servicios

- Gestión Técnica

- Gestión de Aplicaciones

- Gestión de Operaciones

43
Procesos, funciones y roles en ITIL
Los procesos están definidos de la siguiente forma en ITIL, sin embargo se debe iniciar con
la definición para mejor entendimiento, un proceso es un conjunto de actividades
interrelacionadas orientadas a cumplir objetivos específicos.

Los procesos tienen las siguientes características en común:

 Son cuantificables y se basan en el rendimiento

 Tienen resultados específicos.

 Los procesos tienen un cliente final que es el principal beneficiario del servicio

 Se inician como respuesta a un evento que normalmente es una necesidad y la reacción de

la misma del negocio.

Las funciones tienen como principal objetivo dotar a las organizaciones de una estructura
acorde con el principio de especialización. Es decir, es una función es una unidad experta en
la ejecución de una cierta actividad y es la responsable de su resultado. Reúnen todos los
recursos y capacidades vitales para el correcto desarrollo de dicha actividad.

Un rol es un grupo de actividades y responsabilidades concedidas a una persona o un grupo, y

estos pueden desempeñar paralelamente más de un rol. Hay cuatro roles genéricos que juegan
un papel especial en la Gestión de Servicios en TI:

 Propietario del Servicio: es el último delegado cara al cliente y a la organización TI de la

prestación de un servicio específico.

 Propietario del Proceso: es el último responsable frente a la organización TI de que el

proceso cumple sus objetivos. Debe estar implicado en su fase de diseño, implementación
y cambio garantizando en todo instante que se dispone de las métricas precisas para su
correcta monitorización, evaluación y eventual mejora.

 Gestor del Servicio: es el encargado de la gestión de un servicio durante todo su ciclo de

vida: desarrollo, implementación, mantenimiento, monitorización y evaluación.

44
 Gestor del Proceso: es el ejecutor de la gestión de toda la operativa asociada a un proceso
en particular: planificación, organización, monitorización y generación de informes.

¿Porque ITIL es exitoso?

ITIL abarca un enfoque práctico20, hacer lo que funciona. Y lo que funciona es Adaptación de
un marco común de prácticas que Todos los ámbitos de la prestación de servicios de Único
objetivo: el de aportar valor a la negocio. La siguiente lista define la clave Características de
ITIL que contribuyen a su éxito:

Gestión de servicios ITIL nutre al proveedor de prácticas son aplicables en cualquier

organización de TI Porque no se basan en ninguna plataforma tecnológica o tipo de industria.
ITIL es propiedad del gobierno del Reino Unido y no está bajo cualquier práctica o solución
comercial propietaria.

ITIL ofrece soluciones robustas, probadas en el tiempo que tienen aplicabilidad a todo tipo de
organización de servicios. Estas son útiles y pertinentes en los ámbitos público y sectores,
proveedores de servicios internos y externos; pequeñas, medianas y grandes empresas; y
dentro de cualquier entorno técnico. Se busca que las organizaciones adopten ITIL y para
satisfacer las necesidades de la organización de TI y sus clientes.

Las mejores prácticas ITIL representan el aprendizaje, a través de experiencias, y liderazgo

de pensamiento de los mejores proveedores de servicios del mundo.

ITIL tiene éxito porque describe prácticas que permiten a las organizaciones ofrecer
beneficios, inversión y éxito sostenido. ITIL es adoptado por Organizaciones para que puedan
obtener lo siguiente:

 Brindar valor a los clientes a través de servicios

 Integrar la estrategia de servicios con la estrategia empresarial y necesidades del cliente

 Medir, monitorear y optimizar los servicios de TI y rendimiento del proveedor de

servicios

20
[33] Cabinet Office, 2011

45
 Gestionar la inversión y el presupuesto de TI

 Gestionar el riesgo

 Gestionar el conocimiento

 Administrar capacidades y recursos para entregar servicios de manera efectiva y eficiente

 Permitir la adopción de un enfoque estándar para gestión de servicios en toda la empresa

 Cambiar la cultura organizacional para apoyar el logro de un éxito sostenido

 Mejorar la interacción y la relación con clientes

 Coordinar la entrega de bienes y servicios a través de la red de valor

 Optimizar y reducir costos.

46
OBJETO DE ESTUDIO

ORGANIZACIÓN OBJETIVO
BBVA Continental es un banco peruano, que inicia operaciones en la banca privada en 1951,
manteniéndose así hasta 1970 cuando es adquirido por el Estado Peruano como parte de las
reformas del régimen militar. En 1995 se lleva a cabo la privatización del Banco, en la
subasta realizada resulta ganador el Holding Continental S.A., el cual a la fecha administra el
92% y pertenece al grupo bancario BBVA, el cual mantiene el 50% de su patrimonio, y a
Inversiones Brescia, que mantiene el otro 50%.

La oficina principal del BBVA Continental está ubicada en la ciudad de Lima, distrito de San
Isidro, y se cuenta con 320 oficinas comerciales distribuidas en Lima y provincias.
Adicionalmente, cuenta con 23 oficinas especiales, una oficina de Corporate & Investment
Banking, una oficina de Banca Institucional, tres oficinas de Banca Premium y 22 oficinas de
Banca Empresas y Corporativa.

Actualmente se posiciona como el segundo banco en activos del sistema financiero peruano y
en los últimos años se apuesta por lo que llaman “cambiar la forma de hacer banca”, a partir
de una estrategia de venta de productos financieros que incrementen el vínculo con los
clientes, por ejemplo una de las alternativas que utilizaron fue la venta de productos por
combos.

En la Carta del CEO los accionistas, presentada en la Memoria Anual 2015 (ver Anexo 1),
señala tres aspectos fundamentales como foco a futuro21:

 Fortalecer la calidad del servicio para que se constituya en ventaja competitiva diferencial
en todos los puntos de encuentro entre el cliente y el banco;

 Reforzar la sostenibilidad mediante el control de gastos de operación y de riesgo, con

mejores indicadores que el promedio del sistema; y

21
BBVA Continental 2016

47
 Mejorar los procesos orientados al cliente, modernizándolos y optimizándolos para
ofrecer una calidad de servicio sostenible.

A continuación presentamos los macro procesos sobre los cuales se rige la gestión del banco,
los cuales serán trasversales a las áreas, productos y subprocesos; la identificación de cada
uno de estos, permitirá dar el marco de acción para el desarrollo de la propuesta materia de
este trabajo. En el capítulo, Arquitectura Empresarial, sección Arquitectura de Negocio,
podremos profundizar en cada uno de estos:

Ilustración 9: Macroprocesos BBVA

Fuente: Elaboración propia

MISIÓN
“Aportar las mejores soluciones a nuestros clientes, un crecimiento rentable a nuestros
accionistas y progreso en las sociedades en las que estamos presentes”

VISIÓN
Trabajamos por un futuro mejor para las personas.

48
OBJETIVOS ESTRATÉGICOS
El BBVA Continental durante el 2016 ha definido lineamientos claros en la búsqueda de
convertirse en el primer banco digital de la región y brindar una experiencia única a través de
sus diversos canales. Así, a partir de diversas declaraciones e informes, se ha podido
encontrar los siguientes objetivos:

Nro. Objetivo Indicador

1 Ser el banco principal de los clientes SOW

2 Fortalecer la calidad de servicio IReNe

3 Incrementar colocaciones en banca minorista y mayorista Colocaciones brutas

4 Control eficiente de gastos de operación y de riesgo Eficiencia

5 Incrementar la utilidad UAI

6 Ser el banco digital de la región Clientes digitales

Tabla 3: Objetivos estratégicos

Fuente: Elaboración propia (BBVA Continental Informe de Banca Responsable 201522 /
BBVA Continental Memoria 201523)

A continuación, se presenta la matriz de justificación de los objetivos vs los procesos de

negocio, a través de esta se busca identificar el aporte o impacto de cada proceso en los
objetivos estratégicos de la organización, como se ha mencionado, la presente investigación
se sitúa en el macroproceso de Gestión de Colocaciones.

22
[4] BBVA Continental 2015
23
[2] BBVA Continental 2015

49
 Tipo Procesos / Objetivos OE1 OE2 OE3 OE4 OE5 OE6

Gestión de la innovación y digital X X X 3

Estratégicos

Planeamiento de Negocio X X X X X X 6
Visión Cliente CRM y Analytics X X X X X 5
Desarrollo de Productos X X X X X 5
Gestión del Talento X X X 3
Fondeo e Inversiones X X 2
Gestión de Campañas X X X X 4
Gestión de Colocaciones X X X X X X 6
Tácticos

Gestión del Riesgo X X 2

Gestión de TI X X X 3
Cumplimiento X 1
Marketing e Imagen X X X 3
Gestión Captaciones X X 2
Gestión de Procesos X X X 3
Gestión de Gastos X X 2
Atención al Cliente X 1
Operativos

Cobranzas X X 2
Gestión Proveedores X X 2
Seguridad X X 2
Gestión de Agencias X X X 3
6 10 6 16 13 9
Tabla 4: Matriz de objetivos versus macroprocesos
Fuente: Elaboración propia

ORGANIGRAMA
El organigrama del BBVA, cuya última actualización fue realizada en 2015, está compuesto
por una estructura flexible que permite la mayor interrelación entre las diferentes áreas para
el logro de los objetivos. De acuerdo a regulación las áreas de Auditoría y Cumplimiento
reportan a Directorio, mientras que a Gerencia General reportan Gerencias principales.

50
 Ilustración 10: Organigrama BBVA
Fuente: BBVA Continental Informe de Banca Responsable 2015

Es importante resaltar que en el 2015 la estructura de la organización se modifica para dar

soporte a uno de sus objetivos estratégicos, por ello se crea la Gerencia de Banca Digital,
encargada de liderar las iniciativas que permitirán a la institución acercarse a ser el primer
banco digital de la región.

ALCANCE DEL PROYECTO

El alcance de la presente propuesta, cubre el proceso de venta de productos financieros en
agencias del BBVA Continental, dicha elaboración está soportada sobre el marco de trabajo
TOGAF y contempla como entregables desde la fase preliminar, hasta la quinta fase de
Oportunidades y Soluciones. Asimismo, como parte del análisis, se incluye la situación actual
que soporta el proceso en mención, y la situación futura o deseada soportada por la propuesta,
así como las brechas entre cada una de las situaciones.

Por otro lado, en el presente entregable también se propone un modelo para el desarrollo ágil
del software a implementar a partir de las brechas identificadas, desde la evaluación de la
situación actual, hasta la estructura de trabajo y conformación del equipo para alcanzar los
objetivos.

51
Asimismo, también supone la gestión de los servicios de TI de los procesos principales
identificados cuando se realice la puesta en producción del software bajo el marco de trabajo
ITIL, específicamente en lo que corresponde a cinco de sus procesos.

Es importante precisar, que este proyecto no supone la implementación de la propuesta, es

decir, que la puesta en producción de la solución en la organización no formará parte del
entregable final. Por otro lado, los productos financieros considerados en el proceso
corresponderán a aquellos de contratación sencilla venta corta para clientes pre-aprobados,
puntualmente tarjetas de crédito y préstamos personales, y compras de deuda de estos
productos.

OBJETIVOS DEL PROYECTO

Los objetivos del proyecto son la guía del trabajo a desarrollar y se dividen en dos elementos:

OBJETIVO GENERAL.
Proponer una arquitectura empresarial para el BBVA Continental que transforme el proceso
de venta de productos financieros en sus agencias, maximizando las oportunidades de
colocación mientras se acerca a ser el primer banco digital de la región. Asimismo, se
planteará un marco de trabajo para un desarrollo de software flexible que permita mejorar el
time-to-market; y por otro lado, se busca contar una estructura adecuada de gestión de
servicios de TI que agregue valor a la organización.

OBJETIVOS ESPECÍFICOS.

 Analizar la situación actual de la arquitectura empresarial del proceso de venta de

productos financieros en agencias bajo el marco de trabajo TOGAF, hasta la quinta fase.

 Identificar las brechas entre la situación actual y deseada al presentar la propuesta de

arquitectura empresarial, definiendo los proyectos y/o iniciativas necesarias para
cubrirlas.

 Generar un plan de trabajo y presupuesto alineado a las necesidades y limitaciones de la

organización.

52
 Examinar el entorno de la organización para generar un cambio de paradigma para el
desarrollo de software que priorice la flexibilidad, sobre la documentación.

 Proponer una estructura de trabajo que permita construir un software de alta calidad y
adaptable al cambio, aprovechándolo como ventaja competitiva.

 Desarrollar los procesos de gestión de servicios TI necesarios para asegurar la

continuidad y mejora de la propuesta agregando valor al negocio de forma sostenible.

BENEFICIOS DEL PROYECTO.

Se relacionan todos los beneficios que obtendrá la organización del objeto de estudio cuando
se logre implementar el proyecto. Se divide en dos elementos.

BENEFICIOS TANGIBLES

 Generar un nuevo flujo de oportunidades de colocación de más de 100 mil clientes por
mes.

 Incrementar las colocaciones de las agencias en más de S/1’000,000 desde el primer año.

BENEFICIOS INTANGIBLES.

 Reconocimiento del BBVA Continental como marca digital.

 Alineamiento interno de agencias hacia objetivos estratégicos.

 Mejora en la calidad de los leads entregados a los canales.

 Mejora de los productos a partir de la retroalimentación de clientes.

53
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL

INTRODUCCIÓN
El presente capítulo nos permite comprender la importancia que tiene la arquitectura
empresarial, hoy en día hay una marcada tendencia en las empresas a utilizar marcos de
trabajo para desarrollar una arquitectura empresarial, la cual permite alinear procesos, datos,
aplicaciones e infraestructura tecnológica con los objetivos estratégicos del negocio. En el
sector bancario en especial la arquitectura empresarial es clave para lograr identificar que
procesos específicos pueden cambiar para obtener ventajas competitivas e identificar
potenciales mejoras en la organización.

Se brindarán conceptos generales de la arquitectura empresarial así como la aplicación del

marco de trabajo TOGAF (The Open Group Architecture Framework), el cual permite hacer
un análisis completo de la situación actual de los procesos de la empresa, identificar los
procesos principales, visualizar la coherencia que existe en los sistemas de la empresa para
poder garantizar una adecuada integración entre los mismos.

Se culminará presentando una propuesta de arquitectura objetivo (TO BE), en la cual se

analizará un proceso en específico del sector bancario.

ALCANCE
El alcance del presente proyecto se obtuvo mediante un profundo análisis de todos los
procesos del negocio y los objetivos de la empresa. En el presente documento mostramos el
mapa de procesos de la empresa BBVA Continental, los cuales están agrupados en 3 tipos de
procesos: Procesos Estratégicos, Procesos Tácticos y Procesos Operativos.

Después del análisis se seleccionó el proceso “Gestión de Colocaciones” que pertenece al

grupo de “Procesos Tácticos” de la empresa, el cual es uno de los más importantes ya que con
este proceso se quiere alcanzar objetivos estratégicos.

54
Asimismo, se identifica los objetivos estratégicos, entidades, reglas generales y áreas que se
encuentran relacionadas al proceso seleccionado, se realiza el análisis con la perspectiva de la
situación actual (AS IS) del proceso. Además se identificaran los principales problemas
encontrados en el proceso seleccionado a fin de transformarlos en requerimientos para una
propuesta futura.

Continuando con el proyecto de arquitectura se realiza el análisis con la perspectiva de la

situación propuesta (TO BE) del proceso de negocio seleccionado; en donde, se detalla la
explicación de las cuatro vistas de la Arquitectura Empresarial. En este análisis las vistas que
se mencionan son las siguientes: Arquitectura de Negocio, Arquitectura de Datos,
Arquitectura de Aplicaciones y Arquitectura de Tecnología. Es importante mencionar que
este análisis de las vistas también se presentara a la arquitectura de la línea base (AS IS)

Adicionalmente, se realiza el análisis de brechas, la cual nos sirve como herramienta de

análisis para comparar el estado y desempeño real de la empresa, el resultado esperado es la
generación de estrategias y acciones para llegar al objetivo futuro deseado, aunque signifique
eliminar algunas actividades o integrar otras. Para lograr esto se describirá como se dará
solución a los problemas identificados y como interactuaran los roles mediante un diagrama
de procesos.

Asimismo, el presente proyecto tiene como alcance las siguientes fases definidas por
TOGAF: fase A (Visión de la Arquitectura), fase B (Arquitectura de Negocio), fase C
(Arquitectura de Sistemas de Información), fase D (Arquitectura de Tecnología) y E
(Oportunidades y Soluciones).

Finalmente, para culminar con el proyecto de arquitectura empresarial se realizará el plan de

implementación y migración perteneciente a la fase E, en el cual se darán las pautas para
implementar la propuesta, incluyendo como se trabajará con las dependencias y nuevos
procedimientos identificados previamente.

Dado que la empresa realiza el planeamiento iterativo trimestralmente, en el cual se

comprometen todas las aéreas involucradas en el desarrollo de proyectos del banco, el límite
de tiempo que se tendrá para este proyecto será de tres meses.

55
PRELIMINAR
En esta fase buscaremos determinar las capacidades arquitectónicas deseadas por la
organización examinando el contexto organizacional para llevar a cabo la arquitectura
empresarial. Asimismo, se identificará el alcance de los elementos en las organizaciones de la
empresa que serán afectadas por la capacidad arquitectónica.

Principios de Arquitectura

Principios de Negocio
Nombre Foco en el Cliente

Enunciado El cliente como centro de nuestro negocio

Fundamento El Banco ha definido su VISIÓN como la búsqueda permanente de un

mejor futuro para las personas. El Plan de Negocio Responsable integra
una visión holística del negocio e incluye también iniciativas dirigidas a
ejes trasversales a la actividad del Banco, como la sociedad, la educación
y la innovación. Este plan fue aprobado en el Comité de Negocio
Responsable y se despliega mediante planes locales de negocio
responsable.

Supone el desarrollo de productos que integren atributos sociales

diferenciales, que impulsen el crecimiento, que promuevan la inclusión
financiera y que den respuesta a personas con necesidades especiales.

Repercusiones El impacto de este principio permitirá al banco ayudar a que los clientes
tomen siempre decisiones informadas a partir de una comunicación
transparente, clara, responsable y de educación financiera. Asimismo,
buscará establecer relaciones equilibradas con los clientes y con
orientación a largo plazo.

56
Nombre Comunicación transparente, clara y responsable (TCR)

Enunciado Información confiable y fácil de obtener siempre en el momento oportuno

para generar valor a la empresa.

Fundamento La transparencia y la claridad son fundamentales para ayudar a que las

personas entiendan los productos que contratan. Toda comunicación con
el cliente, desde el documento o contrato más sencillo, debe ser clara y
transparente.

Repercusiones Este principio buscará facilitar la toma de decisiones en la contratación de

productos, así como nuevos contratos que estarán redactados pensando en
el cliente, con un lenguaje sencillo, riguroso y preciso.
Los buenos procesos crean buenos datos. Los procesos tendrán que
enfocarse en mejoras continuas (que a su vez mejorará la fiabilidad,
exactitud, relevancia y oportunidad).

Las agencias tendrán que entregar la información que los clientes pueden
confiar.

Nombre Alineamiento del negocio y TI

Enunciado Las decisiones de gestión de información se realizan siempre alineándose

a los objetivos del negocio, con el fin de generar los máximos beneficios
para la sociedad en su conjunto.

Fundamento Este principio significa “servicio por encima de todo”. Un mayor

alineamiento entre IT y el negocio debe generar una ventaja competitiva
para la institución financiera. Las decisiones corporativas que se tomen y
estén soportadas correctamente por el área de TI apuntando a los objetivos
estratégicos garantizan un mejor ROI, lo cual no debe por otro lado
impedir el cumplimiento de tareas ni actividades secundarias.

57
Repercusiones Los proyectos innovadores o novedosos por si solos no serán aprobados a
menos que cubran algún objetivo de la empresa.

Los cambios y servicios que ofrece TI deben ser dirigidos al

establecimiento de ventajas competitivas.

Iniciativas de gestión de la información deben llevarse a cabo sobre la

base de un plan corporativo.

Nombre Creación de valor

Enunciado La creación de valor para los accionistas como resultado de nuestra

actividad.

Fundamento Las decisiones no deben hacerse basándose únicamente en la reducción de

costos. Cada decisión estratégica debe evaluarse sobre la base de las
perspectivas de costos, riesgos y beneficios. Menores costos a menudo
representan mayores riesgos y, tal vez, menos beneficios.

Repercusiones Este principio garantizará que Toda solución o proyecto debe

seleccionarse basada en un profundo análisis de costos, riesgos y
ganancias.

Transparencia con los accionistas, los clientes, los empleados y la

sociedad.

Todo proyecto o cambio en la empresa debe ser medido con un indicador

de ganancia.

58
Nombre Responsabilidad social

Enunciado La Responsabilidad Social Corporativa como compromiso con el

desarrollo.

Fundamento El entorno actual sigue demandando y reclamando un cambio de

comportamiento y un nuevo enfoque por parte de las entidades
financieras. La política de RSC se desarrolla y complementa con una serie
de políticas específicas, normas y compromisos, que garantizan su
adecuado cumplimiento en los ámbitos de aplicación para obtener la
confianza y respeto de los clientes.

Repercusiones Esto permitirá brindar una mejor formación en finanzas y habilidades

destinada a los negocios para Pymes, que juegan un rol importante en el
desarrollo del tejido económico-empresarial.

Realizar la actividad financiera pensando en las personas.

Ofrecer productos y servicios de alto impacto social, adaptados a las

necesidades de los clientes y al contexto en el que viven.

Apoyar el desarrollo de las sociedades donde esté presente el Banco tanto

a través de la actividad financiera como mediante los programas sociales
con foco en la educación y en el conocimiento.

Nombre Continuidad del Negocio

Enunciado Las actividades corporativas deben mantenerse, a pesar de las

interrupciones del sistema.

59
 Fundamento A medida que las operaciones se vuelven más inherentes, los clientes se
vuelven más dependientes de ellas. Se debe contar con la fiabilidad de
todos los sistemas que dan servicio a los clientes.

Todas las áreas de negocio de la empresa deben ser capaces de continuar

realizando sus actividades normales, independientemente de los eventos
externos. Los fallos de hardware, desastres naturales, y la falta de
integridad de los datos no deben interrumpir las actividades empresariales.

Las actividades empresariales, deben ser capaces de emplear mecanismos

alternativos para transmitir información.

Repercusiones El Contar con flujos secundarios, mecanismos de contingencia ante

desastres y brindar un correcto servicio al cliente nos dará una mejor
imagen institucional.
Los planes de recuperación de información, redundancia y capacidad de
mantenimiento deben abordarse desde el momento del diseño de un
proyecto, por lo que la aprobación de proyectos será más rigurosa.

Procesos manuales deben ser incluidos en los planes de contingencia para

evitar mayor tiempo de espera en agencias bancarias.

Principios de Datos

Nombre La Información Tratada Como un Activo

Enunciado La información es un activo valioso para la empresa y se gestiona en base

a este concepto.

60
Fundamento Información representa un valioso recurso de la empresa, usada
correctamente puede crear ventajas competitivas.

La información es la base del proceso de toma de decisiones. Por lo tanto,

debe ser manejada con cuidado para asegurar la conciencia constante de
su ubicación, la fiabilidad de sus contenidos, y el acceso cuando y donde
sea necesario.

Repercusiones Este es uno de los tres principios estrechamente relacionados con respecto
a la información:

La información es un activo.

La información se comparte.

La información es fácilmente accesible.

Asegurar que todas las áreas dentro de la empresa a entender la relación

entre el valor de la información, el intercambio y la accesibilidad nos
permitirá crear consciencia en los empleados del banco.

Nombre Disponibilidad de Información

Enunciado Los usuarios tienen acceso a la información que es necesaria para el

desempeño de sus respectivas funciones. Por lo tanto, la información se
comparte entre diferentes áreas corporativas y posiciones, dependiendo de
los niveles de seguridad establecidos para ese conjunto particular de
información.

61
Fundamento El generar un sistema integral donde se almacene toda la información
conlleva a un gran beneficio y fácil mantenimiento de procedimientos y
datos para el cumplimiento de las actividades de los colaboradores del
banco.

La información compartida promueve mejores decisiones, ya que son

menos dependientes de las fuentes menos fiables e información
gestionados en el proceso de toma de decisiones.

Repercusiones Este principio fomentara la cultura y valores de la empresa para que todos
participen en el intercambio de información de manera responsable.

Se debe mantener una intranet como única fuente de información, la cual

cuente con perfiles de usuarios y seguridad para garantizar la información.

Para habilitar el intercambio de información, un conjunto común de

políticas, procedimientos y normas deben ser desarrollados y aplicados
para regular la gestión de la información tanto a corto como a largo plazo.

Nombre Seguridad de la información

Enunciado La información está protegida basada en la integridad, disponibilidad,

confidencialidad, incontestabilidad, y la autenticidad. Cada pieza de
información está sometida a una evaluación de seguridad basada en esos
cinco factores.

Trazabilidad de seguridad incluye creación y aplicación correcta del

sistema de auditoría y herramientas de supervisión.

62
Fundamento La información es un activo esencial del BBVA Banco Continental, e
imprescindible para la continuidad del negocio.

Por tratarse de un recurso corporativo, debe promoverse y facilitarse su

uso a quienes lo precisen para el ejercicio de sus funciones. Su uso no
autorizado, pérdida o indisponibilidad, puede perjudicar las actividades
y/o la imagen de la compañía.

Repercusiones La integridad de la información en todos los medios que le sirvan de

soporte.

Su confidencialidad, restringiendo el acceso a la información siempre que

su uso no esté autorizado.

Su disponibilidad para ser utilizada por quien lo requiera en el ejercicio de

sus funciones o necesidades de negocio.

Establecer los requisitos aplicables de la norma ISO 27001; incluyendo

las exclusiones con sus respectivas justificaciones, el compromiso de la
Alta Dirección.

63
Principios de Aplicaciones

Nombre Independencia de la Tecnología

Enunciado Hoy en día hay una creciente necesidad del sector bancario por
proporcionar herramientas que le ayuden a lograr la fidelidad del cliente,
para ello se planifican soluciones digitales de diversa magnitud y alcance,
las cuales son muy diferentes y pueden ser hechas y mantenidas con
distintas herramientas y motores de datos.

Las aplicaciones no dependen de las opciones tecnológicas específicas,

por lo tanto, puede funcionar en diferentes plataformas tecnológicas. La
arquitectura de TI debe ser planeada para reducir el impacto de los
cambios tecnológicos en el negocio.

Fundamento La independencia de las aplicaciones tecnológicas permite que sean

adaptables y operadas bajo un enfoque de reutilización de aplicaciones y
servicios obteniendo un mejor costo beneficio.

Este principio se basa en el concepto de que cada decisión se hace

teniendo en cuenta que el software no dependa del sistema operativo o
algún hardware en particular.

64
Repercusiones

El impacto de este principio será muy positivo, puesto que nos brindara la
posibilidad de innovar con nuevas tecnologías y formas de trabajo, dado
que se apuntará a una arquitectura de micro servicios.

Motivar al uso de metodologías ágiles para el desarrollo de software,

propiciar el cambio y la prueba continua.

Este principio requiere que las normas que apoyan la portabilidad, que a
menudo son llamados estándares abiertos.

Interfaces de programación de aplicaciones (APIs) deben ser desarrolladas

para integrar las aplicaciones existentes con entornos operativos y las
aplicaciones desarrolladas sobre la base de la arquitectura de la empresa.

Nombre Aplicaciones de Fácil Uso

Enunciado Buscar que las aplicaciones sean fáciles de usar. La tecnología es

transparente para los usuarios, lo que les permite concentrarse en sus
tareas, más que en cuestiones de operación del sistema.

Fundamento Cuanto más que los usuarios necesitan para entender la tecnología
empleada, el menos productivo que serán

Se anima a los usuarios a trabajar dentro del entorno integrado de

información en lugar de desarrollar sistemas aislados para realizar tareas
fuera del entorno corporativo integrado.

65
Repercusiones

Pensar siempre en la simplicidad y experiencia usuario al diseñar y

plantear nuevos proyectos.

Nuevos proyectos de software que cuenten con un front end deben contar
con el diseño y validación de un equipo de customer experience.

Todas las aplicaciones deben tener la misma apariencia y el diseño. Por lo

tanto, un diseño estándar debe ser desarrollado, y debe aplicarse criterios
de pruebas de usabilidad.

Nombre Reutilización de componentes y simplicidad

Enunciado La arquitectura del banco se construye con los conceptos de bajo

acoplamiento, alta cohesión, componentes reutilizables, modulares y que
implementan servicios.

Arquitectura de sistemas debe ser lo más simple posible para mantener

aún cumplir con todos los requisitos empresariales y corporativos.

Fundamento Los componentes reutilizables representan oportunidades para reducir los

tiempos de TI y los costos de desarrollo.

El proporcionar micro servicios a los diferentes equipos capacita al equipo

a elegir las tecnologías con las que trabajar y el ser responsables de
principio a fin de su micro servicio.

Los componentes modulares aumentan la capacidad de los sistemas para

adaptarse a las diferentes necesidades de evolución, porque el cambio es
aislado de módulos afectados.

66
 Repercusiones El Plantear una arquitectura de servicios con el objetivo de reutilizar
recursos nos permitirá reaccionar rápidamente a los cambios y
necesidades del cliente.
La arquitectura establece normas y directrices para desarrollar los
componentes del sistema.

Principios de Tecnología
Nombre Cambios basados en Requerimientos

Enunciado Los cambios en las aplicaciones y tecnologías se implementan sólo para

satisfacer las necesidades del negocio y cumplir los objetivos estratégicos

Fundamento Los cambios en el sistema están hechos con un análisis de impacto previo.

Esto garantiza que la operación del negocio es la base para cualquier

propuesta de cambio

Repercusiones Este principio nos permitirá ser más eficientes en el desarrollo de

proyectos tecnológicos.

Un desarrollo o mejora del sistema técnico no se pone en práctica a menos

que haya una necesidad de negocio documentado.

Todo proyecto de software debe estar alineado con los principios de

arquitectura. Debe haber un balance entre las necesidades del negocio y
las operaciones de TI.

Nombre Interoperabilidad

67
 Enunciado Software y hardware deben seguir las normas establecidas que promueven
los datos, aplicaciones y la interoperabilidad de la tecnología.

Fundamento Las normas ayudan a garantizar la coherencia, mejorando así la capacidad

de gestionar sistemas, aumentar la satisfacción del usuario, y proteger las
inversiones actuales de TI, por lo tanto maximizar el retorno de la
inversión y la reducción de costos.

Repercusiones Los estándares de interoperabilidad y de la industria deben ser seguidas a

menos que haya una razón comercial obligatoria para implementar una
solución no estándar.

Un proceso para establecer normas, revisión periódica, y se debe

establecer excepciones.

Plataformas actuales deben ser identificadas y documentadas.

Petición de Trabajo de la Arquitectura

Límites de Tiempo
Actualmente la empresa realiza cuatro reuniones trimestrales al año en las cuales se trata y
aborda el alcance e iniciativas de toda la organización para los siguientes tres meses. El
desarrollo del proyecto de arquitectura empresarial debe encajar en estos periodos de tiempo
en los cuales se debe evaluar los objetivos estratégicos a atacar.

El tiempo de duración del proyecto por ende será de tres meses, en los cuales se debe incluir
el trabajar con las diversas áreas que se relacionan con el proceso seleccionado. El proyecto
se realizará en el cuarto trimestre como se indica en la siguiente tabla y en la estimación
inicial se cuenta con los tiempos de refinamiento del proyecto, los cuales pueden ser
apreciados en el cronograma de actividades.

68
Periodos Trimestrales 2016

Periodo Inicio Fin

Primer Trimestre Enero Marzo

Segundo Trimestre Abril Junio

Tercer Trimestre Julio Setiembre

Cuarto Trimestre Octubre Diciembre

Tabla 5: Periodos de revisión de iniciativas y proyectos

Fuente: Elaboración propia

El tiempo de los colaboradores requerido para el proyecto es una limitante importante, esta se
ve reflejada en las dependencias entre áreas del banco, pues suministrar información es clave
para el diseño de la arquitectura, es limitado y depende de los imprevistos que se puedan
presentar en su actividad diaria.

Limitaciones organizacionales
Las limitaciones organizacionales son generadas normalmente por la falta de conocimiento y
expertise en el banco en realizar proyectos de arquitectura empresarial, a continuación se
detallan las limitaciones más marcadas.

El contar con un equipo que se encargue de realizar la arquitectura y que tenga el

empoderamiento adecuado para realizar cambios en los procesos.

Que no se identifiquen adecuadamente a los Stakeholders asignados a los proyectos.

La resistencia al cambio por parte de los involucrados, principalmente aquellos

comprometidos en la gestión financiera y sistemas, quienes serían encargados de llevar a
cabo el requerimiento.

La propuesta de arquitectura empresarial debe obtener el apoyo de las unidades de

Cumplimiento Normativo y de Prevención de Lavado de Activos y Financiamiento del

69
Terrorismo (PLA/FT), las cuales forman parte del Marco Integral de Gestión de Riesgos del
Grupo BBVA, conjuntamente con las actividades que desarrollan las áreas de Servicios
Jurídicos, Riesgos y Auditoría Interna. La propuesta debe ser gestionada dentro de los límites
establecidos, de forma que se aseguren los objetivos del negocio de manera razonable.

No contar con el personal clave o usuarios líderes que tengan experiencia y conocimiento de
arquitectura empresarial durante la ejecución de tareas importantes.

No contar con una adecuada gestión de registro de base de conocimientos para que sirva
como información de entrada al emprender nuevos proyectos.

Limitaciones financieras
Actualmente el objetivo estratégico de convertir el banco en el banco digital de la región
proporciona un presupuesto de dos millones de nuevos soles para llevar a cabo proyectos de
arquitectura empresarial, dado que una adecuada propuesta agilizará la transformación digital
del banco, pero aún continúa la necesidad de vigilar el cumplimiento de los estándares
regulatorios en materia de capital y liquidez.

Contar con los recursos y licencias de aplicaciones necesarias para lograr un planteamiento
adecuado e implementación de la propuesta.

Contar con presupuesto necesario para la contratación de personal calificado y con

experiencia en arquitectura empresarial.

Limitaciones externas, limitaciones de negocio

El bajo porcentaje de clientes digitales en la región hacen que los proyectos de arquitectura
empresarial tomen diversos enfoques para obtener un mejor ROI.

La falta de personal calificado en el mercado para cubrir los roles necesarios para hacer un
proyecto de arquitectura empresarial, fuerza al banco a capacitar a personal interno, lo cual
lleva a una curva de aprendizaje de costo moderado.

70
La velocidad de acción de la competencia en brindar herramientas digitales para los clientes
hace que las decisiones se deban tomar en poco tiempo y la duración de los proyectos se
acorte.

Descripción de la situación actual del negocio

El proceso seleccionado para nuestra propuesta de arquitectura empresarial es “Gestión de
Colocaciones”, focalizado en el subproceso de venta en agencias. Este proceso está
dado por las actividades y procedimientos que se tienen en todas las agencias a nivel
nacional para poder vender los productos financieros a los clientes. En la actualidad,
no se aprovechan las transacciones comunes de los clientes y no clientes que se
acercan a las ventanillas, para ejecutar una venta contextual, a fin de que accedan a las
ofertas más llamativas del banco.

Con el fin de entender la distribución de las agencias a nivel nacional, se presenta el siguiente
cuadro:

Ilustración 11: Oficinas BBVA en Lima

Fuente: www.bbvacontinental.pe

71
 Ilustración 12: Oficinas BBVA en provincias
Fuente: www.bbvacontinental.pe

Participación de Mercado 24
En lo que va del ejercicio 2016, el mercado bancario peruano presenta una modificación en
cuanto al número de instituciones bancarias, al decidir Deutsche Bank cerrar las operaciones
en el país. De este modo, entre las 16 entidades restantes, la participación de los cuatro
bancos más grandes (BCP, BBVA Continental, Scotiabank e Interbank), continúan
concentrando más del 80% de las colocaciones brutas, depósitos y patrimonio. En particular,
BBVA Continental mantiene la segunda posición tanto en colocaciones como en captaciones,
así como el tercer puesto en términos patrimoniales.

Ilustración 13: Participación BBVA en sistema financiero

Fuente: Equilibrium Clasificadora de Riesgo S.A. Informe de Clasificación

24
[1] Equilibrium 2016

72
De considerar el ranking por tipo de crédito, se observa que el Banco mantiene una cuota de
mercado superior al 20% en los segmentos de créditos corporativos (23.24%), grande
empresa (23.91%), mediana empresa (27.99%) e hipotecarios (28.74%), los mismos que son
considerados como segmentos objetivos, manteniendo similar participación a lo registrado al
cierre de 2015.

Ilustración 14: Participación de mercado por tipo de crédito

Fuente: Equilibrium Clasificadora de Riesgo S.A. Informe de Clasificación

En la gráfica anterior se puede apreciar que el banco se mantiene segundo en las colocaciones
totales, sin embargo, en el tipo de crédito consumo, foco de la presente investigación, se
posiciona en la última posición entre los bancos principales. Un factor importante, es que la
competencia cada vez está más agresiva, buscando crear nuevos productos para captar más
clientes mejorándolos con herramientas digitales.

BBVA Continental enfrenta el escenario actual de competencia y desaceleración económica,

donde debe seguir manteniendo el crecimiento continuo a través de los periodos analizados
sin descuidar la calidad crediticia de su cartera de colocaciones, así como de sus indicadores
de solvencia mejorando sus ratios de rentabilidad.

A manera de análisis de la situación actual del negocio en general, se presenta algunas

características de la organización representadas por el FODA, se ha marcado aquellas que se
consideran con mayor impacto en el marco de la presente investigación:

73
 Fortalezas Debilidades

Respaldo de sus accionistas: el Grupo BBVA Descalces entre activos y pasivos en algunos
(Banco Bilbao Vizcaya Argentaria) y el tramos.
Grupo Breca.
Riesgo de mercado asociado a las
Importante participación en el sistema inversiones que mantiene en cartera, dada la
bancario peruano. elevada volatilidad en los mercados
financieros y de divisas.
Adecuados indicadores financieros,
destacando la eficiencia operativa. Deterioro en la calidad de la cartera de
grande, mediana y pequeña empresa en
Capacidad y experiencia profesional de la
relación al sector, a lo cual se suma la
Plana Gerencial.
disminución en la cobertura con provisiones
de la cartera problema del Banco, ubicándose
por debajo de la banca múltiple.

Oportunidades Amenazas

Expansión de la gama de servicios y/o Mayor competencia entre bancos grandes.

productos a través de banca electrónica.
Sobreendeudamiento de clientes actuales y
Bajo nivel de intermediación financiera en el potenciales.
país.
Deterioro de algunos sectores económicos
que podrían afectar la calidad de cartera.

Desaceleración de la economía.

Tabla 6: FODA general BBVA Continental

Fuente: Equilibrium Clasificadora de Riesgo S.A., Informe de Clasificación, BBVA
Continental, Lima, Perú, 29 de setiembre de 2016

74
Luego de analizar la situación actual del negocio se mencionarán los principales problemas
que se encuentran en el proceso de “Gestión de Colocaciones”, y como algunos de los
requerimientos más importantes derivan de estos.

Problemas

 Capacidad reactiva ante los nuevos productos lanzados por la competencia.

 No se está captando nuevos clientes proactivamente, o fidelizando a los actuales, cuando

visitan las agencias del BBVA.

 Tiempos de espera no aprovechados en las agencias bancarias a nivel nacional.

 Interacción con el cliente conlleva papelería en exceso y procesos tediosos que demandan
muchos minutos de atención en oficina.

Requerimientos

 Expansión de la gama de servicios y/o productos a través de banca electrónica.

 Aumentar la agilidad del negocio mediante la optimización, simplificación y

consolidación de los procesos.

 Reducir los tiempos de atención en las agencias del banco.

 Aumentar el porcentaje de clientes digitales del banco mediante una campaña de

digitalización de clientes.

 Brindar una experiencia única en atención a todos los clientes y no clientes del banco en
todas las agencias del país.

Descripción de la Situación actual de la Arquitectura TI

Actualmente el banco cuenta con una arquitectura empresarial antigua, que no integra todos
los macro procesos alineándolos al cumplimento de los objetivos estratégicos. Se cuenta con
políticas, normativas, alineamientos, manuales de procesos y algunos diagramas que indican
cómo se debe trabajar y que pasos seguir en determinadas circunstancias, muchos de estos
procesos están detallados de manera aislada, solo mencionando las áreas de dependencia u
relacionadas al mismo.

75
Todos estos procesos siempre giran y están enfocados al desarrollo de un determinado
producto del banco tratando de obtener un buen servicio y mejorando la calidad para poder
fidelizar al cliente.

Respecto al proceso de gestión de colocaciones del banco, este se da mediante

procedimientos establecidos en la intranet del banco, de modo que todas agencias cumplan
estas directivas.

Problemas

 Falta de procesos integrados en un portal único donde todos los interesados puedan
acceder a la información con facilidad.

 Extensos plazos de entrega de los proyectos para la red de oficinas del banco.

 Aplicaciones aisladas para completar un solo proceso de la red de oficinas.

 Procesos poco flexibles y demora en los cambios.

Requerimientos de TI

 Simplificar la arquitectura actual, asegurando la consistencia y la integridad de todos los

procesos del banco, para que la información detallada y las diferentes vistas de acuerdo al
perfil sean fáciles de acceder.

 Orientar la arquitectura de negocios a servicios que pueden ser utilizados por muchos
procesos y desarrollo de varios proyectos con distintas tecnologías.

 Reducir la cantidad de documentos físicos que se da en la colocación de productos en las

agencias bancarias.

 Responder a la competencia mediante cambios rápidos en los procesos y canales en la red

de agencias.

 Agilidad en la definición y desarrollo de proyectos de TI que brinden herramientas a las

oficinas.

76
VISIÓN DE LA ARQUITECTURA
En esta fase se desarrollará una visión de alto nivel de las capacidades y valor de negocio que
se desean obtener como resultado de la Arquitectura Empresarial propuesta.

Declaración de Trabajo de Arquitectura

Descripción del Proyecto de Arquitectura y Alcance

La presente propuesta busca redefinir la forma en la cual se ejecuta la colocación de
productos financieros en las agencias del BBVA, a partir de un análisis profundo de la
situación actual, el levantamiento de las preocupaciones de interesados y clientes, y los
objetivos estratégicos, se plantearán cambios en el proceso y herramientas utilizadas con un
enfoque digital. La colocación a través de canales alternativos, como ATMs, Banca por
Teléfono o Televentas, Banca por Internet, App BBVA Continental, no son incluidas como
parte del análisis, sin embargo se buscará la escalabilidad de la propuesta de manera que
procedimientos y componentes que se definan puedan ser reutilizados.

Como se indicó en capítulos previos, el alcance de la propuesta está soportado por el marco
de trabajo TOGAF y se estará tomando en cuenta diversos entregables desde la fase
preliminar, hasta la fase E. Oportunidades y Soluciones, donde se presentarán las iniciativas o
proyectos que son requeridos para resolver las brechas identificadas entre las arquitecturas de
la línea base (AS-IS) y destino u objetivo (TO-BE).

Procedimiento específico para Cambios de Alcance

Todo proyecto es susceptible de sufrir cambios en su alcance, ya sea a requerimiento de los
interesados, por paridad competitiva o por necesidades propias del ciclo de vida de los
clientes o productos. Así, en la presente sección, se incluye el procedimiento definido para
realizar cambios al alcance, el cual será necesario para mantener el equilibrio entre las
diferentes restricciones. Es importante señalar que se trata de un proceso documentado en una
Solicitud de Cambios, cuyo formato se encuentra en el Anexo 3 del presente documento.

77
 Ilustración 15: Procedimiento de cambios al alcance
Fuente: Elaboración propia

A continuación se detallan las actividades presentadas en el flujo del gráfico anterior:

Actividad Descripción

Identifica necesidad de El solicitante identifica necesidad de cambio y detalla

cambio características de este.

Presenta solicitud de El solicitante presenta solicitud de cambio según formato

cambio establecido, coordina su preparación con involucrados.

Asigna solicitud para El gestor de proyecto asigna solicitud para revisión otorgándole
revisión una codificación para el control y seguimiento.

Identifica impacto del El gestor de proyecto coordina con diferentes áreas para
cambio identificar impacto del cambio y actualiza el formato presentado.

78
 Actividad Descripción

Se realiza comité y De acuerdo al impacto del cambio es necesario que un comité,

presenta compuesto por los responsables de las principales áreas
involucradas, realice la evaluación y aprobación del cambio.
Este comité se reúne de manera semanal y es necesario enviar la
agenda de los cambios en los proyectos previamente para
revisión de los representantes.

Se ejecuta control de El gestor ejecuta control de cambios luego de la confirmación,

cambios para ello identifica si requiere soporte o participación de otra
área.

Se comunica El gestor de proyecto comunica resolución a interesados y cierra

resolución y cierra solicitud en formato.

Tabla 7: Actividades procedimiento de cambios al alcance proyecto de arquitectura

Fuente: Elaboración propia

A continuación se detallan los roles que forman parte del procedimiento antes descrito:

Rol Descripción

Solicitante Este rol puede encontrarse dentro o fuera del equipo de trabajo
del proyecto de arquitectura empresarial, presenta el
requerimiento de cambio indicando la justificación o motivo que
supone la necesidad de su implementación

Oficina de Proyecto Centraliza e integra las diferentes solicitudes. Realiza el análisis,

evaluando la necesidad y el impacto en conjunto con el
Solicitante en términos de tiempo, costo, riesgo y/o calidad. En
caso sea necesario, eleva la petición al Comité de Aprobación.

79
 Rol Descripción

Comité de Aprobación Evalúa y aprueba en sesión ordinaria o extraordinaria los

cambios al alcance, lo integran los responsables de las diferentes
dominios de arquitectura, únicamente ingresan aquellos cambios
que tienen impacto significativo en las restricciones del proyecto
(+10%).

Tabla 8: Roles procedimiento de cambios al alcance proyecto de arquitectura

Fuente: Elaboración propia

Roles, Responsabilidades y Entregables

Roles25 Responsabilidades Entregables

Arquitecto Encargado de apoyar la estrategia de negocio. Petición de Trabajo

Empresarial Arquitectura
Encargado de identificar los Limites del Proyecto
de arquitectura. Declaración de
Trabajo de
Encargado de elaborar la Declaración de trabajo de
Arquitectura
la arquitectura.
Límites del proyecto
Encargado de elaborar el desglose de la
de Arquitectura
Implementación de Proyectos EDT.
Arquitectura Negocio
Responsable de realizar el cuadro resumen de plan
de Migración. Plan de
Implementación de
Definir las guías y lineamientos para una buena
Migración
gestión de la información.

25
WordPress. (diciembre de 2010). WordPress. Obtenido de WordPress:
https://arquitecturaempresarialcali.wordpress.com/2010/12/05/los-diferentes-roles-del-arquitecto/

80
 Roles25 Responsabilidades Entregables

Ejerce funciones de gobierno y regula normas para EDT

la comunicación.
Refinamiento de
Guiar al líder de TI, para que las inversiones, Proyecto
siempre estén alineadas con la estrategia del
negocio, y le brinde una ventaja competitiva a la
organización.

Gestionar proyecto de propuesta de arquitectura

empresarial.

Realizar el afinamiento adecuado del proyecto de

arquitectura.

Arquitecto de Definir los Principios de la Arquitectura. Principios de la

Negocio Arquitectura
Elaborar la descripción del negocio.
Petición de Trabajo
Elaborar la visión del negocio.
Arquitectura
Definir lista de interesados y sus preocupaciones.
Principios de

Crear Matriz Objetivos del Negocio vs procesos. Arquitectura

Crear diagrama de actividades proceso Visión de la

seleccionado ASIS. Arquitectura

Crear diagrama de actividades proceso Arquitectura Negocio

seleccionado TOBE. ASIS y TOBE

Analizar brechas de arquitectura de negocios. Análisis de Brechas de

Arquitectura de
Sugerir mejoras en los procesos de la Negocio
organización.

81
 Roles25 Responsabilidades Entregables

Arquitecto de Elaborar el Modelo de datos del proceso. Arquitectura de Datos

datos de Línea Base
Elaborar Matriz de datos del proceso seleccionado
vrs procesos del Negocio. Arquitectura Datos
Destino
Elaborar Análisis de Brechas de Datos.
Análisis de Brechas de
Responsable de construir la infraestructura sobre la
Arquitectura de Datos
que estará soportada toda la necesidad que la
organización tenga para el manejo de sus datos.

Arquitecto de Elaborar Diagrama de Aplicaciones y descripción. Arquitectura de

software Aplicaciones Línea
Elaborar Matriz de Aplicaciones del proceso
Base
seleccionado vrs procesos del Negocio.
Arquitectura de
Elaborar Análisis de Brechas de Aplicaciones
Aplicaciones Destino

Guía en el desarrollo del software de la

Análisis de Brecha de
organización, define la estructura, el diseño del
Arquitectura de
software, definición de arquitectura de los
Aplicaciones
sistemas, vista física, vista lógica y mejores
prácticas a seguir. Análisis de Brechas de
Arquitectura de
Responsable de que se cumplan los requisitos
Aplicaciones
funcionales, y los no funcionales, como por
ejemplo el rendimiento del software, su
flexibilidad, usabilidad, reutilización y calidad.

82
 Roles25 Responsabilidades Entregables

Arquitecto de Elaborar Componentes de tecnología. Arquitectura

Infraestructura Tecnológica
Identificar Plataforma de tecnología y su
descomposición. Componentes de
tecnología
Identificar Ambientes y ubicaciones.
Plataforma de
Elaborar Especificaciones de hardware y red.
tecnología y su

Elaborar Análisis de Brechas de Aplicaciones. descomposición.

Se encarga de la implantación, Ambientes

definición, y

evolución y gobierno de las arquitecturas de ubicaciones

infraestructura que permitan a IT y al negocio
Especificaciones de
evolucionar el banco hacia una compañía más
hardware y red
eficiente, ágil y sostenible y adelantándose a las
necesidades y retos actuales y futuros de acuerdo a Análisis de Brecha de
los estándares y políticas del grupo. Arquitectura
Tecnológica

Gerente Colaborar con la creación del Modelo de datos Arquitectura de datos

Fábrica de
Elaborar Matriz de datos del proceso seleccionado Modelo de datos
Soluciones
vrs procesos del Negocio.
Matriz de datos del
Elaborar Diagrama de Aplicaciones y descripción proceso seleccionado
vrs procesos del
Planificar, ejecutar y realizar seguimiento de los
Negocio
proyectos digitales de la unidad, identificando y
elaborando con las Unidades Usuarias el plan Diagrama de
anual de los proyectos y su presupuesto. Aplicaciones y
descripción
Supervisar, administrar y coordinar los trabajos
informáticos que el Banco haya contratado con Arquitectura de

83
 Roles25 Responsabilidades Entregables

empresas externas (fábricas de software) que estén Aplicaciones

bajo la unidad de Fabrica de Soluciones
Análisis de Brechas de
Elaborar Análisis de Brechas de Datos. Datos

Elaborar Análisis de Brechas de Aplicaciones Análisis de Brechas de

Aplicaciones

Tabla 9: Roles, responsabilidades y entregables del proyecto de arquitectura

Fuente: Elaboración propia

Criterios de Aceptación

Criterio Descripción Entregable

Protección y mantenimiento Todos los entregables de la arquitectura Todos

de la documentación empresarial deben ser mantenidos y
resguardados en óptimas condiciones, solo
compartidos en herramientas digitales con
las personas que colaboran o revisar los
documentos.

Control de Versiones Todos los entregables de la arquitectura Todos

empresarial deben tener un adecuado
manejo de versiones, en las cuales se
indiquen fechas y personas que actualizaron
dichos documentos.

84
 Criterio Descripción Entregable

Presentación de Entregables Todos los entregables deben tener un Todos

formato similar en cuando a nombre y
estructura, respetando las fuentes
determinadas en las plantillas y con una
respectiva enumeración e índice de páginas.

Medios de entrega Al finalizar un entregable debe ser cargado Todos

en el repositorio central definido por el
banco e informar a todos los interesados
para la revisión de dicho documento

Alcance de entregables Todos los entregables deben tener un Todos

alcance, el cual informa de manera general
de que va tratar el documento, mencionando
que aspectos se tomaran en dicho
documento.

Diagramas Todos los diagramas contenidos en los Todos

documentos deben presentar una descripción
del mismo, indicando cual es el objetivo y
fuentes del mismo.

Tabla 10: Criterios de aceptación de arquitectura empresarial

Fuente: Elaboración propia

85
Cronograma Tentativo
En la presente sección se muestran las actividades que serán necesarias para elaborar el
proyecto de arquitectura, los tiempos definidos para las actividades están determinadas
después de un análisis con todos los roles que intervienen en el desarrollo del proyecto. El
tiempo establecido para el proyecto es de 3 meses, por lo que el cronograma apunta a
terminar dentro de ese lapso de tiempo. Se incluyen las actividades relacionadas a la gestión
del proyecto y el refinamiento del mismo.

86
 Ilustración 16: Cronograma propuesta de arquitectura empresarial
Fuente: Elaboración Propia

Visión de la Arquitectura

Interesados y sus preocupaciones

Transformar el proceso de venta en agencias, soportado por una Arquitectura Tecnológica
adecuada, es el contexto sobre el cual los diferentes actores del proceso y negocio
involucrados plantean sus preocupaciones e intereses.

A continuación presentamos la tabla resultado de la identificación y análisis de los

principales interesados, es importante precisar que la medición de interés y poder tiene la
siguiente escala:

 1: Muy poco

 3: Poco

87
 5: Medio

 7: Alto

 9: Muy alto

La selección de la valoración por cada uno de estos elementos ha sido evaluada utilizando
como criterio el juicio experto y la experiencia en proyectos anteriores.

N° Interesado Preocupaciones Interés Poder Estrategia

1 Ejecutivos de Simplificar sus herramientas de 5 1 Mantener

Banca Personal trabajo. informado

2 Gerentes / Colocar una mayor cantidad de 7 3 Mantener

Subgerentes de productos, generar eficiencias en la informado
Oficina agencia.

3 Gerentes Proveer de las mejores herramientas 7 5 Mantener

Desarrollo de a la red de agencias para informado
Negocio - Persona incrementar la colocación.
Natural

4 Arquitecto Máximo aprovechamiento de las 9 7 Gestionar

Empresarial capacidades manteniendo el atentamente
alineamiento hacia los objetivos

5 Gerente Adecuar la infraestructura 3 5 Monitorear

Infraestructura tecnológica de manera óptima hacia
los requerimientos del negocio.

6 Gerente Estandarizar los procesos de 7 7 Gestionar

Distribución Red colocación, maximizando la venta atentamente
por arribo.

88
N° Interesado Preocupaciones Interés Poder Estrategia

7 Gerente Banca Generar nuevas plataformas 7 7 Gestionar

Digital digitales que generen impacto en atentamente
los clientes a través de una
experiencia única.

8 Gerente Talento y Crear capacidades digitales en los 5 5 Mantener

Cultura colaboradores de la red. informado

9 Gerente Customer Crear nuevas y únicas experiencias 7 3 Mantener

Experience en los clientes que se acercan a la informado
red de agencias.

10 CEO Expandir la estrategia digital a 7 9 Gestionar

todos los canales. atentamente

11 Responsable Mantener el enfoque y visión entre 5 9 Gestionar

BBVA Latam las diferentes sedes del BBVA a atentamente
nivel mundial

Tabla 11: Listado y análisis de interesados

Fuente: Elaboración propia

89
Lista de asuntos/escenarios que deben abordarse
A continuación se presentan diferentes consideraciones respecto al contexto empresarial
sobre el cual se enmarca la propuesta tanto al interno, como al externo:

 Desaceleración económica exige soluciones innovadoras para captar nuevos clientes y

fidelizar a los existentes.

 Las agencias siguen representando el mayor volumen transaccional del banco, por encima
de los canales alternativos y digitales a pesar de los esfuerzos por derivar a los clientes a
canales más convenientes.

 La generación de ventas en las agencias es reactiva, no se contextualiza los arribos de los

clientes, ni obtiene información de estos.

 Existen cuestionamientos respecto a la rentabilidad real de las agencias.

 Metas de las agencias no alineadas con las posibilidades y herramientas actuales.

 Aprendizaje de nuevas tecnologías en la red de agencias exige mejorar competencias de

los Ejecutivos.

 Complejidad tecnológica para interconectar las diferentes fuentes de datos es el reto del
banco ante cualquier propuesta de cambio.

90
ARQUITECTURAS (AS IS / TO BE)

ARQUITECTURA AS-IS
En esta sección se analiza la situación actual de las diferentes dimensiones de arquitectura.

ARQUITECTURA DE NEGOCIO
El BBVA Continental tiene una clara estrategia para cumplir con sus objetivos en el menor
de los plazos y hacerlos sostenibles en el tiempo. Así, en los capítulos previos se ha podido
profundizar en diferentes aspectos a través de los cuales se debe generar cambios en uno de
sus procesos clave, para que a través de la aplicación de tecnologías, acerque a la institución a
sus metas.

En la descripción de la organización objetivo, se presentaron los objetivos estratégicos y

macroprocesos de la organización, en esta sección relacionaremos esta información,
describiremos el proceso a desarrollar e identificaremos los roles de negocio que participan
en este.

Matriz de Objetivos de Negocio vs Procesos

Si bien el primer capítulo presenta la matriz de justificación de los objetivos estratégicos y los
macro procesos principales, es importante que en esta sección se presente nuevamente.

Objetivos:

Nro. Objetivo

OE1 Ser el banco principal de los clientes

OE2 Fortalecer la calidad de servicio
OE3 Incrementar colocaciones en banca minorista y mayorista
OE4 Control eficiente de gastos de operación y de riesgo
OE5 Incrementar la utilidad
OE6 Ser el banco digital de la región

91
Matriz:

Tipo Procesos / Objetivos OE1 OE2 OE3 OE4 OE5 OE6

Gestión de la innovación y digital X X X 3

Estratégicos

Planeamiento de Negocio X X X X X X 6
Visión Cliente CRM y Analytics X X X X X 5
Desarrollo de Productos X X X X X 5
Gestión del Talento X X X 3
Fondeo e Inversiones X X 2
Gestión de Campañas X X X X 4
Gestión de Colocaciones X X X X X X 6
Gestión del Riesgo X X 2
Gestión de TI X X X 3
Cumplimiento X 1
Tácticos

Marketing e Imagen X X X 3
Gestión Captaciones X X 2
Gestión de Procesos X X X 3
Gestión de Gastos X X 2
Atención al Cliente X 1
Cobranzas X X 2
Gestión Proveedores X X 2
Operativos

Seguridad X X 2
Gestión de Agencias X X X 3
6 10 6 16 13 9

92
Proceso de negocio seleccionado: Venta de Productos Financieros en Agencias (contratación
sencilla)
Subproceso perteneciente al macroproceso 8. Gestión de Colocaciones, uno de los que tiene
mayor relación con los objetivos estratégicos, y a través del cual se genera la venta de
diferentes productos activos (colocaciones) y pasivos (depósitos y ahorros), para efectos de la
presente investigación se tomará en cuenta el proceso de contratación sencilla (flujo de
colocación sencilla) para los productos de venta corta, básicamente Tarjetas y Préstamos
personales.

El proceso inicia cuando los clientes o no clientes se acercan a una agencia, ya sea para
transaccionar o solicitar algún producto, en caso sea lo último, se acerca a plataforma y los
Ejecutivos de Banca Personal le ofrecerán diferentes alternativas de acuerdo a su
requerimiento y capacidad de endeudamiento, para ello los representantes del BBVA
Continental primero solicitan documentación mínima, por ejemplo el documento de
identidad, para posteriormente realizar filtros duros (Reniec y Centrales de Riesgo) en el
módulo Pre-evaluador de la Plataforma Integrada Comercial. En caso se presenten
observaciones, el Gerente de Oficina puede autorizar que se continúe con el proceso.

Con la aceptación del cliente, se debe imprimir la documentación contractual (solicitud,

contrato, hoja resumen), y el cliente la deberá debe completar y firmar; en paralelo el
Ejecutivo ingresa la información al sistema para validar si es posible atenderlo con el proceso
de contratación sencilla, es decir, sin que pase a validación de Riesgos, esto a partir de la base
de ofertas aprobadas en el Datamart de Campañas. De ser así, se completa el proceso y envía
el expediente al Backoffice para que proceda al desembolso o emisión de tarjeta.

93
 Diagrama de actividades

Ilustración 17: Diagrama de actividades AS-IS proceso venta en agencias

Fuente: Elaboración propia

Roles de Negocio: Matriz RACI

Analista Riesgos
Gerente Oficina

Controller BO
Ejecutivo BP

Actividades / Roles
Cliente

Ingresa a agencia y genera ticket R

Solicita información de producto financiero R

Recibe cliente y brinda información R

Solicita documentación básica de producto R

94
 Analista Riesgos
Gerente Oficina

Controller BO
Ejecutivo BP
Actividades / Roles

Cliente
Verifica si cuenta con documentación R

Entrega copia de documentación básica R I

Evalúa con "Pre-evaluador" I R A

Verifica información de scoring/laboral R/A C

Imprime formatos TCR R I

Solicita llenado a cliente y registra expediente en

R
sistema

Completa formatos y entrega R A

Revisión BD campañas aprobadas R

Escanea y completa expediente R A I

Tabla 12: RACI Diagrama de actividades AS-IS

Fuente: Elaboración propia

95
ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN

ARQUITECTURA DE DATOS
En esta fase se buscará identificar los componentes candidatos para que sea posible
desarrollar la arquitectura de datos de destino a fin de que sea funcional a la arquitectura de
negocio a la visión de la arquitectura, y que responda a la vez a la petición de trabajo de
arquitectura y a las preocupaciones de los interesados.

Modelo de Datos
Luego del análisis del proceso de “Gestión de Colocaciones” se identifican las entidades que
participan y guardan la información actual del proceso.

El proceso comprende ofrecer los productos del banco a los clientes y no clientes que realizan
transacciones por ventanilla, para ello se cuenta previamente con un sistema que proporciona
la información de productos y ofertas comerciales a determinados clientes, los cuales se ven
reflejados en la entidad Oferta. Este input es generado por un proceso de inteligencia de
negocios y cargado al proceso seleccionado de gestión de colocaciones siempre y cuando sea
requerido actualizar nuevas ofertas. La red de agencias es la encargada de solicitar la carga de
campañas en cualquier día del mes según sea necesario. Las ofertas de productos se van a
agrupar en campañas normalmente de duración mensual.

En la presente sección se mostrará el diagrama físico de datos con sus respectivas relaciones,
este modelo pertenece a la arquitectura de negocio “AS-IS”.

96
 Ilustración 18: Modelo de datos físico proceso seleccionado AS-IS
Fuente: Elaboración Propia

ID Objetivo de Negocio Descripción

E001 Persona Entidad que guarda datos generales del cliente

E002 Oferta Oferta de un producto del banco a un cliente, un

cliente puede tener varias ofertas registradas en una
determinada campaña

97
 ID Objetivo de Negocio Descripción

E003 Campaña Entidad que se crea para agrupar ofertar a los clientes

E004 Accion_Comercial Una acción comercial guarda toda la interacción

entre el cliente y la unidad gestora referente a una
oferta

E005 Producto Producto ofertados por el banco

E006 Sub_Producto Sub producto que pertenece a un producto

E007 Oficina Datos generales de las oficinas de la red

E008 Unidad_Gestora Entidad que referencia a una estación de trabajo en

una agencia, que es ocupada por un agente bancario

E009 Distrito Distritos del Perú

E010 Provincia Provincias del Perú

E011 Departamento Departamentos del Perú

Tabla 13: Descripción modelo de datos físico

Fuente: Elaboración Propia

Matriz de Datos del proceso seleccionado Versus Procesos del negocio

Para tener un mejor análisis de las entidades del negocio seleccionado, en la presente sección
se muestra una matriz de las entidades indicando en que otros procesos de la organización
están siendo utilizadas. Esto tiene como objetivo el ver que tan sensible son algunas entidades
y analizar bien antes de cambiarlas, ya sea para agregar, actualizar o eliminar campos, así
como para evaluar la posibilidad de eliminar alguna entidad que dejará de ser utilizada.

98
Ilustración 19: Matriz de datos vs procesos de negocio
Fuente: Elaboración Propia

99
ARQUITECTURA DE APLICACIÓN
En esta arquitectura se definen las soluciones o aplicaciones tecnológicas y sus relaciones con
los procesos de negocio principales de la organización.

Las aplicaciones que se mostrarán en el siguiente gráfico son las que se utilizan en el día a día
de la red de agencias del banco, cumpliendo con todos los requerimientos y solicitudes de los
clientes. Asimismo se muestran los sistemas que sirven de input y dan soporte al negocio
seleccionado.

En el diagrama se puede apreciar sistemas que tiene relación entre sí, es el caso de la
aplicación Plataforma integral comercial, la cual consume información de servicios para
obtener las ofertas de los clientes. Asimismo ay aplicaciones independientes que sirven de
apoyo a la red de oficina pero que no dependen de otras.

En base a la arquitectura de aplicaciones actual de la organización, se presentan las

aplicaciones empleadas en el proceso de negocio: Gestión de Colocaciones, Venta de
productos financieros en agencias.

100
 Ilustración 20: Diagrama de Aplicaciones
Fuente: Elaboración Propia

ID Objetivo de Negocio Descripción

AP01 NACAR Sistema propio del banco, el cual tiene diversas

funcionalidades de apoyo a la red de oficinas,
permite registrar y actualizar clientes, gestionar
colocaciones, agendar atenciones y ver data histórica
de los clientes.

AP02 Plataforma Integral Sistema web que proporciona información de clientes

Comercial y ofertas de productos

AP03 Portal Web Aplicación web donde los clientes pueden ver sus
cuentas y saldos

AP04 Google Suit Conjunto de herramientas de google para la red de

oficinas

AP05 Business Intelligence Sistema de inteligencia de negocios del banco

AP06 Datamart de Sistema de creación de campañas con temporadas y

Campañas clientes. Este sistema muestra las ofertas de
productos activos OPA del banco, como prestamos
de libre disposición o préstamos hipotecarios.

AP07 Recursos Humanos Sistema integral del banco que guarda información
de todos los colaboradores del banco.

AP08 Apertura de Cuentas Sistema integral de apertura de cuentas de clientes

AP09 Motor de Sistema de cálculo de cotizaciones de productos del

Cotizaciones banco, incluye tasas de interés.

101
 ID Objetivo de Negocio Descripción

AP10 RENIEC Sistema de obtención de datos del cliente

AP11 Productos Sistema de manejo de productos y subproductos

AP12 Personas Sistema integral de información del cliente, se tiene

información personal como lugar de trabajo y salario.

AP13 Seguridad Sistema de seguridad del banco

AP14 Alfresco Sistema integral de manejo de documentos

AP15 Jira Sistema de manejo de tickets

AP16 LDAP Manejo de cuentas y sesiones de los colaboradores

del banco

AP17 Remedy Herramienta para el manejo de tickets de servicio

técnico

Tabla 14: Descripción Aplicaciones

Fuente: Elaboración Propia

Matriz de Aplicaciones del proceso seleccionado versus procesos del Negocio

En el siguiente diagrama se mostrarán todas las aplicaciones del proceso seleccionado y se
identificará si tienen relación con otros procesos de la empresa, esto tiene como objetivo el
ver el impacto de las aplicaciones y las dependencias de las mismas.

102
Ilustración 21: Matriz aplicaciones versus macroprocesos AS-IS
Fuente: Elaboración Propia

103
ARQUITECTURA TECNOLÓGICA
En esta sección se identifica la situación actual de los componentes tecnológicos y cómo se
relacionan con las aplicaciones para dar soporte al proceso de venta en agencias. A efectos
del presente análisis se identificarán los componentes relacionados a las aplicaciones de
usuario final y negocio que impactan en el proceso.

A continuación se presentan los entregables principales de esta fase:

Componentes de tecnología y relaciones con sistemas de información

En este diagrama se podrá ver cómo componentes de aplicación, mencionados en la sección
anterior, se relacionan con los componentes de tecnología abordados en esta sección. Cabe
señalar que tanto componentes, como aplicaciones son gestionados en BBVA México, donde
se centraliza la información de Latinoamérica.

Componente de aplicación Componente de Tecnología

Portal Web / Intranet Servidor de Intranet
Balanceador Load Balancing Server
Plataforma Integral Comercial IIS (arreglo de servidores)
Plataforma Integral Comercial FileServer
Plataforma Integral Comercial Servidor Oracle 10G
Google Suite Cloud
Datamart Campañas (OPA) WAS – XML
Reniec Windows Service Server
RCC Servidor Oracle 10G
NACAR Mainframe
Apertura de cuentas Mainframe
Tabla 15: Componentes de tecnología y aplicaciones AS-IS
Fuente: Elaboración Propia

104
Plataforma de tecnología y descomposición
En la siguiente tabla se considerará la descomposición de las diferentes plataformas que
forman parte de la implementación de la arquitectura tecnológica del proceso seleccionado:

Plataforma Ubicación Componente de Componente de

Tecnológica Aplicación Tecnología

Windows México Portal Web / Intranet Servidor de Intranet

AIX México Balanceador Load Balancing Server

Windows México Plataforma Integral IIS (arreglo de

Comercial servidores)

Windows México Plataforma Integral FileServer

Comercial

AIX México Plataforma Integral Servidor Oracle 10G

Comercial

Linux México Datamart Campañas WAS – XML

(OPA)

Windows México Reniec Windows Service Server

AIX México RCC Servidor Oracle 10G

IBM ZOS México NACAR Mainframe

IBM ZOS México Apertura de cuentas Mainframe

N.A. México Google Suite Cloud

Tabla 16: Plataforma de Tecnología y Descomposición AS-IS

Fuente: Elaboración Propia

105
Ambientes y ubicaciones
El BBVA Continental, en consideración de la criticidad de sus procesos de cara a los clientes
y la organización, ha considerado diferentes ambientes que dan soporte al proceso de
desarrollo de software y control de calidad. Asimismo, es importante señalar que todas las
aplicaciones y datos del proceso se encuentran alojados en servidores en México.

Es importante señalar, que los ambientes de Desarrollo y UAT no consideran un balanceador

para redirigir las solicitudes de los usuarios a los servidores de acuerdo a la carga, así como
únicamente se tiene un servidor que brinda soporte por cada ambiente; en el caso del
ambiente de integración (SIT), si bien se considera, por consideraciones de presupuesto, no se
trata del mismo volumen del ambiente productivo. El detalle de la implementación se podrá
verificar en la siguiente sección Comunicaciones Físicas.

Ambiente Ubicación

Desarrollo México
UAT México
SIT México
Producción México
Tabla 17: Ambientes y Ubicaciones de Tecnología AS-IS
Fuente: Elaboración Propia

Ilustración 22: Mapa BBVA Ambientes y Ubicaciones

Fuente: Elaboración Propia

106
Comunicaciones físicas
El presente diagrama corresponde a los diferentes componentes físicos que están
considerados en el proceso de Gestión de colocaciones, subproceso de venta de productos
financieros en las agencias del BBVA Continental, para efectos del presente estudio se ha
considerado el ambiente productivo.

Como se menciona en la sección anterior, los componentes en general, se encuentran alojados

en el Datacenter de México. Es importante precisar que por el volumen de agencias que
ingresan se ha considerado un balanceador que distribuya la carga entre diferentes servidores
IIS.

Ilustración 23: Diagrama de Comunicaciones Físicas - AS-IS

Fuente: Elaboración propia

107
FUNDAMENTACIÓN Y JUSTIFICACIÓN DE LA ARQUITECTURA
PROPUESTA
La arquitectura propuesta se encuentra soportada por los objetivos estratégicos de la
organización y capacidades descritas en los capítulos anteriores. La necesidad de aprovechar
el flujo de usuarios que acuden diariamente a las agencias como oportunidad para
incrementar las ventas y el cross-sell, además de la satisfacción del cliente es la clave para
entender lo que se requiere.

A continuación se lista la problemática identificada en el proceso actual:

Proceso de colocación reactivo: las agencias esperan a que los clientes consulten o lleguen
predispuestos a obtener uno de los productos financieros, esto genera tiempos muertos en los
Ejecutivos de Negocio si es que no se presentan clientes.

Tiempos de espera no aprovechados: el flujo de clientes que visita las agencias tiene un
tiempo de espera promedio de 7 minutos, sin embargo de acuerdo a la estacionalidad, puede
llegar a ser superior a los 20 minutos. Durante esta espera actualmente no se realiza ninguna
actividad de cara a la experiencia del cliente en la agencia.

Derivación a canales alternativos: durante los últimos 3 años la estrategia del banco fue
potenciar las funcionalidades y transacciones en canales como los cajeros, banca por internet
o aplicación móvil; sin embargo, las agencias siguen teniendo mayor volumen transaccional,
es decir los clientes continúan utilizando este canal más allá del crecimiento de los demás
canales.

Retroalimentación de información de ventas en agencias: con el fortalecimiento de las

colocaciones, se debería contar con información detallada del proceso, llevando una bitácora
de los ofrecimientos y ventas por canal; asimismo, de los intentos de venta no culminados
satisfactoriamente, esto permitiría mejorar los productos alineándolos a las expectativas de
los clientes.

En base a lo indicado, es que se busca contar con un proceso distinto, que rompa paradigmas
en la gestión de las agencias, y empodere a los Ejecutivos brindándoles las herramientas

108
necesarias para incrementar la colocación a través de una venta proactiva, que los acerque a
los clientes y permita cerrar ventas mediante los beneficios propios de los productos,
aprovechando las capacidades existentes en la organización, como es la gestión de campañas.

ARQUITECTURA TO-BE

ARQUITECTURA DE NEGOCIO
La propuesta de arquitectura de negocio busca complementar el proceso de venta ejecutado
actualmente en las agencias del BBVA y contextualizar la experiencia del cliente
aprovechando así las oportunidades que se generan con su visita a una oficina. Así, en las
siguientes secciones, podrá observarse qué cambios se generarán, los cuales se encuentran
alineados a los objetivos de la organización.

Matriz de Objetivos de Negocio vs Procesos

La presente propuesta no modifica la matriz de justificación de objetivos vs procesos, sin
embargo a nivel de sub proceso se fortalecen objetivos puntuales.

Objetivos:

Nro. Objetivo

OE1 Ser el banco principal de los clientes

OE2 Fortalecer la calidad de servicio

OE3 Incrementar colocaciones en banca minorista y mayorista

OE4 Control eficiente de gastos de operación y de riesgo

OE5 Incrementar la utilidad

OE6 Ser el banco digital de la región

109
Matriz:

Procesos / Objetivos OE1 OE2 OE3 OE4 OE5 OE6

Gestión de Colocaciones X X X X X X

Venta proactiva de productos

X X X X X X
financieros en agencias

Se puede apreciar como el proceso objetivo definido mantiene la relación con los objetivos
estratégicos, robusteciendo cada uno de estos, sin embargo, resalta el alineamiento respecto a
los objetivos OE1, OE3, OE4 y OE6.

Proceso de negocio propuesto: Venta proactiva de productos financieros en agencias

El proceso de negocio propuesto, complementa el subproceso Venta de Productos
Financieros en Agencias (contratación sencilla), a través de una arquitectura empresarial
orientada al cliente y la eficiencia organizacional, maximizando los puntos de contacto y
generando nuevas oportunidades.

Para esta propuesta, cuando un cliente o no cliente se acerca a una agencia u oficina, al
registrar su documento de identidad al registro, automáticamente el Ejecutivo de Banca
Personal será alertado en caso tenga ofertas disponibles, este es el cambio principal ya que se
transforma un proceso reactivo a uno proactivo, yendo hacia el cliente cuando este arriba.

Posteriormente, el Ejecutivo presenta al cliente las ofertas a través del Gestor Móvil, una
ventaja es que únicamente se dirige al cliente con lo que ya tiene pre-aprobado, lo que
permite un ratio menor de rechazo de cara a las políticas del banco, este únicamente
dependerá si es que el cliente no solicita una mejora o cambio, la cual podrá ser evaluada por
el Gerente o Subgerente de Oficina de acuerdo a las políticas de Riesgo establecidas. Como
alcance de la presente propuesta, se considera hasta la presentación y aceptación preliminar
de la oferta, las actividades posteriores no sufren mayores variaciones.

110
 Un punto a destacar de este proceso, es la información relevada en las actividades del proceso
ante observaciones o negativas del cliente respecto de la oferta presentada, esto servirá como
input analytics a los macroprocesos de desarrollo de productos y gestión de campañas (ver
macroprocesos en el Capítulo 1, sección Organización Objetivo).

Diagrama de actividades

Ilustración 24: Diagrama de actividades TO-BE proceso venta en agencias

Fuente: Elaboración propia

Roles de Negocio: Matriz RACI

Controller
Ejecutivo

Analista

Actividades / Roles
Riesgos
Gerente
Oficina
Cliente

BO
BP

Ingresa a agencia y genera ticket R I

Verifica si tiene campaña R A

Se acerca a cliente y presenta oferta R A

111
 Controller
Ejecutivo

Analista
Actividades / Roles

Riesgos
Gerente
Oficina
Cliente

BO
BP
Indica si está interesado R I

Acompaña a cliente a plataforma para cerrar venta R

Requiere cambios R I C

Verifica condiciones y scoring R/A C

Imprime formatos TCR R I

Solicita llenado a cliente y registra expediente en

R
sistema

Completa formatos y entrega R A

Escanea y completa expediente R A I

Tabla 18: RACI Diagrama de Actividades TO-BE

Fuente: Elaboración Propia

ARQUITECTURA DE DATOS

Modelo de Datos
Luego de un análisis del proceso de “Gestión de Colocaciones” y definido el modelo de
datos ASIS, se propone un modelo de datos el cual incluya 2 entidades más, una donde se
almacenen los datos del usuario que ingresa al sistema y una de bitácora, donde se
almacenarán los eventos que el usuario ejecute, esto tiene como objetivo el obtener el mayor
historial de comportamiento del cliente y explotar esta información a futuro para realizar
mejoras en el proceso y cambiar las ofertas que están teniendo un menor impacto en el
cliente.

112
La bitácora permitirá guardar el comportamiento del cliente en relación a los productos que
se le ofrece, por ejemplo se guardará información en caso se agenda alguna reunión sobre
algún producto de interés con el cliente y también posteriormente si el cliente acepto el
producto o solo se quedó en agenda. Esta información permitirá determinar que productos
tienen mayor porcentaje de aceptación en los clientes y asimismo ver los productos menos
llamativos, estos últimos podrán ser replanteados o mejorados como resultado del análisis y
explotación de la información dada por la bitácora.

113
Ilustración 25: Modelo de datos físico proceso seleccionado TO-BE
Fuente: Elaboración Propia

114
ID Objetivo de Negocio Descripción

E001 Persona Entidad que guarda datos generales del cliente

E002 Oferta Oferta de un producto del banco a un cliente

E003 Campaña Entidad que se crea para agrupar ofertar a los clientes

E004 Accion_Comercial Una acción comercial guarda toda la interacción

entre el cliente y la unidad gestora referente a una
oferta

E005 Producto Producto ofertados por el banco

E006 Sub_Producto Sub producto que pertenece a un producto

E007 Oficina Datos generales de las oficinas de la red

E008 Unidad_Gestora Entidad que referencia a una estación de trabajo en

una agencia, que es ocupada por un agente bancario

E009 Distrito Distritos del Perú

E010 Provincia Provincias del Perú

E011 Departamento Departamentos del Perú

E012 Usuario Tabla que guarda toda la información del usuario que
ingresa al sistema

E013 Bitácora Entidad donde se guardan eventos del cliente.

Tabla 199: Descripción modelo de datos físico proceso seleccionado TO-BE

Fuente: Elaboración Propia

115
Matriz de Datos del Proceso seleccionado Versus Procesos del Negocio
En el modelo de datos de la arquitectura TO-BE del proceso seleccionado se agrega a la
matriz dos nuevas tablas propuestas.

Ilustración 26: Matriz de datos TO-BE vs procesos de negocio

Fuente: Elaboración Propia

116
ARQUITECTURA DE APLICACIÓN
En base a la arquitectura de aplicaciones actual de la organización, se presentan las
aplicaciones empleadas en el proceso de negocio: Gestión de Colocaciones.

En el siguiente diagrama, se muestra la propuesta de arquitectura de aplicación, la cual agrega

una nueva aplicación para la red de oficinas del banco.

Esta propuesta va alineada al objetivo del banco de ser el banco digital de la región, la
aplicación será para entorno Móvil y se accederá mediante Tablets.

Diagrama de Aplicación

Ilustración 27: Diagrama de aplicaciones TO-BE

Fuente: Elaboración Propia

117
 ID Objetivo de Negocio Descripción

AP01 NACAR Sistema propio del banco, el cual tiene diversas

funcionalidades de apoyo a la red de oficinas,
permite registrar y actualizar clientes, gestionar
colocaciones, agendar atenciones y ver data histórica
de los clientes

AP02 Plataforma Integral Sistema web que proporciona información de clientes

Comercial y ofertas de productos

AP03 Portal Web Aplicación web donde los clientes pueden ver sus
cuentas y saldos

AP04 Google Suite Conjunto de herramientas de google para la red de

oficinas

AP05 Business Intelligence Sistema de inteligencia de negocios del banco

AP06 Datamart de Sistema de creación de campañas con temporadas y

Campañas clientes. Este sistema muestra las ofertas de
productos Activos OPA del banco, que son ofertas
que generan activos, como préstamos de libre
disposición o préstamos hipotecarios

AP07 Recursos Humanos Sistema integral del banco que guarda información
de todos los colaboradores del banco.

AP08 Apertura de Cuentas Sistema integral de apertura de cuentas de clientes

AP09 Motor de Sistema de cálculo de cotizaciones de productos del

Cotizaciones banco, incluye tasas de interés.

118
 ID Objetivo de Negocio Descripción

AP10 RENIEC Sistema de obtención de datos del cliente

AP11 Productos Sistema de manejo de productos y subproductos del

banco

AP12 Personas Sistema integral de información del cliente, se tiene

información personal como lugar de trabajo y salario

AP13 Seguridad Sistema de seguridad del banco

AP14 Alfresco Sistema integral de manejo de documentos

AP15 Jira Sistema de manejo de tickets

AP16 LDAP Manejo de cuentas y sesiones de los colaboradores

del banco

AP17 Remedy Herramienta para el manejo de tickets de servicio

técnico

AP18 Gestor Móvil Plataforma Móvil para la red de oficinas, permitirá

ofrecer los productos del banco

Tabla 2020: Descripción aplicaciones proceso seleccionado TO-BE

Fuente: Elaboración Propia

119
Matriz de Aplicaciones del proceso seleccionado versus procesos del Negocio

Ilustración 28: Matriz aplicaciones versus macroprocesos TO-BE

Fuente: Elaboración Propia

120
ARQUITECTURA TECNOLÓGICA
En esta sección se identifica los componentes tecnológicos requeridos para satisfacer la
propuesta de arquitectura empresarial. A efectos del presente análisis, principalmente, se
identificarán los componentes relacionados a las aplicaciones con mayor impacto en el
proceso.

A continuación se presentan los entregables considerados para esta fase:

Componentes de tecnología y relaciones con sistemas de información

Se puede apreciar cómo se mantienen los componentes para satisfacer el flujo regular que
permanecerá vigente, sin embargo, la propuesta de arquitectura, requiere nuevos
componentes y/o la reutilización de los existentes, los cuales se han marcado en la siguiente
tabla.

Componente de aplicación Componente de Tecnología

Portal Web / Intranet Servidor de Intranet

Balanceador Load Balancing Server

Plataforma Integral Comercial IIS (granja de servidores)

Plataforma Integral Comercial FileServer

Plataforma Integral Comercial Servidor Oracle 10G

/ Gestor Móvil

Google Suite Cloud

Datamart Campañas (OPA) WAS – XML

Reniec Windows Service Server

RCC Servidor Oracle 10G

121
 Componente de aplicación Componente de Tecnología

NACAR Mainframe

Apertura de cuentas Mainframe

Gestor Móvil Tablet

Tabla 211: Componentes de tecnología y aplicaciones TO-BE

Fuente: Elaboración Propia

Plataforma de tecnología y descomposición

En general, la arquitectura destino, plantea la reutilización de todos los componentes, sin
embargo es importante señalar que se incluye nuevo hardware, como son las Tablets, que se
encontrarán en las agencias para dar soporte al proceso. Asimismo, la comunicación de estas
con la red, estará en una red móvil especial, e ingresará a través de un firewall.

Plataforma Ubicación Componente de Componente de

Tecnológica Aplicación Tecnología

Windows México Portal Web / Intranet Servidor de Intranet

AIX México Balanceador Load Balancing

Server

Windows México Plataforma Integral IIS (arreglo de

Comercial servidores)

Windows México Plataforma Integral FileServer

Comercial

AIX México Plataforma Integral Servidor Oracle 10G

Comercial

122
 Plataforma Ubicación Componente de Componente de
Tecnológica Aplicación Tecnología

Linux México Datamart Campañas WAS – XML

(OPA)

Windows México Reniec Windows Service

Server

AIX México RCC Servidor Oracle 10G

IBM ZOS México NACAR Mainframe

IBM ZOS México Apertura de cuentas Mainframe

N.A. México Google Suite Cloud

Android México Gestor Móvil Tablet (ref.

Samsung)

Tabla 22: Plataforma de Tecnología y Descomposición TO-BE

Fuente: Elaboración Propia

Ambientes y ubicaciones
En este caso la propuesta de arquitectura, no genera variación en los ambientes y ubicaciones,
a manera de referencia se presenta la tabla con esta información.

Ambiente Ubicación

Desarrollo México

UAT México

SIT México

123
 Ambiente Ubicación

Producción México

Tabla 23: Ambientes y Ubicaciones de Tecnología TO-BE

Fuente: Elaboración Propia

Comunicaciones físicas
En este diagrama se podrá apreciar los requerimientos de tecnología para satisfacer la
propuesta de arquitectura, los demás componentes se mantienen para dar soporte al proceso
regular que permanecerá vigente. En tal sentido, se agregará tanto componentes de hardware
para la herramienta que utilizarán los usuarios (Tablets), como un servidor para dar soporte a
esta, el cual se conecta con la base de datos existente.

Ilustración 29: Diagrama de Comunicaciones Físicas – TO-BE

Fuente: Elaboración propia

124
ANÁLISIS DE BRECHAS

Arquitectura de Negocio
Luego de analizar el proceso seleccionado de la línea base y el esperado u objetivo, se ha
podido realizar la comparación entre las actividades correspondiente al proceso:

Escanea y completa expediente

Verifica condiciones y scoring
Proceso de

registra expediente en sistema

Se acerca a cliente y presenta

Completa formatos y entrega

plataforma para cerrar venta
Registra decisión y motivo
Ingresa a agencia y genera

negocio TO-BE

Solicita llenado a cliente y

Verifica si tiene campaña

Imprime formatos TCR

Acompaña a cliente a
Proceso de negocio

Eliminar
AS-IS
oferta
ticket

Ingresa a agencia y genera ticket

A
Recibe cliente y brinda información
E
Solicita documentación básica de
E
producto
Verifica si cuenta con
E
documentación
Entrega copia de documentación
E
básica
Evalúa con "Pre-evaluador"
E
Verifica información de
M
scoring/laboral
Imprime formatos TCR
M
Solicita llenado a cliente y registra
M
expediente en sistema
Completa formatos y entrega
M
Revisión BD campañas aprobadas
E
Escanea y completa expediente
M

Nuevo I I I I
M = Mantener, A=Actualizar, I=Implementar, E=Eliminar

Ilustración 30: Análisis brechas procesos de negocio AS-IS vs TO-BE

Fuente: Elaboración propia

125
GAPs identificados en la Arquitectura de Negocio
Los GAPs encontrados en la arquitectura de datos del proceso de Gestión de Colocaciones,
subproceso de venta de productos financieros en agencias, son:

Tipo ID Descripción

Actualizar GAP1 Se identificará los clientes que ingresan a la agencia y

comprobará las ofertas disponibles para estos, con ello se busca
maximizar la posibilidad de colocación en la agencia, lo cual está
alineado con el objetivo de incremento de colocaciones

Implementar GAP2 Se debe poder verificar en una herramienta digital las campañas
de los clientes, así se alineará al objetivo de ser el banco digital
por excelencia.

Implementar GAP3 La presentación de las ofertas de productos financieros en el lugar

de la agencia en donde esté el cliente, acercándose a él y
mejorando los niveles de satisfacción.

Implementar GAP4 En caso no esté interesado en la oferta o no se pueda concluir,

levantar la información generada en la venta. Esto podrá
retroalimentar a la organización, mejores productos, genera
mayor probabilidad de adquisición futura.

Implementar GAP5 Dirigir al cliente a la plataforma para que puedan cerrar el

proceso de venta, este sería el cierre del cambio principal al
proceso actual.

Eliminar GAP6 Venta reactiva, donde no se aprovechan las esperas, perteneciente

al proceso regular.

126
 Tipo ID Descripción

Eliminar GAP7 Ya no es necesaria la documentación, en cuanto se trata de ofertas

aprobadas.

Eliminar GAP8 Idem GAP7.

Eliminar GAP9 Idem GAP7.

Eliminar GAP10 No es necesaria la pre-evaluación que se hacía, ya que las ofertas

tienen los filtros duros previos, se busca eficiencia en el cierre.

127
Arquitectura de Datos
Se presenta el análisis de brechas de la arquitectura de datos, en este análisis de compararon
la arquitectura de datos AS-IS y TO-BE, el objetivo de esta sección es identificar claramente
cuáles serán los cambios en el modelo de datos y el impacto que tendrán en la solución
propuesta.

Arquitectura
Datos TO-BE
Accion_Comercial

Unidad_Gestora
Sub_Producto

Departamento
Arquitectura Datos
Campaña

Provincia
Producto

Eliminar
Bitácora
Persona

Usuario
Oficina

Distrito
Oferta

AS-IS

Persona
M
Oferta
M
Campaña
M
Accion_Comercial
A
Producto
M
Sub_Producto
M
Oficina
M
Unidad_Gestora
M
Distrito
M
Provincia
M
Departamento
M

Nuevo I I
M = Mantener, A=Actualizar, I=Implementar, E=Eliminar

Ilustración 31: Análisis brechas arquitectura de datos AS-IS vs TO-BE

Fuente: Elaboración propia

GAPS identificados en la Arquitectura de Datos:

Los GAPs encontrados en la arquitectura de datos del proceso de Gestión de Colocaciones,
subproceso de venta de productos financieros en agencias, son:

128
 Tipo ID Descripción

Actualizar GAP11 Se actualizará la entidad Acción Comercial, agregando un campo

de Canal, este campo indica cual es el canal de atención brindada
al cliente, los canales pueden ser canal web o canal móvil, este
último si el cliente es atendido por las tablets que estarán
controladas por los ejecutivos en las oficinas del banco.

Implementar GAP12 Se implementará la entidad Bitácora, esta entidad es requerida

para guardar el comportamiento del cliente en relación a los
productos ofrecidos por el ejecutivo. Con esta información se
podrá analizar qué productos tiene mayor impacto en el cliente y
que productos deben ser mejorados. Esta entidad será trabajada
con un proceso de Business Intelligence.

Implementar GAP13 Se implementará la entidad Usuario, con el objetivo de guardar

información más detallada del ejecutivo de venta, esta
información será utilizada para medir los indicadores de ventas en
las oficinas ya que cada ejecutivo tiene un jefe el cual tiene
objetivos de ventas que cumplir.

Nota: No se han identificado entidades que deban eliminarse.

129
Arquitectura de Aplicaciones
En la presente sección se muestran las aplicaciones del proceso seleccionado, y se identifica
lo siguiente:
Plataforma Integral Comercial

Arquitectura
Aplicación TO-BE

Datamart de Campañas

Motor de Cotizaciones
Business Intelligence

Apertura de Cuentas
Recursos Humanos

Gestor Móvil
Google Suit
Portal Web

Seguridad
Productos
Arquitectura Aplicación

RENIEC

Personas

Eliminar
Alfresco

Remedy
LDAP
AS-IS
Nacar

Jira
Nacar
M
Plataforma Integral Comercial
A
Portal Web
M
Google Suit
M
Business Intelligence
A
Datamart de Campañas
M
Recursos Humanos
M
Apertura de Cuentas
M
Motor de Cotizaciones
M
RENIEC
M
Productos
M
Personas
M
Seguridad
M
Alfresco
M
Jira
M
LDAP
M
Remedy
M

Nuevo I
M = Mantener, A=Actualizar, I=Implementar, E=Eliminar

Ilustración 32: Análisis brechas arquitectura de aplicaciones AS-IS vs TO-BE

Fuente: Elaboración propia

GAPS identificados en la Arquitectura de Aplicaciones:

Los GAPs encontrados en la arquitectura de aplicaciones del proceso de Gestión de
Colocaciones son:

130
Tipo ID Descripción

Actualizar GAP14 Se actualizará el sistema de Plataforma Integral Comercial para

que soporte el nuevo campo de la entidad Acción comercial y
guarde información del canal que se está usando, en el caso de
esta aplicación el canal será Web.

Actualizar GAP15 Se actualizará el sistema de Business Intelligence en el cual se

procederá a tomar en cuenta la explotación granular de la
información de las entidades usuario y bitácora las cuales serán
agregadas en la propuesta de la arquitectura de datos TOBE. Esta
información será ingresada tanto del gestor móvil propuesto como
de la plataforma web existente de ofertas.

Implementar GAP16 Se implementará el sistema Gestor Móvil, el cual es la versión

para dispositivos móviles de la Plataforma Integral comercial, en
la cual se podrán ofrecer los productos del cliente.

Nota: No se han identificado aplicaciones que deban eliminarse.

131
Arquitectura Tecnológica
Según se pudo verificar en las secciones anteriores, la arquitectura tecnológica destino
reutiliza las capacidades internas identificadas en la línea base, quedando la implementación
de los componentes relacionados a la solución planteada. En la siguiente tabla se puede
apreciar el detalle comparativo.

Mainframe (Apertura cuentas)

Arquitectura

Servidor Oracle 10G (RCC)

Tecnológica TO-BE
IIS (granja de servidores)

Windows Service Server

WAS – XML (Datamart
(Plataforma Comercial)
Load Balancing Server

Mainframe (NACAR)
Servidor Oracle 10G

Cloud Google Suite

Servidor de Intranet

Campañas)
FileServer

Arquitectura Tecnológica

(Reniec)

Eliminar
Tablet
AS-IS

Servidor de Intranet
M
Load Balancing Server
M
IIS (granja de servidores)
M
FileServer
M
Servidor Oracle 10G (Plataforma
A
Comercial)
Cloud Google Suite
M
WAS – XML (Datamart
M
Campañas)
Windows Service Server (Reniec)
M
Servidor Oracle 10G (RCC)
M
Mainframe (NACAR)
M
Mainframe (Apertura cuentas)
M

Nuevo I
M = Mantener, A=Actualizar, I=Implementar, E=Eliminar

Ilustración 33: Análisis brechas arquitectura tecnológica AS-IS vs TO-BE

Fuente: Elaboración propia

132
GAPs identificados en la Arquitectura Tecnológica:
Los GAPs encontrados en la arquitectura de datos del proceso de Gestión de Colocaciones,
subproceso de venta de productos financieros en agencias, son:

Tipo ID Descripción

Actualizar GAP17 Se reutilizará la base de datos Oracle 10g que soporta la gestión
comercial; para dar soporte a la propuesta, se debe repotenciar y
habilitar la conexión del servidor móvil.

Implementar GAP18 Se debe adquirir Tablets para las agencias donde se podrá ejecutar
la aplicación que de soporte al nuevo proceso. Las características
planteadas son:

Pantalla: 9.5 pulgadas

SO: Android

Marca: Samsung (de preferencia)

Nota: No se han identificado componentes que deban eliminarse.

133
EVALUACIÓN DE IMPACTO
La evaluación de impacto está relacionada a los riesgos que supone la implementación de la
propuesta de arquitectura empresarial.

En la presente sección se presentan los riesgos encontrados para la aplicación de la propuesta

de arquitectura, su probabilidad, su impacto y su estrategia de mitigación.

Para identificar los factores de riesgo que pueden poner en peligro el desarrollo del proyecto
se emplea la matriz de probabilidad e impacto definida por el PMBOK.

Ilustración 34: Matriz de Probabilidad e Impacto

Fuente: Guía del PMBOK

Donde las escalas para la probabilidad e impacto son:

Ilustración 35: Escalas de Probabilidad e Impacto

Fuente: Guía del PMBOK

134
A continuación, se presenta la matriz de riesgos identificados para la implementación del
proyecto, donde la columna resultado define la prioridad de atención de acuerdo a los
siguientes colores.

Ilustración 36: Importancia de los Riesgos

Fuente: Guía del PMBOK

Tabla 24: Matriz de Riesgos Identificados

Fuente: Elaboración propia

135
OPORTUNIDADES Y SOLUCIONES

Estructura de Desglose de Trabajo - EDT

Este diagrama permitirá reconocer los diferentes entregables que forman parte del proyecto
de arquitectura empresarial, asimismo las fases en los cuales están enmarcados. Es importante
señalar, que estos entregables se podrán verificar en los diferentes capítulos del presente
documento.

Ilustración 37: EDT

Fuente: Elaboración propia

136
Cuadro Resumen del Plan de Migración
BRECHA PROYECTO PROBLEMA COSTOS SOLUCIÓN POTENCIAL RIESGOS
GAP1 Proyecto: Proponer Desarrollo No se cuenta con un notificador de que un cliente o no cliente esta sacado un S/. 1,265,520 Incluir una notificación a un dispositivo móvil contralado por un ejecutivo de No identificar flujos alternos de registros rápidos en caso de personas que
de Gestor Móvil ticket en la agencia venta, para poder identificar clientes que sacan ticket para ser atendidos ingresan al banco no son clientes o no tienen ninguna cuenta con el banco
GAP2 Proyecto: Proponer Desarrollo No se identifica ráapidamente en las agencias si un cliente tiene ofertas asignadas Identificar en línea por medio digital si un cliente tiene ofertas solo con el No contar con información ráapida y oportunda que alimente la solución
de Gestor Móvil documento de identidad planteada
GAP3 Proyecto: Proponer Desarrollo No se aprovechan los tiempos de espera del cliente dentro de la oficina para Contar con una aplicación móvil que permita a los ejecutivos del banco acercarse No contar con dispositivos disponibles en toda la red de agencias.
de Gestor Móvil ofrecerle las ofertas de productos del banco a los clientes desde el primer momento que ingresan a la agencia para ofrecerles Layout de las agencias que genere complicaciones en el pasillaje
productos
GAP4 Proyecto: Proponer Desarrollo No se cuenta con información continua para la mejora de las ofertas y/o Permitir registrar la decisión y/o feed-back de los clientes ante una negativa de la No medir tiempos máximos por actividad de ofrecer productos al cliente
de Gestor Móvil productos oferta
GAP5 Proyecto: Proponer Desarrollo No se aprovechan los tiempos de espera del cliente dentro de la oficina para Marcar las pre-aceptaciones de los clientes, para luego dirigirlos a las No medir tiempos máximos por actividad de ofrecer productos al cliente
de Gestor Móvil ofrecerle las ofertas de productos del banco plataformas con el fin de cerrar el proceso de forma rápida
GAP6 Proyecto: Proponer Desarrollo Poco aprovechamiento del volumen total de clientes que visitan las agencias con Eliminar esta actividad en el nuevo proceso, dado que ya no es necesaria Ninguno
de Gestor Móvil el proceso de venta reactivo
GAP7 Proyecto: Proponer Desarrollo Referente a la solicitud de la documentación, el cliente podría no contar con la Eliminar la solicitud de documentos y aprovechar de una mejor manera las Ninguno
de Gestor Móvil información, lo que no cierra la venta interfaces con la documentación básica
GAP8 Proyecto: Proponer Desarrollo Demora en recopilación de documentos necesarios para evaluar al cliente Eliminar la recopilación de documentos Ninguno
de Gestor Móvil
GAP9 Proyecto: Proponer Desarrollo La documentación genera muchos gastos administrativos y toma muhco tiempo Eliminar al máximo en lo posible manejar documentos físicos para la colocación Ninguno
de Gestor Móvil de productos
GAP10 Proyecto: Proponer Desarrollo No se cuenta con una evaluación previa a clientes en riesgo para tener Contar con ofertas que consideren los filtros de preevaluación del cliente para Ninguno
de Gestor Móvil información inicial y que la evaluación de un cliente no tome mucho tiempo aprovechar el tiempo de una manera eficiente
GAP12 Proyecto: Proponer Desarrollo No se registra el comportamiento del cliente en relación a los productos que le Registrar adecuadamente la interacción del cliente con el ejecutivo del banco en No identificar bien los eventos a registrar por parte del cliente. No contar con
de Gestor Móvil son ofrecidos por lo que no se puede determinar si los productos tiene impacto y relación a los productos que se le ofrece, así sea para indicar colocaciones o suficiente detalle de los eventos para poder mapear los eventos desde el personal
atraen nuevos clientes al banco pérdida de ofertas de atención hasta el territorio al que pertenece la agencia
GAP13 Proyecto: Proponer Desarrollo No se cuenta con información adicional del usuario que esta atendiendo al cliente Registrar a detalle datos del usuario que ofrece productos del banco mediante las No tener bien definida la jerarquía de jefes de los ejecutivos de oficina
de Gestor Móvil en u determinado canal, ni quien es su jefe directo para poder mapear la jerarquía plataformas web y móvil en las agencias

GAP16 Proyecto: Proponer Desarrollo Actualmente las agencias no cuentan con un sistema móvil para ofrecer los Permitir a los ejecutivos del banco contar con un sistema móvil de ofertas, en el No identificar bien los costos escondidos del proyecto como el relacionado a la
de Gestor Móvil productos y aprovechar los tiempos de espera del cliente en las colas. cual se pueda obtener toda la información del cliente para generar colocaciones compra de tablas para las agencias y su respectivo mantenimiento.
en las agencias Bajo número de clientes digitales en el banco.
GAP17 Proyecto: Proponer Desarrollo Capacidad de almacenamiento actual limitada, se esperará un mayor volumen de Aumentar la capacidad de la base de datos Oracle 10g para que soporte un No medir bien el crecimiento mensual del volumen de información
de Gestor Móvil información cada mes mayor volumen de almacenamiento.
GAP18 Proyecto: Proponer Desarrollo Incapacidad de ofrecer los productos del banco en diferentes canales. No se Adquirir tabletas de 9.5”. El modelo homologado es Samsung Tab S2 (costo No determinar bien las capacidades técnicas de los equipos, para que cubran las
de Gestor Móvil aprovechan los tiempos de espera del cliente para ofrecer las ofertas del banco. aprox S/. 2400). necesidades del ejecutivo de oficina
La tableta debe contar con soporte de conexión por redes WIFI y 4G (chip de
datos) para apoyar la movilidad fuera de instalaciones del Banco.

GAP11 Proyecto: Actualización de El modelo de datos actual no soporta el registro del canal de atención al cliente. S/. 6,000 Incluir el campo que permita el registro del canal de atención desde las No se identifique bien los campos a guardar.
Plataforma Integral Comercial aplicaciones de ofertas en las agencias del banco
GAP14 Proyecto: Actualización de El sistema Actual de ofertas no guarda información del canal que está siendo Incluir el registro del canal de atención desde las aplicaciones de ofertas en las No identificar todos los componentes de la aplicación y diagramas que deben ser
Plataforma Integral Comercial atendido el cliente. agencias del banco. actualizados para guardar coherencia en todo el sistema
GAP15 Proyecto: Explotación de El sistema actual de Business Intelligence no explota información del S/. 50,000 Brindar la información necesaria al sistema de Business Intelligence del banco No contar con formatos de datos adecuados que dificulten mas la explotación de
Información de colocación en comportamiento del cliente, lo cual no permite evaluar el impacto de los para poder analizar mejor el impacto de las ofertas en agencias. la información
agencias productos ofrecidos

Arquitectura de Negocio
Arquitectura de Datos
Arquitectura de Aplicación
Arquitectura Tecnológica

Tabla 25: Cuadro resumen plan de migración

Fuente: Elaboración propia

137
Diagrama de Beneficios
A través de este entregable se busca relacionar las características principales de la
arquitectura destino con los indicadores clave de la organización, lo cual es importante para
asegurar el alineamiento entre los proyectos e iniciativas planteadas hacia los objetivos
estratégicos.

Características Impacto Beneficios KPI*

Mayor cruce de
SOW
clientes

Aprovechamiento de visitas
Incremento de oportunidades
a las agencias de clientes y Incremento de
de colocación de productos
usuarios productos vendidos

Colocaciones brutas
Incremento ratio de
Conocimiento de la calidad ocupación
de las ofertas

Feedback en línea por cada Mejoras en los leads

Eficiencia
intento de venta Oportunidades para mejorar cargados
los productos o combos
existentes
Desarrollo de
productos
Integración con sistemas Tiempo de implementación IReNe
existentes más corto
Menor gasto

Eficiencia en la
Utilización de solución Facilita el acercamiento a los Clientes digitales
atención
móvil clientes y usuarios

Reconocimiento
digital

* Relacionados a objetivos estratégicos

Ilustración 38: Diagrama de Beneficios

Fuente: Elaboración propia

138
CONCLUSIONES
Como resultado da investigación y análisis de la arquitectura empresarial es posible concluir,
que utilizar el marco de trabajo TOGAF, enfocándolo en procesos específicos, como el de
Gestión de Colocaciones, es clave en organizaciones financieras del tamaño del BBVA
Continental, ya que permite dirigir esfuerzos y capacidades consiguiendo que de forma ágil
se puedan plantear cambios en los procesos, o como en el caso de la presente propuesta,
generar procesos alternativos que agreguen valor y satisfagan a los objetivos estratégicos.

Al realizar el análisis de las brechas entre la arquitectura de la línea base y la arquitectura

destino del proceso de venta en agencias del banco, se logró plantear diferentes iniciativas y/o
proyectos para cubrir dichas brechas, sin embargo, se logró concluir que para levar a cabo los
proyectos se deben tener identificado los perfiles profesionales que trabajarán en la
propuesta, así como la priorización de los proyectos basados en las capacidades de la
organización, el nivel de alineamiento con los objetivos estratégicos y la cartera de proyectos
del BBVA Continental.

Después de todo el análisis realizado, al identificar los diferentes gaps del proceso de venta
en agencias, entre la situación actual y deseada, fue necesario tener un enfoque holístico para
dar con una propuesta de solución adecuada, es decir, los diferentes dominios no podían estar
divorciados entre sí, ya que se busca impactar en las colocaciones a nivel general del BBVA
Continental; un diagrama de beneficios como cierre es clave para aterrizar la información de
los diferentes entregables y conceptos, asimismo contar con indicadores que midan estos
beneficios para tener un claro mapa de que beneficios necesitan una mejora adicional a
futuro.

139
CAPÍTULO 3. MÉTODOS ÁGILES PARA EL
DESARROLLO DE SOFTWARE

INTRODUCCIÓN
En el presente capítulo se identifican los requerimientos y características necesarias para
adoptar un método de desarrollo ágil en la organización objetivo para llevar a cabo la
arquitectura empresarial propuesta en el capítulo anterior. Así, primero se determinan los
objetivos que se generan al promover un cambio filosófico en el equipo de trabajo, luego se
analizarán las fortalezas y debilidades de la organización para adoptar este paradigma.

Asimismo, se realiza un diagnóstico del grupo y se identifica la composición que debe tener
este, llegando al detalle de perfiles, cantidad de recursos y costos, de tal manera que se cuente
con un soporte adecuado que permita la adaptación al modelo.

Finalmente, se evalúa el marco de trabajo que se adapte de mejor manera a la organización, y

se definen dinámicas y herramientas claves para el éxito en la ejecución de los proyectos.

OBJETIVOS

Objetivo general
Proponer un modelo iterativo y evolutivo de desarrollo que permita generar ganancias rápidas
a la organización acelerando el time-to-market al adaptar la arquitectura empresarial a las
necesidades de los clientes.

140
Objetivos específicos
 Generar equipos autodirigidos que agreguen valor a la organización, basados en las
responsabilidades y no los roles, con resultados asociados a la medida y eficiencia en la
que todos se comprometen con estas.

 Mejorar la respuesta ante los cambios que surgen durante la ejecución de los proyectos
tecnológicos.

 Romper los silos entre los miembros de los equipos de trabajo que participan en los
proyectos.

IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES

La matriz FODA o DAFO (SWOT por sus siglas en inglés) ha sido durante años la
herramienta por excelencia para conocer la situación real en la que una organización, la
mayoría de autores da crédito a Albert Humphrey como el creador de esta herramienta.

Heinz Weihrich, en “The TOWS Matrix, A Tool for Situational Analysis” 26, brinda
consideraciones generales en planificación estratégica y ayuda a identificar adecuadamente
las variables que permitan hacer coincidir las amenazas y oportunidades ambientales con las
debilidades de la empresa y sus fortalezas. Para la presente propuesta, se ha tomado en cuenta
este texto, y se brinda un ejemplo tangible por cada variable encontrada.

Es importante precisar que el análisis se sitúa sobre el estado de la organización en el marco

de la implementación de un método ágil de desarrollo.

26
[19] WEIHRICH 2011

141
 FORTALEZAS DEBILIDADES

Cultura de la organización enfocada a la Dependencia de casa matriz para toma de

innovación: Nuevos modelos de decisiones clave: sobretodo en términos de
agencias enfocados en la transparencia, presupuesto, necesidad de solicitar
nuevos productos y campañas aprobación a PMO regional
(Hipotecario Libre, Tarjeta Zero,
Poco tiempo disponible de usuarios clave
Tarjetas Contactless, Cuenta Ganadora,
de proyectos tecnológicos: coordinaciones
Conciertos)
propias de negocio dejan poco espacio para
Compromiso de alta gerencia, cambios compartir con proyectos
estructurales que soportan el cambio de
Rigurosidad en documentación mínima
paradigma: Creación de gerencia de
INTERNO

para pases a producción: los pases son

Banca Digital y Equipos Ágiles
realizados por personal externo y requieren
Capacidad de retención de de documentación de acuerdo a un
colaboradores: bajo ratio de rotación en protocolo establecido
personal administrativo
Dependencia de diferentes plataformas y
Amplio presupuesto para ecosistema equipos técnicos: la arquitectura actual
digital, ya cuenta con proyectos ágiles tiene un modelo tallarín, a través del cual
iniciados: ver entrevista a Gerente de son cientos de conexiones que hay que
Desarrollo de Negocios en Anexo 6 controlar

Tendencia a la procrastinación al abarcar

demasiadas iniciativas sin tener los
recursos o capacidades necesarios

OPORTUNIDADES AMENAZAS
EXTERNO

Amplia exposición de las metodologías Reducción del time-to-market de

ágiles competidores principales

Apogeo de diseño centrado en personas Búsqueda de otras empresas por talento

142
En general, cada punto señalado se encuentran documentados, por ejemplo en los Anexos 1 y
2 se puede apreciar los esfuerzos de la organización objetivo por realizar cambios
significativos en la forma de trabajo que permitan alcanzar sus objetivos estratégicos, lo cual
constituyen fortalezas que se deben potenciar.

Por otro lado, respecto a las debilidades, fundamentalmente el ser un banco global, existe
dependencia y requerimientos mínimos definidos por la casa matriz, en este caso BBVA
España; adicionalmente, como se ha mencionado previamente, la arquitectura tiene diferentes
componentes que hace necesario coordinación extensa con diferentes responsables. Para
reducir el impacto de estas debilidades, es clave apalancarse en las fortalezas, sobre todo
ahora que Perú está definido como el que debe ser el referente digital de la región (ver
objetivos estratégicos).

DIAGNÓSTICO DEL GRUPO

Realizar un diagnóstico del grupo es clave, pero este debe estar enmarcado en la evaluación
de la situación actual que se gesta en la organización, cuáles son los problemas que atraviesa
a partir de las debilidades identificadas.

Para analizar este contexto, se utiliza el enfoque de complejidad de Cynefin, con ello se
evalúa la efectividad de aplicar métodos ágiles de desarrollo en la organización objetivo para
el desarrollo de la arquitectura empresarial propuesta del proceso de venta proactiva en
agencias.

De acuerdo a lo señalado, Cynefin propone cinco dominios bajo los cuales pueden situarse
los problemas (simple, complicado, complejo, caótico y desordenado), en este caso luego de
tomar en consideración las variables internas y externas del negocio, procesos, personas y
capacidades, el BBVA se enfrenta a un dominio COMPLEJO, por cuanto la problemática que
la propuesta busca resolver es distinta a lo que antes se ha hecho en la organización e
inclusive a nivel regional, por lo que se requerirá creatividad e innovación para llevarla a
cabo. Será importante señalar, que si bien se tienen expectativas sobre los resultados, se
requiere una rápida adaptación conforme se vaya adquiriendo experiencia y retroalimentación

143
de usuarios y clientes; en este escenario es que se recomienda la adopción de metodologías
ágiles.

La cultura de la organización tiene a la tolerancia al error como una de sus virtudes, esto
permite aprender continuamente de los desaciertos de forma tal que se cuente con mejores
productos y herramientas. Crear una solución nueva, bajo un nuevo contexto que el banco
debe adoptar, requiere de esta fortaleza, y de reconocer a cada integrante del equipo de
trabajo como factor crítico para alcanzar los objetivos.

Conocidas no solo las fortalezas, sino sobre todo las debilidades, BBVA ha venido
repotenciando el grupo humano que ejecuta los diferentes proyectos digitales de la
organización, desde la alta gerencia, hasta los diferentes equipos de trabajo. En el siguiente
cuadro se podrá apreciar cómo el grupo abordará los problemas que se podrían generar
producto de las debilidades ya identificadas.

Debilidad Problema Acción

Dependencia de casa matriz Retraso en las aprobaciones Definir autonomías globales

para toma de decisiones de nuevos proyectos o para proyectos de banca
clave controles de cambio digital con visión cliente

Poco tiempo disponible de Definiciones incompletas o Usuarios clave formarán

usuarios clave de proyectos entendimientos incorrectos parte de los equipos de
de las necesidades proyecto a tiempo completo,
ver siguiente sección para
mayor detalle

Rigurosidad en Gasto de horas hombre en Generación de formatos

documentación mínima para tareas que no agregan valor flexibles en coordinación con
pases a producción al producto final la Matriz y Datacenter
México

144
 Debilidad Problema Acción

Dependencia de diferentes Falta de alineamiento entre Definir responsables que

plataformas y equipos los diferentes proyectos y consoliden las diferentes
técnicos demoras en desarrollos necesidades compartidas y
las prioricen

Seleccionar proyectos con la

menor cantidad de
dependencia (caso Barclays
Bank27) y/o iniciarlos con la
mayor cantidad ya resuelta

Tabla 26: Cuadro Debilidad – Problema – Acción

Fuente: Elaboración Propia

Es importante precisar que el BBVA Continental a partir del 2016 ha adoptado el marco de
trabajo SCRUM y cuenta con diferentes equipos que llevan a cabo los proyectos de la
gerencia de Banca Digital (ver Organigrama). A continuación se profundiza en la selección
de la herramienta, dinámicas y entregables, además de cómo se gesta el cambio cultural en la
organización.

COMPOSICIÓN DE LOS GRUPOS DE TRABAJO

La organización, al tomar la decisión de generar un cambio en la forma de ejecutar proyectos
tecnológicos, e inclusive de negocio, inicia por contar con un partner que apoye y dé soporte
a la gestión del cambio. Aquí se presentan algunas acciones producto de este
acompañamiento y, en algunos casos, relacionándolo con casos de éxito de otras instituciones
financieras globales, con el fin de seleccionar y organizar los grupos que formarán parte de
los proyectos de desarrollo ágil.

27
[25] MANJI y JOLIC 2011

145
Casos de éxito en la adopción del modelo ágil para entidades financieras, como ING 28 o
Barclays, mencionan que el primer objetivo al comenzar a armar grupos de trabajo era
mejorar la entrega de proyectos individuales, lo cual se podía ejecutar a través de proyectos
piloto. En el caso del BBVA no fue diferente, el partner entrena y capacita durante semanas
intensivas a los equipos encargados de llevar a cabo el piloto tanto en habilidades blandas,
como en conceptos, técnicas y herramientas, lo mismo con los llamados a ser Scrum Master;
adicionalmente se debe adecuar infraestructura adecuada para poder situar a todos en la
misma sala, con ello se busca facilitar la coordinación e integración de los miembros.

Como se ha mencionado, y se revisa a detalle en las siguientes secciones, el BBVA

Continental apuesta por el marco de trabajo SCRUM como soporte para la realización de
proyectos ágiles, por lo que el grupo de trabajo debe contar con los siguientes roles, definidos
en el marco teórico, y que en esta parte se explica qué elementos de la organización lo
conforman y con qué características:

Rol Descripción

Juan Palacio, en Flexibilidad con Scrum, indica que las empresas

pueden optar porque en lugar de una persona con la función de
“ScrumMaster”, sean las personas y puestos más adecuados en cada
organización los que reciban la formación adecuada y asuman las
funciones correspondientes para cubrir esta responsabilidad. Así lo
hizo el BBVA, sin embargo, a pesar del entrenamiento, para los
Scrum Master proyectos iniciales, y mientras se está adoptando el modelo, se
utilizará un experto del partner para dar soporte y guía al Scrum
Master definido por la organización.

Su rol será de facilitador o coach del equipo no queda de lado, así

como para brindar apoyo al equipo. Entre sus responsabilidades, de
acuerdo a lo indicado por la Guía SBOK, están:

28
[24] AROONI y VERHEYEN 2012

146
Rol Descripción

Ayudar a identificar los socios

Formar el equipo Scrum: selección, colaboración y desarrollo

Facilitar en las reuniones, tareas, estimaciones

Ayudar al Product Owner en la creación de la lista priorizada

Asistir en el desarrollo de la lista de pendientes

Asegurar la actualización de los tableros

Facilitar la presentación de los entregables

Garantizar que exista un ambiente ideal de trabajo

Representar al equipo Scrum

Finalmente, entre las principales características, fuera del

conocimiento de Scrum, están: Motivador, Accesible, Perceptivo,
Moderador, Solucionador de Problemas y Coordinador.

147
 Rol Descripción

En este punto cobra importancia una de las debilidades mencionadas

en las secciones previas. Este rol será tomado por un usuario del
Negocio con autonomía para toma de decisiones, siendo que se trata
del representante de los interesados en el producto final, sin
embargo su asignación será parcial puesto que tendrá otros
proyectos a los que estará asignado. Las responsabilidades con las
que contaba serán delegadas.

Nuevamente, tomando lo indicado por Juan Palacio, para el

proyecto enmarcado en el presente trabajo, al estar relacionado a la
adquisición de clientes, el rol será desempeñado por responsable de
proceso, en este caso el Jefe de Gestión de Clientes en la Gerencia
de Desarrollo de Negocio.

En el caso de ING, por ejemplo, una de las expectativas es que la

satisfacción del cliente se vea incrementada con una mayor
participación del negocio en los proyectos.

Entre sus responsabilidades principales según la Guía SBOK están:

Product Owner
Definir la visión del proyecto

Ayudar a la elección del Scrum Master y del equipo

Definir los criterios de aceptación

Proporcionar orientación y claridad sobre las estimaciones

Aprobar las historias de usuario

Aceptar / Rechazar los entregables

Participar en reuniones, por ejemplo la retrospectiva

Finalmente, entre las principales características: Manejar148

incertidumbre, Decisivo, Pragmático, Orientado al logro,
Comunicador y Proactivo.
 Rol Descripción

El equipo de desarrollo se compone por personas con características

técnico-funcionales para la construcción del producto y serán auto-
organizados.

Es importante precisar que un participante puede tener una o más de

estas características, asimismo puede formar parte de la
organización, como ser miembro de un proveedor.

Para el presente trabajo, se considerarán 3 subroles, aunque todos

podrán desarrollar.

Diseñador de la experiencia (1), como de cliente que puedan

levantar la VOC (Voice of Customer) y plasmarlas en journeys de
Development acuerdo a los requisitos del PO. Deben tener conocimientos de CX,
Team UX, Design services. También tendrá tareas dentro del desarrollo.

Programadores (3), con conocimientos específicos de la tecnología

de la aplicación, o con la base necesaria para poder ayudar en
diferentes tareas. Experiencia en diseño orientado a servicios. En el
Anexo 5 se detalla un perfil propuesto.

QA (1), aseguradores de calidad durante el desarrollo, con sentido

crítico y sentido de urgencia, es clave por la necesidad de realizar
pases a producción asegurando la mayor calidad.

Las principales responsabilidades del equipo son proveer las

estimaciones, comprometerse al inicio del Sprint a construir ciertas
características y finalmente entregar el producto.

Tabla 277: Composición Roles Grupo Trabajo

Fuente: Se señala al interno del cuadro

149
A continuación se presenta la tabla con un presupuesto para el grupo de trabajo, cabe señalar
que no se trata de un gasto extra para la organización ya que son recursos internos los que se
está utilizando. Adicionalmente, se está considerando un coach de una consultora externa que
dará guía y soporte al marco de trabajo:

Cantidad Costo Asignación Meses Total

Coach (externo) 1 S/10,000 15% 3 S/4,500

Scrum Master 1 S/7,000 50% 3 S/11,500

Product Owner 1 S/8,000 25% 3 S/6,000

Diseñador 1 S/6,000 100% 3 S/18,000

Desarrollador 3 S/5,000 100% 3 S/60,000

Desarrollador-QA 1 S/5,000 100% 3 S/60,000

Total S/95,500

Nota: no se ha considerado el factor empresa base para el presente análisis (1.27).

Tabla 28: Costeo grupo de trabajo

Fuente: Elaboración propia

Para conformar los grupos de trabajo, además de tener en cuenta las características técnicas,
se deberá considerar habilidades blandas o valores propios de la personalidad de cada
integrante de forma complementaria a los valores propios de SCRUM (Foco, Coraje,
Apertura, Compromiso y Respeto). En un inicio podría resultar difícil identificar estas
competencias, pero es clave para crear una cultura adecuada alrededor del equipo.

150
 Disciplina: mantener el orden respecto de las reglas y/o normas definidas por el equipo
para el proyecto.

 Autoaprendizaje: cada día es un día para ser mejor, aprender nuevos conceptos, técnicas y
herramientas para no solo difundirlos para generar un mejor desempeño o resultado.

 Proactividad: se busca personas con iniciativa, que ante situaciones difíciles se harán
cargo y darán lo mejor de sí para el equipo sea cual fuere la tarea.

 Humildad: se busca gente que forme parte de un todo, sencilla y que busque el logro
común por encima de todo.

 Transparencia: decir lo que se piensa, mostrarse tal y como es uno.

En el Anexo 5 se podrá visualizar un formato de contratación para los desarrolladores con las
habilidades técnicas y competencias profesionales requeridas.

Finalmente, algo clave es que se trabajará con grupos voluntarios, es decir que estén
dispuestos a adoptar el marco de trabajo y nuevo modelo por convicción, y no por moda o por
“figurar” en la organización.

Además de la conformación de cada grupo de trabajo, donde se busca tener equipos

autodirigidos de alto desempeño; es importante que la organización por completo se adapte.
Barclays por ejemplo, define que el gobierno no es opcional al implementar métodos ágiles, y
en el caso del BBVA Continental, el cambio fue total, inclusive restructurando el
organigrama para dar el mejor soporte a las nuevas iniciativas, así fue que se creó la gerencia
de Banca Digital que consolida una serie de unidades:

Banca Digital

Multicanalidad Fábrica de Soluciones Transformación Customer Experience

Digitales

151
En esta gerencia se encuentra la unidad de Fábrica de Soluciones Digitales, bajo la cual se
conforman los grupos de trabajo SCRUM, brindando esa estructura necesaria para realizar un
seguimiento adecuado a cada proyecto ágil.

De acuerdo al Manual de Organización y Funciones, se ha definido los siguientes objetivos y

funciones para esta unidad:

Desarrollar, implementar y gestionar requerimientos ágiles de forma incremental propuestos

por la misma unidad y/o de las unidades usuarias brindando innovación, calidad y eficiencia
bajo los lineamientos de la organización. Los requerimientos ágiles deben cumplir los
criterios establecidos por la metodología SCRUM que impliquen desarrollo de aplicaciones
y/o implementación de soluciones para la Organización.

Entregar en forma incremental y oportuna, herramientas tecnológicas en lo que a software

aplicativo se refiere, que soporten el objetivo digital de las Unidades del Banco, permitiendo
ofrecer una experiencia inmediata, sencilla y transparente.

A pesar de que se busca conformar un equipo con la menor cantidad de dependencias, es

necesario mencionar la existencia usuarios clave que deben ser consultados por los proyectos,
sin embargo en algunos casos estos usuarios podrían formar parte de los equipos (ver
entrevista a Gerente de Desarrollo de Negocios en el Anexo 6). Aquí algunos ejemplos:
Contabilidad, Legal, Riesgos, Cumplimiento y Arquitectos Empresariales o Soporte
Tecnológico.

152
IDENTIFICACIÓN DE LAS DINÁMICAS Y DEFINICIÓN DE
LAS HERRAMIENTAS A UTILIZAR

Herramientas Ágiles

Planning Poker
Un factor crítico de éxito en todo proyecto que trabaja con el framework de Scrum es la
madurez y capacidad del equipo de desarrollo para estimar las historias de usuario, esta
capacidad no se adquiere de inmediato, sino más bien se va ganando con la experiencia de los
integrantes del equipo. Lo que normalmente se ve en un equipo es que este expertise es
variado entre uno y otro miembro, por lo cual es frecuente que se propongan herramientas o
métodos de estimación para los proyectos.

Para nuestra presente propuesta utilizamos la dinámica de Planning Poker para la estimación
de puntos de historia, lo cual nos dará un indicador del nivel de dificultad y esfuerzo que
tiene cada historia de usuario respecto a la otra.

Para la estimación se propone utilizar la serie de números de Fibonacci, la cual es una

secuencia de números no lineal. Esta serie de números ayudará al equipo de desarrollo a
concientizar más acerca de las estimaciones, dado que hay una marcada diferencia entre uno
y otro número. También es importante mencionar que el aumentar el tamaño de las tareas
aumenta también el margen de error en las estimaciones, como lo indica el libro Scrum y XP
desde las trincheras de Henrik Kniberg29.

La propuesta sugiere utilizar aplicaciones de celular gratuitas para poder hacer la estimación,
las cuales ya vienen con cartas con la secuencia de números de Fibonacci. Como por ejemplo
el aplicativo Agile Planning Poker, que puede ser descargado para cualquier SmartPhone.

29
[21] KNIBERG 2007

153
 Ilustración 39: Applicaciòn Agile Planning
Fuente: http://www.ascentiqsolutions.co.uk/index.php/apps

La ventaja de utilizar una herramienta digital es que es más rápida de usar en vez de usar
tarjetas físicas con las secuencias de números. La forma de utilizar esta aplicación será la
siguiente:

1. Se selecciona una historia de usuario, la cual necesita ser estimada en puntos de usuario.
2. Se solicita información sobre la historia al Product Owner en caso de no estar clara la
historia de usuario.
3. El equipo de desarrollo selecciona un número en el aplicativo, y lo esconde hasta que se
indica que todos muestren sus números a la misma vez.
4. El Scrum Master pregunta a los integrantes del equipo que sacaron la menor y la menor
carta el porqué de su decisión.
5. Se reevalúa y todo el equipo saca nuevamente un número.
6. Se cuenta cual es el número con más similitudes entre el equipo de desarrollo y se define
ese número como el elegido para la historia de usuario.
7. Se pasa a estimar la siguiente historia de usuario.
La aplicación además brinda la opción de seleccionar la carta con símbolo de infinito, la cual
indica que no se tiene claro el alcance de esa historia de usuario y del mismo modo nos
permita sacar la carta del símbolo de una taza de café, la cual siguiere al Scrum Master que es
necesario un descanso.

154
Es común que estas estimaciones se den al inicio del Sprint, luego del Sprint Planning por lo
que puede ser pesado para el equipo de desarrollo, los descansos ayudan a que todo el equipo
este concentrado y atento en las estimaciones. El consenso de todo el equipo es crucial para la
estimación y se espera que este proceso madure con el avance de los Sprints.

Product Backlog
Para realizar un control adecuado de los requerimientos del proyecto y tener la información
centralizada se debe contar con un Product Backlog con cierta información necesaria.

Hay muchas herramientas que permiten la creación y mantenimiento de un backlog de

Scrum, pero para el caso de la empresa ya se cuenta un licencias para todo el suite de google,
por ello se propone trabajar estas herramientas en línea con google docs entre otras. Esto trae
muchas ventajas al equipo de desarrollo, dado que el backlog puede ser compartido, revisado
y actualizado en tiempo real por los interesados del proyecto. Es muy común que las
prioridades del backlog cambien debido a los requerimientos y dependencias del negocio, por
lo que también se le conoce como un documento vivo, dado a sus continuos cambios durante
los ciclos de desarrollo.

Es importante mencionar que para la propuesta vamos a definir las historias de usuario en lo
posible usando el concepto de Job Stories, este concepto nos permitirá tener información más
detallada de lo que se espera con la historia de usuario así también de que roles intervienen en
cada una. La ventaja de utilizar Job Stories es que cada historia nos da una situación inicial
más detallada de cómo se inicia el requerimiento30.

Para la formación de los Sprint se va considerar un Sprint Cero31, donde se va definir la

estructura del proyecto así como una primera versión de la interfaz gráfica que va tener el
proyecto.

El sprint cero tiene como objetivo armar el esqueleto del proyecto para que este bien definido
y los siguientes sprints se desarrollen con normalidad. Es por ello que este primer sprint solo

30
[27] MAZAN 2015
31
[28] PRAKASH 2013

155
va entregar al usuario pocas historias que representen valor pero este debe estar informado
que es debido a el esfuerzo por tener todo el ambiente de desarrollo listo para el trabajo del
equipo. Todo sprint debe entregar valor al negocio así sea una pequeña interfaz pero ya es
algo visible y que pueda tener feedback. Es importante mencionar que el primer sprint suele
ser más lento comparado con los siguientes pero es una buena muestra inicial para medir la
velocidad del equipo de desarrollo.

Para la definición de historias de usuario técnicas se incluye el rol de desarrollador en donde

corresponde, las que no dan un valor directo al usuario pero son necesarias para el proyecto.
Muchas tareas técnicas son incluidas en requerimientos del cliente como recomienda que se
deba hacer Scrum Alliance.

El template del Product Backlog para el proyecto se presenta a continuación, es importante

mencionar que la definición de los Sprint es una versión inicial y que esta puede cambiar en
cualquier momento en la planificación del sprint según se re priorice por el Product Owner.
En la siguiente tabla se muestran 6 Sprint incluido el sprint cero. La duración de cada uno
será de 2 semanas, por lo que se calcula un total de 3 meses de desarrollo. Asimismo, es
importante mencionar que se cuenta con historias de usuario que no han sido incluidas en la
definición de los Sprints, sin embargo pueden ser incluidas en cualquier momento en caso el
Product Owner así lo considerara, debido a que el Product Backlog es un documento vivo en
el tiempo.

156
PRODUCT
BACKLOG

157
158
159
160
161
162
Tabla 29: Product Backlog
Fuente: Elaboración propia

163
A continuación se detallan los datos que describen el Product Backlog:

ID: Es el Id del user story, creado consecutivamente, y va relacionado al Nombre del

proyecto a trabajar.

Sprint: Es el número del Sprint al que corresponde la historia de usuario.

Prioridad: prioridad que tiene la historia de usuario, está definida por el Product Owner y el
negocio, el rango de prioridad propuesta para este proyecto es del 1 al 5 donde 1 es la más
alta prioridad.

Nombre Historia: Nombre de la historia de usuario, el nombre debe ser relacionado al

requerimiento que se va cumplir y debe ser claro de entender por el equipo de desarrollo. De
incluir palabras no muy comunes de negocio se debe describir con un comentario adicional
en la columna final.

Cuando: En esta columna se va identificar el rol que va ejercer la tarea y una condición, la
cual va dar inicio al requerimiento, se debe ser lo más detallado posible en cuando a la
situación inicial. Se darà bajo el concepto de Job Story.

Quiero: En esta columna se expresa la necesidad del negocio, la motivación para hacer el
requerimiento, lo que se quiere obtener.

Para que: Resultado esperado por el negocio, es la salida que debe darse para dar por
aprobado la historia de usuario.

Criterios de aceptación: En esta columna se describen las condiciones que deben de

cumplirse para poder dar por aprobada la historia de usuario por completo, también se puede
indicar validaciones adicionales para no generar supuestos. En este punto también se pueden
indicar detalles esperadas de la interfaz de usuario resultante de la historia.

SP: Se coloca un número indicando la complejidad de la historia de usuario, utilizando el

rango de números de fibonacci.

Estado: Indica el estado de la historia de usuario, la cual puede pasar a estar en los siguientes
estados TODO, PENDING, DONE.

164
Comentarios y dependencias: Indican comentarios adicionales de la historia de usuario y se
indican las dependencias si las hubieran.

Sprint Planning
Luego de analizar, y definir los requerimientos del negocio en el Product Backlog, se
procederá a hacer el sprint planning. Esta reunión debe darse al inicio de un nuevo sprint, en
el cual se definirán cuales historias de usuario pasarán a formar parte del sprint. En esta
reunión debe participar todos los interesados del proyecto, incluyendo al Product Owner. El
objetivo del Sprint planning es obtener el Sprint Backlog, el cual tiene la lista de historias de
usuarios incluyendo la estimación de las tareas que deben ser cubiertas para dar por
completado una historia. A continuación se mostrará un ejemplo de la propuesta planteada
para el Sprint Backlog, la cual se detallará al final de esta sección. Se muestra el Sprint 0 y el
Sprint 1.

Sprint 0

Ilustración 40: Sprint 0

Fuente: Elaboración propia

165
Ilustración 41: Sprint Backlog Del Sprint 0
Fuente: Elaboración propia

166
Sprint 1

Ilustración 42: Sprint 1

Fuente: Elaboración propia

167
Ilustración 43: Sprint Backlog del Sprint 1
Fuente: Elaboración propia

168
Para el Sprint Backlog se puede apreciar que en la propuesta planteada se cuenta con un
template el cual permitirá tanto agrupar las historias de usuario a trabajar como tener una
visión clara de las capacidades del equipo de desarrollo. Asimismo se muestra claramente
cuál es el Objetivo del sprint, el cual debe ser definido al final, luego de tener claro el
compromiso de las historias que se van a desarrollar. También se tendrá una sección donde se
muestra los días de trabajo que tiene el equipo de desarrollo para el sprint.

En la sección de indicadores se puede apreciar los siguientes campos:

 Story points (SP) comprometidos: Es la suma de todos los puntos de historia

comprometidos en el Sprint.

 Capacity scrum: Este número se determina, sumando las horas totales que el equipo de
desarrollo puede desarrollar. Para la propuesta actual se tiene que en un sprint de 2
semanas, serán 8 los días de desarrollo ya que 2 días se tomarán en actividades de
planeación, demos, retrospectivas entre otras, por ello se tiene 8 (días de desarrollo) * 6
(horas trabajo al día) * 5(desarrolladores) = 240 horas.

 Velocidad (SP cumplidos): Este número indica cuantas historias de usuario han sido
cumplidas, se determina cuando se realiza la demo del sprint y se suman los puntos de
historia de las historias que el Product Owner da por aprobadas, en la tabla vemos que la
columna Aprobación indica el OK de la historia.

 Historias adicionales: Número de historias de usuario adicionales fuera de la

planificación inicial.

 SP adicionales: Puntos de historia adicionales fuera de la planificación inicial.

 Horas adicionales: Suma de horas relacionadas a las historias de usuario adicionales.

 Horas tareas fuera de compromisos: Horas de trabajo fuera del compromiso.

Es muy importante identificar con todo el equipo cual será el objetivo del Sprint, el cual debe
ser también mencionado al final del sprint cuando se realiza la Demo, cada sprint debe tener
obligatoriamente un objetivo como lo indica el autor en el libro Scrum desde las trincheras.

169
Luego de la definición del sprint se procederá a definir y estimar las tareas involucradas por
cada historia de usuario, en esta reunión no es necesario incluir al Product Owner dado que es
una reunión más técnica.

Para la propuesta actual no se dan estimaciones en horas mayores a 6 para tener un mejor
control de las tareas, si hubieran tareas que requieran un desarrollo de más de 6 horas se
siguiere dividir la tarea en 2 o más sub tareas.

Tablero de Scrum
Luego de tener definido el Sprint y estimadas las tareas necesarias se debe contar con una
propuesta de tablero de Scrum, donde el equipo pueda plasmar todo lo planeado y hacerlo
más visible, de modo que diariamente se revise, analice y haga le seguimiento del avance de
desarrollo, esto con las reuniones diarias que se explicaran más adelante.

A continuación se muestra la propuesta para el Sprint 0 y Sprint 1

170
Sprint 0

171
Sprint 0 (continuación)

Ilustración 44: Tablero Scrum del Sprint 0

Fuente: Elaboración propia

172
Sprint 1

173
Sprint 1 (continuación)

Ilustración 45: Tablero Scrum del Sprint 1

Fuente: Elaboración propia

174
En el tablero mostrado se puede apreciar todas las tareas, el objetivo del Scrum, y las
historias de usuario comprometidas. Lo primero que se aprecia en la parte superior es el
objetivo del Sprint, para ello es importante que el Scrum Master lo recuerde diariamente para
que todos los integrantes se centren en cumplirlo.

En la columna de Backlog, se puede apreciar las historias de usuario comprometidas y las

tareas estimadas. Cada tarea tendrá una letra relacionada a la historia de usuario a la que
pertenecen, esto permitirá no perder el orden de las tareas al ir cambiando los estados de las
mismas. Asimismo se indicará las horas estimadas por cada tarea y lo que realmente tomó al
ser dada como finalizada.

Cada tarea debe pasar por los estados de TODO, DOING Y DONE, descritos a continuación.

 TODO: Estado que indica que la tarea esta lista para ser iniciada y no presenta
dependencias.

 DOING: Estado que indica que una tarea está siendo desarrollada por un miembro del
equipo.

 DONE: Estado que indica que la tarea fue culminada y no necesita más desarrollo.

Físicamente este tablero debe ser una pizarra, en la cual se pueda manejar fácilmente sticky
notes para ver el progreso de las tareas. También se puede utilizar plumones para indicar
cosas adicionales. Cuando una tarea está bloqueada por alguna razón, se debe hacer visible el
bloqueo agregando un post-it de color rojo, el cual indicará al Scrum Master que debe
intentar solucionar el bloqueo con urgencia.

La propuesta final de cómo se vería el tablero de Scrum propuesto sería la siguiente. El

BurnDown chat se explicará en el siguiente punto.

175
 Ilustración 46: Tablero Scrum
Fuente: Elaboración propia

Burndown Chart
Para poder medir cómo va el desarrollo día a día con respecto al tiempo que dura cada sprint
se va proponer el uso del Burndown Chart, este gráfico es también conocido en español
como gráfico de trabajo pendiente. El objetivo del gráfico es tener una visión de las tareas
que se van quemando día a día reflejadas en las horas estimadas.

Es decir por cada tarea que se va terminando en el tablero de Scrum como DONE se
acumulan las horas de las tareas y restarlas del monto total de horas restantes del sprint, de
este modo al final del sprint el último día el acumulado de horas debería llegar a cero horas
pendientes.

El procedimiento propuesto para llevar correctamente el burndown chart es el siguiente:

1. Se define un espacio al costado del tablero de scrum para ubicar el gráfico

2. Se crea el gráfico con cintas pegadas en una pizarra o con plumones si no hubiera cintas.
3. Luego del sprint planning cuando ya se tiene el compromiso final del sprint se suman las
horas estimadas de las historias de usuario y esa será el eje Y (trabajo pendiente)

176
4. El eje X serán los días del sprint que se van a trabajar, no se considerarán los sábados y
domingos dado que no son días laborables.
5. Cada día al finalizar el daily meeting se contabilizarán las tareas terminadas en horas y se
le restara al total de horas del eje Y.
6. De esta manera las horas deberían ir disminuyendo hasta llegar a cero.
A continuación un ejemplo de cómo sería el Burndown chart trabajado con Puntos de
historia.

Ilustración 47: Modelo BurnDown

Fuente: Scrum desde las trincheras32

En la presente imagen podemos apreciar el gráfico para un Sprint de 3 semanas, en el cual se

tiene un compromiso de 70 puntos de historia. El primer día del Sprint es el 1 de agosto y no
se están considerando sábado ni domingos para el gráfico. El 16 de agosto el equipo estima
que quedan aproximadamente 15 puntos de historia por hacer. La gráfica nos muestra que
estamos avanzados respecto a lo planificado, lo cual indica que al paso actual se culminaría
con el compromiso con éxito.

Se da este ejemplo adrede para poder apreciar cómo se puede trabajar el gráfico ya sea con
horas o con puntos de historia. Siempre mencionando que nuestra propuesta será trabajar el

32
[21] KNIBERG 2007

177
gráfico con horas para tener una visión más detallada del avance. A continuación la propuesta
planteada en horas de tareas.

Ilustración 48: BurnDown Propuesto

Fuente: Elaboración Propio

La ubicación BurnDown Chart en la propuesta será justo al lado derecho en el tablero de

Scrum, esto es crítico para mantener una visión diaria del mismo. Cada día en el Daily
Meeting el Scrum Board y el chart deben ser vistos por el equipo de desarrollo. Este gráfico

178
es un indicador muy efectivo para ver cuando es necesario poner el acelerador en el proceso
de desarrollo o a ver si el sprint va con tiempos de holgura por lo cual se puede aceptar o
coordinar otras historias de usuario, asimismo por el lado negativo se puede ver cuando no se
va cumplir con el compromiso antes de llegar al último día del sprint, por lo que se puede ir
pensando o coordinando con el Product Owner un futuro negocio del siguiente sprint en
cuestiones de completar las historias de usuario que no fueron completadas en su totalidad.

El gráfico nos va una foto diaria de la velocidad del equipo respecto a el compromiso, todos
los integrantes del equipo deben saber y comprender la gráfica así como de participar en la
actualización de la misma día a día. Es responsabilidad del scrum master mantener el gráfico
a la fecha y entendible.

Tres de los motivos más comunes de por qué tener y llevar un Burndown Chart son:

 Ayudan a determinar cuánto esfuerzo falta para terminar el compromiso del sprint

 Son visuales y fáciles de entender

 No requiere mucho esfuerzo el darle mantenimiento

Daily Meting
La reunión diaria de sprint es muy importante, es en ella donde se menciona a todo el equipo
la situación actual del proyecto. Para la actual propuesta se definirán reglas a cumplir de
modo que la reunión diaria se lleve bien y aporte al desarrollo del equipo:

 La reunión empezará a las 9AM en punto

 Se definirá una penalidad a los miembros del equipo que lleguen tarde

 La reunión será frente al tablero de scrum donde se encuentran las tareas

 La reunión será de pie

 La reunión no durará más de 15 minutos.

La reunión diaria debe ser lo más sencilla posible y debe tener como objetivo generar
confianza y dar transparencia al desarrollo.

179
Para poder todos estar al tanto del desarrollo de cada uno se responderán las siguientes
preguntas:

 ¿Qué hiciste el día de ayer?

 ¿Qué vas a hacer el día de hoy?

 ¿Hay algún impedimento en las tareas que harás hoy?

Al responder estas preguntas se podrá identificar fácilmente algún impedimento antes de que
retrase más el desarrollo.

Para la propuesta actual se sugiere contar con una pelota de mano para la reunión diaria, de
modo que solo el miembro del equipo que está hablando tenga en sus manos la pelota, luego
de responder las 3 pregunta este integrante pasa la pelota a cualquier otro intégrate. Esto tiene
como propósito buscar que todos los integrantes estén atentos y mirando al compañero de
equipo que está hablando porque saben que la pelota les puede caer en cualquier momento.

Asimismo en la reunión diaria se actualizará el tablero de scrum por cada integrante del
equipo, moviendo las cartillas con las tareas seleccionadas. Si hubiera alguna tarea finalizada,
esta debe indicar las horas reales que tomó en finalizarse, como se muestra en el tablero
ejemplo se debe llenar con plumón.

Finalmente, al culminar con todos los integrantes del equipo, se debe actualizar el Burndown
chart con las horas quemadas el día anterior. Se siguiere para esto que la actualización sea
rotativa, es decir cada integrante del equipo actualizará el gráfico intercaladamente de modo
que todos tengan pleno conocimiento y entiendan la importancia del burndown chat, al ver
las curvas de avance diario.

Demo Sprint
Al culminar las tareas de un sprint el último día del mismo se debe dar una reunión muy
importante, que es muchas ocasiones no es muy tomada enserio. Para nuestra actual
propuesta se va proponer tener la Demo del sprint el décimo día del sprint, del mismo modo
si el sprint fuera de tres o cuatro semanas se daría el último día.

180
Hay diferentes maneras de plantear una demo de sprint, pero el objetivo central siempre debe
ser el mismo, el cual es mostrar todo el desarrollo que se hizo durante las 2 semanas y
obtener la aprobación del Product Owner.

El autor del libro Scrum y XP desde las Trincheras nos recomienda los siguientes puntos a
tomar en cuenta para el desarrollo de la demo33:

 Asegúrate de presentar claramente el objetivo del sprint. Si hay personas en la demo que
no saben nada sobre el product, tomate un par de minutos para decribirlo.

 No pierdas mucho tiempo preparando la demo, especialmente en llamativas

presentaciones. Déjate de milongas y concéntrate mostrar código funcionando.

 Mantén el paso rápido, es decir, concentra tu preparación en hacer que la demo sea
rápida en lugar de bonita.

 Mantén la demo a nivel de negocio, deja los detalles técnicos aparte. Concéntrate en
“qué hemos hecho” en lugar de “cómo lo hemos hecho”.

 En la medida de lo posible, deja que la audiencia pruebe el producto por si misma.

 No muestres un montón de pequeños errores solucionados y funcionalidades triviales.

Menciónalos, pero no los muestres, ya que normalmente se tarda mucho y desvía la
atención de las historias más importantes.

Teniendo en cuenta esto, la propuesta plantea algunas variaciones en la Demo Sprint. Podrá
ser observada por los siguientes roles/personas, solo siendo algunos opcionales y los demás
deben tener presencia obligatoria.

 Equipo de desarrollo

 Product Owner

 Scrum master

 Otros equipos scrum (opcionales)

 Gerentes y jefes del área (opcionales)

181
 Stakeholders (opcionales)

Esta dinámica se dará en una sala de reuniones donde se encontrará físicamente el equipo de
desarrollo, el scrum master y el product owner de manera obligatoria. La sala de reuniones
deberá contar con un proyector o monitores grandes donde se pueda proyectar el aplicativo y
revisar las funcionalidades. Asimismo, Se propone realizar la demo de manera virtual
mediante una transmisión de video utilizando herramientas de streaming en vivo. En el
mercado hay muchos aplicativos fue permiten esto de manera gratuita, pero para la actual
propuesta se propondrá Facebook Live. Para hacer esto posible, se debe contar con un
administrador que cree un grupo cerrado en facebook, en el cual se va agregar a todos los
interesados del proyecto.

De este modo el día que se realice la demo se creará un evento indicando la hora y los temas
que se van a abordar en la demo, de esta manera los interesados recibirán una notificación al
celular con la descripción de la demo que podrán ver en vivo. Cuando empiece la demo se
transmitirá en vivo de manera que todos los que están en el grupo puedan verla desde sus
celulares o laptos en donde se encuentren.

Ilustración 49: Streaming

Fuente: http://entodonoticias.com/streaming-ha-llegado-quedarse/

33
[21] KNIBERG 2007

182
La fortaleza de utilizar herramientas digitales es que es mucho más accesible para más
interesados del proyecto, dado que muchas veces estas personas no están presentes por no
estar cerca o por motivos de espacio. Asimismo mediante la utilización de herramientas como
facebook live permitirá obtener comentarios en tiempo real acerca de la presentación los
cuales pueden ser respondidos en el mismo instante o dejadas para el final de la presentación.
De la misma forma los interesados que no pueden ver la presentación en vivo, pueden
visualizarla posteriormente dado que el video se quedará cargado en el grupo.

Se espera que luego de terminada la Demo del Sprint se tengan claras la historias de usuario
que fueron terminadas y las que no de la misma manera para poder tomar decisiones en base
a los objetivos planteados.

Retrospectiva
La primera propuesta de retrospectiva permitirá al equipo recordar que es lo que se hizo en
las 2 semanas del sprint, identificando actividades que se hicieron bien, actividades que
pueden mejorar y actividades nuevas que se pueden empezar a hacer en búsqueda de mejorar
como equipo.

Para esto se creará un tablero en el cual se tengan 4 columnas y 4 filas, y debe participar todo
el equipo de desarrollo así como el Product Owner y Scrum Master. Todos los integrantes del
equipo escribirán en el tablero actividades sin un límite de participaciones, todas las ideas son
bienvenidas por el equipo. Asimismo, la columna de la izquierda puede variar si es que el
equipo sugiere agregar algún ámbito diferente, esta dinámica es flexible a las necesidades del
equipo.

183
 Ilustración 50: Dinámica de Retrospectiva
Fuente: Elaboración Propia

A continuación se describen a mayor detalle las filas y columnas del tablero:

 Que se hizo bien: Columna donde se indican las actividades que se realizaron durante el
sprint y tuvieron impacto positivo.

 Qué puede mejorar: Columna donde se colocan actividades que no se realizaron bien
durante el sprint y tuvo un impacto negativo en el equipo

 Empezar a hacer: Actividades que se proponen hacer por el equipo para mejorar

 Técnico: En esta fila se agregan las actividades del ámbito técnico que se realizaron
durante el sprint, se puede agregar en cualquier columna.

 Scrum: Actividades relacionadas a como se está utilizando el framework de Scrum

 Ambiente de Trabajo: Actividades que o situaciones que están relacionadas al lugar de

trabajo del equipo.

184
 Equipo: Actividades relacionadas al equipo

 Action Points: Acciones planteadas por el equipo para solucionar empezar a trabajar en
las actividades de mejora identificadas. Cada action point debe tener un solo responsable
así como una fecha de cumplimiento. Los action points son revisados en la siguiente
retrospectiva.

El objetivo de esta retrospectiva es analizar qué actividades resultaron provechosas durante el

Sprint para mantener el buen trabajo de las mismas, esto hace que el equipo se sienta
motivado en continuar haciéndolas. Asimismo permite identificar que actividades pueden
ayudar al equipo a tener un mejor desenvolvimiento, mientras el equipo se sienta mejor en el
ambiente de trabajo mejor será el desarrollo.

Es importante que se llegue a identificar varios action points en cada retrospectiva para que
se logre la mejora continua, por ello siempre se debe tener un responsable para que sea
revisado el cumplimiento de los puntos en la siguiente retrospectiva.

Se puede apreciar que con esta actividad se busca trabajar en las habilidades blandas de
Disciplina, Pro actividad y Transparencia, al cumplir con los action points el equipo logrará
mejorar en estas habilidades.

Retrospectiva 2
La siguiente dinámica propuesta se centra principalmente en identificar qué habilidades tanto
técnicas como blandas son necesarias en el equipo de desarrollo, este análisis tendrá como
base de medición el desarrollo del sprint actual. Es decir se debe analizar qué habilidades son
las más requeridas en el equipo para que el sprint se lleve correctamente y pensar que tan
bien el equipo está en esas habilidades. Puede ser que un integrante domine una habilidad
pero el resto del equipo no, por lo cual lo puede escribir para medir en qué nivel está el
equipo en esa habilidad.

Es importante mencionar que para esta dinámica no se miden las habilidades individuales
sino del equipo, por lo cual se debe llegar a consensos.

Para realizar esta retrospectiva se deben seguir los siguientes pasos:

185
1. Cada integrante del equipo debe identificar que habilidades cree que el equipo debe tener.
2. Identificar habilidades técnicas como blandas.
3. Agrupar habilidades similares
4. El Scrum Master explicará que cada habilidad debe ser colocada al lado derecho del
tablero, mientras más a la derecha esté simbolizará mayor dominio. Mientras más a la
izquierda menor dominio.
5. El Scrum Master cogerá cada tarjeta de habilidad preguntando a cada integrante en que
lado y lejanía se colocará la tarjeta hasta llegar a un consenso de todo el equipo.
6. Todas las tarjetas de habilidades deben ser ubicadas en una posición del tablero de nivele
de dominio.
7. Cuando todas las tarjetas de habilidades estén posicionadas cada integrante del equipo
elegirá con un punto que tarjeta le parece más importante mejorar para el siguiente sprint.
8. Solo se debe seleccionar una habilidad para mejorar
9. Todo el equipo propondrá una actividad que ayude a mejorar al equipo en esa habilidad
10. Se buscarán responsables para que se lleve a cabo la propuesta planteada.

186
 Ilustración 51: Dinámica de Retrospectiva 2
Fuente: Elaboración Propia

En la imagen anterior podemos ver un ejemplo de la retrospectiva planteada, en la cual se

aprecia en el lado izquierdo todas las habilidades identificadas por el equipo, y a la derecha el
tablero de nivel de dominio, donde se irán colocando las habilidades del equipo, en este
ejemplo podemos apreciar que el equipo tiene un bajo dominio de la habilidad 1 y un alto
dominio de la habilidad 2, pero al tener un menor dominio de la habilidad de manejo de la
herramienta GIT para el control de versiones, se podría proponer mejorar esta última con un
taller para el siguiente sprint. Importante mencionar que todas las habilidades deben ser
colocadas en el lado derecho pero para motivos del ejemplo solo se han colocado esas 3.

A diferencia de la retrospectiva anterior esta dinámica permite identificar y analizar al equipo

acerca de solo habilidades, creando una mayor conciencia y buscando la mejora continua de
habilidades.

Esta retrospectiva nos permite trabajar las habilidades blandas de Auto aprendizaje,
Humildad y Proactividad, al fomentar que el mismo equipo logre mejorar el nivel de

187
habilidades del equipo en conjunto. Un equipo de Scrum madura con el esfuerzo de todos los
integrantes.

Como se mencionó, toda retrospectiva debe terminar en un action point con un responsable,
el equipo debe saber priorizar que puntos son los críticos trabajar para el siguiente sprint. No
todo se puede solucionar en un sprint por lo que se debe poner bien el límite de acción como
lo menciona el libro Técnicas para la realización de Retrospectivas de Kleer34.

Coaching Comunidad Agile

Entender los conceptos de Scrum es relativamente fácil, dado a la vasta información y
ejemplos que podemos encontrar en internet, pero esto también puede causar problemas a un
equipo de desarrollo que no tiene experiencia en el trabajo con Scrum, esto se debe al tener
muchas propuestas y no todas se acomodan a las habilidades de los integrantes ni al negocio
en el que está el equipo. Por ello que la propuesta presente cuenta con un servicio de
coaching por un tercero que está a tiempo completo en la empresa como Outsourcing. Este
coach se encargará de guiar a los equipos de desarrollo de la empresa en el transcurso de los
sprint asegurándose de que se aplique bien el framework, reduciendo riesgos y esfuerzos
innecesarios.

Como una actividad inicial se propone una introducción a Scrum, y los objetivos que se
esperan alcanzar mediante la entrega de requerimientos que le den valor a las agencias
bancarias.

Se propone también cada 2 semanas se tenga una reunión libre para que los integrantes del
equipo de desarrollo se inscriban, la cual tendrá como objetivo hacer dinámicas de mejora
continua en los equipos. Estas reuniones no serán obligatorias, por lo cual no tendrá relación
con el tiempo de desarrollo del sprint, cada integrante del equipo tomará la decisión de asistir
siempre y cuando todas sus tareas estén controladas y con previa aprobación del scrum
master. Estas reuniones se darán normalmente en los días de finalización del sprint, por lo
que complementará y motivará al equipo a identificar más problemas y temas que deseen
abordarse en sprint futuros así como la investigación de nuevas herramientas de desarrollo.

188
A continuación se menciona una dinámica que se puede dar en las reuniones de comunidad
ágil. Es importante mencionar que esta actividad difiere a la retrospectiva dado que esta
última se basa en lo que se realizó durante el sprint, pero esta dinámica va más allá y se
enfoca en aprender y utilizar nuevas herramientas que ayudan al desarrollo.

Descripción de la dinámica:

Cada asistente a la reunión escribe un aspecto tecnológico que cree se debe utilizar en un
sprint normal, tales como integración continua, pruebas automatizadas entre otros.

Luego de que todos dan las ideas, las comentan y se define que enfoque esperan tomar dichas
mejoras o que ten madura este la empresa para implementar estas mejora. Todos realizan una
votación y se define que nueva herramienta o tecnología se busca aprender y aplicar, y se
selecciona un responsable de intentar implementarlo y si el caso fuera éxito compartirlo con
todo el equipo.

34
[26] GARIBALDI 2016

189
CRONOGRAMA TENTATIVO TRABAJO
Como se señaló en el capítulo 2, trimestralmente se realizan diferentes revisiones de los
proyectos. La propuesta es que en el roadmap de la organización, el proyecto Gestor Móvil se
ejecute durante el segundo trimestre del 2017, debido a que existen dependencias al interno
que se deben superar previamente. En el FODA realizado en los capítulos anteriores, se
menciona esta situación, por lo que una forma de manejarlo ha sido que los proyectos se
inicien con la mayoría de dependencias solucionadas, por lo menos aquellas de complejidad
media-alta.

A continuación el cronograma tentativo que consta de 6 Sprints cada uno de dos semanas,
iniciando desde un Sprint 0.

2017
Etapa
Ene Feb Mar Abr May Jun Jul Ago Sep
Preparación y Entrenamiento
Sprint 0
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Producción
Post-producción

190
CONCLUSIONES
Luego de analizar los principios del agilísimo y del framework de Scrum, se logró
comprender que para obtener un mayor impacto con la adopción de la nueva forma de trabajo
propuesta, no solo es necesario aplicar las dinámicas y herramientas, sino que desde el más
alto nivel se comprometan con el nuevo modelo. Claramente el BBVA así lo hizo, haciendo
cambios estratégicos modificando la estructura, reasignando recursos clave y facilitando
modificaciones a los procesos core del negocio.

Al realizar el análisis actual de los grupos de trabajo del banco, se logró comprender que es
necesario adoptar dinámicas en las áreas que trabajarán con Scrum para poder cambiar la
mentalidad de los profesionales e ir mejorando con cada entregable, de este modo se logrará
una mejora continua y se fortalecerán las habilidades blandas y técnicas de los equipos de
trabajo. En el caso del BBVA, se proponen algunos modelos ad-hoc sobre el marco de
trabajo.

Luego del análisis de comprendió también que existen diferentes autores que presentan
teorías acerca de los modelos de desarrollo ágil, no es necesario “inventar” la forma en cómo
se ejecuta, se puede tomar y adaptar más dinámicas poco a poco en los equipos de trabajo,
llevando a cabo unas adecuadas retrospectivas se irán quitando y agregando mejoras en el
proceso de desarrollo.

Se ha logrado evidenciar que un modelo ágil funciona mejor en un escenario complejo, como
el del presente trabajo, sin embargo en otros escenarios se debe evaluar qué modelo aplicar.
En el BBVA así como se ha estructurado una serie de equipos Scrum, también se sigue
manteniendo equipos que ejecutan proyectos bajo el enfoque tradicional, en los cuales no se
requieren entregables rápidos sino más bien proyectos más documentados y con tiempos
definidos.

191
Después de todo el análisis realizado se ha logrado comprender que la adopción del
framework de trabajo Scrum debe ser aplicado comprendiendo y dándole importancia a los
valores del modelo, si no se cuenta actualmente con el personal acorde al perfil requerido se
debe llevar un proceso de contratación en las cuales se busquen profesionales con las
habilidades identificadas en el presente trabajo y que tengan claro la importancia del
cumplimiento de los valores de Scrum para el éxito de los proyectos.

192
CAPÍTULO 4. GESTIÓN DE SERVICIOS EN TI

INTRODUCCIÓN
El presente capítulo señala los servicios identificados para ser gestionados por la
organización objetivo a partir del desarrollo de la propuesta de arquitectura empresarial, en el
marco de desarrollo de las mejores prácticas de ITIL.

Es importante mencionar que de la totalidad de procesos que se mencionan en este marco de

trabajo, el enfoque estará en desarrollar cinco de estos, como son la Gestión del Portafolio,
Gestión de Nivel de Servicios, Gestión de la Configuración, Gestión de Cambios y Gestión
de Incidencias.

Primero se mencionarán aspectos relacionados a la evaluación estratégica de la organización

y desarrollarán las fichas que definen los diferentes procesos abordados, posteriormente se
presentará la forma en la que se desarrolla el proceso ITIL en la organización objetivo, su
alcance, procedimientos, y registros requeridos, entre otros datos importantes.

EVALUACIÓN ESTRATÉGICA

Estrategia de Negocio
En esta sección se presenta diferentes aspectos relacionados a la estrategia de la organización
en la búsqueda por alcanzar sus objetivos.

Visión
Este punto ha sido presentado en el capítulo 1, sección Organización Objetivo.

Misión
Este punto ha sido presentado en el capítulo 1, sección Organización Objetivo.

193
Objetivos estratégicos
Este punto ha sido presentado en el capítulo 1, sección Organización Objetivo.

Prioridades de la organización
De acuerdo a la entrevista realizada al CEO del BBVA Continental se pueden desprender los
siguientes ejes como prioridades estratégicas de la organización:

 Innovación en productos, procesos, precios y comisiones.

 Experiencia Única, para desarrollar un modelo de franquicia en las agencias, para que los
clientes sienta una atención diferente frente al resto de competidores.

 Desarrollo de capacidades digitales.

FODA
Durante el desarrollo del presente trabajo profesional se han desarrollado diversos FODA que
se pueden encontrar en los capítulos 2, Petición del Trabajo de Arquitectura, Descripción de
la situación actual del negocio, donde se menciona de manera general aspectos de la
organización; y 3, Identificación de Fortalezas y Debilidades, donde se identifican de manera
específica variables que impactan en el desarrollo de software bajo un método ágil.

Servicios de Negocio Ofrecidos

El BBVA Continental ofrece a sus clientes una vasta cantidad de productos financieros, tanto
para personas naturales o jurídicas. El presente trabajo se enfoca en los productos que se
ofrecen al segmento retail de clientes, por lo que a continuación se brindará un listado de los
principales productos tanto activos, como pasivos, dirigido al grupo en mención.

194
 Tipo Nombre Nombre

Pasivo Cuentas y Ahorro Cuenta ganadora

Cuenta sueldo y CTS

Cuentas a plazo

Cuentas de ahorro

Activo Tarjetas Visa Clásica Primera

Visa Continental 0

Visa Lifemiles

Activo Préstamo Personal Préstamo al Toque

Crédito Vehicular

Crédito Hipotecario

Compra de Deuda

Servicios Seguros Seguro de autos

Seguro de salud

Seguro de protección

Tabla 30: Servicios de negocio ofrecidos

Fuente: www.bbvacontinental.com.pe

Estrategia de TI
En la presente sección se identificará los servicios directamente impactados por la
implementación de la propuesta de arquitectura empresarial, se brindará una breve

195
descripción de estos e identificará las prioridades de TI orientadas a satisfacer los objetivos
de la organización.

Servicios internos y externos identificados

Luego de realizar el análisis de impacto de la implementación de la propuesta de arquitectura
se identificó que no existen servicios externos, o de relación directa con el cliente final, que
sufrirán variaciones. Respecto de los servicios internos, se lista a continuación los servicios
impactados.

Código Servicio Descripción Tipo

SI001 Servicio Gestor Servicio que permite el ofrecimiento de Interno

Móvil productos a clientes a través de tablets de
manera móvil en las agencias del BBVA
Continental

SI002 Servicio de Servicio que permite explotar la Interno

Explotación de retroalimentación brindada por agencias
Información de y clientes respecto a los productos
Colocación en ofrecidos a clientes con campaña
Agencias

Tabla 31: Servicios Identificados

Fuente: Elaboración propia

En las siguientes secciones se profundizará en las características de los servicios.

196
Prioridades de inversión
TI, a través de la Gerencia de Fábrica de Soluciones, que se encuentra en la Gerencia de
Banca Digital; tiene prioridades de inversión alineadas a las prioridades estratégicas de la
organización.

Ámbito 2013 2015 2017

Banca Digital 6° 5° 1°

Canales tradicionales 4° 6° 2°

Web 6° 2° 3°

CRM 3° 1° 4°

Backoffice Process 2° 3° 5°

Business Intelligence 5° 4° 6°

Business Continuity 8° 9° 8°

Seguridad de Información 9° 7° 7°

ERP 1° 8° 9°

Tabla 32: Priorización estratégica

Fuente: BBVA Continental (elaboración propia)

Es importante precisar que la prioridad no indica que un ámbito deje de ser importante, solo
señala el destino de la inversión tecnológica de acuerdo a los objetivos estratégicos y
situación actual de la organización y TI.

197
PLANIFICACIÓN ESTRATÉGICA
En la presente sección se identificarán los diferentes servicios que tienen impacto en el proceso para el que se define la propuesta, asimismo se
planteará una ficha con el requerimiento del servicio resultante de la implementación de esta propuesta, y realizará la evaluación financiera y de
riesgos.

SERVICIOS INTERNOS, EXTERNOS Y DE SOPORTE

A continuación se listan los servicios identificados con impacto en la propuesta los cuales se encuentran agrupados según su tipificación. Es
importante precisar, que no se identifican procesos externos como resultado de la propuesta realizada.

Servicios internos

Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Priorida Horas
Soporte d de
Servic
io

SI001 Servicio Servicio que permite Interno Gerente Ejecutivo SS001, SS002, Pérdida de CRÍTI L-V:
Gestor Móvil el ofrecimiento de Banca Banca SS003, SS004, oportunidades CO 9-19
productos a clientes SS005, SS006, S: 9-

198
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Priorida Horas
Soporte d de
Servic
io

a través de tablets de Digital Personal SS007, SS008, 13

manera móvil en las SS009, SS010
agencias del BBVA
Continental

SI002 Servicio de Servicio que permite Interno Gerente Gerente SS002, SS006, Pérdida de ALTA 24x7:
Explotación explotar la Desarrollo de Oficina SS008, SS010 oportunidades 365
de retroalimentación Negocios días
Insatisfacción
Información brindada por
de clientes
de agencias y clientes
Colocación respecto a los
en Agencias productos ofrecidos
a clientes con
campaña

199
Servicios de Soporte

Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS001 Servicios de Servicio que Soporte Gerente de TI Falta de ALTA Los 365
RENIEC brinda validación días, 24
información de de datos *7
las bases de
datos de
RENIEC

SS002 Gestión de Servicio que Soporte Gerente de TI Imagen del CRITICO Los 365
seguridad LDAP proporciona los Banco días, 24
accesos a los *7
aplicativos del
Banco

200
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS003 Gestión de File Administrar los Soporte Gerente de Imagen del ALTA Los 365
Servers servidores File Infraestructura Banco días, 24
servers para *7
trabajar con
carpetas
compartidas
delimitando sus
accesos según
los perfiles y
tipos de usuario
que se tienen en
la organización.

201
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS004 Gestión de Servicio que Soporte Gerente de TI Imagen del ALTA Los 365
adquisición de analiza y Banco días, 24
HW/SW aprueba las *7
comprar que son
requeridas para
los proyectos de
tecnología del
Banco

202
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS005 Operación del Mantener SOPORTE Gerente de Cuello de ALTA Los 365
balanceador de equilibrado la Infraestructura botella para días, 24
carga distribución del la atención *7
tráfico de de
peticiones entre solicitudes
múltiples de
servidores, así posiciones
como el de los
recupero vehículos.
inmediato en Imagen del
caso de fallas. Banco

203
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS006 Gestión de red del Administración SOPORTE Gerente de TI Direcciones ALTA Los 365
Banco de los recursos IPs días, 24
de la red duplicadas *7
evitando que Empleo de
este llegue a credenciales
funcionar de usuarios
incorrectamente, retirados
degradando sus Imagen del
prestaciones. Banco

204
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS007 Gestión de Soporte Proporcionar SOPORTE Gerente de TI Bloqueo en ALTA Los 365
Técnico asistencia a los las días, 24
usuarios para actividades *7
resolver de los
problemas con usuarios
el hardware y Imagen del
software. Banco

205
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS008 Gestión de Internet Administrar los SOPORTE Gerente de Lentitud en ALTA 24x7:
/ Web sitios y Infraestructura la 365 días
contenidos web navegación
a los que tienen de internet
acceso los Acceso a
usuarios de la sitios web
organización; de dudosa
así como medir procedencia
la o de
disponibilidad contenidos
del servicio restringidos
ofrecida por el Imagen
ISP.

206
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS009 Operación de Controlar que SOPORTE Gerente de Sin internet ALTA L-V: 9-
chips de Tablets los chips Infraestructura 19
Menos
configurados en S: 9-13
ventas
las tablets de
venta cuenten
con todos los
servicios

207
Código Servicio Descripción Tipo Propietario Cliente Servicios de Impacto Prioridad Horas
Soporte de
Servicio

SS010 Ejecución de Control en la SOPORTE Gerente de Información ALTA Los 365

Trabajos ejecución de Producción de no días, 24
Personalizados trabajos Sistemas sincronizada *7
programados para
configurados gestionar
para diferentes los procesos
aplicaciones:
para el presente
trabajo se
considera la
carga de
campañas y
DWH

208
REQUERIMIENTO DEL SERVICIO IDENTIFICADO
Como parte del proceso de Gestión de Portafolio de Servicio, se describirá los requerimientos
del servicio interno Gestor Móvil, para ello se utilizará la ficha de Alcance de Servicio, la
cual será definida en el siguiente subcapítulo Procesos ITIL.

Propósito Este documento presenta el Alcance del Servicio que nace

mediante un requerimiento del cliente o alguna mejora que
presenta la organización.

Adicionalmente se muestra una matriz de riesgos, la valoración

económica y el alineamiento con los objetivos de la organización.

Área Solicitante DESARROLLO DE NEGOCIO

Alcance del Servicio Otorgar información oportuna del cliente y no cliente cuando se
acerquen a las oficinas del banco BBVA Continental. La
información debe ser lo más detallada posible y consultada en
tiempo real por cualquiera de los ejecutivos del banco.

Objetivos del Servicio El objetivo principal es tener un front móvil para la atención y
gestión comercial.

Aumentar las colocaciones del banco.

Permitir que los ejecutivos del banco puedan ofrecer los productos
fuera de las oficinas acercándose donde los clientes.

Incrementar la cantidad de clientes digitales.

Nombre Servicio GESTOR MÓVIL

Gerencia Responsable DESARROLLO COMERCIAL

209
Segmento Objetivo del Clientes y No Clientes Personas Natural
Servicio

Canal del Servicio OFICINAS LIMA X

OFICINAS PROVINCIA X

BEC & BEI X

ATM

BANCA POR INTERNET

BANCA TELEFÓNICA X

FFVV MASIVOS

AGENTES EXPRESS

OTRO (ESPECIFIQUE)

Usuario Solicitante Carlos Jharek Dávila Pino

Fecha deseada 01 de junio de 2017

FUNCIONALIDAD

Requerimiento Gestor Móvil

Descripción Nueva herramienta comercial que permita la consulta de

información financiera del cliente para generar campañas de
ofrecimiento de productos con condiciones acordes a sus
necesidades. La herramienta permitirá visualizar las ofertas
asociadas a los clientes, asimismo se podrá obtener
retroalimentación de los intentos de venta.

210
Información Adicional El diseño de la herramienta deberá contar estándares de UX (User
Experience), lo cual permitirá una navegación intuitiva,
reduciendo considerablemente el tiempo de entrenamiento.

Beneficios del Servicio El servicio les permitirá a los Ejecutivos identificar mayores
oportunidades de colocación en las agencias aprovechando los
arribos de los clientes a las agencias. Así, de forma de ágil y
confiable, podrán ofrecer los productos para generar nuevas ventas
y obtener retroalimentación continua de los clientes.

ALINEAMIENTO ESTRATÉGICO

OE1 Ser el banco principal de los clientes X

OE2 Fortalecer la calidad de servicio

OE3 Incrementar colocaciones en banca minorista y mayorista X

OE4 Control eficiente de gastos de operación y de riesgo

OE5 Incrementar la utilidad X

OE6 Ser el banco digital de la región X

Tabla 33: Ficha de Alcance de Servicio Gestor Móvil

Fuente: Elaboración propia

EVALUACIÓN FINANCIERA
En esta sección se realizará la evaluación financiera del servicio Gestor Móvil, a través de la
evaluación de beneficios y costos. Para ello se presentará el flujo económico, y el cálculo del
VAN y TIR del proyecto.

211
Flujo económico
Para el flujo económico se considerarán los ingresos netos por colocación de Tarjetas de
Crédito y Compras de Deuda, el detalle del cálculo y supuestos se mencionan en el capítulo 5
del presente trabajo. Asimismo, en la inversión y gastos, el desarrollo del software incluye
todos los componentes relacionados a la construcción de la solución móvil, hardware y pagos
por servicios utilizados permanentemente.

FLUJO ECONÓMICO - NUEVOS SOLES

2017 2018 2019
Momento 0 Año 1 Año 2 Año 3
Ingresos / Ahorros (Soles) Propuesto Propuesto Propuesto Propuesto
INGRESOS POR COLOCACIONES 1,463,069.00 5,267,048.00 6,583,810.00

Ingresos Totales 1,463,069.00 5,267,048.00 6,583,810.00

Acumulados 1,463,069.00 6,730,117.00 13,313,927.00

Inversión y Gastos (Soles) Propuesto Propuesto Propuesto Propuesto

DESARROLLO SW 460,000.00
TABLETS(1° Lote - 200 Tablets) 480,000.00 96,000.00 144,000.00
SERVIDOR ORACLE 10G 50,000.00
SOFTWARE ADQUIRIDO 34,000.00 34,000.00 34,000.00
DEPRECIACIÓN DESARROLLOS 92,000.00 92,000.00 92,000.00
DEPRECIACIÓN TABLETS 120,000.00 144,000.00 180,000.00
CONSULTAS RENIEC 10,000.00 22,064.00 34,819.00
SERVICIO INTERNET 80,000.00 288,000.00 360,000.00
MONITOREOS 60,000.00 60,000.00 60,000.00
GASTOS ADMINISTRATIVOS 31,325.75 142,246.55 225,977.00
OTROS 30,000.00 75,793.00 119,611.00
GASTO TOTAL 990,000.00 553,325.75 1,002,103.55 1,106,407.00
Acumulado 990,000.00 1,543,325.75 2,545,429.30 3,651,836.30

FLUJO DE CAJA AÑO 990,000.00 909,743.25 4,264,944.45 5,477,403.00

FLUJO DE CAJA ACUMULADO 990,000.00 -80,256.75 4,184,687.70 9,662,090.70

Tabla 34: Flujo económico Gestor Móvil

Fuente: Elaboración propia

212
VAN y TIR
En la evaluación del VAN, al tercer periodo, se evidencia que desde el primer periodo se
encuentran resultados positivos.

Tasa 12.00%

Valor Actual Valor Actual

Período Ingresos Egresos VAN
Ingresos Egresos
0 0 990,000 990,000 -990,000
1 1,463,069 1,306,312 553,326 494,041 812,271
2 5,267,048 4,198,858 1,002,104 798,871 3,399,988
3 6,583,810 4,686,226 1,106,407 787,519 3,898,707
10,191,396 3,070,430 7,120,966

Tabla 35: VAN Gestor Móvil

Fuente: Elaboración propia

En lo que se refiere a la evaluación del TIR, se encuentra un elevado %, en línea con los
diferentes proyectos realizados en el BBVA Continental.

TIR 134%

Período Ingresos Egresos

0 0 -990,000
1 1,463,069 -553,326
2 5,267,048 -1,002,104
3 6,583,810 -1,106,407

Tabla 36: TIR Gestor Móvil

Fuente: Elaboración propia

213
EVALUACIÓN DE RIESGOS
En esta sección se identifican los diferentes riesgos asociados a la implementación del
servicio Gestor Móvil.

MATRIZ DE RIESGOS
ID PROYECTO: SI001
FECHA DE INICIO: 01/03/2017
FECHA DE TÉRMINO PROPUESTA: 01/06/2017

Probabilida

Prioridad
(A/M/B)
Impacto

(1 - 9)
Riesgo Posible resultado Responsable de la
# Síntoma Respuesta

d
(si) (entonces) acción de respuesta

No contar con personal acorde al Incumplimiento de metas Retraso en las actividades Identificar las habilidades blandas y
perfil requerido para el desarrollo y establecidas en el documento de inicio del proyecto. técnicas de cada perfil requerido,
Gerente de Fábrica de
1 mantenimiento del servicio del proyecto. Media Alto 3 organizándolas por puesto requerido
Soluciones Digitales
solicitado. Más aún cuando los para brindar mayor detalle al área de
servicios son software innovadores recursos humanos
Falta de involucramiento de los Toma de decisiones erróneas Retraso en la planificación Realizar cronogramas de reuniones
usuarios clave y la alta gerencia. o no contar con todo el inicial del proyecto al con los interesados del proyecto de
detalle necesario para cumplir demorar en las manera semanal, identificando
Gerente de Fábrica de
2 con los requerimientos y aprobaciones y cambios Bajo Alto 6 dependencias con anticipación para no
Soluciones Digitales
alinearse a los objetivos del durante el proyecto afectar el avance. Contar con apuntes
negocio propuesto de los acuerdos a los que se llega en
cada reunión
Cambios en el alcance durante el No cumplimiento de los Re trabajo en el Plantear como se reaccionarán ante los
proyecto objetivos del proyecto. desarrollo del proyecto al cambios antes de empezar con el
dejar requerimientos a proyecto. Solicitar plantilla de
3 Media Medio 5 Analista de Banca Digital
medias para empezar Requerimientos de cambios e indicar
otros nuevos. quién será el responsable de la gestión
de cambios del proyecto
Equipos de computo Retraso en el inicio del Demora en el desarrollo Realizar un documento de
desactualizados sin el software proyecto y el cumplimiento de la solución características mínimas por cada perfil
Gerente de Arquitectura
4 necesario para el desarrollo del de tareas asignadas Bajo Bajo 9 del proyecto para contar con los
de Software
proyecto equipos necesarios antes de empezado
el proyecto
Falta de documentación actualizada Toma de requerimientos Entregas de poco valor al Identificar sub procesos en lo cuales
incompleta, alcance no usuario final del proyecto hace falta más documentación para
5 definido correctamente Media Medio 5 hacer reuniones con los apoderados Analista de Banca Digital
del proceso. Levantar nueva
documentación
Contratación de terceros para Incumplimiento en los Retraso en el desarrollo No contratar proveedores para los
apoyar en el desarrollo del proyecto tiempos de entrega por parte por tareas que dependen puestos críticos del proyecto. Para los Gerente de Fábrica de
6 Baja Baja 9
del proveedor de los requerimientos de puestos importantes seleccionar gente Soluciones Digitales
los terceros del banco acorde al perfil.
Probabilidad

A 4 2 1
M 7 5 3
B 9 8 6
B M A
Impacto

Tabla 37: Evaluación de Riesgos Gestor Móvil

Fuente: Elaboración propia

214
DISEÑO DEL SERVICIO
En esta sección se presentará la documentación generada en el proceso del mismo nombre,
específicamente se considerarán los artefactos de gestión de nivel de servicio y los acuerdos
relacionados al servicio interno y servicios de soporte identificados.

REQUERIMIENTO DE NIVEL DE SERVICIO

En esta sección se presentan los requerimientos de nivel de servicio solicitados por el cliente
interno para el servicio Gestor Móvil. Dichos requerimientos, serán evaluados para proponer
un SLA acorde a las necesidades de negocio, lo cual podrá verificarse en la siguiente sección.

Service Level Request

Organization Business & Process Engineering
Fecha: 12.12.2016
Datos del solicitante
Nombre: Gonzalo Camargo
Registro: X19200
Unidad: Gerencia de Banca Digital
Fecha: 05/01/2017

Datos del requerimiento

Nombre: Servicio Gestor Movil
Descripción: Servicio a través del cual los Ejecutivos de Banca Personal de las agencias, pueden ofrecer
productos activos a los clientes que ingresan a las agencias, esto lo harán de forma proactiva a partir de la
carga de campañas con ofertas preaprobadas.

Horario disponible
(X) Lunes a Viernes 09:00 – 19:00 y Sábados: 09:00 – 13:00
( ) 24 x 7
( ) Otros, especificar:

Indisponibilidad relacionada a temas contractuales o normativos

( ) < 4 horas
( ) < 1 día
( ) < 1 semana
(X) Otros, especificar: no es un servicio con impacto regulatorio y/o contractual

Tiempo de respuesta
Prioridad < a 1 hora < a 5 horas < a 24 horas < a 48 horas
Urgente X
Alta X
Media X 215
Baja X

Medición del servicio

 ( ) 24 x 7
( ) Otros, especificar:

Indisponibilidad relacionada a temas contractuales o normativos

( ) < 4 horas
( ) < 1 día
( ) < 1 semana
(X) Otros, especificar: no es un servicio con impacto regulatorio y/o contractual

Tiempo de respuesta
Prioridad < a 1 hora < a 5 horas < a 24 horas < a 48 horas
Urgente X
Alta X
Media X
Baja X

Medición del servicio

( ) Estadísticas de rendimiento del servicio
(X) Tiempos de respuesta a tickets según prioridad
( ) Otros, especificar:

Monitoreo del servicio

(X) Reportes de Centro de Servicios
( ) Alertas en correo electrónico / sms
( ) Otros, especificar:

ACUERDO DE NIVEL DE SERVICIO

En la presente sección se incluirá el acuerdo de nivel de servicio identificado para el servicio
de Gestor Móvil; en este se documentarán las responsabilidades y límites en el ofrecimiento
del servicio.

SLA_ GESTOR MÓVIL

Organization Business & Process Engineering
Fecha: 12.12.2016

1. Condiciones Generales
El presente documento especifica los términos del Acuerdo de Niveles de Servicio (también llamado
SLA, Service Level Agreement en inglés) bajo los cuales el área de Ingeniería se compromete a
brindar el servicio especificado.
El área de ingeniería en conjungo con la Gerencia de Banca Digital, pueden modificar el presente
Acuerdo de Niveles de Servicio en cualquier momento, informándose al cliente interno (Red de
Oficinas) formalmente.

2. Definiciones

2.1 CA Service Desk Manager: sistema a través del cual se ingresarán los tickets de cambios e
incidencias. Para ingresar debe realizarse con el registro de colaborador y contraseña de red.
2.2. Tiempo de respuesta (TAT): El tiempo de respuesta para dar solución a una solicitud, incidente
o problema estará relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.
En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la vez, se
considerara la variable “complejidad” para determinar el orden de atención: Baja, Media, Alta y Por
definir.
2.3. Disponibilidad: La disponibilidad implica la posibilidad del cliente de hacer uso del servicio
Gestor Móvil.
2.4. Tiempo medio de restauración (MTTR): es el tiempo transcurrido entre la hora de detección del
problema proactiva o reactivamente y la hora de restablecimiento del servicio. El tiempo medio de
restauración se calculará obteniendo el promedio de los tiempos de restauración del mes. 216
2.5. Mantenimiento programado: El mantenimiento programado es un tipo de interrupción realizado
para reemplazar / agregar servicios o instalar elementos a la red a fin de ampliar y mejorar
permanentemente el servicio Gestor Móvil. Será notificado previamente y el cuyo lapso de duración
 2.1 CA Service Desk Manager: sistema a través del cual se ingresarán los tickets de cambios e
incidencias. Para ingresar debe realizarse con el registro de colaborador y contraseña de red.
2.2. Tiempo de respuesta (TAT): El tiempo de respuesta para dar solución a una solicitud, incidente
o problema estará relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.
En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la vez, se
considerara la variable “complejidad” para determinar el orden de atención: Baja, Media, Alta y Por
definir.
2.3. Disponibilidad: La disponibilidad implica la posibilidad del cliente de hacer uso del servicio
Gestor Móvil.
2.4. Tiempo medio de restauración (MTTR): es el tiempo transcurrido entre la hora de detección del
problema proactiva o reactivamente y la hora de restablecimiento del servicio. El tiempo medio de
restauración se calculará obteniendo el promedio de los tiempos de restauración del mes.
2.5. Mantenimiento programado: El mantenimiento programado es un tipo de interrupción realizado
para reemplazar / agregar servicios o instalar elementos a la red a fin de ampliar y mejorar
permanentemente el servicio Gestor Móvil. Será notificado previamente y el cuyo lapso de duración
es 1 hora minutos, siendo el horario de mantenimiento entre la 00:00 y las 03:00 horas.

3. Compromisos
3.1. Tiempos de respuesta
Urgente: máximo 1 hora
Alta: máximo 4 horas
Media: máximo 24 horas
Baja: de acuerdo a coordinación previa entre las áreas
3.2. Disponibilidad
99% del tiempo disponible en el rango requerido
3.3. Tiempo medio de restauración
20 minutos, de lo contrario se cataloga como "no disponible".
3.4. Mantenimiento programado

Solo se podrá realizar entre las 00 y 03 horas. De lo contrario se cataloga como "no disponible".
4. Comunicación
Los usuarios pueden comunicarse a través de la central de centro de servicios, correo electrónico o el
sistema CA Service Desk Manager.
5. Exclusiones
Cualquier problema generado por origen en el usuario, mantenimientos programados o coordinados,
problemas atribuibles a la red quedarán excluídos de los compromisos.

NIVEL DE SERVICIO OPERACIONAL

En la presente sección se incluirá los principales acuerdos de servicios identificados para
servicios de soporte; se documentarán las responsabilidades y límites.

OLA_ Servicio Consulta de RENIEC

Organization Business & Process Engineering
Fecha: 12.12.2016
1. Condiciones Generales

El presente documento especifica los términos del Acuerdo de Nivel Operacional (también llamado OLA,
Operational Level Agreement en inglés) bajo los cuales el área de Ingeniería se compromete a brindar el
servicio especificado.
Tanto el área de Ingeniería, como las áreas a las que se le brindará el servicio podrán solicitar la revisión
del presente acuerdo, se define una periodicidad trimestral para ello.
Se mantendrá habilitado el servicio a través de una conexión con la entidad gubernamental, Reniec.
2. Definiciones
2.1 CA Service Desk Manager: sistema a través del cual se ingresarán los tickets de cambios e
incidencias. Para ingresar debe realizarse con el registro de colaborador y contraseña de red.
2.2. Tiempo de respuesta (TAT): El tiempo de respuesta para dar solución a una solicitud, incidente o
problema estará relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.
En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la vez, se
considerara la variable “complejidad” para determinar el orden de atención: Baja, Media, Alta y Por 217
definir.
2.3. Disponibilidad: La disponibilidad implica la posibilidad del cliente de hacer uso del servicio Gestor
Móvil.
 Fecha: 12.12.2016
1. Condiciones Generales

El presente documento especifica los términos del Acuerdo de Nivel Operacional (también llamado OLA,
Operational Level Agreement en inglés) bajo los cuales el área de Ingeniería se compromete a brindar el
servicio especificado.
Tanto el área de Ingeniería, como las áreas a las que se le brindará el servicio podrán solicitar la revisión
del presente acuerdo, se define una periodicidad trimestral para ello.
Se mantendrá habilitado el servicio a través de una conexión con la entidad gubernamental, Reniec.
2. Definiciones
2.1 CA Service Desk Manager: sistema a través del cual se ingresarán los tickets de cambios e
incidencias. Para ingresar debe realizarse con el registro de colaborador y contraseña de red.
2.2. Tiempo de respuesta (TAT): El tiempo de respuesta para dar solución a una solicitud, incidente o
problema estará relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.
En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la vez, se
considerara la variable “complejidad” para determinar el orden de atención: Baja, Media, Alta y Por
definir.
2.3. Disponibilidad: La disponibilidad implica la posibilidad del cliente de hacer uso del servicio Gestor
Móvil.
2.4. Tiempo medio de restauración (MTTR): es el tiempo transcurrido entre la hora de detección del
problema proactiva o reactivamente y la hora de restablecimiento del servicio. El tiempo medio de
restauración se calculará obteniendo el promedio de los tiempos de restauración del mes.
2.5. Mantenimiento programado: El mantenimiento programado es un tipo de interrupción realizado para
reemplazar / agregar servicios o instalar elementos a la red a fin de ampliar y mejorar permanentemente el
servicio Gestor Móvil. Será notificado previamente y el cuyo lapso de duración es 1 hora minutos, siendo
el horario de mantenimiento entre la 00:00 y las 03:00 horas.

3. Compromisos
3.1. Tiempos de respuesta
Urgente: máximo 1 hora
Alta: máximo 4 horas
Media: máximo 24 horas
Baja: de acuerdo a coordinación previa entre las áreas
3.2. Disponibilidad
99% del tiempo disponible en el rango requerido
3.3. Tiempo medio de restauración
20 minutos, de lo contrario se cataloga como "no disponible".
3.4. Mantenimiento programado

Solo se podrá realizar entre las 00 y 03 horas. De lo contrario se cataloga como "no disponible".
4. Comunicación
Los usuarios pueden comunicarse a través de la central de centro de servicios, correo electrónico o el
sistema CA Service Desk Manager.
5. Exclusiones
Cualquier problema generado por origen en el usuario, mantenimientos programados o coordinados,
problemas atribuibles a la red quedarán excluídos de los compromisos. Asimismo, al ser un servicio
conectado con una institución externa, este acuerdo se circunscribe bajo el supuesto de que dicha entidad
mantenga habilitada la conectividad.

218
CONTRATOS DE PROVEEDORES (UNDERPINNING CONTRACTS)
En la presente sección se presentará las características del contrato de servicio con el
proveedor de conexión a internet mediante el cual operará el Servicio Gestor móvil, desde las
Tablets requeridas para su uso.

1. Datos del proveedor

Razón Social: América Móvil del Perú SA
Nro. R.U.C.:
Dirección: Nicolas Arriola 480, La Victoria, Lima, Perú
Teléfono: 135 (móviles) y 0-800-00-911 (desde fijo)
Horario: 24x7
2. Datos de contacto
Contacto 1
Nombres y Apellidos: Carol Ruiz
Cargo: Ejecutivo Cuentas Corporativas
Correo Electrónico: [email protected]
Contacto 2
Nombres y Apellidos: Jose Felipas
Cargo: Asistente Cuentas Corporativas
Correo Electrónico: [email protected]
3. Servicio que brinda
Brinda servicio de internet a través de chips en las Tablets utilizadas por el Servicio
Gestor Móvil
4. Soporte que brinda
El soporte que se brinda es 24x7 para consultas o mantenimientos programados, para
incidencias es de lunes a sábado de 8:00 a 20:00
5. Compromiso de garantía
El internet brindado estará en el rango de 10% sobre el ancho de banda ofrecido,
asimismo la continuidad del funcionamiento al 99%.
La cobertura de la señal solo se dará en las zonas especificadas por Claro en su web
(opción Consulta de Cobertura).

TRANSICIÓN DEL SERVICIO

En esta sección se presentará la documentación generada en el proceso del mismo nombre,
específicamente se considerarán los artefactos de gestión de nivel de servicio y los acuerdos
relacionados al servicio interno y servicios de soporte identificados.

219
REQUERIMIENTO DE CAMBIO
Un requerimiento de cambio se realiza sobre un servicio previamente existente; en el caso del
presente trabajo profesional, se propone un nuevo servicio por lo que no aplicaría desarrollo
sobre esta sección.

ELEMENTOS DE CONFIGURACIÓN
A continuación se presentarán los CIs identificados para el servicio de Gestor Móvil.

Lista de CIs de Hardware

Lista de CIs de Software

220
PROCESOS ITIL
En esta sección se describirán los procesos diseñados para la organización en estudio, BBVA
Continental. Es importante resaltar que cada uno de estos procesos tiene los registros o
evidencias de los documentos o fichas que se elaboran en cada proceso y que han sido
desarrolladas en las secciones previas de este documento.

PROCESO DE GESTIÓN DEL PORTAFOLIO DEL SERVICIO

Este proceso forma parte de la Estrategia de Servicios, y busca el máximo valor a la
organización controlando los riesgos y costos a través de un análisis del mercado y la
selección adecuada de servicios. A continuación se presenta la definición del proceso para la
organización objetivo en el marco del presente trabajo profesional.

OBJETIVO
El presente documento establece el flujo de actividades para realizar adecuadamente la
Gestión del Portafolio de Servicios del banco para generar el máximo valor controlando los
riesgos y costos involucrados en el cumplimiento del mismo.

ALCANCE
El presente procedimiento está dirigido a toda el Área de Tecnologías de Información y
describe las tareas que deben realizar los diferentes roles de la empresa para evaluar la
factibilidad del servicio solicitado.

REFERENCIAS
ITIL 2011.

DEFINICIONES

 Portafolio de Servicio: Listado completo y detallado de los servicios administrados por la

organización, describiéndolos en términos de valor del negocio.

221
 Proyección de Servicios (Service Pipeline): Fase 1 del Portafolio de Servicios, que
incluye tan sólo los servicios que están en fase de estudio o desarrollo.

 Catálogo de Servicios (Service Catalogue): Fase 2 del Portafolio de Servicios, que

incluye tan solo aquellos servicios que la organización está prestando actualmente de cara
a los clientes.

 Servicios Retirados (Retired Services): Fase 3 del Portafolio de Servicios, que incluye tan
solo los servicios que hayan sido retirados o estén próximos a su baja. Es importante
conservar la documentación de estos servicios puesto que otros puedan verse en la
necesidad de recurrir a ella.

 ROI (Return of Investment): El Retorno sobre la Inversión es una herramienta para

analizar el rendimiento que la empresa tiene desde el punto de vista financiero (utilidad
en base a la inversión).

 RFC (Requirement for change): Solicitud formal para la implementación de un cambio.

Se registrará en el 4.6. CA Service Desk Manager.

 CA Service Desk Manager: Aplicativo en donde se registra el RFC para que internamente
se pueda hacer el seguimiento (cambios de estados) correspondiente.

RESPONSABILIDADES
El Gerente de Fábrica de Soluciones Digitales es el responsable de asegurar la correcta
aplicación del presente procedimiento.

CONDICIONES GENERALES
Se entiende que todas las nuevas solicitudes de servicio provienen de la reunión trimestral de
planificación, en la cual se definen los requerimientos y se les da priorización. Todas las
dependencias que puedan tener los servicios son identificadas en la planificación trimestral,
en la cual todos los equipos involucrados aceptan los compromisos que tengan que ver con
otros equipos para que no aparezcan bloqueos en el trimestre de trabajo.

222
DESARROLLO

Realizar solicitud de servicio y enviar mail con la solicitud (inicial)

Gerente de Desarrollo de Negocio

Recibe las solicitudes de los gerentes territoriales de la red de oficinas del banco y procede a
priorizarlas junto con ellos

Crea la Ficha del alcance del servicio con información inicial para que sea evaluado por el
Gestor de Portafolio de Servicios.

En caso de que la solicitud se tratase de una baja de un servicio vigente en el Portafolio de

Servicios, el flujo es el mismo, dado a que se tiene que evaluar el impacto por todos los
responsables del portafolio de modo de asegurar el correcto funcionamiento de servicios
relacionados al que será dado de baja.

Recibir Solicitud de Servicio y Realiza Reunión con los interesados

Analista de Banca Digital

Recibe las solicitudes del Gerente de Desarrollo de Negocio vía mail y la revisa

Si la información de la solicitud no es clara o hace falta más detalle lo llama por teléfono para
agilizar el proceso y no tener demoras.

Para que todos los detalles de la solicitud estén claras el gerente de banca digital convoca a
una breve reunión con los interesados del servicio para confirmar la información obtenida.

Crear Ficha de Alcance del Servicio y la envía

Analista de Banca Digital

Crea la Ficha de Alcance del Servicio

Envía la ficha al Gerente de Fábrica de Soluciones Digitales

223
Recibir la Ficha de Alcance del Servicio

Gerente de Fábrica de Soluciones Digitales

Recibirá la Ficha de alcance del servicio, en caso la Ficha presente algunos errores podrá
actualizarla.

Identificar los riesgos del servicio

Gerente de Fábrica de Soluciones Digitales

Elabora una Matriz de Riesgos en la que se identifiquen los posibles impactos y
probabilidades que implicaría la implementación del servicio requerido, por ejemplo: relación
con otros servicios (en fase de desarrollo o ya vigentes), tiempos de implementación, recursos
disponibles, etc. Asimismo se evaluará el impacto si se está solicitando la baja de un servicio.

Una vez que se tenga la Matriz de Riesgos del servicio, se enviará al Gerente de Arquitectura
de Software.

Evaluar la factibilidad técnica del servicio

Gerente de Arquitectura de Software

El gerente evalúa la factibilidad técnica del servicio en base a la Ficha del alcance del
servicio y la Matriz de Riesgos.

Si el análisis de factibilidad técnica es viable, se continuará con la siguiente tarea; de lo

contrario, el Gerente de Arquitectura de software indicará las limitaciones o motivos por los
cuales no se podrá cumplir con lo solicitado por el negocio.

Gerente de Fábrica de Soluciones Digitales

En caso de rechazo, el Gerente de Fábrica de soluciones Digitales, informará al Gerente de
Desarrollo de Negocio los motivos por los cuales no será factible la creación del servicio
solicitado. El gerente de desarrollo de Negocio recibirá la información y el proceso culmina,
si se plantea disminuir el alcance, el servicio pasará por el mismo proceso desde el inicio.

224
Solicitar Evaluación del Servicio

Gerente de Fábrica de Soluciones Digitales

El gerente solicita una evaluación del servicio a las demás áreas interesadas que son
Arquitectura de datos y Finanzas.

Evaluar Factibilidad del Servicio

Arquitecto de Datos
El arquitecto de datos evalúa que base de datos será requerida para el servicio, si se deben
crear nuevos esquemas y la cantidad de sesiones que se necesitarán para poder dar la
seguridad y continuidad de la información requerida.

Si el requerimiento es una baja de servicio el arquitecto de datos evalúa si la base de datos

puede ser eliminada sin afectar a otros servicios.

Gerente de Finanzas
El gerente de finanzas evaluará si el servicio requiere muchos recursos nuevos, solo si el
proyecto es muy costoso mencionará que el proyecto no es factible o necesita mayor análisis.

El gerente de Finanzas se basará solamente en la ficha del alcance del servicio para tomar su
decisión.

En la Ficha de Alcance de servicio se debe dar detalle de que nuevos recursos se deben
comprar para dar soporte al servicio.

Elaborar Evaluación Financiera

Gerencia de Fábrica de Soluciones Digitales

Elabora la Evaluación Financiera del servicio para que la apruebe el Gerente de Desarrollo de
Negocio.

Envía la Evaluación Financiera al Gerente de Desarrollo de Negocio.

225
Recibir la Evaluación Financiera.

Gerente de Desarrollo de Negocio

El Gerente de Desarrollo de Negocio revisa la evaluación Financiera y toma la decisión de
continuar o no con el servicio solicitado.

Una vez que se tenga la aprobación del Gerente de Desarrollo de Negocio, la siguiente tarea
será la mencionada en el punto 7.11., caso contrario, el proceso se dará por concluido.

Si el Gerente de Desarrollo de Negocios decide no proceder con el servicio, informa a todos

los involucrados el porqué de la decisión vía mail. Si es pertinente también podría convocar a
una reunión para dar mayores detalles de la decisión.

Registrar el RFC

Gerente de Fábrica de Soluciones Digitales

El Gerente Registra el RFC, en base a la Ficha del Alcance del Servicio ya aprobado por las
Gerencias de Arquitectura, Gerencias de Desarrollo de Negocio y Finanzas.

Una vez que se tenga el RFC, el documento es enviado a los procesos de:

Diseño de Servicios - Gestión de Proveedores: Para solicitar la cotización oficial del

desarrollo del servicio (nuevo o modificado)

Transición de Servicios - Gestión del Cambio: Para evaluar y planificar el proceso de cambio
que implica la implementación del servicio.

Actualizar el Portafolio de servicio.

Gerente de Fábrica de Soluciones Digitales

Actualiza el Portafolio de Servicios, según la fase en la que se encuentre el servicio:
Proyección de Servicios, Catálogo de Servicios o Servicios Retirados. Adicionalmente,
indicará el estado en la que se encuentra el servicio: Retención, Sustitución, Racionalización,
Refactorización, Renovación, Retirada.

226
REGISTROS

 Ficha del Alcance del Servicio.

 Matriz de Riesgos del Servicio

 Flujo de Caja proyectado

 RFC.

227
ANEXOS

Plantilla Ficha Alcance del Servicio

Plantilla: Ficha del Alcance del Servicio

Fuente: Elaboración propia

228
Matriz de Riesgos del Servicio

Plantilla: Matriz de Riesgos del Servicio

Fuente: Elaboración propia

229
Flujo de Caja Proyectado

Plantilla: Flujo de Caja Proyectado

Fuente: Elaboración propia

230
Diagrama de Flujo

Ilustración 52: Diagrama de Flujo del Proceso de Gestión de Portafolio de Servicio

Fuente: Elaboración Propia

231
PROCESO DE GESTIÓN DEL NIVEL DEL SERVICIO
Este proceso forma parte del Diseño del Servicio, y busca generar acuerdos con los clientes y
que el funcionamiento de los servicios se encuentre alineado a los objetivos de la
organización. A continuación se presenta la definición del proceso para la organización
objetivo en el marco del presente trabajo profesional.

OBJETIVO
El presente documento establece las pautas para realizar adecuadamente la Gestión del Nivel
de Servicio de TI, alineando la tecnología con los procesos de negocio del BBVA
Continental.

ALCANCE
El presente procedimiento está dirigido a satisfacer los servicios de la organización, tanto en
canales de atención, administrativos, backoffice y diferentes aplicaciones de uso interno y de
cara a clientes y no clientes tanto personas naturales, como jurídicas. Describe desde la
definición de los requerimientos de Nivel de Servicio hasta su implementación y
comunicación.

REFERENCIAS
ITIL 2011

DEFINICIONES

 SLA (Service Level Agreement): Un acuerdo de nivel de servicio es un contrato escrito

entre un proveedor de servicio de TI y su cliente, con el objeto de fijar niveles de calidad
en los servicios acordados.

 SLR (Service Level Request): Un Requisito de Nivel de Servicio es un documento que

recoge la información detallada de las necesidades del cliente y sus expectativas de
rendimiento y nivel de servicios.

232
 OLA (Operational Level Agreement): Un Acuerdo de Nivel Operacional es un
documento interno de la organización donde se especifican las responsabilidades y
compromisos de los diferentes departamentos de la organización de TI en la prestación de
un determinado servicio.

 UC (Underpinning Contract): Un Contrato de Soporte es un acuerdo con un proveedor

externo para la prestación de servicios no cubiertos por la propia organización.

RESPONSABILIDADES
El Gerente de Organization Business & Process Engineering es el responsable de asegurar la
correcta aplicación del presente procedimiento.

DIAGRAMA

Ilustración 53: Diagrama de Flujo del Proceso de Gestión de Nivel de Servicio

Fuente: Elaboración Propia

233
DESARROLLO

Antecedentes

Gerencia Banca Digital

Recibe las solicitudes de los clientes, los cuales pueden ser nuevos servicios o modificaciones
a los niveles de calidad de los servicios vigentes.

Determina requisitos del servicio nuevo o cambio

Gerencia Banca Digital

Elabora el SLR en base a la solicitud del cliente interno, ya sea para incluir o modificar un
SLA existente.

Identifica si existen UCs relacionados

Analista de Nivel de Servicio

Identifica si existen proveedores externos que participan en la prestación del servicio.

Por cada uno, verifica las cláusulas hagan referencia a los niveles de servicio recibidos.

Identifica si existen OLA relacionados

Analista de Nivel de Servicio

Identifica qué áreas internas participan en la prestación del servicio.

Por cada una, verifica si existen acuerdos internos ya definidos

Evalúa factibilidad de SLR

Analista de Nivel de Servicio

Elabora el análisis de factibilidad del SLR.

234
Si el análisis de factibilidad es viable, propone las opciones para alcanzar los nuevos términos
del SLA; de lo contrario indicará las limitaciones o motivos por los cuales no se podrán
cumplir lo solicitado y lo comunicará a los interesados.

Elabora o modifica el SLA

Analista de Nivel de Servicio

En coordinación con las gerencias y usuarios responsables se realiza la elaboración y/o
modificación del SLA.

Una vez que se cuenta con el documento, se envía para la aprobación de las gerencias de las
unidades con funciones relacionadas o impactadas por el SLA.

Evalúa y brinda resolución al SLA

Gerencias: Banca Digital, Engineering, Distribución Red, Desarrollo de Negocios

Las gerencias indicadas son responsables de aprobar, rechazar y/o brindar observaciones al
SLA de acuerdo a su nivel de autonomía y relación del SLA con las funciones de cada una de
estas.

Si alguna rechaza el SLA, deberá indicar las observaciones de su rechazo.

El Analista de Nivel de Servicio deberá realizar las modificaciones correspondientes en base

a las observaciones dadas por las Gerencias, en caso se trate de una aprobación con
observaciones.

Actualizar OLA

Analista de Nivel de Servicio

Actualiza los OLAs que estuvieran relacionados al SLA creado o modificado.

Comunicar los cambios realizados en el SLA

235
Analista de Nivel de Servicio
Comunica a los interesados en el cumplimiento del SLA el cierre de la definición a fin de que
sea conocido.

INDICADORES

Código Nombre

BBVA-NS-001 Porcentaje de satisfacción con el servicio

BBVA-NS-002 Porcentaje de incumplimiento de SLA / OLA

BBVA-NS-003 Porcentaje de incidentes escalados

REGISTROS

TIEMPO DISP.
CÓDIGO TITULO RESPONS. LUGAR
RET. FINAL

Requerimiento
Gerente Gerencia Banca
BBVA-NS-SLR de Nivel de 3 años Eliminar
Banca Digital Digital
Servicio

Organization
Analista de
Acuerdo de Business &
BBVA-NS-SLA Nivel de 3 años Eliminar
Nivel de Servicio Process
Servicio
Engineering

Organization
Acuerdo de Analista de
Business &
BBVA-NS-OLA Nivel Nivel de 3 años Eliminar
Process
Operacional Servicio
Engineering

236
ANEXOS

Requerimiento de nivel de servicio

Datos del solicitante
Nombre:
Registro:
Unidad:
Fecha:

Datos del requerimiento

Nombre:
Descripción:

Horario disponible
( ) Lunes a Viernes 09:00 – 19:00 y Sábados: 09:00 – 13:00
( ) 24 x 7
( ) Otros, especificar:

Indisponibilidad relacionada a temas contractuales o normativos

( ) < 4 horas
( ) < 1 día
( ) < 1 semana
( ) Otros, especificar:

Tiempo de respuesta
Prioridad Inmediata < a 5 horas < a 10 horas < a 30 horas
Urgente
Alta
Media
Baja

Medición del servicio

( ) Estadísticas de rendimiento del servicio
( ) Tiempos de respuesta a tickets según prioridad
( ) Otros, especificar:

Monitoreo del servicio

( ) Reportes en Centro de Servicios
( ) Alertas en correo electrónico / sms
( ) Otros, especificar:

237
Acuerdo de Nivel de Servicio (SLA)

1. Condiciones Generales
Se presentan las especificaciones y características generales del SLA respecto del servicio
requerido.
2. Definiciones
Se deben presentar definiciones relacionadas al servicio y los procesos relacionados a la
gestión del nivel de servicio.
3. Compromisos
3.1. Tiempos de respuesta
Se debe indicar, de acuerdo a la criticidad de un evento en el servicio, los tiempos de
respuesta desde la creación de un ticket de incidencia.
3.2. Disponibilidad
Se debe indicar el compromiso de disponibilidad promedio diaria del servicio en los
tiempos definidos en que debe estar habilitado.
3.3. Tiempo medio de restauración
Se debe indicar el tiempo máximo para la restauración del servicio en caso no esté
disponible.
3.4. Mantenimiento programado
Se debe indicar los horarios en donde se podrá realizar actualizaciones o mantenimiento
al servicio, asimismo las previsiones en caso no sea posible cumplir este horario.
4. Comunicación
Se debe indicar los diferentes canales de comunicación para consultas, solicitudes o
incidentes relacionados al servicio.
5. Exclusiones
Se debe señalar aquellas situaciones que no se consideran en el cálculo de la disponibilidad
del servicio y/o los diferentes compromisos establecidos

238
Acuerdo de Nivel Operacional (OLA)

1. Condiciones Generales
Se presentan las especificaciones y características generales del OLA respecto del servicio
de soporte requerido.
2. Definiciones
Se deben presentar definiciones relacionadas al servicio y los procesos relacionados a la
gestión del nivel de servicio.
3. Compromisos
3.1. Tiempos de respuesta
Se debe indicar, de acuerdo a la criticidad de un evento en el servicio, los tiempos de
respuesta desde la creación de un ticket de incidencia.
3.2. Disponibilidad
Se debe indicar el compromiso de disponibilidad promedio diaria del servicio en los
tiempos definidos en que debe estar habilitado.
3.3. Tiempo medio de restauración
Se debe indicar el tiempo máximo para la restauración del servicio en caso no esté
disponible.
3.4. Mantenimiento programado
Se debe indicar los horarios en donde se podrá realizar actualizaciones o mantenimiento
al servicio, asimismo las previsiones en caso no sea posible cumplir este horario.
4. Comunicación
Se debe indicar los diferentes canales de comunicación para consultas, solicitudes o
incidentes relacionados al servicio.
5. Exclusiones
Se debe señalar aquellas situaciones que no se consideran en el cálculo de la disponibilidad
del servicio y/o los diferentes compromisos establecidos

239
Contrato de Soporte (UC)

1. Datos del proveedor

Razón Social:
Nro. R.U.C.:
Dirección:
Teléfono:
Horario:
2. Datos de contacto
Contacto 1
Nombres y Apellidos:
Cargo:
Correo Electrónico:
Contacto 2
Ø Nombres y Apellidos:
Ø Cargo:
Ø Correo Electrónico:
3. Servicio que brinda
Indicar cuál es el servicio que brinda el proveedor de manera detallada.
4. Soporte que brinda
Indicar las condiciones del soporte a consultas, requerimientos e incidentes.
5. Compromiso de garantía
Indicar el compromiso respecto del funcionamiento o disponibilidad del servicio,
señalando el periodo de esta, de ser necesario.

240
PROCESO GESTIÓN DE CAMBIOS
Este proceso forma parte de la Transición de Servicios, y busca manejar los cambios que se
generan en los servicios. A continuación se presenta la definición del proceso para la
organización objetivo en el marco del presente trabajo profesional.

OBJETIVO:
El presente documento establece las pautas para realizar adecuadamente la Gestión del
Cambio con el fin de supervisar y aprobar la introducción o modificación de nuevos
servicios, siguiendo los procedimientos establecidos y asegurando en todo momento la
calidad y continuidad.

ALCANCE:
El presente procedimiento está dirigido a las diferentes unidades del BBVA Continental
encargadas de solicitar y gestionar servicios, y describe cómo manejar convenientemente los
cambios de los servicios prestados desde la planificación, evaluación, pruebas,
implementación y documentación de los mismos.

REFERENCIAS:
ITIL 2011

DEFINICIONES:

 Incidencia: Cualquier evento que no forma parte de la operación estándar de un servicio y

que causa o puede causar una interrupción o una reducción de calidad del mismo.

 Problema: Causa subyacente, aún no identificada, de una serie de incidentes o un

incidente aislado de importancia significativa.

 CAB (Change Advisor Board): Órgano interno compuesto por representantes de las
unidades de Banca Digital, Organization Business & Process Engineering, y Finanzas (de
acuerdo a autonomía). El CAB se encarga de aprobar / rechazar una solicitud de cambio,
previa evaluación, priorización y programación de los mismos.

241
 ECAB (Emergency Change Advisor Board): Órgano interno que toma decisiones
relacionadas con cambios de emergencia cuyo impacto es significativo (naturaleza /
urgencia).

 RFC (Requirement for change): Solicitud formal para la implementación de un cambio.

Se registrará en el 4.6. CA Service Desk Manager.

 CA Service Desk Manager: Aplicativo en donde se registra el RFC para que internamente
se pueda hacer el seguimiento (cambios de estados) correspondiente.

RESPONSABILIDADES:
El Gerente de Organization & Business Process Engineering es el responsable de asegurar la
correcta aplicación del presente procedimiento.

DIAGRAMA:

Ilustración 54: Diagrama de Flujo del Proceso de Gestión de Cambios

Fuente: Elaboración Propia

242
DESARROLLO:

Antecedentes
La solicitud del cambio ha sido previamente registrado en el sistema CA Service Desk
Manager.

La solicitud del cambio puede provenir de los procesos de Gestión de Portafolio de Servicios,
Gestión de Eventos, o Gestión de Problemas.

Verificar el RFC

Especialista de Cambio
Evalúa los alcances del RFC, así como se verifica de que éste tenga la prioridad e
información funcional correcta.

Si el RFC cumple, será evaluado con un checklist técnico, que corresponde a lo descrito en
8.3; de lo contrario se da por concluido el proceso de Gestión del Cambio e informa a los
interesados e iniciadores del proceso.

Ejecutar checklist de certificación técnica

Especialista de Cambio
Verifica el tipo de implementación y obtiene del compartido de documentación el checklist
de validación correspondiente.

Si no tiene observaciones, o estas son menores, las resuelve y avanza; de lo contrario se da

por concluido el proceso de Gestión del Cambio e informa a los interesados e iniciadores del
proceso.

Planificar RFC y enviar al CAB

Especialista de Cambio

243
Analiza los recursos necesarios y programa la ejecución del RFC.

Con esta información envía a CAB (Comité de Cambios) para su evaluación en la sesión
correspondiente de la semana.

Evaluar y autorizar cambio

Comité de Cambios
El comité se reúne y revisa los cambios planificados enviados por el Analista.

En caso exista acuerdo mayoritario, se autoriza y evalúa la programación, en caso sea

correcta avanza hacia 8.8, si no continúa en 8.7. En caso se rechace el RFC, se comunicará al
Especialista de Cambio y continúa en 8.6.

Registrar motivo de cancelación y actualizar RFC

Especialista de Cambio
Toma conocimiento del rechazo del RFC, y actualiza en el sistema el status de este,
incluyendo el motivo de rechazo.

Informa a los interesados e iniciador del cambio.

Actualizar programación

Comité de Cambios
De acuerdo al análisis de riesgos que realiza, y otros cambios, se toma la decisión de
reprogramar la fecha/hora de la ejecución del cambio.

Esto será informado al Especialista de Cambio mediante el sistema para que realice las
coordinaciones que correspondan.

Coordinar implementación

244
Especialista de Cambio
De acuerdo al resultado del Comité, el Especialista verifica las consideraciones para la
ejecución del cambio y cierra la programación con Producción e Implementación.

(Inicio Gestión de entrega y despliegue)

Ejecutar RFC (HW/SW)

Implementador de Cambios
Recibe por el sistema petición de implementación, y verifica que cuente con todo lo
requerido.

Ejecuta lo solicitado en el RFC, sea cambio relacionado a software, hardware o ambos, e

ingresa acción en el sistema.

En caso se presenten problemas durante la ejecución, continúa con 8.10.

Ejecutar rollback

Implementador de Cambios
Retorna HW/SW a momento previo a la ejecución del RFC.

Ingresa al sistema actividad y escala a Especialistas para ejecutar nuevamente el RFC (8.9).

Verificar post-pase

Implementador de Cambios
Verifica que los componentes se encuentren funcionando satisfactoriamente según lo
requerido en el RFC. En caso sea así, informa y cierra estación en el sistema; de lo contrario
ejecuta 8.10.

(Fin Gestión de entrega y despliegue)

245
Verificar y cerrar RFC

Especialista de Cambio
Verifica que lo solicitado en el RFC se encuentre implementado de manera adecuada.

Informa a interesados y cierra el RFC.

INDICADORES:
Código Descripción

BBVA-GC-001 Cambios sobre total de servicios y componentes

BBVA-GC-002 Número de cambios de emergencia sobre total de cambios

BBVA-GC-003 Número de cambios no autorizados sobre total de cambios

REGISTROS:

TIEMPO DISP.
CÓDIGO TITULO RESPONS LUGAR
RET. FINAL

Organization
Requerimiento Especialista Business &
BBVA-GC-RFC 5 años Almacenar
de Cambio de Cambios Process
Engineering

Respons.: Responsable

Tiempo Ret.: Tiempo Retención

Disp. Final: Disposición final

246
ANEXOS:
Request for Change (RFC), Formulario de Registro en Sistema

Ilustración 55: Sistema CA Service Desk Manager

Fuente: Elaboración Propia

247
PROCESO ACTIVOS DEL SERVICIO Y GESTIÓN DE LA
CONFIGURACIÓN
El BBVA Continental constantemente debe implementar nuevos proyectos de tecnologías de
la información para tomar iniciativa en el mercado o para responder a los ataques de la
competencia y no quedarse rezagado. Este rápido crecimiento en tecnología debe darse de
manera ordenada y mapeando todos los nuevos equipos y nuevas aplicaciones que se están
adquiriendo para darles una adecuada gestión, el presente proceso nos da un flujo de cómo
trabajar con nuevos CIs.

OBJETIVO
El presente documento establece las pautas para realizar adecuadamente la Gestión de la
Configuración y Activos de TI, llevando un registro actualizado de todos los elementos de
configuración de la infraestructura de TI junto con sus interrelaciones.

ALCANCE
El presente procedimiento está dirigido a toda el Área de Tecnologías de Información y
describe como obtener el máximo provecho del detalle de la infraestructura de TI, brindando
información precisa y fiable para servir de apoyo a otros procesos como Gestión de
Incidencias, de Problemas y de Cambios.

REFERENCIAS
ITIL 2011

DEFINICIONES

 CI (Configuration Item): Un Elemento de Configuración es todo activo, servicio,

componente de servicio o cualquier ítem que es o está bajo el control de la Gestión de la
Configuración.

248
 CMDB (Configuration Management Database): La Base de Datos de la Gestión de la
Configuración contiene la información detallada de cada CI y sus diferentes
interrelaciones o interdependencias tanto físicas como lógicas con otras CI’s.

 BMC Remedy It Service: Herramienta que da soporte y mantenimiento de la base de

datos de la Gestión de la configuración. CMDB

RESPONSABILIDADES
El Gerente de Infraestructura es el responsable de asegurar la correcta aplicación del presente
procedimiento.

CONDICIONES GENERALES
Cuando se actualiza la lista de CI's siempre se debe analizar si este nuevo CI requiere
monitoreo. Los monitoreos como por ejemplo revisión de ejecución de jobs nocturnos son
llevados a cabo por el equipo de Frente único que se encuentra físicamente en México dado
que los servidores están ubicados en ese país. Es importante que todo nuevo CI que necesite
monitoreo este considerado por el equipo de frente único sino no podrá tener el soporte
rápido y las alertas necesarias para dar soporte a otros procesos.

249
DIAGRAMA

Ilustración 56: Diagrama del Proceso de Activos del Servicio y Gestión de Configuración
Fuente: Elaboración Propia

250
DESARROLLO

Notificación de RFC

Gestor de Cambio
Realiza la notificación cuando se da un RFC

El Gestor de Cambio debe informar al Gerente de Infraestructura del cambio que se llevará a
cabo en el banco.

Identificar HW / SW y Servicios de TI

Gerente de Infraestructura
En base a la información generada por la aplicación de Inventarios (OCS), se identificarán los
cambios o nuevas adiciones de Hardware / Software dentro de la infraestructura de TI.

En cuanto a los Servicios, se tomará como referencia el RFC.

Clasificar CI’s en Remedy IT service

Gerente de Infraestructura
Clasifica el HW / SW y Servicios de TI para poder determinar su criticidad y definirlos como
CI’s.

Los cambios o mejoras en la infraestructura deben ser registrados en el listado de CI´s

Los CI's son gestionados por la herramienta Remedy It service

Actualizar el Listado de CI’s

Gerente de Infraestructura

251
Actualiza el Listado de CI’s, donde se incluirán sus atributos o características: Código de CI,
Tipo de CI, Nombre de CI, Descripción de CI, Ubicación, CI Monitoreado, Responsable,
Plataforma Tecnológica, etc.

También se deben considerar los tipos de relaciones lógicas y físicas entre CI’s o
subcomponentes registrados independientemente.

Actualizar el Diagrama de Infraestructura de TI

Gerente de Infraestructura
Actualiza el Diagrama de Infraestructura de TI en base a las relaciones establecidas en el
Listado de CI’s.

El Diagrama de Infraestructura de TI es enviada al Arquitecto de Infraestructura para su

validación.

Validar el Diagrama de Infraestructura de TI

Arquitecto de Infraestructura
Si el Diagrama de Infraestructura de TI es válido, se actualiza el documento en la CMDB; de
lo contrario será devuelto al Gerente de Infraestructura con los motivos del rechazo,
regresándose a la tarea mencionada en el punto 8.3.

Controlar los estados de los CI’s

Gerente de Infraestructura
Controla los estados de los CI’s a través de la herramienta Remedy.

En el caso de que se haya realizado una baja, adición o cambio en los CI’s, estos deberán
actualizarse en la herramienta de monitoreo.

Cuando se tenga una alerta en la herramienta Remedy, deberá informarse a los procesos de
Gestión de la Capacidad o Gestión de la Disponibilidad.

252
Si el CI debe monitorearse, se debe enviar la información del CI al jefe de Frente único para
que procesa a registrarlo.

Recibir CI's y Registarlos

Jefe de Frente Único

El Jefe de Frente Único recibe los CI's que requieren de monitoreo y procede a registrarlos en
una herramienta de monitoreo.

El Jefe de Frente Único es responsable del monitoreo de todos los CI's.

Asignar Tareas de Monitoreo

Jefe de Frente Único

El Jefe de Frente Único crea tareas de monitoreo de acorde a lo requerido.

El Jefe de Frente Único asigna las tareas a los colaboradores de su equipo y programa las
alarmas para tener informe de cuando no son cumplidas estas tareas.

El Jefe de Frente Único informa de las tareas de monitoreo al Gerente de infraestructura para
que tenga pleno conocimiento de ellas.

Actualizar Listado de CI's

Gerente de Infraestructura
El Gerente de Infraestructura actualiza el listado de CI's indicando si son monitoreadas o no

Finalmente el Gerente de infraestructura notifica a los encargados de la Gestión de Capacidad

y de la Gestión de la disponibilidad para que estén informados de los CI's.

253
 INDICADORES

Código Descripción

BBVA-AC-K-022 Incremento en la reutilización y redistribución de recursos y

activos poco usados

BBVA-AC-K-023 Mejorar los tiempos de ejecución del mantenimiento de los

ítems de configuración

BBVA-AC-K-024 Mejorar el radio de licencias empleadas vs licencias

adquiridas

BBVA- AC-K-025 Mejorar el radio de software instalado vs software autorizado

REGISTROS

TIEMPO
DE DISPOSICIÓ
CÓDIGO TITULO RESPONSABLE LUGAR
RETENSIÓ N FINAL
N

Líder HD / Oficina
CP-AC-F-012 Listado de CI’s 5 años Triturado
Infraestructura Gerencia TI

254
ANEXOS

Diagrama de Infraestructura Propuesta

Ilustración 57: Diagrama de Infraestructura Propuesta BBVA

Fuente: Elaboración Propia

255
Listado de CI's

Ilustración 58: Lista de CI's de Software

Fuente: Elaboración Propia

Ilustración 59: Lista de CI's de Hardware

Fuente: Elaboración Propia

256
PROCESO DE GESTIÓN DE INCIDENTES
Este proceso forma parte de la Operación de Servicios, y busca proveer y mantener las
herramientas, los procesos y las reglas para un manejo de incidentes efectivo y eficiente. A
continuación se presenta la definición del proceso para la organización objetivo en el marco
del presente trabajo profesional.

OBJETIVO:

El presente documento establece las pautas para realizar adecuadamente la Gestión de

Incidentes para poder resolver, de la manera más rápida y eficaz posible, cualquier incidente
que cause una interrupción en los servicios los cuales podrían llegar a afectar a los clientes y
no clientes del BBVA Continental.

ALCANCE:

El presente procedimiento está dirigido a las áreas del BBVA encargadas de restaurar los
servicios luego de incidentes, para asegurar la operatividad y cumplir con los niveles de
servicios acordados (SLAs, OLAs) mejorando así la satisfacción general de sus clientes y
usuarios.

REFERENCIAS:

ITIL 2011

DEFINICIONES:

 Evento: Todo suceso detectable que tiene importancia para la estructura de la

organización de TI, para la prestación de un servicio o para la evaluación del mismo.

 Incidencia: Cualquier evento que no forma parte de la operación estándar de un servicio y

que causa o puede causar una interrupción o una reducción de calidad del mismo.

 Problema: Causa subyacente, aún no identificada, de una serie de incidentes o un

incidente aislado de importancia significativa.

257
 Excepción: Tipo de evento que indica que un servicio está operando de manera irregular y
puede representar un fallo total, un cese de funcionalidad o una disminución del
rendimiento.

 KDB (Known Data Base): Base de datos de errores conocidos.

 FAQ (Frequently Asked Questions): Listado de preguntas y respuestas de uso frecuente

respecto a un tema en particular.

 RFC (Requirement for change): Solicitud formal para la implementación de un cambio.

Se registrará en el 4.8. CA Service Desk Manager.

 CA Service Desk Manager: Aplicativo en donde se registra el RFC para que internamente
se pueda hacer el seguimiento (cambios de estados) correspondiente.

RESPONSABILIDADES:
El Gerente de Organization & Business Process Engineering es el responsable de asegurar la
correcta aplicación del presente procedimiento.

DIAGRAMA:

258
 Ilustración 60: Diagrama de Flujo del Proceso de Gestión de Incidentes
Fuente: Elaboración Propia

Nota: por la naturaleza propia del negocio, el BBVA Continental cuenta con diferentes
niveles de atención según se defina el servicio.

DESARROLLO:

Antecedentes
El incidente ha sido previamente registrado en el CA Service Desk Manager.

Se considera como cliente, tanto a los usuarios internos como a los clientes externos, a los
cuales se les brinda servicios.

Evaluar incidente

Analista Primer Nivel

Evalúa el incidente y clasifica y completa información en el sistema.

Luego busca información en el KBD (Knowledge Database). De encontrarla sigue con 8.3;
de lo contrario evalúa si es necesario escalar a un siguiente nivel (8.7), esta actividad será
iterativa por cuantos niveles sean necesarios. En caso pueda resolverlo, pasa a 8.4.

Ejecutar pasos

Analista Primer Nivel

Ejecuta los pasos necesarios de acuerdo a lo indicado en la el KBD. Luego verifica si la
solución es definitiva y de ser así avanza hasta 8.6; de lo contrario continúa con el proceso de
Gestión de Problemas.

Analizar y resolver incidente

Analista Primer Nivel

259
Realiza el diagnóstico del incidente, identificando las posibles causas y determinando las
posibles acciones para solucionarlo.

Ejecuta la solución encontrada para resolver el incidente.

Documentar solución

Analista Primer Nivel

Registra la solución en el KDB, en la categoría correspondiente e informa a administrador de
plataforma para verificación.

Luego verifica si la solución es definitiva y de ser así avanza hasta 8.6; de lo contrario
continúa con el proceso de Gestión de Problemas e ingresa una nota en el KBD.

Comunicar y cerrar ticket de incidente

Analista Primer Nivel

Comunica la solución del incidente al o los afectados, en caso haya canales comprometidos
también realiza la comunicación a los responsables según tabla de contactos.

Cierra el ticket de incidencia incluyendo observaciones necesarias; termina el proceso.

Realizar diagnóstico técnico

Analista “N” Nivel

Realiza el diagnóstico técnico del incidente, identificando las posibles causas y determinando
las posibles acciones de solución, teniendo como referencia las primeras acciones realizadas
por el Analista Primer Nivel.

Si una vez realizado el diagnóstico, se determina que el incidente es un problema, se

procederá con la tarea descrita en el punto 8.8. De lo contrario, continúa en 8.9

Si requiere escalar a otro nivel continúa iterativamente con la actividad hacia el siguiente
nivel.

260
Actualizar ticket con acciones técnicas

Analista “N” Nivel

Actualiza el ticket del incidente ingresando al CA Service Desk Manager, y documenta las
acciones realizadas siendo el incidente derivado al proceso de Gestión de Problemas.

Verificar con usuario

Analista “N” Nivel

Se contacta con el usuario que ingresó el incidente para contar con mayores detalles de este y
preparar la solución.

Ingresa la acción en el sistema y actualiza el ticket y nivel de servicio.

Analizar y resolver incidente

Analista “N” Nivel

Realiza el diagnóstico del incidente, identificando las posibles causas y determinando las
posibles acciones para solucionarlo.

Ejecuta la solución encontrada para resolver el incidente.

Documentar solución

Analista “N” Nivel

Registra la solución en el KDB, en la categoría correspondiente e informa a administrador de
plataforma para verificación.

Luego verifica si la solución es definitiva y de ser así avanza hasta 8.6; de lo contrario
continúa con el proceso de Gestión de Problemas e ingresa una nota en el KBD.

261
INDICADORES:

Código Descripción

BBVA-GI-001 % de incidentes resueltos fuera del nivel de servicio

BBVA-GI-002 % de incidentes escalados (1 y 2)

BBVA-GI-003 % neto de satisfacción de incidentes

REGISTROS:

TIEMPO
RESPONSABL DISPOSICIÓ
CÓDIGO TITULO RETENCIÓ LUGAR
E N FINAL
N

Organization
Registro y atención Especialista de Business &
BBVA-GI-RFC 5 años Almacenar
de incidentes Incidentes Process
Engineering

262
ANEXOS:

Formulario de Registro de Incidente en Sistema

263
Formularios de Atención de Incidente en Sistema

Recepción y complementación de información

264
Nivel de Servicio

Solución

265
CONCLUSIONES
Luego del análisis y comprensión de los procesos de ITIL y la aplicación de las plantillas
resultantes de los procesos trabajados, se pudo comprender que se debe entregar no solo un
servicio que cubra con los requerimientos iniciales del banco, sino también pensar en todo
momento en cómo se asegurará el correcto funcionamiento del servicio en producción, y
cómo se gestionarán sus futuros cambios a corto y largo plazo, teniendo en cuenta la rápida
evolución que se viene llevando a cabo en el sector financiero del país.

Se llegó a la conclusión que el contar con procesos definidos para la gestión de servicios
garantiza un correcto análisis previo al desarrollo del servicio, siendo crítico tener una
evaluación financiera en el cual se deba proyectar una ganancia o ahorro para el banco,
cuando el servicio haya sido concluido y puesto en producción, esto alineará los esfuerzos de
crear nuevos servicios con los objetivos estratégicos de BBVA.

Además, se ha logrado comprender también la importancia de contar con una Base de Datos
de la Gestión de la Configuración (CMDB) actualizada y con un nivel de detalle alto
referente a la descripción de los CI, esto permitirá tener un adecuado monitoreo de los CI’s
para poder lograr una ventaja competitiva en lo que respecta a mejorar la calidad de la
atención en las oficinas del banco, al siempre tener todas las herramientas funcionando en el
momento oportuno para los ejecutivos de ventas.

Finalmente, se ha concluido que las métricas y niveles de acuerdos en los servicios son
fundamentales para controlar y alertar posibles problemas antes de que ocurran. Asimismo, se
comprendió que los acuerdos se pueden ir ajustando según las necesidades de mejora de los
procesos asociados, lo cual se dará en muchas oportunidades dado que el BBVA siempre está
haciendo mejoras en sus procesos, agregando nuevas herramientas tecnológicas y contratando
nuevos perfiles profesionales para lograr sus objetivos estratégicos como por ejemplo, ser el
banco digital de la región.

266
CAPÍTULO 5: ESTRUCTURA PROPUESTA

INTRODUCCIÓN
El presente capítulo consolida lo presentado en los capítulos anteriores, así mismo explica
cómo se integran los diferentes conceptos presentados en la elaboración de la propuesta de
arquitectura empresarial para responder de forma idónea a los objetivos estratégicos de la
organización, en el proceso de venta en agencias financieras del BBVA.

En un inicio, se presenta brevemente los elementos y/o marcos de trabajo utilizados en los
capítulos previos y que permiten comprender cada etapa requerida en el proceso de creación
de la propuesta. Posteriormente, se muestra un diagrama con el cual se identifican las
relaciones entre estos elementos de forma secuencial para un mejor entendimiento de la
estructura propuesta.

Finalmente, se brindan conclusiones al capítulo, a través de las cuales se argumenta cómo la

propuesta satisface a los objetivos a través de la integración de los elementos presentados.

ELEMENTOS A CONSIDERAR
La solución propuesta tiene diferentes elementos a considerar, los cuales han sido revisados y
analizados por separado para comprender en cada capítulo el aporte de cada uno de estos, de
forma tal que se comienza por lo particular, para luego pasar a la propuesta general ya
estructurada. En el gráfico presentado a continuación, se puede apreciar cómo los diferentes
elementos utilizados se encuentran enmarcados dentro de la organización objetivo, en este
caso el BBVA Continental, la cual provee a la propuesta de inputs como su visión, misión,
objetivos, lineamientos, entre otros componentes estratégicos. Después, se continúa con el
desarrollo de la Arquitectura Empresarial a través del ciclo ADM para analizar cada una de
las dimensiones y obtener las brechas que serán cubiertas con un proyecto; luego se continúa

267
con la definición del framework de desarrollo de software, el cual al ser culminado requerirá
de la gestión de servicios de TI para su mantenimiento y sostenibilidad.

Ilustración 61: Elementos utilizados en la propuesta

Fuente: Elaboración Propia

ORGANIZACIÓN OBJETIVO
A través del análisis de la organización es que se reconocen los objetivos estratégicos que se
persiguen, los cuales son claves para la selección del proceso que se toma para ser estudiado.
Así, a continuación se presentan los objetivos del BBVA con impacto directo en el proceso y
la propuesta de arquitectura.

Nro. Objetivo

1 Ser el banco principal de los clientes

2 Fortalecer la calidad de servicio

3 Incrementar colocaciones en banca minorista y mayorista

4 Control eficiente de gastos de operación y de riesgo

268
 Nro. Objetivo

5 Incrementar la utilidad

6 Ser el banco digital de la región

Tabla 38: Objetivos estratégicos BBVA (propuesta)

Fuente: BBVA Continental

Cada uno de estos objetivos se encuentra en el Balance Scorecard de la organización y tienen

indicadores que se revisan mensualmente como: SoW (Share of Wallet), IReNe (Indice de
Recomendación Neto), colocaciones brutas, usuarios digitales, entre otros. Asimismo, en el
presente trabajo se puede apreciar cómo se relacionan con los macro procesos del BBVA
Continental, lo cual se aprecia en la tabla 4, “Matriz de objetivos versus macroprocesos”.

Es importante precisar que si bien se ha tomado como proceso macro uno de los que más
impacto tiene en los objetivos, como es el de Gestión de las colocaciones, finalmente la
propuesta sobre el subproceso seleccionado Gestión de venta de productos financieros en
agencias impactará a cuatro de estos (1,3, 5, 6).

ARQUITECTURA EMPRESARIAL
En el capítulo 2 se desarrolla ampliamente la propuesta de arquitectura empresarial bajo el
marco de trabajo TOGAF, desde la fase Preliminar, hasta la fase E, para cada una de sus
dimensiones tanto en lo referido a la situación actual, como a la situación propuesta o deseada
y las brechas encontradas entre ambas para el proceso de negocio de colocación o venta de
productos financieros en las agencias del BBVA; esto permitió definir el software a través del
cual se podrían cubrir las brechas principales, al cual se ha definido como “Gestor Móvil”,
además de servicios complementarios como la explotación de información generada en el
proceso de venta en las agencias, todos ellos deben ser implementados a través de proyectos o
iniciativas de desarrollo.

El entendimiento del negocio, desarrollado en los primeros entregables de arquitectura, y las

necesidades desarrolladas en la fundamentación y justificación, fueron claves para contar con

269
una propuesta consistente con los objetivos estratégicos, lo cual podrá apreciarse al describir
el diagrama de relación entre los elementos desarrollados en esta sección.

La propuesta de arquitectura empresarial para el presente trabajo empieza con el cambio en el

proceso de negocio core de venta en agencias financiera, en este proceso se eliminarán
algunas actividades que realizaba el personal del banco en la ventanilla, estas actividades
serán reemplazadas con acciones concretas de acercamiento del personal del banco hacia el
cliente, mientras este se encuentre en espera de su turno de atención. El personal del banco al
contar con el aplicativo móvil mostrará al cliente todas las ofertas que el banco tiene para el,
de no concretarse una colocación el ejecutivo del banco tiene aún la posibilidad de guiar al
cliente a realizar su proceso financiero en otro canal, el cual resulte menos costoso para el
banco.

Para contar con toda la información oportuna y generar un correcto almacenamiento del
feedback de los cliente, se realizó una propuesta arquitectura de datos que cubra mejor las
necesidades del negocio, por ello se agregan nuevos campos en tablas ya existentes para el
proceso de ventas en agencias y se están creando nuevas tablas para tener almacenada toda la
interacción de los ejecutivos y los clientes del banco.

La arquitectura de aplicaciones contará con el “Gestor Móvil” como nueva herramientas para
los ejecutivos del banco.

Finalmente, la propuesta para la arquitectura tecnológica, consiste en adquirir un primer lote

de 200 Tablets para que sean utilizadas en cada agencia definida por el Negocio. Asimismo,
se identificó la necesidad de repotenciar la base de datos Oracle 10G actual para ganar mayor
capacidad de procesamiento, esto dado que se requerirá mayor información referente a la
interacción de las ofertas y el cliente.

MÉTODOS ÁGILES PARA EL DESARROLLO

Como marco de trabajo para el desarrollo se ha seleccionado a SCRUM. El BBVA
Continental recientemente ejecuta proyectos bajo este modelo, sin embargo se buscará en el
presente trabajo profesional fortalecer la integración con otros marcos, adaptándolo a las
necesidades del proceso y la organización. La utilización de SCRUM permitirá tener mayor

270
flexibilidad en los proyectos eliminando las burocracias normales que se tenía en los
proyectos bajo un modelo de cascada, además buscará una mayor colaboración con el usuario
final beneficiado con el proyecto y el equipo de trabajo.

Para llevar mejor la aplicación de SCRUM en el banco, se llevará a cabo una reunión
trimestral donde asistirán todas las áreas de desarrollo así como las de soporte para definir
compromisos e identificar dependencias con otras áreas, de este modo al culminar la reunión
todos los equipos se van con los compromisos para los siguientes tres meses. Finalmente al
contar con los compromisos y dependencias el equipo priorizará las historias de usuario
según las necesidades del negocio.

Ya en el ciclo de desarrollo de SCRUM, la propuesta actual cuenta con una definición

diferente de cómo escribir las historias de usuario, se plantea utilizar el concepto de Job
Stories, en el cual se va a definir una situación inicial, en la cual haya un rol y una acción que
den inicio a la historia de usuario, con esto se tendrá un mayor detalle de el resultado
esperado reduciendo la incertidumbre que normalmente se da en procesos de negocio con
diferentes perfiles de uso y se generará mayor valor al culminar el desarrollo.

Finalmente, se propone realizar las demos de sprint mediante streaming para que todos los
interesados en el desarrollo del sprint puedan ver el resultado final y como el mismo va
cumpliendo con todos los criterios de aceptación acordados, esto genera una mayor base de
conocimiento, la cual puede ser accedida por todos los demás integrantes de los equipos.

GESTIÓN DE SERVICIOS DE TI
Como marco de trabajo para la gestión de servicios TI, se identificaron y desarrollaron 5
procesos (Gestión del Portafolio, Gestión de Nivel de Servicio, Gestión del Cambio, Gestión
de la Configuración y Gestión de Incidencias) de los 32 mencionados en el marco de trabajo
ITIL. En la elaboración de dichos procedimientos, destaca cómo cada uno de estos agrega
valor al negocio, a través de la constante retroalimentación por el análisis de indicadores, y
aseguramiento de la calidad.

Así por ejemplo, se define la gestión de incidentes, a través de la cual se podrá monitorear la
correcta ejecución del servicio creado y definir medidas preventivas y correctivas que

271
permitan que cumpla los niveles de servicios comprometidos. Los registros generados por
este proceso, en conjunto con otros, permitirán una mejora continua del servicio, lo cual
beneficiará tanto a clientes internos, como clientes externos, siempre alineados a los objetivos
estratégicos de la organización.

DIAGRAMA DE RELACIÓN ENTRE ELEMENTOS

Los elementos presentados en la sección se pueden mostrar de forma gráfica, donde se
evidencia de forma macro la interacción entre los diferentes elementos y cómo esto impacta
en los resultados de la organización.

Ilustración 62: Diagrama de relación entre elementos de la propuesta

Fuente: Elaboración propia

En el diagrama se puede apreciar cómo se parte desde los objetivos estratégicos que guían a
la organización para definir sus iniciativas. De manera trasversal se define la idea de negocio,
y con ello se analizarán las diferentes dimensiones de arquitectura empresarial en el marco
TOGAF (ver capítulo 2) sobre el proceso seleccionado mediante la aplicación del ciclo
ADM. Así, considerando lo relevado en las fases Preliminar y Visión de la arquitectura es
que se identifican de los componentes de la arquitectura actual, en sus diferentes

272
dimensiones, y teniendo clara la fundamentación de la propuesta, es que se identifican las
brechas o gaps con la arquitectura empresarial deseada, el detalle de estos se puede verificar
en la sección Análisis de Brechas del capítulo 2.

El BBVA busca que el desarrollo e implementación del software propuesto sea realizado a
través de un método ágil, que minimice los tiempos y maximice la eficacia. Así es que para
alcanzar los resultados se propone utilizar el framework SCRUM, lo que requiere de un
cambio cultural en la organización, para ello se cuenta con el compromiso al más alto nivel
de la organización tal y como se puede apreciar en las entrevistas publicadas de sus
principales ejecutivos en los anexos, asimismo se cuenta con un soporte de una consultora a
través de un coach para ejecutar acciones con resultados comprobados, los cuales trabajan de
la mano con el área de Talento y Cultura con el fin de hacer que los cambios y nuevos
modelos sea sostenible en el tiempo. Contar en el menor tiempo posible con la propuesta de
arquitectura empresarial y reducir las brechas, por lo menos a nivel de MVP (Minimum
Viable Product), es clave para probarlo de cara a los Ejecutivos y clientes y conseguir
feedback.

Si bien la definición de la arquitectura empresarial propuesta, en el marco de trabajo TOGAF,

permite tener mapeado el alineamiento con los objetivos estratégicos y el mejor uso de las
capacidades; y el desarrollo de software bajo un modelo ágil, de esta propuesta, brinda
rapidez y flexibilidad; queda otro elemento clave que es la gestión de los servicios generados,
para asegurar que los servicios agreguen valor al negocio, con un nivel de calidad ideal y una
rápida y eficaz respuesta ante cambios e incidentes.

La gestión de los servicios TI, para este caso el servicio Gestor Móvil y el servicio de
explotación de información, es clave para que los resultados se consigan; porque de lo
contrario, las estimaciones de ingresos, con las que se preparan los casos de negocio y flujo
de caja, no tendrían validez. Poniéndolo en perspectiva, la gestión de servicios TI tiene
impacto directo en los resultados financieros conseguidos a través del servicio.

A través de la propuesta se permitirá una mejora en los ratios de colocación, lo cual tiene
impacto directo en la utilidad y en el cross-sell de los clientes, lo que permite fidelizarlos.
Asimismo, el engage que se hace a través de herramientas digitales en las agencias, acercarán

273
a la organización al objetivo de ser el banco digital de la región, liderando los avances sobre
sus pares del BBVA en los demás países.

Cómo se justifican los ingresos para la implementación de la propuesta

Es importante precisar que el sustento del incremento de las colocaciones en las agencias, se
da a partir de un piloto realizado en oficinas estadísticamente representativas de diferentes
tamaños; así, de forma manual se levantó la información de los clientes que arribaban a estas
agencias para realizar operaciones y verificaba si contaban con campañas, de esta manera
mientras esperaban se les ofrecía el producto para medir la efectividad de la colocación.

Los productos ofrecidos fueron tarjetas de crédito y compras de deuda y en la siguiente tabla
se puede apreciar los resultados promedio respecto de lo que sería la venta adicional:

Oficina 1 Oficina 2 Oficina 3 Oficina 4

Arribos en campaña 1,870 1,560 1,230 1,469

% colocación (TC / CD) 1.53% 2.34% 1.68% 2.90%

Tabla 39: Piloto beneficios económicos

Fuente: Elaboración Propia / Planeamiento BBVA Continental

TC: Tarjeta de Crédito

CD: Compra de deuda

A partir de esta información, se envía al área de Planeamiento los resultados para que,
considerando la utilidad neta de los productos, se puedan proyectar los ingresos financieros
para los siguientes años, incluyendo de forma parcial el presente año, de forma conservadora.

En S/

2017 2018 2019

1,463,069 5,267,048 6,583,810

274
 Tabla 40: Cálculo beneficios económicos esperados
Fuente: Elaboración Propia / Planeamiento BBVA Continental

Adicionalmente, el incremento de colocaciones a clientes actuales, asegura un mejor cross, lo

cual genera un impacto en la principalidad del banco en el uso de sus productos por parte del
cliente e indirectamente reduce la posibilidad de churn (fuga de clientes).

CONCLUSIONES
Las brechas encontradas en la arquitectura de negocios impiden al BBVA Continental
alcanzar mayores ventas en las agencias por no aprovechar las esperas de los clientes y actuar
de manera reactiva, lo cual no permite alinear correctamente el proceso de venta en agencias
financieras con los objetivos estratégicos, estas brechas podrán ser resueltas a través de la
propuesta de arquitectura definida para realizar una venta proactiva en las agencias a través
de Tablets.

La retroalimentación de la arquitectura de negocio, donde se define el proceso, se podrá

realizar a través de la gestión de información generada en las ventas en agencias u oficinas,
para lo cual es necesaria una implementación alineada con la gestión de servicios debido a su
relevancia para los procesos de mejora de los productos financieros. Las mejoras que se
planteen deberán ser gestionadas a través del proceso de cambios, lo cual podría tener
impacto en las arquitecturas de datos y aplicación. De esta manera se puede apreciar cómo se
integran los diferentes elementos en uno de los gaps definidos.

Contar con un método ágil de desarrollo flexible y alineado a la gestión de los servicios, es
importante para dar continuidad y mantenimiento a la implementación de aplicaciones, la
constante demanda de nuevos productos al mercado en el sector financiero debe ser cubierta
y gestionada correctamente por el área de TI, para ello se deben definir niveles de servicio
como respuesta a cambios e incidentes. Esta es una clave para transformar al BBVA
Continental como un banco digital, siendo que la velocidad en el time-to-market es requisito
indispensable para ser visto de esta manera.

La implementación de la propuesta de arquitectura empresarial, requerirá de la aplicación de

diferentes técnicas y herramientas asociados a la gestión de los recursos tanto humanos como

275
tecnológicos, esto en consideración que la integración de los tres grandes temas en el BBVA
Continental, requieren de una transformación cultural y cognitiva para poder ejecutar los
proyectos o iniciativas presentados de manera orquestada.

276
CONCLUSIONES

Basado en el análisis de impacto del presente trabajo, se entiende que el alineamiento con los
objetivos estratégicos, no solo debe realizarse en el desarrollo de la arquitectura empresarial,
sino mantenido en el desarrollo de software, y en la gestión de servicios de TI; de esta forma
en cada etapa se mitigan los riesgos relacionados al retraso en los proyectos y obtiene menor
incertidumbre respecto del comportamiento en un entorno productivo, agregando valor al
negocio y consiguiendo mayor nivel de satisfacción al usuario final del banco.

La mejora de un proceso se obtiene por diferentes vías, sin embargo, como en la propuesta, el
apalancamiento en la tecnología y mejores prácticas permite ser disruptivos y lograr
resultados únicos, que sin la aplicación de los métodos adecuados no podría lograrse.

Luego del análisis de cada capítulo desarrollado, se comprendió que es crítico considerar las
funciones y roles requeridos para que el proyecto tenga éxito, de esta manera se debe definir
el perfil del recurso profesional necesario con una lista de habilidades técnicas y blandas, no
llegando solo a esto, sino también coordinar con el área de recursos humanos para una mejor
gestión en la contratación y mitigar la materialización de riesgos.

Los procesos del negocio pueden ser mejorados agregando herramientas tecnológicas y
reduciendo la gestión manual para lograr el objetivo estratégico de ser el bando digital de la
región, sin embargo esta decisión debe provenir de la identificación de las brechas en las
diferentes arquitecturas, además de que es clave evaluar financieramente la propuesta
resultante con el fin de que sea rentable al negocio.

Después de un profundo y constante análisis, se comprendió que los proyectos de software

pueden ser desarrollados a través de diferentes herramientas y métodos, sin embargo la
implementación de un framework ágil permite tener el feedback del cliente en corto tiempo, y
entregar valor rápidamente, esto es crítico en el BBVA Continental por los constantes
cambios que se generan en el sector bancario y la agresiva competencia que busca innovar
tecnológicamente.

277
RECOMENDACIONES
De forma previa al inicio de cualquier proyecto, es necesario profundizar en conceptos
propios del negocio y procesos materia de la investigación, esto es clave para poder
desarrollar adecuadamente un cambio respecto de la arquitectura empresarial de un proceso o
subproceso en la organización.

Es necesario incorporar procesos de mejora continua en la gestión del servicio, si bien en el

presente trabajo profesional, se desarrollaron cinco de estos, el uso generalizado de las
mejores prácticas permitirá aprovechar la retroalimentación brindada por los clientes a través
de la propuesta de arquitectura.

El cambio cultural que supone la adopción de métodos ágiles, debería ser acompañada por un
coach, que dé soporte al proceso; sin dejarlo aislado del gobierno de tecnología, y del
desarrollo de la arquitectura empresarial y gestión de servicios en la organización

278
GLOSARIO DE TÉRMINOS

Arquitectura orientada a servicios: Es un concepto de arquitectura de software que define la

utilización de servicios para dar soporte a los requisitos del negocio.

AS-IS: Situación actual de un proceso o realidad determinada.

ATM: Más conocido como cajero automático, es una computadora especializada que permite
manejar dinero de forma conveniente.

Back-End: Es el área que se dedica a la parte lógica de un sitio web, es el encargado de que
todo funcione como debería, no es visible para el usuario ya que no se trata de diseño, o
elementos gráficos, se trata de programar las funciones que tendrá un sitio

Backoffice: Es el conjunto de actividades de apoyo al negocio, es la parte de las empresas que

realizan las tareas destinadas a gestionar la propia empresa y que no tienen contacto directo
con el cliente.

Balanceador: Dispositivo de hardware o software que se antepone a un conjunto de

servidores que atienden una aplicación al cual asigna las solicitudes de procesamiento en base
disponibilidad.

Centrales de Riesgo: Entidad de carácter privado especializado en el almacenamiento de

datos acerca del comportamiento de pago en las obligaciones de las personas naturales o
jurídicas.

Clientes: Personas naturales o jurídicas que tienen productos financieros con el banco.

Colaborador: Persona que pertenece a la organización ocupando un cargo.

Combo: Oferta de dos o más productos a un cliente, los cuales unidos traen mejores
beneficios. Incrementan el cross-sell.

279
Contratación sencilla: Colocación de productos rápida, es decir que puede ser iniciada y
cerrada en el mismo día.

Colocación: Préstamos realizados por una institución financiera a una persona o empresa.
Permite poner dinero en circulación en la economía, ya que los bancos toman el dinero o los
recursos que obtienen a través de la captación y, con éstos, otorgan créditos a las personas,
empresas u organizaciones que los soliciten. Para el presente trabajo las colocaciones se
refieren a ventas y viceversa.

Cross-sell: Es una técnica a través del cual las organizaciones buscan ofrecer productos
nuevos o complementarios a sus clientes.

Customer Experience: Es la suma de todas las experiencias que tiene un cliente con un
proveedor de bienes y/o servicios, a lo largo de la duración de la relación con ese proveedor.
Usada actualmente como una estrategia empresarial que permite construir valor.

Churn: Ratio con el cual se mide el abandono o fuga de clientes de la organización durante
un periodo definido, generalmente las empresas diferencian el churn voluntario, del
involuntario. El primero de estos nace de una decisión del cliente, el segundo por motivos
exógenos a este o decisión de la empresa (faltas al contrato, morosidad, riesgo, entro otros).

Datacenter: Se denomina centro de procesamiento de datos (CPD) a aquella ubicación donde

se concentran los recursos necesarios para el procesamiento de la información de una
organización.

Datamart: Es una base de datos departamental, especializada en el almacenamiento de los

datos de un área de negocio específica. Se caracteriza por disponer la estructura óptima de
datos para analizar la información al detalle desde todas las perspectivas que afecten a los
procesos de dicho departamento.

Eficiencia: Ratio que presenta los gastos sobre los ingresos brutos de la organización.

Framework: Un framework corresponde a los componentes especiales que actúan como base
para la estructuración y ensamble de componentes en construcciones más complejas.

280
Front End: Es la parte del desarrollo web que se dedica al diseño de un sitio web, desde la
estructura del sitio hasta los estilos como colores, fondos, tamaños hasta llegar a las
animaciones y efectos.

ITIL: Definido como un conjunto de buenas prácticas destinadas a mejorar la gestión y

provisión de servicios TI.

Lean Manufacturing (Producción Ajustada): Es un modelo de gestión enfocado a la creación

de flujo para poder entregar el máximo valor para los clientes, utilizando para ello los
mínimos recursos necesarios: es decir ajustados.

MVP (Minimum Viable Product): Se trata de una implementación funcional pero básica, pero
que permite a la organización retroalimentarse rápidamente del comportamiento de clientes
internos o externo, ante el producto que se ha desarrollado. El término fue popularizado por
Eric Ries, en el libro “The Lean Startup”.

Omnicanalidad: Esquema por el cual un cliente puede iniciar una operación por un canal, y
continuarla y terminarla en otros, de forma consistente.

Productos Activos: Productos financieros que generan deuda al cliente.

Productos Pasivos: Productos destinados al ahorro y obtener beneficios a cambio por medio
de intereses, el beneficiario es el cliente.

Portal Web: Aplicación web institucional basada en tecnología estándar en lenguaje HTML.

Suite: Es un conjunto de aplicaciones y herramientas de software incluidas en un sólo paquete

y que, por lo general, comparten un aspecto similar y se integran entre sí.

Stakeholder: Todo aquel que puede afectar o ser afectado por las actividades de los procesos
de negocio de una organización.

Time-to-market: Velocidad con que una empresa u organización lanza nuevos productos o
funcionalidades. Acortar este plazo se convierte en ventaja competitiva.

TO-BE: Situación propuesta de un proceso o realidad.

281
TOGAF: Es un método paso a paso y probado para desarrollar y mantener una Arquitectura

Empresarial.

Usuarios: Personas naturales o jurídicas que visitan las agencias, pero que aún no tienen
productos financieros con el banco.

282
SIGLARIO

ADM: Architecture Development Method

API: Application Programming Interface

ATM: Automated Teller Machine

BI: Business Intelligence

CD: Compra de Deuda

CEO: Chief Executive Officer

CI: Configuration item

FODA: Fortalezas, Oportunidades, Debilidades y Amenazas

IIS: Internet Information Services

IReNe: Índice de Recomendación Neto

ISO: Organización Internacional de Normalización

MVP: Minimum Viable Product

PBI: Product Backlog Item

PLA/FT: Prevención de Lavado de Activos y Financiamiento del Terrorismo

RENIEC: Registro Nacional de Identificación y Estado Civil

RCC: Reporte Crediticio Consolidado

ROI: Return On investment

283
RSC: Responsabilidad Social Corporativa

SIT: System integration testing

SOW: Share of Wallet

TCR: Comunicación Transparente, Clara y Responsable

TOGAF: The Open Group Architecture Framework

TC: Tarjeta de Crédito

UAT: User Acceptance Testing

284
 BIBLIOGRAFÍA

[1] S.A, E. C. (29 de 09 de 2016). Equilibrium Clasificadora de Riesgo, empresa

clasificadora de riesgo en el Perú (Consulta el 15 de Octubre de 2016) :

http://www.equilibrium.com.pe/BcoContinental.pdf

[2] BBVA Continental (Lima, 31 marzo del 2016), BBVA Continental Memoria 2015
(Consulta el 15 de Octubre de 2016):
https://extranetperu.grupobbva.pe/memoria2015/descargas/pdf/memoria-completa.pdf

[3] Periódico El Comercio (Lima, 12 Setiembre del 2016), El comercio Web (Consulta el 15
de Octubre de 2016): http://elcomercio.pe/economia/dia-1/bbva-no-se-nos-puede-acusar-
que-lucramos-finanzas-noticia-1931058?ref=flujo_tags_66283&ft=nota_3&e=titulo

[4] BBVA Continental (Lima, 12 Setiembre del 2016), Informe de Responsabilidad

Corporativa 2015 (Consulta el 15 de Octubre de 2016):
https://www.bbva.com.co/fbin/mult/Informe_de_Responsabilidad_Corporativa_2015_tcm13
04-568093.pdf

[5] Gartner (26 Mayo del 2016), Enterprise Architecture (EA). Definiciones de arquitectura
empresarial. (Consulta el 15 de Octubre de 2016): http://www.gartner.com/it-
glossary/enterprise-architecture-ea/

[6] Revista Virtual Universidad Católica del Norte” (Colombia, febrero-mayo de 2012),
Capacidades de negocio en el contexto empresarial (Consulta el 15 de Octubre de 2016):
http://revistavirtual.ucn.edu.co/index.php/RevistaUCN/article/viewFile/349/664

[7] The Open Group (United Kingdom, Enero de 2013), Guía de bolsillo de TOGAF
(Consulta el 15 de Octubre de 2016):
http://www.vanharen.net/Samplefiles/9789087537104SMPL.pdf

[8] GOETHALS, F. (2006); “Managements and enterprise architecture click: The FADE
framework, Information Systems Frontiers.

285
[9] DE BOER, F. (2005) et al., “Change Impact Analysis of Enterprise Architectures,”
Proceedings of the 2005 IEEE International Conference on Information Reuse and
Integration (IRI-2005). Las Vegas, USA.

[10] LANKHORST, M. (2005); Enterprise Architecture at Work -Modeling, Communication,

and Analysis. Berlin: Berlin Heidelberg, Springer-Verlag.

[11] ZACHMAN, J. (1987); A Framework for Information Systems Architecture, the IBM
Systems Journal.

[12] U. S. D. o. Defense, “Technical Architecture Framework for Information Management

(TAFIM),” D. o. Defense, ed., 1994.

[13] J. Schekkerman, Enterprise Architecture Good Practices Guide: How to Manage the
Enterprise Architecture Practice: Trafford Publishing, 2006, 386 p.

[14] J. Mc Govern et al., “A Practical Guide to Enterprise Architecture,” en, Bloomington:

Prentice Hall, 2003.

[15] PRESSMAN, Roger (2005); Ingeniería de Software, una guía práctica. México:
McGraw-Hill. 6ta edición.

[16] COCKBURN, Alistair (2006); Agile Software Development. Estados Unidos: Addison-
Wesley Professional. 2da edición

[17] ALAIMO, Diego Martín (2013); Proyectos ágiles con Scrum. Buenos Aires: Kleer,
EBOOK. 1ra edición

[18] PALACIO, Juan (2007). Flexibilidad con Scrum. Lulu.com

[19] WEIHRICH, Heinz (2011); The TOWS Matrix, A Tool for Situational Analysis. San
Francisco: Heinz Weihrich’s Homepage.

[20] SCRUMstudy™ (2016); Una guía para el cuerpo de conocimiento de Scrum (GUIA
SBOK™). Estados Unidos de América: SCRUMstudy™

286
[21] KNIBERG, Henrik (2007); Scrum y XP desde las Trincheras. Estados Unidos de
América: InfoQ

[22] BECK, Kent (2002); Test Driven Development. Estados Unidos de América: Addison-
Wesley Professional

[23] BLE, Carlos y otros (2010); Diseño Ágil con TDD. Iexpertos.com

[24] AROONI, Amir y VERHEYEN, Gunther (2012) ING Capturing agility via Scrum at a
large Dutch bank (consulta: 15 de noviembre de 2016).

https://www.scrum.org

[25] MANJI, Lubaina y JOLIC, Dragan (2011) Agile Transformation at Barclays Retail and
Business Banking (consulta: 15 de noviembre de 2016).

http://www.agileconference.org/wp-content/uploads/2011/06/Agile-Transformation-at-
Barclays-Bank.pdf

[26] GARIBALDI, Juan. Técnicas para la realización de Retrospectivas. Buenos Aires:

Kleer. (consulta: 15 de noviembre de 2016).

(http://media.kleer.la/kleer-tecnicas-de-retrospectivas-es.pdf)

[27] MAZAN, Manuel (2015) De los “User Stories” a los “Job Stories”: más contexto, mejor
entendimiento (consulta: 15 de noviembre de 2016).

http://agiland.pe/blog/de-los-user-stories-a-los-job-stories-mas-contexto-mejor-
entendimiento/

[28] PRAKASH, Anurag (2013) What Is Sprint Zero? (consulta: 15 de noviembre de 2016).

https://www.scrumalliance.org/community/articles/2013/september/what-is-sprint-zero

[29] KACZOR, Krystian (2011) 5 Common Mistakes We Make Writing User Stories

(consulta: 15 de noviembre de 2016).

287
(https://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-
make-writing-user-stories)

[30] ARANGO, Martín; LONDOÑO, Jesús y ZAPATA, Julian (2010) Arquitectura

Empresarial - Una Visión General (consulta: 15 de noviembre de 2016).

(http://www.scielo.org.co/pdf/rium/v9n16/v9n16a09.pdf)

[31] BIABLE MANAGEMENT, Excellence and Innovation (2016) ITIL v3 - Manuel

Íntegro (consulta: 27 de enero de 2017). (http://www.biable.es/wp-
content/uploads/2014/ManualITIL.pdf)

[32] IT GOVERNANCE INSTITUTE (2008) COBIT 4.1, ITIL V3 e ISO/IEC 27002

(consulta: 27 de enero de 2017). (https://www.isaca.org/Knowledge-
Center/Research/Documents/Alineando-COBIT-4-1-ITIL-v3-y-ISO-27002-en-beneficio-de-
la-empresa_res_Spa_0108.pdf)

[33] The Efficiency & Reform Group Service Desk, Cabinet Office (2011) ITIL Service
Strategy (consulta: 27 de enero de 2017). (http://www.kornev-online.net/ITIL/01%20-
%20ITIL%20V3%202011%20Service%20Strategy%20SS.pdf)

288
 ANEXOS
ANEXO 1: Carta Gerente General Memoria 2015

Carta del Gerente General

Apreciados accionistas:

Durante el 2015, nuestra institución continuó con la ejecución de los lineamientos estratégicos establecidos para los

próximos años. Hemos reafirmado nuestro rumbo hacia el crecimiento, no obstante la menor velocidad de la economía

local que se manifestó a partir del final del ciclo de precios altos de las materias primas internacionales y que ha

afectado a la mayoría de economías emergentes desde fines del 2012.

En primer lugar, mantenemos nuestro objetivo estratégico de seguir fortaleciendo la calidad de servicio para que se

constituya en una ventaja competitiva diferencial frente a nuestros competidores en todos los puntos de encuentro

entre el cliente y el banco. Para ello, hemos ejecutado acciones que nos han permitido conservar el liderazgo en calidad

de servicio; una acción especialmente significativa ha sido la inversión en el desarrollo de nuestros canales digitales, la

cual continuaremos agresivamente en el futuro.

Iniciamos el 2016 con novedades importantes en distintos frentes: de procesos, herramientas comerciales, capacidades

de gestión multicanalidad, nuevos modelos de gestión por segmentos para nuestra red de Banca Empresas y de Banca

Minorista.

En segundo lugar, logramos reforzar nuestra sostenibilidad financiera mediante el control de gastos de operación y de

riesgo, con mejores indicadores al promedio del sistema en ambas variables. Esto a su vez nos ha permitido obtener un

nivel de rendimiento sobre el patrimonio superior al promedio de nuestros principales competidores.

En tercer lugar, hemos trabajado arduamente en la mejora de nuestros procesos orientados al cliente, cuya

modernización y optimización son fundamentales para ofrecer una calidad de servicio sostenible en el mediano plazo.

Con ese fin hemos creado el Área de Procesos y desarrollado nuevas herramientas de gestión por parte de nuestra

fuerza de ventas, destinadas a incrementar la productividad comercial de las redes de distribución.

Asimismo, hemos impulsado temas “de base”, tales como la adaptación de nuestra infraestructura tecnológica, la

potenciación del trabajo en equipo con esquemas de trabajo tipo Agile, y nuevos esquemas de formación

descentralizada en oficinas, entre otros aspectos. En definitiva, hemos focalizado nuestros esfuerzos en la asignación de

recursos financieros y de gestión a la permanente repotenciación de nuestro equipo humano.

Iniciamos el 2016 con novedades importantes en distintos frentes: de procesos, herramientas comerciales, capacidades

de gestión multicanalidad, nuevos modelos de gestión por segmentos para nuestra red de Banca Empresas y de Banca

Minorista, metodologías de planificación trimestral, entre otros; todo lo cual, en conjunto, impulsará el proceso

289
transformador de nuestra institución hacia la modernidad, para beneficio de nuestros clientes, colaboradores y

accionistas.

Eduardo Torres-Llosa

Gerente General

290
 ANEXO 2: Entrevista a Gerente General, diario El Comercio
Perú
Extracto entrevista a Eduardo Torres Llosa, 16 de setiembre de 2016.

BBVA: "Queremos convertirnos en

un banco digital en dos años"

Tras nueve años al mando del banco

BBVA Continental, Eduardo Torres
Llosa, CEO de la entidad, tiene como
nuevo encargo transformar y llevar al
banco a la nueva era digital para cumplir
con su propósito. El ejecutivo brinda
detalles de cómo llevará a cabo esta
tarea.

¿Ya cuánto tiempo está al mando del banco?

Casi una década. Estoy desde el 2007.

¿Qué logros ha alcanzado?

En estos nueve años, las prioridades y los retos estratégicos han ido cambiando. Nuestro primer
gran reto, en el 2007, fue ser el mejor banco en calidad de servicio frente a nuestros
competidores comparables, que es el reconocimiento que queremos de nuestros clientes; y con
mucho trabajo y humildad lo conseguimos en los últimos tres o cuatro años. Ahora el encargo es
otro.

291
¿Cuál es el encargo ahora?

El encargo es ampliar nuestra vocación de calidad de servicio, aplicando las tecnologías y con
mayor énfasis la innovación, con el objetivo de estar más cerca de nuestros clientes para poder
cumplir con nuestro propósito de poner al alcance de todas las oportunidades de esta nueva
era.

¿De qué forma piensan alcanzar su propósito?

Tenemos tres grandes ejes que nos ayudarán a cumplir con nuestro propósito: Primero, mucha
innovación en productos, procesos, precios y comisiones. Segundo, hemos lanzado un proyecto
muy ambicioso que se llama Experiencia Única, que consiste en desarrollar el modelo de
franquicia en nuestras redes, en el ámbito nacional, para que nuestros clientes sientan que los
atendemos de forma diferente frente al resto de competidores. El tercer eje es el desarrollo de
nuestras capacidades digitales.

¿En qué nivel de desarrollo se encuentran sus capacidades digitales?

Según los miembros del Comité de Dirección de nuestro banco, estamos todavía a menos de la
mitad del camino. Eso significa que recién en tres años podríamos transformar la organización.
Pero queremos meterle velocidad y convertirnos en un banco digital en dos años. Sí podemos
porque el grupo al que pertenecemos está muy centrado en esta transformación. Por ejemplo,
hoy estamos trabajando proyectos de bigdata e inteligencia artificial con expertos del grupo.

(…)

Están lanzando nuevos productos y eliminando algunas comisiones de forma rápida,

¿qué nuevos lanzamientos y descuentos se vienen?

Si logras ser una entidad que promueve un proceso de innovación mucho más ágil y rápido vas
a tener la posibilidad de lanzar más productos que antes. En ese sentido, la planificación anual
ya no sirve para una empresa que se perfila digital como nosotros, porque el mundo cambia muy
rápido, sino, tiene que ser trimestral y los entregables (el desarrollo de productos y servicios)
cada 15 días. Hoy, la pregunta que nos hacemos ya no es qué es lo próximo que vamos lanzar,
sino, cómo nos organizarnos para sacar productos innovadores todos los días.

292
¿De qué forma está cambiando el proceso productivo en la banca?

En las empresas digitales, el personal especializado en hacer la programación de los productos,

las pruebas de calidad y pasarlos a producción, es encerrado literalmente en un salón para que
se ponga de acuerdo y haga todo lo que tiene que hacer para desarrollarlos. Si alguien no rinde,
el propio equipo lo bota. Aquí todos tienen el mismo poder de decisión, independientemente del
cargo. Esto desde el punto de vista organizativo y cultural es un cambio tremendo y nosotros
estamos en ese proceso.

(…)

293
 ANEXO 3: Formato de Solicitud de Cambios
Solicitud de cambio

[Nombre del Proyecto] [Código de proyecto]

Fecha: [dd/mm/aaa]

Datos de la solicitud de cambio

Nro control de solicitud de cambio

Solicitante del cambio

Área del solicitante

Lugar

Patrocinador del proyecto

Gerente del proyecto

Categoría de cambio

Marcar todas las que apliquen:

Alcance Cronograma Costos Calidad Recursos Procedimientos

Documentación Otro

Causa / origen del cambio

294
 Solicitud de cliente Reparación de defecto Acción correctiva
Acción preventiva Actualización / Modificación de documento
Otros

Descripción de la propuesta de cambio

Justificación de la propuesta de cambio

Impacto del cambio en la línea base

Alcance:

Cronograma:

Costo:

Calidad:

Implicaciones para los interesados

295
Riesgos

Comentarios

Aprobación

Firmas del comité de cambios

Nombre Rol / Cargo Firma

296
 ANEXO 4: Entregables ADM - TOGAF

Fuente: Curso Arquitectura Empresarial, Mg. Samantha López Pérez. UPC, 2016.

297
 ANEXO 5: Perfil Puesto Desarrollador Scrum

Gerencia de Talento y Cultura

FORMATO PARA RELEVAR EL PERFIL DEL PUESTO
Solo para uso interno de Selección

DATOS DEL AREA SOLICITANTE

Puesto DESARROLLADOR EQUIPO SCRUM
Gerencia BANCA DIGITAL / FABRICA DE SOLUCIONES
N° pers a
Personas a cargo Si No Ubicación física
cargo
DATOS DE LA POSICIÓN
Número de vacantes 1 Origen de la posición Nueva Reemplazo
Tipo Proceso Interno Externo Mixto Estado de la posición Aprobada No aprobada

PERFIL
Grado académico Universitario
Especialidad (es) Egresado Ing. Sistemas, Ing. Informática, Ing. Software

Experiencia en herramientas de programación Java: Netbeans, Javascript, JQuery y Bootstrap.

Experiencia y manejo avanzado de los siguientes Frameworks: Spring MVC, JDBC, Security, Hibernate,
Struts, AJAX, GIT, Maven, Jenkins.
Experiencia y manejo intermedio de los siguientes servidores de aplicaciones: Tomcat (wars) y
Weblogic (wars, ears, jars).
Requisitos Principales Experiencia y manejo avanzado de los siguientes Web Services: SOAP, Json, REST, JAX, API, WS,
JSP, XML, entre otros.
Experiencia o conocimiento de ANDROID SDK, ANDROID STUDIO (Desarrollo Android); JIRA AGILE
(Colaboración); GIT (Control de Código Fuente); MAVEN (Creación de Versiones); JUNIT (Pruebas
Unitarias, Assertions); MOCKITO (Stubs)
•Métodos ágiles de desarrollo (SCRUM)

Idiomas Inglés básico

CSD Certified Scrum Developer
Otras preferencias

FUNCIONES
(Colocar mínimo tres funciones)
Análisis de requerimientos de software, historias de usuario y documentación.
Programación de aplicaciones móviles y sistemas de gestión empresarial
Actualización y mejoras a los sistemas que ya se encuentran en producción.
COMPETENCIAS
(Marcar o escribir las cinco más relevantes para la posición)
HABILIDAD COMERCIAL ORIENTACION A RESULTADOS AUTODESARROLLO
COMUNICACIÓN EFECTIVA PROACTIVIDAD E INICIATIVA TOLERANCIA A LA PRESION
CAP RELACIONARSE A TODO NIVEL CAPACIDAD DE ANALISIS ADAPTACIÓN AL CAMBIO
NEGOCIACIÓN ORIENTACION Al CLIENTE
LIDERAZGO TRABAJO EN EQUIPO

298
ANEXO 6: Entrevista a Gerente Desarrollo de Negocio, diario
El Comercio Perú
Extracto entrevista a Gonzalo Camargo, 19 de agosto de 2016.

BBVA: "Con los procesos de siempre no lanzas un producto al mes"

En medio de esta entrevista, Gonzalo Camargo, Gerente general adjunto de Desarrollo de

Negocios del BBVA Continental, voltea los roles y me lanza una pregunta que queda sin
respuesta: “¿Qué innovación en productos bancarios recuerdas en los últimos años?”.

Por eso mismo, sorprende la racha de lanzamientos del BBVA Continental en los últimos meses,
con siete nuevos productos e iniciativas como su propia radio de rock nacional y, esta misma
semana, la eliminación de la comisión interplaza.

— ¿Cuál es la estrategia detrás de esta racha?

El propósito del BBVA es llevar los beneficios de la nueva era a todas las personas. En el Perú,
eso nos llevó a reflexionar sobre a quién nos dirigíamos. Por ejemplo, los típicos clientes de la
banca son personas dependientes, pero según Arellano Marketing, dos tercios de la clase media
son independientes. Con varios de estos productos, buscamos darles a estos nuevos usuarios
los beneficios que ya tiene el cliente clásico.

— ¿Cómo fue el trabajo al interior del banco para crear estos productos?
Antes, un banco abría la puerta y venía la gente. Esa etapa ya pasó. Y, además, ahora el
consumidor tiene acceso a la experiencia de compra digital, que es sencilla e inclusiva. Piensa
en Amazon, en Google o en Cinepapaya. Y cuando vas a la web del banco…

—Son varias páginas o pasos para llegar al producto.

Entonces, para ser parte de esta revolución digital, teníamos que hacer otra revolución, pero
interna. Con los mismos procesos y metodologías de siempre no llegas a sacar un producto al
mes desde diferentes áreas.

—¿Qué cambiaron?
Ahora trabajamos en ‘scrums’: células de gente multidisciplinaria a la que le das retos y no se
desintegran hasta que los resuelvan. Eso no solo te permite un mejor ‘time to market’, sino que
la gente está motivada porque ve que las ideas se concretan en un mes o dos meses.

299
—¿Fue fácil crear células con gente de varias áreas?
No, porque hay que romper silos. Para cada área, la innovación ya no es “su” producto, sino el
de todo el equipo. Además, antes el flujo para innovar era entre el jefe de producto y el área de
sistemas. Ahora incorporamos la experiencia del cliente. Partimos de ahí, el jefe de producto
debe encontrar una solución, y se ejecuta. Es la metodología ágil que usan las compañías
digitales. Y es el abecé del márketing también, pero muchos lo olvidamos, sobre todo en un
contexto de alto crecimiento del país.

— Su modelo de innovación es por proyecto, no con un laboratorio.

Para banca, no me gusta un ‘lab’ de innovación, porque esta no puede estar aislada del ‘core’ de
tu negocio y corres el riesgo de que no esté vinculado con aquellos que están cerca del cliente.
No es una discusión menor y lo peor que te puede pasar es que te quedes en un nivel
intermedio: sacar cosas alucinantes, pero sin impacto en el negocio porque tienen poco que ver
con lo que el cliente necesita.

—¿Cómo se manejan los ‘scrums’ con áreas como legal o riesgos?

Tienen miembros dentro de las células y están empoderados. La metodología no funciona si
alguien del equipo dice que debe consultar algo con su jefe y que vuelve luego con la respuesta.
Ahora llevaremos esta forma de trabajar a cambiar nuestros procesos. Es un reto enorme.

300