Itil - Ans PDF

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR
FACULTAD DE INGENIERÍA
TESIS DE GRADO PREVIA A LA OBTENCIÓN DEL TÍTULO DE “MAGISTER
EN GERENCIA DE TECNOLOGÍAS DE INFORMACIÓN"
GUÍA METODOLÓGÍCA PARA GENERAR ACUERDOS DE NIVELES
DE SERVICIO (ANS) PARA ARQUITECTURA DE SERVICIOS WEB EN
INSTITUCIONES FINANCIERAS DEL SECTOR PÚBLICO UTILIZANDO
ITIL V3
EDISON RUBEN NICOLALDE JAQUE
QUITO, JUNIO 2013

Dedicado a mi esposa Gladis y mis hijas Karina y Daniela
2
CAPÍTULO I: MARCO TEORICO ................................................................ 6
1.1 Introducción .................................................................................... 8

1.2 Marcos de referencia ITIL V3, COBIT V4.1....................................10
1.2.1 ITIL InformationTechnology Infrastructure Library .................................10
1.2.2 COBIT (Control OBjectives for Information and related Technology) .13
1.3 Base legal de los servicios de las Instituciones Financieras del
Sector Público IFSP .......................................................................16
1.3.1 BANCO CENTRAL DEL ECUADOR BCE ............................................ 16
1.3.2 BANCO NACIONAL DE FOMENTO BNF .............................................. 20
1.3.3 CORPORACION FINANCIERA NACIONAL CFN ................................ 22
1.3.4 BANCO DEL IESS BIESS ..................................................................... 27
1.3.5 BANCO DEL ESTADO BEDE ................................................................ 29
1.3.6 BANCO ECUATORIANO DE LA VIVIENDA BEV ................................. 31
1.3.7 INSTITUTO ECUATORIANO DE CREDITO EDUCATIVO IECE ........ 33
1.4 Administración de Niveles de Servicio SLM ................................36
1.4.1 Diseño de Servicios ................................................................................. 36
1.4.2 Políticas y principios de la administración de niveles de servicio SLM40
1.4.3 Actividades, métodos y técnicas de SLM ............................................. 42
1.4.4. Indicadores clave ..................................................................................43
1.4.5 Factores críticos de éxito, desafíos y riesgos de SLM ......................... 44
CAPÍTULO 2: GESTIÓN DE LOS ACUERDOS DE NIVELES DE

SERVICIO PARA ARQUITECTURA DE SERVICIOS WEB EN IFSP ....... 48
2.1 Análisis de la situación actual de los ANS en las IFSP ..............................50

2.1.1 Comparativo del proceso DS1 Definir y administrar niveles de servicio.
................................................................................................................... 72
2.2 Análisis cuantitativo de los servicios con arquitectura Web .......................75
2.3 Análisis de los niveles de operación internos OLA ....................................76
2.4 Análisis de roles y responsabilidades ........................................................78
2.5 Análisis de contratos de servicios con terceros .........................................79
3
CAPÍTULO 3: DESARROLLO DE LA GUÍA METODOLÓGICA PARA
GENERAR ANS PARA ARQUITECTURA DE SERVICIOS WEB EN
INSTITUCIONES FINANCIERAS DEL SECTOR PÚBLICO DENTRO
DEL MARCO DE REFERENCIA ITIL V3 ................................................... 81
3.1 Definición de procedimientos para establecer un ANS.................. 81

3.1.1 El diseño general del ANS. ......................................................................82
3.1.2 Determinar los participantes en el proceso de ANS ..............................84
3.1.3 Identificar los componentes del proceso de ANS...................................86
3.1.4 La revisión de los acuerdos base, OLA y contratos con terceros .........87
3.1.5 Elaboración de un acuerdo inicial, requerimientos de nuevos servicios
y generación de SLR ................................................................................88
3.1.6 El Monitoreo del rendimiento del servicio ...............................................90
3.1.7 La medición y mejora de la satisfacción del cliente ...............................92
3.1.8 La generación de reportes de servicio ....................................................93
3.1.9 La revisión del servicio y plan de mejora ................................................95
3.1.10 El desarrollo de relaciones y contactos.................................................95
3.1.11 La Administración de reclamos y elogios..............................................96
3.2 Definición de documentos para establecer un ANS ...............................97
3.2.1 Catálogo de servicios................................................................................97
3.2.2 Acuerdos de Nivel Operacional OLAs .....................................................98
3.2.3 Administración de incidentes, problemas y cambios .............................99
3.2.4 Proveedores externos ...............................................................................99
3.3 Definición de roles y responsabilidades ...............................................100
3.3.1 modelo RACI ........................................................................................... 100
3.3.2 Atributos y competencias de los roles ................................................... 102
3.3.3 Roles y responsabilidades asociadas ................................................... 103
3.4 Esquema de administración de los ANS ...............................................109
3.4.1 Realizar reuniones mensuales con los clientes ................................... 109
3.4.2 Análisis proactivo de las interrupciones del servicio ............................ 110
3.4.3 Renegociar y ajustar los ANS de acuerdo a los cambios de negocio 110
3.4.4 Revisar y actualizar los ANS cada año ................................................. 110
4
CAPÍTULO 4: IMPLANTACIÓN DE LA GUÍA METODOLÓGICA A UN
SERVICIO WEB EN UNA IFSP................................................................ 111
4.1 Definición de un servicio para establecer un ANS ................................113

4.1.1 Componentes tecnológicos del servicio ................................................ 113
4.1.2 Grupos de soporte del servicio .............................................................. 117
4.2 Generación de documentos para establecer un ANS ............................119
4.2.1 Catalogo de clientes y módulos asociados ........................................... 119
4.2.2 Acuerdos de nivel de operación OLA .................................................... 120
4.3 Generación de roles y responsabilidades ..............................................122
4.3.1 Matriz RACI ...................................................................................... 124
4.4 Relación con terceros ..............................................................................124
4.5 Generación de un ANS para un aplicativo de arquitectura Web en una
IFSP ...............................................................................................126
CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES .................... 139
5.1 Conclusiones .........................................................................................140

5.2 Recomendaciones .................................................................................143
BIBLIOGRAFIA Y REFERENCIAS .......................................................... 145
ANEXO 1 .................................................................................................. 148

Acuerdo de Nivel de Operación (OLA) ..........................................................148
de: Servicios Informáticos de la DI ...................................................................148
ANEXO 2 .................................................................................................. 153
Acuerdo de Nivel de Operación (OLA) .................................................. 153
de: Infraestructura Tecnológica y Base de Datos de la DI ............................ 153
ANEXO 3 .................................................................................................. 160
GLOSARIO ......................................................................................................160
ANEXO 4 .................................................................................................. 161

ENCUESTA EN LAS INSTITUCIONES FINANCIERAS DEL SECTOR PÚBLICO161
5
INDICE DE TABLAS
Tabla 2.1 Relación de los procesos de COBIT V4.1 con ITIL V3………………………………… 51
Tabla 2.2 Matriz para encuesta y cálculo de nivel de madurez COBIT…………………………… 53
Tabla 2.3 COBIT Cálculo de nivel de madurez …………………………………………………….. 56
Tabla 2.4 COBIT Encuesta para medir control interno de un proceso………………………….. 57
Tabla 2.5 Nivel de Madurez de los procesos de apoyo a los ANS en el BNF…………………. 59
Tabla 2.6 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el BNF…. 60
Tabla 2.7 Nivel de Madurez de los procesos de apoyo a los ANS en el BCE…………………. 61
Tabla 2.8 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el BCE…. 62
Tabla 2.9 Nivel de Madurez de los procesos de apoyo a los ANS en la CFN…………………. 63
Tabla 2.10 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en la CFN… 64
Tabla 2.11 Nivel de Madurez de los procesos de apoyo a los ANS en el IECE………………. 65
Tabla 2.12 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el IECE… 66
Tabla 2.13 Nivel de Madurez de los procesos de apoyo a los ANS en el BEDE…………….. 67
Tabla 2.14 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el BEDE.. 68
Tabla 2.15 Nivel de Madurez de los procesos de apoyo a los ANS en las IFSP……………….. 69
Tabla 2.16 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en las IFSP.. 71
Tabla 2.17 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el BNF…. 73
Tabla 2.18 Promedio de Nivel de Madurez de los procesos de apoyo a los ANS en las IFSP… 74
Tabla 2.19 Servicios con arquitectura Web de cada IFSP…………………………………………… 76
Tabla 2.20 Nivel de acuerdo para los OLAs en las IFSP…………………………………………….. 77
Tabla 2.21 Nivel de madurez de DS2 Administración de terceros…………………………………. 78
Tabla 3.1 Matriz RACI de un proceso…………………………………………………. … 100
Tabla 4.1 Matriz de distribución de procesos por unidad organizacional ………………………… 117
Tabla 4.2 Matriz de control de clientes………………………………………………………………… 119
Tabla 4.3 Matriz RACI para servicio del Portal………………………………………………….….. 123
Tabla 4.4 Matriz Nivel de Servicio de los Proveedores ……………………………………………... 125
Tabla 4.5 tiempo de respuesta y escalamiento de incidentes……………………………………… 129
Tabla 4.6 Frecuencia de entrega de reportes ……………………………………………………….. 130
Tabla 4.7 Frecuencia de entrega de reportes……………………………………………. 136
6
INDICE DE FIGURAS
Figura 1.1 ITIL Rol en el tiempo……………………………………………………………….. 11
Figura 1.2 Libros ITIL V3……………………………………………………………………….. 13
Figura 1.3 Dominios de COBIT V4.1…………………………………………………………. 15
Figura 1.4 Principales actividades del proceso de SLM …………………………………… 43
Figura.2.1 Nivel de Madurez del proceso DS1 para el BNF……………………………….. 56
Figura 2.2 Nivel de madurez y control de los procesos en el BNF………………………... 61
Figura 2.3 Nivel de madurez y control de los procesos en el BCE……………………….. 63
Figura 2.4 Nivel de madurez y control de los procesos en la CFN………………………... 65
Figura 2.5 Nivel de madurez y control de los procesos en el IECE………………………. 67
Figura 2.6 Nivel de madurez y control de los procesos en el BEDE……………………… 69
Figura 2.7 Nivel de madurez de los procesos en las IFSP………………………………… 70
Figura 2.8 Nivel de control interno de los procesos en las IFSP………………………….. 72
Figura 2.9 Nivel de madurez proceso DS1 en las IFSP…………………………………… 73
Figura 2.10 Nivel de control interno proceso DS1 en las IFSP…………………………… 74
Figura 2.11 Servicios con arquitectura Web de cada IFSP……………………………….. 76
Figura 2.12 Nivel de acuerdo para los OLAs en las IFSP………………………………… 77
Figura 2.13 Nivel de madurez de los servicios DS3 y DS8 en las IFSP………………… 78
Figura 2.14 Nivel de madurez del servicio DS2 en las IFSP…………………………….. 80
Figura 3.1 Acuerdo de Nivel de Servicio de multi-nivel…………………………………… 83
Figura 3.2 Generación de un Acuerdo de Nivel de Servicio……………………………… 85
Figura 3.3 reporte de cumplimiento de ANS……………………………………………….. 94
Figura 4.1 Partícipes del portal de Servicios Electrónicos………………………………. 112
Figura 4.2 Dispositivos de hardware Portal de Servicios Electrónicos…………………. 115
Figura 4.3 Configuración Alta Disponibilidad Geográfica………………………………… 117
7
CAPÍTULO I: MARCO TEORICO
1.1 Introducción
Las Instituciones Financieras del Sector Público (IFSP) al igual que las
instituciones del sector financiero privado son intermediarios del mercado
financiero que siendo bancos o sin serlo ofrecen préstamos o facilidades de
financiamiento en dinero, sus servicios de información, aplicaciones y
operaciones financieras son obligatorias e indelegables y están direccionados a
sectores específicos, determinados en la ley o decretos de su creación.
Para ofrecer sus servicios de manera ágil y oportuna a sus clientes que pueden
ser instituciones del sistema financiero público y privado, organismos del estado
y personas naturales o jurídicas, las IFSP se encuentran impulsando el uso de
Internet como medio de acceso y han desarrollado aplicaciones sobre plataforma
Web para que sus servicios sean entregados con rapidez y calidad.
La utilización de las tecnologías de la información TI permite mejorar la
administración de la calidad y la confiabilidad de los servicios y cumplir con los
requerimientos regulatorios y contractuales. Para mejorar la administración de
servicios de TI se han desarrollado marcos de referencia que establecen
estándares y mejores prácticas como ITIL, COBIT, ISO 20000 y 27000 entre
otros. Cada institución debe ajustar su utilización a las necesidades de su
negocio de tal forma de lograr el mayor beneficio para la institución y sus
clientes.
8
ITIL es el marco de referencia de las mejores prácticas para la gestión y soporte
de servicios de TI, el mismo que se compone de cinco libros y constituye una
guía para la planeación, entrega y gestión con calidad de servicios de TI.
En el libro de diseño de servicios se encuentra el proceso de Gestión de Niveles
de Servicio que establece los objetivos y las actividades para generar los
Acuerdos de Nivel de Servicio.
El establecer un Acuerdo de Nivel de Servicio ANS o SLA (Service Level
Agreement) entre el proveedor de los servicios y los clientes usando las
recomendaciones de los marcos de trabajo como ITIL ( Information Technology
Infraestructure Library), CobiT® (Control Objectives for Information and related
Technology), ISO/IEC 27002:2005 entre otros, permitirá establecer un marco de
entendimiento respecto al cumplimiento con las necesidades y expectativas de
los clientes, considerando la capacidad de la infraestructura de TI instalada, del
personal asignado al servicio, la disponibilidad horaria, el tiempo de respuesta
entre otros.
Un Acuerdo de Nivel de Servicio ANS además permitirá establecer una línea
base de referencia que permita medir el Nivel de Servicio y establecer políticas
para mejoramiento continuo del servicio y de esta forma incrementar la calidad
de los servicios en las IFSP que no paseen una metodología para establecer el
impacto de los factores internos y externos que influyen en la determinación de
un Acuerdo de Nivel de Servicio.
9
1.2 Marcos de referencia ITIL V3, COBIT V4.1
El desarrollo acelerado de los sistemas de TI no siempre está en relación directa
con las necesidades y estrategias de negocios de las organizaciones, para
apoyar el proceso de alinear el desarrollo de TI con los objetivos de la empresa
se han creado marcos de referencia que recogen la experiencia de las mejores
prácticas de gestión de TI y permite a las empresas tener procesos de TI
controlados y gestionados bajo estándares internacionales que permitan apoyar
la estrategia de negocio de la empresa, cumplir con requerimientos regulatorios y
lograr resultados exitosos. “Para ser más efectivos, las mejores prácticas
deberían ser aplicadas en el contexto del negocio, enfocándose donde su
utilización proporcione el mayor beneficio a la organización”1.
Existen varios marcos de referencia creados por organizaciones internacionales
como la OGC que publica ITIL y PRINCE 2, la ITGI con COBIT, Risk IT y Val IT e
ISO con ISO/IEC 20000 e ISO/IEC 27002 entre otras. Cada uno de ellos
orientados a diferentes aspectos de la administración de TI, por ejemplo COBIT
es un marco de referencia orientado a la gestión y control dirigido principalmente
a la alta gerencia y auditores mientras que ITIL está orientado hacia la gestión y
soporte de servicios de TI.
1.2.1 ITIL InformationTechnology Infrastructure Library
ITIL es un marco de referencia publicado por la OGC del gobierno Británico que
describe las mejores prácticas para la gestión de los servicios de TI, orientado a
1
http://www.isaca.org/Knowledge-Center/Research/Documents/Alineando-Cobit-4.1,-ITIL-v3-y-
ISO-27002-en-beneficio-de-la-empresa-v2,7.pdf pag 6
10
la medición y mejoramiento continuo de la calidad de los servicios entregados
analizados desde los dos puntos de vista, cliente y negocio.
ITIL se considera una guía general que puede aplicarse a cualquier tipo de
empresa grande o pequeña y es independiente de la plataforma tecnológica
utilizada, ha evolucionado desde su creación en los años 80s hasta la
actualidad, adaptando el enfoque y su rol de acuerdo con el desarrollo de TI y su
relación de apoyo con el negocio de las organizaciones. El gráfico mostrado en
la figura 1.1 detalla esta evolución.
Figura 1.1 ITIL Rol en el tiempo

Fuente: http://www.best-management-practice.com
/gempdf/itsmf_an_introductory_overview_of_itil_v3.pdf
ITIL considera la información como un recurso estratégico de las empresas, los
servicios de TI administran la información por tanto los servicios de TI se
consideran como un elemento estratégico en el cual se debe invertir para
entregar los servicios con alta calidad y optimización de costos.
11
Las organizaciones buscan que los servicios de TI estén alineados con las
necesidades y requerimientos del negocio y sean soporte del mismo, además de
que los servicios de TI se conviertan en el agente de cambio que facilita la
transformación del negocio con procesos eficientes, disminuyendo o eliminando
interrupciones y pérdidas de horas productivas. Para ITIL, servicio significa
entregar valor a los clientes, facilitando alcanzar sus objetivos y resultados sin
asumir riesgos y costos.
Las mejores prácticas de ITIL proveen los procesos, métodos, funciones y roles
para agregar valor a los servicios de TI, por lo cual una efectiva administración
convierte a los servicios de TI en un activo estratégico. Una recomendación
práctica para la implementación de ITIL es realizar aquellas cosas que ya fueron
probadas para trabajar de forma efectiva.
La publicación de ITIL V3 está compuesta por 5 libros que los ha identificado
como servicios:
Estrategia de Servicio
Diseño de Servicio
Transición de Servicio
Operación de Servicio
Servicio de Mejora Continua
Los 5 libros cubren cada etapa del ciclo de vida de un servicio, que inicia con la
definición y análisis de los requerimientos, considerados en la Estrategia y
Diseño del Servicio, continua con la migración al ambiente de producción en la
12
Transición y termina con la Operación y Mejoramiento en la Operación y Mejora
Continua del Servicio2.
Figura 1.2 Libros ITIL V3

Fuente: http://www.tcpsi.com/images/itil.gif
Siempre que sea posible la Mejora Continua del Servicio debe identificar las
oportunidades debilidades y fallas para su mejoramiento en cualquier momento
de las etapas del ciclo de vida.
1.2.2 COBIT (Control OBjectives for Information and related Technology)
COBIT es un marco de gobierno de las tecnologías de información que
proporciona una serie de herramientas para que la alta gerencia pueda conectar
los requerimientos de control con los aspectos técnicos y los riesgos del negocio.
COBIT puede ser utilizado en los más altos niveles de gobierno de TI,
proporcionando un marco de referencia global de control basado en el modelo
de procesos de TI que el ITGI pretende se pueda adaptar a cada empresa.
2
http://www.tcpsi.com/images/itil.gif
13
COBIT es un instrumento de gobierno de TI que lo pueden utilizar los directores
y auditores para facilitar el proceso de toma de decisiones en torno a las TIC,
considerando los factores clave de gobierno como el aseguramiento del valor de
TI, la administración de riesgo asociado a TI, así como el cumplimiento de los
requerimientos de control de información .
COBIT brinda buenas prácticas para garantizar que TI soporte los objetivos del
negocio, aproveche al máximo su información para crear oportunidades y ganar
ventajas competitivas, además permite optimizar los recursos disponibles de TI
incluyendo aplicaciones, información, infraestructura y personas.
COBIT fue desarrollado por ISACA a inicios de la década de los años 90 y su
primera publicación se la realizó en el año de 1996, en el año de 1998 se crea el
ITGI como un organismo que apoya la investigación y desarrollo de COBIT y
publicaciones adicionales para la implementación práctica del mismo. Las
versiones recientes publicadas por ITGI son COBIT 4.0 publicada en noviembre
de 2005, COBIT 4.1 en abril de 2007 y COBIT 5 en abril de 2012.3
COBIT 4.1 se estructura en 4 grandes áreas denominados dominios, los cuales
se muestran en la figura 1 y se definen como:
 Planear y Organizar (PO) – Proporciona dirección para la entrega de
Soluciones en (AI) y la entrega de servicio (DS).
 Adquirir e Implementar (AI) – Proporciona las soluciones y las pasa
para convertirlas en servicios.

3
http://es.wikipedia.org/wiki/Objetivos_de_control_para_la_información_y_tecnologías_relaciona
das
14
 Entregar y Dar Soporte (DS) – Recibe las soluciones y las hace
utilizables por los usuarios finales.
 Monitorear y Evaluar (ME) -Monitorear todos los procesos para
asegurar que se sigue la dirección prevista.
Figura 1.3 Dominios de COBIT V4.1

Fuente:http://www.isaca.org/Knowledge-Center/
cobit/Documents/cobiT4.1spanish.pdf.
A su vez cada dominio contiene procesos denominados “Objetivos de control de
alto nivel”, y estos a su vez contienen un determinado número de “Objetivos de
control específicos”.
COBIT se ha posicionado como el estándar de mayor aceptación para el
gobierno y control TI por toda su estructura y desarrollo, por el cumplimiento de
normas Internacionales como COSO, Sarbanes-Oxley, Basilea III, ITIL entre
otras, es así que la nueva versión publicada por ISACA denominada COBIT 5,
integra en sus procesos las publicaciones de Val IT y Risk IT como procesos
para la creación de valor y control de riesgos de los procesos.
15
1.3 Base legal de los servicios de las Instituciones Financieras del Sector
Público IFSP
La creación de las Instituciones Financieras del Sector Público obedece a la
necesidad de atender a sectores específicos que por sus condiciones
económicas no pueden ser atendidos por las Instituciones Financieras Privadas
y por razones de política de Estado deben orientar sus recursos al impulso de
actividades que promuevan el desarrollo económico nacional a través de
préstamos y facilidades de financiamiento en dinero.
Las Instituciones Financieras del Sector Público que se encuentran controladas
por la Superintendencia de Bancos y Seguros son:
BCE BANCO CENTRAL DEL ECUADOR
BNF BANCO NACIONAL DE FOMENTO
CFN CORPORACION FINANCIERA NACIONAL
BIESS BANCO DEL IESS
BEDE BANCO DEL ESTADO
BEV BANCO ECUATORIANO DE LA VIVIENDA
IECE INSTITUTO ECUATORIANO DE CREDITO EDUCATIVO
1.3.1 BANCO CENTRAL DEL ECUADOR BCE
El Banco Central del Ecuador inicia sus actividades el 10 de agosto de 1927, fue
creado por Presidente Isidro Ayora quien decretó la Ley Orgánica del Banco
Central del Ecuador el 12 de marzo de 1927 (Registro Oficial N. 283).
16
El Banco Central del Ecuador surgía como una compañía anónima autorizada
durante 50 años para emitir dinero, descontar a tasa fija, constituirse en
depositaria del gobierno y de los bancos asociados, administrar el mercado de
cambios y fungir de agente fiscal.
En la actualidad sus funciones están establecidas en la nueva Constitución que
rige a partir de octubre de 2008 y se rige por la ley de Régimen Monetario y
Banco del Estado y su ley reformatoria publicada el 5 de octubre de 2009.
Misión
"Instrumentar las políticas monetaria, financiera, crediticia y cambiaria del
Estado, administrar el Sistema de Pagos, actuar como depositario de los fondos
públicos y como agente fiscal y financiero del Estado, administrar las reservas,
proveer información y estadística de síntesis macroeconómica".4
Autoridades
Según el Art. 2 de la Ley Reformatoria a la Ley de Régimen Monetario y Banco
del Estado el Directorio del Banco Central del Ecuador se conforma de la
siguiente manera:
a) Un delegado del Presidente de la república, quien lo presidirá y tendrá
voto dirimente.
b) El Ministro que coordine la Política Económica o su delegado.
c) El Ministro que coordine la Producción o su delegado.
4
http://www.bce.fin.ec/contenido.php?CNT=ARB0000002
17
d) El delegado de las instituciones financieras públicas de desarrollo.
e) El Secretario Nacional de Planificación o su delegado y,
f) El Ministro de Finanzas o su delegado.
Asistirán a este Directorio con voz pero sin voto: El Superintendente de Bancos y
Seguros y el Gerente General del Banco Central del Ecuador.
Productos y Servicios
La Constitución de la República del Ecuador enmarca las actividades del Banco
Central, especialmente los artículos:
Art. 299.- El Presupuesto General del Estado se gestionará a través de una
Cuenta Única del Tesoro Nacional abierta en el Banco Central, con las
subcuentas correspondientes.
En el Banco Central se crearán cuentas especiales para el manejo de los
depósitos de las empresas públicas y los gobiernos autónomos
descentralizados, y las demás cuentas que correspondan.
Los recursos públicos se manejarán en la banca pública, de acuerdo con la ley.
La ley establecerá los mecanismos de acreditación y pagos, así como de
inversión de recursos financieros. Se prohíbe a las entidades del sector público
invertir sus recursos en el exterior sin autorización legal.
18
Art. 302.- Las políticas monetaria, crediticia, cambiaria y financiera tendrán
como objetivos:
1. Suministrar los medios de pago necesarios para que el sistema económico
opere con eficiencia.
2. Establecer niveles de liquidez global que garanticen adecuados márgenes
de seguridad financiera.
3. Orientar los excedentes de liquidez hacia la inversión requerida para el
desarrollo del país.
4. Promover niveles y relaciones entre las tasas de interés pasiva y activa que
estimulen el ahorro nacional y el financiamiento de las actividades
productivas, con el propósito de mantener la estabilidad de precios y los
equilibrios monetarios en la balanza de pagos, de acuerdo al objetivo de
estabilidad económica definido en la Constitución.
Art. 303.- La formulación de las políticas monetaria, crediticia, cambiaria y
financiera es facultad exclusiva de la Función Ejecutiva y se instrumentará a
través del Banco Central. La ley regulará la circulación de la moneda con poder
liberatorio en el territorio ecuatoriano.
La ejecución de la política crediticia y financiera también se ejercerá a través de
la banca pública.
El Banco central es una persona jurídica de derecho público, cuya organización
y funcionamiento será establecido por la ley.5
5
http://www.asambleanacional.gov.ec/documentos/Constitucion-2008.pdf
19
En cumplimiento a lo establecido en la Constitución y en la Ley de Régimen
Monetario y Banco del Estado, el Banco Central del Ecuador ha creado varios
servicios sobre plataforma Web, los mismos que son publicados para los
usuarios del internet por medio de página Web http://www.bce.fin.ec y a través
de la red privada de comunicaciones del BCE por medio de acceso al portal de
servicios. https://www4.bce.fin.ec
Los principales servicios que brinda el BCE a los usuarios de las instituciones
públicas y privadas que son accesibles por Internet o por enlaces de
comunicaciones exclusivos del BCE están:
 Sistema de Pagos.
 Depósito Centralizado de Valores.
 Sistema Unitario de Compensación Regional de Pagos SUCRE.
 Estadísticas monetarias financieras, de comercio exterior, de síntesis
macroeconómica.
 Cuentas Corrientes.
1.3.2 BANCO NACIONAL DE FOMENTO BNF
El Banco Nacional de Fomento nace el 4 de marzo de 1928 como Banco
Hipotecario del Ecuador, en octubre de 1943 se transforma en Banco Nacional
de Fomento Provincial y en noviembre de 1964 se expidió la Ley Orgánica del
Banco Nacional de Fomento la misma que fue reformada y publicada en octubre
de 2007 y que se encuentra vigente hasta la fecha, Con esta Ley el Banco
Nacional de Fomento es una institución financiera pública de fomento y
20
desarrollo, autónoma, con personería jurídica, patrimonio propio y duración
indefinida.
La autonomía del Banco Nacional de Fomento está plenamente garantizada en
la Constitución política vigente, y la institución, en todas sus operaciones, sólo
está sujeta al control de la Superintendencia de Bancos.
La nueva Ley exige al Estado que implemente los seguros como mecanismo de
protección contra riesgos y contingencias que puedan afectar el pago de los
créditos al Banco. Este seguro deberá estar cubierto con el aporte del Estado y
el beneficiario del crédito. El aporte estatal, según determina la ley aprobada, se
hará con cargo al Fondo de Ahorro y Contingencias.
Misión
“Fomentar el desarrollo socio-económico y sostenible del país con equidad
territorial, enfocado principalmente en los micro, pequeños y medianos
productores a través de servicios y productos financieros al alcance de la
población.”6
DIRECTORIO
El Directorio del Banco Nacional de Fomento está integrado por los siguientes
vocales:
1) El Presidente de la República o su delegado, quien lo presidirá;
2) El Ministro Coordinador de la Política Económica o su delegado;
6
https://www.bnf.fin.ec/index.php?option=com_content&view=article&id=1&Itemid=23&lang=es
21
3) El Ministro Coordinador de la Producción, Empleo y Competitividad o su
delegado;
4) El Ministro de Agricultura, Ganadería, Acuacultura y Pesca o su
delegado; y,
5) El Ministro de Industrias y Productividad o su delegado.
PRODUCTOS Y SERVICIOS
 Crédito productivo, créditos para producción, comercio y compra de tierras.
 Bienes de consumo o pagos de servicios hasta 300.000 dólares.
 Crédito Agrícola. Forestal y Pequeña Industria, Compra de tierras y
maquinaria, hasta 20.000 dólares.
 Crédito 5-5-5, hasta 5.000 dólares, 5 años de plazo y 5% anual.
 Crédito Desarrollo Humano, personas que reciben el bono de DH, hasta
420 dólares.
 Crédito quirografario, hasta 15.000 dólares.
 Servicios Bancarios: Cuentas corrientes, ahorros, depósitos, pagos, giros,
certificados.
 Servicios adicionales: Convenios otras instituciones ANECACAO, socio
bosque, puntomático, redoblamiento ovino sierra, dispensadores de
monedas.
1.3.3 CORPORACION FINANCIERA NACIONAL CFN
Corporación Financiera Nacional banca de desarrollo del Ecuador, es una
institución financiera pública, cuya misión consiste en canalizar productos
22
financieros y no financieros alineados al Plan Nacional del Buen Vivir para servir
a los sectores productivos del país.
La acción institucional está enmarcada dentro de los lineamientos de los
programas del Gobierno Nacional dirigidos a la estabilización y dinamización
económica convirtiéndose en un agente decisivo para la consecución de las
reformas emprendidas.
Lleva un ritmo de acción coherente con los objetivos nacionales, brindando el
empuje necesario para que los sectores productivos enfrenten en mejores
condiciones la competencia externa. El sector privado se siente estimulado para
emprender proyectos de envergadura con la incorporación de modernos y
sofisticados procesos tecnológicos acorde con las exigencias de la sociedad y la
globalización del siglo XXI.
Cuenta con una amplia red de oficinas sucursales independientes y autónomas a
nivel nacional, permitiéndoles servir a los sectores más alejados de las
principales capitales de provincia reflejando óptimos niveles de operatividad y
colocación de créditos.
Misión
“A través de la provisión de productos financieros y no financieros alineados al
Plan Nacional del Buen Vivir, servir a los sectores productivos del País.”7
DIRECTORIO
7
http://www.cfn.fin.ec/index.php?option=com_content&view=article&id=5&Itemid=360
23
Art. 5.- El Directorio es la autoridad máxima de la Corporación y estará integrado
por los siguientes miembros:
a. Un representante nombrado por el Presidente de la República, quien
presidirá el Directorio y la Corporación;
b. El Ministro de Economía y Finanzas o su delegado;
c. El Ministro de Comercio Exterior, Industrialización, Pesca y
Competitividad o su delegado;
d. El Ministro de Agricultura y Ganadería o su delegado;
e. El Ministro de Turismo o su delegado;
f. Un representante principal elegido por las Cámaras de la Producción de
la Sierra y el Oriente, para el período de dos años, quien podrá ser
reelegido indefinidamente; y,
g. Un representante principal elegido por las Cámaras de la Producción de
la Costa y Galápagos, para un período de dos años, quien podrá ser
reelegido indefinidamente.
El Gerente General de la Corporación Financiera Nacional asistirá al
Directorio con voz pero sin voto.
Crédito Forestal, Diseñado para iniciar viveros, plantaciones forestales,
industrializar y comercializar la madera, con créditos que pueden llegar hasta 20
años plazo y con períodos de gracia total de hasta 20 años, para apoyar el Plan
Nacional de Forestación y Reforestación.
24
Desarrollo al Turismo, Para apoyo a la inversión productiva, responsable y
rentable en el sector de Turismo como un factor de desarrollo, generación de
empleo y crecimiento económico.
Financiamiento estratégico, Capital de trabajo para actividades financiables de
la Clasificación Industrial Internacional Uniforme CIIU.
Crédito Automotriz, Segmento de transporte público, urbano, de taxi, de carga
liviana, interprovincial, escolar y pesado.
Multisectorial Sectores Priorizados, Incluye financiamiento de Confecciones y
calzado, Farmacéutica, Metalmecánica, Energías renovables, Petroquímica,
Turismo, Automotor, Cadena Agroforestal, Transporte y logística, Tecnología:
Hardware y Software, Bioquímica, Plástico y caucho, Alimentos y Servicios
logísticos.
AXIMECUADOR, La División de Comercio Exterior para concretar apoyo
financiero a personas y empresas que fomentan progreso en Ecuador a través
de las exportaciones e importaciones.
Negocios Fiduciarios, Estructurar y administrar negocios fiduciarios a nivel
nacional, manteniendo el liderazgo de la CFN, como la única administradora
pública activa e independiente de los sectores financieros privados, en el
mercado fiduciario.
25
Fondo de Garantía, Herramienta que facilita el acceso al crédito de la Micro y
Pequeña Empresa del Ecuador. que no disponen de garantías adecuadas y
suficientes para acceder al crédito.
El Programa de Financiamiento Bursátil (PFB), Consiste en la inversión de
recursos en títulos valores de renta fija de empresas, instituciones financieras y
municipios del país, que ofrezcan expectativas de seguridad, liquidez y
rendimiento.
Fomento productivo, Apoyo destinado a sectores, zonas y regiones de menor
desarrollo relativo con potencial de producción, diseñado para identificar
Proyectos Productivos de alto impacto social y económico
Asistencia Técnica, Procesos integrales de capacitación y cooperación
interinstitucional e internacional.
Convenios con la CAF Corporación Andina de Fomento, ALIDE Asociación
latinoamericana de instituciones financieras para el desarrollo, CORFO
Corporación de Fomento de la Producción de la República de Chile, BANCO DE
CHILE.
CFN Banking, Banca en Línea, en el cual usted, puede realizar consultas sobre
el estado de su crédito, consultar su estado de cuenta, tabla de amortización,
recibos de pago, e incluso puede proyectar a corto plazo valores a pagar.
Atención al Cliente, Buzón electrónico para quejas, sugerencias y denuncias
26
1.3.4 BANCO DEL IESS BIESS
El Banco del Instituto Ecuatoriano de Seguridad Social inició las actividades para
atención a los afiliados y jubilados el 18 de octubre del año 2010. La
Constitución de la República del Ecuador en su artículo 372, establece la
creación de una entidad financiera de propiedad del Instituto Ecuatoriano de
Seguridad Social la cual será responsable de canalizar sus inversiones y
administrar los fondos previsionales públicos, inversiones privativas y no
privativas; y, que su gestión se sujetará a los principios de seguridad, solvencia,
eficiencia, rentabilidad y al control del órgano competente.
En el Suplemento de Registro Oficial No. 587, de 11 de mayo de 2009 se aprobó
la creación del Banco del Instituto Ecuatoriano de Seguridad Social, BIESS. El
Banco es una institución financiera pública con autonomía administrativa, técnica
y financiera, con finalidad social y de servicio público de propiedad del Instituto
Ecuatoriano de Seguridad Social, con domicilio principal en la ciudad de Quito,
Distrito Metropolitano.
El objetivo principal del BIESS es convertirse en la institución financiera más
grande del país que apoye equitativamente proyectos de inversión en los
sectores productivos y estratégicos de la economía ecuatoriana con el fin de
fomentar la generación de empleo y valor agregado y para poder brindar el mejor
servicio financiero del país.8
Misión
8
http://www.biess.fin.ec/nuestra-institucion/historia
27
“Administrar, de manera eficiente, los recursos previsionales de los asegurados
generando operaciones financieras con retorno social y económico adecuado,
que contribuyan a impulsar la producción, creen valor agregado y garanticen
nuevas fuentes de empleo.”9
El BIESS es creado para canalizar el ahorro nacional de los asegurados hacia el
desarrollo productivo, a fin de potenciar el dinamismo económico del país, a
través de inversiones estructuradas, proyectos de inversión en los sectores
productivos. Y financiamiento a largo plazo de proyectos públicos y privados,
productivos y de infraestructura que generen rentabilidad financiera, valor
agregado y nuevas fuentes de empleo, así como también inversiones en títulos
de renta fija o variable a través de del mercado primario y secundario.
Préstamos Hipotecarios, para la adquisición de bienes inmuebles como
unidades de vivienda, construcción, remodelación, ampliación y/o mejoramiento
de las mismas, terrenos, oficinas, locales comerciales o consultorios.
Préstamos Quirografarios, por un monto igual al valor acumulado en los
Fondos de Reserva y Cesantía; y, dependiendo de la capacidad de pago, hasta
un monto de hasta 80 salarios básicos unificados del trabajador en general.
9
http://www.biess.fin.ec/nuestra-institucion/mision-y-visión
28
Préstamos prendarios, créditos inmediatos con dinero en efectivo, recibiendo
como garantía joyas de oro.
Banca de inversión, asesoría e información a empresas privadas y los
gobiernos, en materia de finanzas, valores, estructuración de portafolios de
valores, negociación de paquetes accionarios, adquisiciones, fusiones,
escisiones y otras operaciones del mercado de valores.
Negocios Fiduciarios, canalizar permanentemente recursos hacia sectores
industriales, inmobiliarios, energéticos y petroleros, mediante la inversión en
proyectos rentables, bajo mecanismos de Negocios Fiduciarios.
1.3.5 BANCO DEL ESTADO BEDE
El “Banco de Desarrollo del Ecuador” - BEDE- comienza su funcionamiento
como persona jurídica autónoma de derecho privado con finalidad social y
pública, el 6 de agosto de 1979, fecha desde la cual se expidió la Ley estatutaria.
Actualmente sus funciones están establecidas en la nueva Constitución que rige
a partir de octubre de 2008 y se rige por la ley de Régimen Monetario y Banco
del Estado y su ley reformatoria publicada el 5 de octubre de 2009.
Misión
“Impulsar de acuerdo a las políticas de Estado, el desarrollo sostenible con
equidad social y regional, promoviendo la competitividad territorial, mediante la
29
oferta de soluciones financieras y servicios de asistencia técnica, para mejorar la
calidad de vida de la población.”10
Autoridades
Según la Ley Reformatoria a la Ley de Régimen Monetario y Banco del Estado
Art. 117.- La administración superior del Banco del Estado corresponderá al
Directorio, integrado por seis miembros designados de la siguiente manera:
a) El Ministro de Economía y Finanzas, quien lo presidirá;
b) Un vocal principal y su suplente nombrados por el Presidente de la
República mediante Decreto Ejecutivo;
c) Un vocal por los trabajadores del país, elegido por las centrales
sindicales reconocidas legalmente;
d) Un representante elegido de entre los gerentes generales de las
instituciones financieras públicas del país;
e) Un representante de las municipalidades; y,
f) Un representante de los consejos provinciales y de los organismos
regionales de desarrollo;
Según el artículo 96 de la Ley Orgánica de Régimen Monetario y Banco Del
Estado. “El objetivo del Banco del Estado es financiar programas, proyectos,
obras y servicios encaminados a la provisión de servicios públicos cuya
prestación es responsabilidad del Estado, sea que los preste directamente o por
delegación a empresas mixtas, a través de las diversas formas previstas en la

10
http://www.bancoestado.com/index.php?option=com_content&view=article&id=55&Itemid=62
&lang=es
30
Constitución y en la Ley de Modernización del Estado, Privatizaciones y
Prestación de Servicios Públicos por parte de la Iniciativa Privada; financiar
programas del sector público, calificados por el Directorio como proyectos que
contribuyan al desarrollo socio - económico nacional; prestar servicios bancarios
y financieros facultados por la ley.”11
Los servicios que el BEDE presenta a sus clientes en su página Web son:
Promadec 2: Saneamiento ambiental
Pirsa: Agua potable y alcantarillado
Probarrio: Mejorando los barrios
Puentes: comunicación de pueblos amazónicos
Gestión patrimonial: Conservación de patrimonio
Gestión de riesgo: Prevenir y rehabilitar zonas afectadas
Equipamiento urbano comercial: Camales, terminales, mercados
Construyendo: Caminos secundarios
Proindepor: Infraestructura deportiva
1.3.6 BANCO ECUATORIANO DE LA VIVIENDA BEV
El Banco Ecuatoriano de la Vivienda (BEV) fue creado el 26 de mayo de 1.961,
mediante el Decreto-Ley de Emergencia No. 23, publicado en el Registro Oficial
No. 223, siendo su finalidad la de atender el déficit de la demanda habitacional
en el país.
11
www.bce.fin.ec/documentos/ElBancoCentral/leyRegimenMonetario.pdf‎
31
La institución afronta con responsabilidad el desafío de convertirse en un Banco
de Desarrollo al servicio de la ejecución de proyectos habitacionales de interés
social acorde al Plan Nacional del Buen Vivir, siendo uno de los objetivos
fundamentales de la entidad, atender el mercado hipotecario y financiero, esto
es atendiendo la demanda de vivienda y su financiamiento con suficientes
recursos y con la participación dinámica del sector privado.
Para cumplir con su compromiso el BEV está presente a nivel nacional a través
de las oficinas de Quito, Guayaquil, Cuenca, Ambato y Portoviejo; así como
también, con Instituciones Financieras debidamente autorizadas.
Misión
“Obtener y colocar los recursos requeridos para ejecutar programas
habitacionales integrales para contribuir al buen vivir de los ecuatorianos.”12
Directorio del BEV
Presidente del Directorio del Banco Ecuatoriano de la Vivienda
Vocal representante del Instituto Ecuatoriano de Seguridad Social (IESS)
Vocal representante del Ministerio de Finanzas
Vocal Designado por la Organización de Obreros del BEV
PRODUCTOS
Créditos al constructor
Redescuento de Cartera
Fondos de Garantía
12
http://www.bev.fin.ec/index.php/quienes-somos/mision-y-vision
32
Cuentas de Ahorro
SERVICIOS
Proyectos Habitacionales
Capacitaciones
Banca virtual
Banca móvil
1.3.7 INSTITUTO ECUATORIANO DE CREDITO EDUCATIVO IECE
En 1971, la entonces junta nacional de planificación y coordinación creó una
comisión presidida por su director técnico, Dr. Francisco Vivanco Riofrío para
que, con asesoramiento del Banco Interamericano de Desarrollo, BID, y del
Instituto Colombiano para estudios en el exterior, Icetex, desarrollen un proyecto
de ley que permita la creación de una entidad que administre y coordine los
recursos destinados a apoyar a los estudiantes.
Con estos antecedentes, el 26 de abril de 1971 el presidente de la república Dr.
José María Velasco Ibarra, firma el decreto No. 601, publicado en registro oficial
212 de los mismos mes y año, crea el Instituto Ecuatoriano de Crédito Educativo
y Becas, IECE, como entidad de derecho público, adscrita a la junta de
planificación y coordinación económica, con personería jurídica, autonomía
administrativa, patrimonio y fondos propios, con sede en la capital de la
república, a fin de que cumpla con los objetivos antes referidos.
33
En la administración de la Lcda. Alba luz Mora, en el afán de contar con un
cuerpo legal que esté acorde con los nuevos retos del derecho financiero y con
las operaciones que realiza la institución, mediante registro oficial No.179 del 03
de enero del 2006, se expide la ley sustitutiva a la ley del IECE, cuyo Artículo 1
expresa.
“El Instituto Ecuatoriano de Crédito Educativo y Becas, IECE, es una entidad
financiera de derecho público, con personería jurídica, autonomía administrativa
y financiera, con patrimonio y fondos propios, con domicilio principal en la ciudad
de Quito y jurisdicción en todo el territorio nacional.”13
Objetivos Estratégicos IECE
Conceder crédito educativo y becas de acuerdo a los criterios de priorización
establecidos en la política pública.
Fortalecer la estructura económica-financiera de la entidad.
Mejorar continuamente la administración del IECE bajo los principios
constitucionales de eficacia, eficiencia, calidez a través de estándares de
calidad en los servicios e infraestructura que ofrece la Institución.
Misión
“El IECE contribuye al desarrollo del talento humano, mediante el manejo de
productos y servicios orientados a potencializar, con calidad, calidez y
oportunidad las capacidades de sus beneficiarios, demostrando eficiencia en el
13
www.iece.fin.ec/docs/lotaip/.../ley_sustitutiva_a_la_ley_del_IECE.pdf
34
manejo, operatividad, seguimiento y monitoreo de los programas generados a
nivel nacional.”14
Directorio del IECE
De acuerdo con el artículo 4 de la ley sustitutiva el directorio del IECE está
integrado por los siguientes miembros.
- El Ministro de Educación y Cultura o su delegado permanente con rango
de subsecretario, quien lo presidirá.
- El delegado del Presidente del Consejo Nacional de Educación Superior,
CONESUP.
- El Secretario Nacional de Ciencia y Tecnología, SENACYT, o su
delegado.
- El delegado del presidente de la Federación Nacional de las Cámaras de
la Producción.
- El director Ejecutivo del Instituto Ecuatoriano de Cooperación
Internacional INECI, o su delegado.
- El Gerente General del IECE actuará como Secretario del Directorio y
tendrá voz pero no voto.
SERVICIOS
Crédito Educativo, Son los recursos económicos reembolsables que el IECE
entrega a los ecuatorianos, ecuatorianas y extranjeros residentes o a través de
14
http://www.iece.fin.ec/institucion/mision-vision
35
sus representantes legales, en caso de ser menores de edad, o apoderados
para financiar en forma total o parcial los estudios en el país o en el exterior.
BECAS, Nacionales e Internacionales, Son ayudas económicas no
reembolsables que se otorgan a ecuatorianos de capacidad académica
comprobada y de limitados recursos económicos, para que realicen estudios en
el país y en el exterior, contribuyendo así a la formación de los recursos
humanos ecuatorianos en los diferentes niveles académicos; los fondos
provienen de entidades públicas y privadas del Ecuador y de gobiernos de
países amigos y organismos internacionales.
Becas Especiales, Consejo de Gobierno de Galápagos (Ingala), para hijos de
héroes (CENEPA), Estudiantil de entrenamiento.
Servicios en línea, Solicitudes, Reporte académico, Saldos
1.4 Administración de Niveles de Servicio SLM
La administración de niveles de servicio SLM (Service level Management) se
encuentra en el libro de Diseño de Servicios de la publicación de ITIL V3.
1.4.1 Diseño de Servicios
El rol de la etapa de diseño de servicios puede ser definido como “El diseño de
servicios de TI adecuados e innovadores, incluyendo sus arquitecturas,
36
procesos, políticas y documentación, para satisfacer las necesidades actuales y
futuras de los requerimientos del negocio.”15
Todas las organizaciones que utilizan TI dependen que los procesos y servicios
de TI estén administrados y apoyados de forma apropiada, una buena gestión
de TI permite al negocio evitar pérdida de horas productivas, reducir costos,
mejorar ingresos y alcanzar los objetivos de negocio.
Para una efectiva provisión de servicios de TI se han identificado cuatro tipos de
activos que deben ser adquiridos, administrados e integrados de forma eficiente,
estos son:
 Infraestructura
 aplicaciones
 información
 personas
Por si solos estos cuatros activos no generan valor deben ser combinados para
construir los servicios.
Una vez generado un servicio este debe estar en continuo mantenimiento, ya
que se pueden necesitar cambios por actualización de tecnología, cambios en
los procesos de negocio, que puede llegar a requerir cambio en la utilización y
en la calidad del servicio, incluso la cancelación de un servicio.
15
http://www.best-management-
practice.com/gempdf/itsmf_an_introductory_overview_of_itil_v3.pdf
37
El diseño de servicios permite crear las especificaciones de diseño para cada
uno de los activos que son necesarios para implantar un servicio con calidad y a
un costo razonable que permita la satisfacción del cliente.
El servicio debe ser diseñado para que los cambios durante su ciclo de vida sean
mínimos, pero a la vez que sea versátil para que se adapte fácilmente a los
cambios de políticas de negocio.
Un enfoque holístico debería ser adoptado en el Diseño de Servicio para
asegurar la consistencia e integración con todas las actividades y procesos de
TI, un Diseño de Servicio adecuado depende de la utilización efectiva y eficiente
de los recursos de la organización los mismos que incluyen:
 Personas, sus habilidades en competencias relacionadas con la provisión
de servicios de TI.
 Productos, Los sistemas de administración y la tecnología utilizados en la
entrega de los servicios de IT.
 Procesos, los procesos, roles y actividades relacionados con la provisión
de servicios de TI.
 Socios, soporte y asistencia de servicios de TI de parte de los
proveedores, fabricantes y asociados de negocio.
El diseño de un servicio inicia con un conjunto de requerimientos que necesita el
negocio y termina con el desarrollo de una solución de servicio diseñada para
cumplir con los requerimientos y resultados planteados a través de un paquete
de diseño de servicio (SDP Service Design Package) que será generado por
38
cada nuevo servicio y cuando exista un cambio mayor o retiro de un servicio,
cada SDP debe ser procesado en las etapas de Transición y Operación de
servicio.
La etapa de diseño de servicio está compuesta por siete procesos que son:
Administración de Catálogo de Servicios.- Es la fuente central que contiene
todos los detalles, estado, interfaces y dependencias de los servicios de TI en
ejecución o en elaboración, que serán entregados al negocio y que pueden ser
revisados por las áreas de negocio que tienen aprobado el acceso.
Administración de Niveles de Servicio.- Negocia y documenta los acuerdos de
nivel de servicio con los clientes, monitorea los servicios de forma consistente y
produce reportes para comparar el cumplimiento de los niveles acordados,
cumple con las expectativas de clientes y usuarios en términos de calidad del
servicio.
Administración de Capacidad.- Su propósito está enfocado en la
administración de la capacidad y rendimiento de toda la infraestructura instalada,
establece una relación entre los recursos y los servicios para que coincida con la
capacidad que el negocio demanda. Genera y mantiene un plan de capacidad
adecuado y actualizado.
Administración de disponibilidad.- Relaciona los servicios, componentes y
recursos para satisfacer o superar los objetivos de disponibilidad y demanda de
los servicios de negocio a un costo efectivo. Asegura la implementación de
39
medidas reactivas y proactivas para optimizar y mejorar la disponibilidad de los
servicios de TI que dan soporte a la organización.
Con frecuencia la disponibilidad se mide como una relación porcentual entre el
tiempo de actividad acordado y el de inactividad de un servicio.
Administración de Continuidad de servicios de TI.- Determina la capacidad
de recuperación y reducción de riesgos de los servicios de TI y las estrategias
para apoyar los planes de continuidad y recuperación del negocio. Siendo la
tecnología un componente crítico un muchos procesos de negocio es necesario
establecer esquemas de alta disponibilidad en los servicios de TI.
Administración de la Seguridad de la Información.- Su propósito es alinear
las políticas de seguridad de TI con las de negocio para garantizar que la
seguridad de la información es administrada de forma correcta y efectiva y
además cumple con los requerimientos de disponibilidad, confidencialidad,
Integridad y no repudio.
Administración de Proveedores.- Su propósito es obtener valor agregado de
los servicios de los proveedores y que estos sean entregados de acuerdo con los
contratos, cumpliendo sus términos y condiciones. El servicio y soporte de los
proveedores debe permitir cumplir con los objetivos de servicio de TI y las
expectativas de negocio.
1.4.2 Políticas y principios de la administración de niveles de servicio SLM
40
SLM es el proceso que agrupa a las tareas de planificación, coordinación,
redacción, acuerdos, seguimiento y notificación de ANS, y la revisión continua
de los logros del servicio para garantizar que la calidad del servicio se mantiene
y mejora gradualmente a un costo justificable.
SLM también asegura que los nuevos requerimientos son captados y que los
nuevos servicios, cambios en los servicios y los ANS son desarrollados para
acoplarse a las necesidades del negocio y sus expectativas.
Los ANS proporcionan las bases para la administración de las relaciones entre el
proveedor del servicio y los clientes. Un ANS es un acuerdo escrito entre un
proveedor de servicios de TI y los clientes de TI, definiendo los objetivos clave
del servicio y las responsabilidades de ambas partes. Debe desarrollar una
asociación entre las dos partes para alcanzar acuerdos mutuamente
beneficiosos. Un ANS debe evitar caer en el desprestigio y la confrontación ya
que esto dificultaría cualquier mejora en la calidad del servicio
SLM es responsable de garantizar que todos los objetivos y medidas acordadas
con el negocio en los ANS se apoyan en apropiados acuerdos de niveles de
operación o contratos con las unidades internas o proveedores externos.
Un acuerdo de nivel de operación OLA (Operation Level Agreement) es un
acuerdo entre un proveedor de servicios de TI y otra parte de la misma
organización que provee otros servicios como mantenimiento de aire
acondicionado, mantenimiento de energía entre otras, un OLA debe contener
41
objetivos que apoyen los ANS y aseguren que las metas de los ANS sean
incumplidas por fallas en actividades de soporte.
1.4.3 Actividades, métodos y técnicas de SLM
Las actividades clave de este proceso deben incluir:
 Determinar, negociar, documentar y acordar los requerimientos para
nuevos servicios o cambios a los servicios actuales a través de
requerimientos de niveles de servicio y administrar y revisar los servicios
operacionales por medio de los ANS.
 Monitorear y medir el rendimiento alcanzado en todos los servicios en
operación y comparar con los objetivos de los ANS.
 Comparar, medir y mejorar la satisfacción del cliente
 Generar reportes de servicio.
 Examinar y revisar los ANS, el alcance de los OLA y contratos que apoyen
el servicio
 Desarrollar, mantener y operar los procedimientos para el ingreso,
procesamiento y resolución de todos los reclamos y el ingreso y
distribución de las felicitaciones
 Mantener disponibles y actualizados las plantillas y estándares de la SLM
42
Figura 1.4 Principales actividades del proceso de SLM
Fuente:http://ebookbrowse.com/ogc-itil-v3-service-design-pdf-d314512167,pag 68
1.4.4. Indicadores clave
Para administrar la calidad tanto en número como en nivel de los servicios
entregados, es importante medir:
 Porcentaje de reducción de los objetivos no descritos en los ANS.
 Porcentaje de incremento de la percepción de los objetivos alcanzados de
los ANS por parte de cliente, por intermedio de la revisión del servicio o
encuestas.
43
 Porcentaje de reducción de incumplimientos de los ANS causados por
servicios o contratos de soporte con terceros.
 Porcentaje de reducción de incumplimientos de los ANS causados por
incumplimiento de los OLAs.
Para acuerdos ya establecidos medir:
 Número total y porcentaje de incremento de los ANS totalmente
documentados.
 Porcentaje de incremento de los servicios con ANS comparado con los
servicios en operación.
 Porcentaje de disminución en los costos de monitoreo y generación de
reportes de los ANS.
 Porcentaje de incremento en la rapidez de generar y acordar ANS
apropiados a cada cliente.
 La frecuencia de reuniones con los clientes para revisión de servicios.
Para la administración de negocio medir.
 Reducción en número y severidad de los incumplimientos de los ANS.
1.4.5 Factores críticos de éxito, desafíos y riesgos de SLM
Un desafío que se presenta en la SLM es identificar al representante adecuado
para la negociación por parte del cliente, se sugiere que quien utilizará el servicio
es la persona adecuada para firmar un ANS.
44
Puede existir un representante de varios clientes quien conozca los
requerimientos del servicio con quien se facilite negociar, caso contrario varias
reuniones son necesarias para identificar los verdaderos requerimientos.
Cuando no existe experiencia previa en un ANS es aconsejable iniciar con un
borrador de ANS, buscar un servicio y un cliente con deseos de mejorar la
calidad del servicio ayuda a preparar el borrador.
Es importante que los requerimientos del cliente a todo nivel, tanto ejecutivos
como usuarios sean identificados e incorporados en el ANS. Además también se
debe considerar a los representantes internos del servicio de TI y sus
proveedores externos, todos deben estar de acuerdo en que los niveles de
servicio son realistas y alcanzables.
Cuando no existe datos históricos de monitoreo, es aconsejable mantener el
borrador del acuerdo hasta tener datos de monitoreo que confirmen que se
pueden alcanzar los niveles de servicio que están en el acuerdo, cuando los
objetivos y tiempos de servicio se han confirmado se puede firmar el ANS.
Los ANS deben ser firmados por los representantes apropiados por parte del
cliente y del proveedor de servicio, las dos partes deben tener el compromiso de
alcanzar el acuerdo y una vez que el ANS se haya firmado es necesario una
publicidad amplia a todo nivel para asegurar que todos los interesados conocen
la existencia del acuerdo y sus objetivos clave.
45
Los nuevos ANS, OLA, RLA (Request Level Agreement) deben ser difundidos a
los grupos internos de soporte como la Mesa de Ayuda, Catálogo de Servicios,
Control de cambios entre otros, ayuda a la difusión mantener un resumen de los
objetivos clave para mantener siempre presente los objetivos en que se está
trabajando y de ser posible añadir estos objetivos en las herramientas de soporte
incluyendo alertas automáticas cuando se alcance los límites establecidos.
Los nuevos ANS, OLA, RLA deben ser difundidos a todos los clientes y usuarios
para que conozcan lo que pueden esperar del servicio y cuando expresar su
desacuerdo o insatisfacción.
Es importante que el personal de mesa de ayuda este comprometido con los
ANS ya que al ser el primer punto de contacto de los clientes para el reporte de
incidentes, requerimientos y quejas, el personal deben ser los embajadores de la
cultura de servicio para hacer que el cliente no pierda la fe en los ANS firmados.
Los riesgos asociados a la provisión del servicio son:
 La falta de precisión en el ingreso, participación y compromiso del negocio
y los usuarios.
 Los recursos y herramientas requeridos para alcanzar, documentar,
monitorear y reportar los acuerdos de niveles de servicio.
 El proceso de convierte en administrativo y burocrático antes que un
proceso activo y proactivo que entrega un beneficio medible al negocio.
Evitar la utilización de procesos de SLM.
 Medidas y reportes difíciles de medir y mejorar, y que no son registrados.
46
 Alta expectativa de los clientes y baja percepción.
 Inapropiado y pésimo canal de comunicación entre el negocio y los
clientes.
47
CAPÍTULO 2: GESTIÓN DE LOS ACUERDOS DE NIVELES DE
SERVICIO PARA ARQUITECTURA DE SERVICIOS WEB EN IFSP
La gestión de los acuerdos de niveles de servicio para arquitectura de servicios
Web y para otros servicios que una Institución este en proceso de generar o ya
los tenga generados y firmados se lo debe realizar en base a las
recomendaciones descritas en el libro de ITIL V3 Diseño de Servicio, en el
proceso de administración de niveles de servicio (Service Level Management
SLM).
La meta del proceso de SLM es asegurar que todos los servicios de TI actuales
sean entregados con el nivel de servicio de TI acordado y que los futuros
servicios alcanzarán estos niveles.
El propósito del SLM es asegurar que la operación de los servicios y su
rendimiento son medidos de una forma profesional y consistente en toda la
organización de TI y que sus reportes satisfacen las necesidades del negocio.
Los principales objetivos del SLM son:
 Definir, documentar, acordar, monitorear, medir, reportar y revisar el nivel
de los servicios de TI suministrado.
 Proveer y mejorar la comunicación y relación con el negocio y los clientes.
 Monitorear y mejorar la satisfacción del cliente con la calidad del servicio
suministrado.
 Asegurar que el proveedor de TI y los clientes tengan expectativas claras y
sin ambigüedades de los niveles de servicio suministrados.
48
 Realizar mediciones proactivas para mejorar los niveles de servicio
suministrados considerando un costo justificable.
El SLM es el punto de contacto y comunicaciones entre los clientes y los
administradores de negocio de la organización y también entre los proveedores
de servicios de TI y el negocio.
El SLM necesita administrar las expectativas y percepciones del negocio,
clientes y usuarios para asegurar la calidad de servicio suministrado por el
proveedor está de acuerdo con estas expectativas. Para cumplir con esto el SLM
debe establecer y mantener Acuerdos de Niveles de Servicio ANS para todos los
servicios actuales y administrar el nivel de servicio entregado para que cumpla
con las medidas de calidad y metas contenidos en este ANS. Además debe
generar y acordar Requerimientos de Niveles de Servicios (Service Level
Request SLR ) para los nuevos servicios planificados o para cambios en los
servicios actuales.
El SLM asegura que todos los servicios y componentes son diseñados y
suministrados para cumplir con las metas en términos de las necesidades de
negocio. Algunas otras tareas que debe cumplir el SLM son:16
 Desarrollar y administrar acuerdos de niveles de operación para asegurar
que sus metas están alineadas con las metas de la SLM.
 Revisar y administrar los contratos y acuerdos con proveedores para
asegurar que sus metas están alineadas con las metas de la SLM.
16
ITIL v3 - Service Design
49
 Reportes y administración de todos los servicios y revisión de los
incumplimientos y deficiencias de los Acuerdos de Niveles de Servicios.
 Iniciar y coordinar el Plan de Mejoramiento de Servicio para administrar,
planificar e implementar procesos de mejora de todos los servicios.
2.1 Análisis de la situación actual de los ANS en las IFSP
Para evaluar la situación actual de los Acuerdos de Niveles de Servicio y otros
procesos de TI que dan apoyo a un servicio con arquitectura Web en las
Instituciones Financieras del Sector Público se ha desarrollado una encuesta
dirigida a los Directores o Gerentes de la unidad organizacional de TI.
Considerando que un servicio con arquitectura Web hace uso se la
infraestructura tecnológica de una institución, el soporte de grupos de apoyo
internos y externos y el soporte de servicios de terceros, se determina la
necesidad de definir los procesos internos de TI que dan apoyo a los servicios
Web y están altamente relacionados con la administración de niveles de servicio
y la generación de ANS.
El dominio Entrega y Soporte ( Delivery and Support DS ) de COBIT contiene
los procesos que controlan que los servicios sean utilizables por los usuarios
finales y que los mismos tengan la calidad, continuidad, el soporte y seguridad.
Estos procesos a su vez están relacionados con los procesos de Diseño de
Servicios (Service Design SD) de ITIL V3.17 Por tanto se ha definido siete
procesos que son considerados como básicos en empresas que inician la
17
Alineando-Cobit-4.1,-ITIL-v3-y-ISO-27002-en-beneficio-de-la-empresa-v2,7
50
implementación de procesos basados en ITIL y que están altamente
relacionados con la suscripción de acuerdos de niveles de servicios, como punto
de partida se debe realizar un diagnóstico de la situación actual de estos
procesos para medir su nivel madurez y grado de control interno siendo estos
procesos:18
Tabla 2.1 Relación de los procesos de COBIT V4.1 con ITIL V3

Fuente:http://www.isaca.org/Education/Conferences/Documents/LatinCACS-ISRM-
Presentations/124.pdf
Elaborado por: Edison Nicolalde Jaque
COBIT V 4.1 ITIL V3
DS1 Definir y administrar niveles de SD Gestión de Niveles de Servicio

servicio
DS2 Administrar servicios de terceros SD Gestión de Proveedores
DS3 Administrar el desempeño y la SD Gestión de la Capacidad

capacidad
DS4 Garantizar la continuidad del SD Gestión de Continuidad de
servicio de TI servicios de TI
DS8 Administrar la mesa de servicio y SO Gestión de eventos
los incidentes SO Gestión de Incidentes
DS9 Administrar la configuración ST Gestión de la configuración y
activos de servicio
DS10 Administración de problemas SO Gestión de problemas
Para la medición del nivel de madurez y nivel de control de los procesos, se
utiliza la matriz de preguntas desarrolladas por ISACA, las cuales se han
revisado con el director de la presente investigación para que las mismas tengan
la claridad y se ajusten al objetivo de medición propuesto.
La encuesta está dirigida a los gerentes o directores del área de tecnología de la
información de cada una de las instituciones, a quienes se ha enviado la solicitud
18
http://www.isaca.org/Education/Conferences/Documents/LatinCACS-ISRM-
Presentations/124.pdf
51
de autorización para realizar la encuesta y utilizar la información que se obtiene
de la misma, ya que para las instituciones financieras la información generada es
considerada como un activo de la institución.
Para la encuesta en algunos casos los directores han designado a los
responsables del área de infraestructura y de servicios para la entrega de
información y llenado de la matriz de datos. A cada uno de los entrevistados se
ha entregado una copia de la tabla del modelo de madurez genérico establecido
por COBIT y se ha explicado a los entrevistados las características de cada
atributo a cumplir en cada uno de los niveles, cada atributo está calificado con
una escala de cumplimiento que se valora en cuatro niveles establecidos como:
 DEFINITIVAMENTE NO
 UN POCO
 EN BUENA MEDIDA
 DEFINITIVAMENTE SI
Para cada nivel de explica el objetivo de control del proceso y se revisan uno a
uno los atributos de cada nivel de madurez, solicitando a los entrevistados que
cada una de las respuestas sean un reflejo de la situación actual y que se tenga
el respaldo correspondiente en cuanto a documentación, difusión y aplicación.
En varios casos se ha solicitado la validación correspondiente, por ejemplo
verificando el software utilizado para el monitoreo y control de los dispositivos o
software de administración de incidentes y problemas, esto debido a la cantidad
de tiempo disponible de cada uno de los entrevistados.
52
Cada una de las encuestas se evalúa de acuerdo con la matriz de calificación
COBIT Maturity Level Calculatión19 donde en cada nivel de madurez a cada una
de las actividades se asigna un peso proporcional y un grado de acuerdo que
multiplicados entre sí, generan el aporte individual de cada actividad al valor del
nivel de madurez respectivo, la suma de los valores de cada nivel da como
resultado en valor del nivel de madurez del proceso.
Como ejemplo se muestra el cálculo del nivel de madurez del proceso DS1
“Definir y administrar niveles de servicio” para el Banco Nacional de Fomento
BNF
Tabla 2.2 Matriz para encuesta y cálculo de nivel de madurez COBIT

Fuente:http://www.docstoc.com/docs/68591473/Cobit-Maturity-Calculation-Form-2011-
EuroCACS
DOMINIO COBIT: ENTREGA DE SERVICIOS Y SOPORTE
NIVEL DE MADUREZ
INSTITUCION: BANCO NACIONAL DE FOMENTO BNF
PROCESO: DS1 Definir y administrar niveles El proceso de Definir y administrar niveles de servicio
de servicio que satisfacen los requerimientos de negocio de
asegurar la alineación de servicios claves de TI con la
estrategia de negocio.
Alcanza un nivel de madurez cuando:
TEMAS NIVEL DE MADUREZ 1 PESO GRADO DE ACUERDO
X 0.00 0.33 0.66 1.00
DEFINITI- UN EN DEFINITI- VALOR

Inicial/Ad Hoc % VAMEN- POCO BUENA VAMEN-
TE NO MEDIDA TE SI
1 Existe conciencia de la necesidad de administrar 30 X 0,198

los niveles de servicio, sin embargo el proceso es
informal y reactivo.
2 Se reconoce la necesidad de establecer la 20 X 0,132
responsabilidad y rendición de cuentas para la
definición y administración de servicios, si bien
aún no está definida.
3 Existen algunos indicadores de desempeño pero 30 X 0,198
son solamente cualitativos con las metas
definidas sin presición.
4 La notificación de incumplimientos es informal, 20 X 0,066
inconsistente y sin frecuencia definida
0,594
19
http://www.docstoc.com/docs/68591473/Cobit-Maturity-Calculation-Form-2011-EuroCACS
53
Repetible pero intuitivo % DEFINITI- UN EN DEFINITI- VALOR
VAMEN- POCO BUENA VAMEN-
TE NO MEDIDA TE SI
1 Existen acuerdos de niveles de servicio aunque 20 X 0,000

son informales y sin documentación.
2 Los reportes de los niveles de servicio existen, 20 X 0,066
aunque no estén completos y con valor apropiado
para los clientes.
3 Los reportes de los niveles de servicio existen, 20 X 0,066
aunque solo como esfuerzos individuales
aislados de los administradores.
4 Está designado un coordinador de niveles de 20 X 0,200
servicio con responsabilidades definidas, pero
con autoridad limitada.
5 Si existe un proceso para verificar el 20 X 0,066
cumplimiento de los acuerdos de niveles de
servicio ANS / SLA, el proceso es voluntario y no
está generalizado.
0,398

Proceso definido % DEFINITI- UN EN DEFINITI- VALOR
TE NO MEDIDA TE SI
1 Las responsabilidades están bien definidas 15 X 0,050

aunque con autoridad discrecional.
2 El proceso de desarrollo de los ANS/SLA está en 20 X 0,066
orden y cuenta con puntos de control para
revalorar los niveles de servicio y la satisfacción
de cliente.
3 Los servicios y los niveles de servicio están 20 X 0,200
definidos, documentados y se ha acordado
utilizar un proceso estándar
4 Las deficiencias en los niveles de servicio están 15 X 0,000
identificadas sin embargo los procedimientos
para resolver las deficiencias son informales.
5 Existe un vínculo claro entre el cumplimiento del 15 X 0,099

nivel de servicio previsto y el presupuesto
asignado.
6 Los niveles de servicio están definidos si bien no 15 X 0,050
pueden responder completamente a las
necesidades del negocio.
0,464

Administrado y medible % DEFINITI- UN EN DEFINITI- VALOR
TE NO MEDIDA TE SI
1 Se integra la definición de los niveles de servicio 10 X 0,000

a la fase de definición de requerimientos del
sistema y se incorporan en el diseño de la
aplicación y de los ambientes de operación.
2 La satisfacción del cliente es medida y valorada 15 X 0,000
de forma habitual.
3 Las medidas de desempeño reflejan las 10 X 0,000
necesidades del cliente, en lugar de las metas de
TI.
4 Las medidas para la valoración de los niveles de 10 X 0,000
servicio se vuelven estandarizadas y reflejan los
estándares de la industria.
54
5 Los criterios para la definición de los niveles de 10 X 0,066
servicio están basados en la criticidad del
negocio e incluyen consideraciones de
disponibilidad, confiabilidad, desempeño,
capacidad de crecimiento, soporte al usuario,
planeación de continuidad y seguridad.
6 Cuando no se cumplen los niveles de servicio, se 10 X 0,000
llevan a cabo análisis causa-raíz de manera
rutinaria.
7 El proceso de reportes por monitoreo de niveles 10 X 0,000
de servicio se vuelve cada vez más
automatizado.
8 Los riesgos operacionales y financieros 10 X 0,000
asociados con la falta de cumplimiento de los
niveles de servicio, están definidos y se
entienden claramente.
9 Se implementa y mantiene un sistema formal de 15 X 0,000
medición de los KPIs y los KGIs.
0,066

Optimizado % DEFINITI- UN EN DEFINITI- VALOR
TE NO MEDIDA TE SI
1 Los niveles de servicio son continuamente 15 X 0,050

reevaluados para asegurar la alineación de TI y
los objetivos del negocio, mientras se toma
ventaja de la tecnología incluyendo le relación
costo-beneficio.
2 Todos los procesos de administración de niveles 15 X 0,150
de servicio están sujetos a mejora continua.
3 Los niveles de satisfacción del cliente son 15 X 0,000
administrados y monitoreados de manera
continua.
4 Los niveles de servicio esperados reflejan metas 20 X 0,000
estratégicas de las unidades de negocio y son
evaluadas contra las normas de la industria.
5 La administración de TI tiene los recursos y la 15 X 0,000

asignación de responsabilidades necesarias para
cumplir con los objetivos de niveles de servicio y
la compensación está estructurada para brindar
incentivos por cumplir con dichos objetivos.
6 La alta gerencia monitorea los KPIs y los KGIs 20 X 0,000
como parte de un proceso de mejora continua.
0,1995
ENTREVISTADO ENTREVISTADOR
NOMBRE: Santiago Jarrín Edison Nicolalde
CARGO: Subgerente Tecnología
FECHA: 09 de mayo del 2013
55
Tabla 2.3 COBIT Cálculo de nivel de madurez
EuroCACS
NIVEL
MADUREZ CUMPLIMIENTO CONTRIBUCION BNF
inicial 0,59 0,33 0,20

repetible 0,398 0,66 0,26
definido 0,464 1 0,46
administrado 0,066 1,33 0,09
optimizado 0,1995 1,66 0,33
NIVEL DE MADUREZ DEL PROCESO DS1 1,34
NIVEL MADUREZ DS1

1.34
1.40
1.20
1.00
0.80
0.60
0.40 NIVEL MADUREZ
0.20
0.00
Figura.2.1 Nivel de Madurez del proceso DS1 para el BNF

Elaborado por : Edison Nicolalde Jaque
Como medida complementaria a la medición del nivel de madurez de los
procesos definidos, se ha realizado la medición del nivel de control interno para
cada uno de ellos en base al modelo de COBIT. En este caso al igual que el
anterior cada actividad se valora con un peso y un nivel de acuerdo, sumando
los aportes da como resultado el porcentaje de cumplimiento del control interno
del proceso.
56
Como ejemplo se muestra el cálculo del nivel de control interno del proceso DS1
“Definir y administrar niveles de servicio” para el Banco Nacional de Fomento
BNF
Tabla 2.4 COBIT Encuesta para medir control interno de un proceso

EuroCACS
DOMINIO COBIT: ENTREGA DE SERVICIOS Y SOPORTE
CONTROL DE PROCESO
INSTITUCION: BANCO NACIONAL DE FOMENTO BNF
PROCESO: DS1 Definir y administrar Contar con una definición documentada y un
niveles de servicio acuerdo de servicios de TI y de niveles de servicio,
hace posible una comunicación efectiva entre la
gerencia de TI y los clientes de negocio respecto de
los servicios requeridos. Este proceso también
incluye el seguimiento y la notificación oportuna a las
partes interesadas sobre el cumplimiento de los
niveles de servicio. Este proceso permite la
alineación entre los servicios de TI y los requisitos
relacionados con el negocio.
OBJETIVOS DE CONTROL PES GRADO DE ACUERDO
O
X 0.00 0.33 0.66 1.00
% DEFINITI UN EN DEFINITI VALOR
-VAMEN- POCO BUENA -VAMEN-
TE NO MEDID TE SI
A
1 La alta dirección, en representación de la 8,33 x 0,027
empresa y su funcionamiento, tiene
participación en el diseño y aprobación del
marco SLA.
2 Los funcionarios clave, han formalizado el 8,33 x 0,055
criterio de rendimiento para apoyar y medir
el logro de los objetivos del SLA, y si un
proceso está en marcha para monitorear y
reportar el logro de los objetivos.
3 Se verifica el desempeño de los SLAs 8,33 x 0,027
interno y externo, y se compara los
resultados reales para su alineación con los
requisitos de SLA esperados.
4 Confirmar que los objetivos de servicios de 8,33 X 0,055
TI alineados con los objetivos de negocio, y
formalmente definir las expectativas y las
mediciones de desempeño.
5 Se analiza los registros históricos de 8,33 x 0,027
rendimiento, y se verifica que los resultados
se comparan contra anteriores compromisos
de mejora del servicio.
6 Verifica que el formato del contenido de los 8,33 x 0,083
SLA incluyen exclusiones, acuerdos
comerciales y Olas.
57
7 Se verifica que los contratos de SLAs 8,33 0,000
incluyan al menos:
Definición, Costo
- Costo del servicio
- Nivel de servicio mínimo cuantificable
- Nivel de apoyo de la función de TI
- La disponibilidad, fiabilidad y capacidad de
crecimiento
- Procedimiento para cambio de cualquier
parte del contrato
- Planificación de continuidad
- Escrito y aprobado formalmente acuerdo
entre el proveedor y el usuario del servicio
- Vigencia y nuevo periodo de revisión /
renovación / no renovación
- Contenido y frecuencia de los informes
sobre la ejecución y el pago por servicios
- Cargos realistas en comparación con las
prácticas de la historia, la industria y las
mejores
8 Se encuesta a los dueños del proceso de 8,33 x 0,000

negocio y los usuarios en cuanto a su grado
de satisfacción con los servicios de TI
proporcionados, para identificar posibles
áreas débiles. Estas investigaciones pueden
llevarse a cabo en persona o por medio de
una encuesta anónima.
9 Se dispone de un proceso para realinear 8,33 x 0,027

continuamente objetivos del SLA y las
medidas de desempeño con los objetivos de
negocio y estrategia de TI, aprovechando
expertos en el tema y en comparación con la
práctica aceptada en la industria y puntos de
referencia.
1 Existe un proceso de gestión del cambio 8,33 x 0,055
0 adecuada para , los objetivos del SLA y las
medidas de rendimiento
1 Existe un proceso de gestión para asegurar 8,33 x 0,027
1 que el servicio de catálogo o cartera está
disponible, completa y actualizada, y se
revisa periódicamente para asegurar la
alineación con los requerimientos del
negocio.
1 Los OLAs están en el lugar que permita 8,33 x 0,083
2 identificar, documentar y explicar cómo los
servicios serán entregados técnicamente
para apoyar el SLA (s). Se asegura que los
OLAs incluyen todos los procesos técnicos
que se utilizan y los SLA que apoyan (un
solo OLA puede apoyar varios SLA).
46,9
%
FIRMAS
ENTREVISTADO ENTREVISTADOR
NOMBRE: Santiago Jarrín Edison Nicolalde
CARGO: Subgerente Tecnología
FECHA: 09 de mayo del 2013
58
Este proceso de valoración de las encuestas permite visualizar el grado de
madurez y el grado de control interno de cada uno de los procesos, en cada una
de las instituciones. Para establecer la relación entre madurez y control, a la
calificación del grado de madurez expresado en la escala de 1 a 5 se ha
convertido en porcentaje, obteniéndose los resultados que se muestra a
continuación:
BANCO NACIONAL DE FOMENTO
En la tabla 2.6 se tabula los valores de nivel de madurez y aplicando los pesos
de cumplimiento y contribución y se determina que, el proceso DS10
Administración de problemas tiene el mayor nivel de madurez, mientras que el
proceso DS4 Garantizar la continuidad del servicio de TI se muestra con el
menor nivel de madurez.
Tabla 2.5 Nivel de Madurez de los procesos de apoyo a los ANS en el BNF
NIVEL
PROCESO inicial repetible definido administrado optimizado MADUREZ

DS1 Definir y adm 0,196 0,263 0,464 0,088 0,331 1,34
niveles de servicio
DS2 Adm servicios de 0,24 0,37 0,65 0,40 0,25 1,91
terceros
DS3 Adm el desempeño 0,109 0,250 0,512 0,680 0,959 2,51
y la capacidad
DS4 Garantizar la 0,13 0,26 0,31 0,24 0,11 1,06
continuidad del
servicio
DS8 Adm la mesa de 0,137 0,328 0,663 0,948 0,438 2,51
servicio y los
incidentes
DS9 Adm la 0,330 0,370 0,330 0,417 0,548 1,99
configuración
DS10 Adm de 0,185 0,492 0,579 0,993 0,990 3,24
problemas
59
La tabla 2.7 presenta el nivel de control interno de los procesos en el BNF, el
proceso DS8 Administrar la mesa de servicio y los incidentes tiene el mayor
porcentaje de control interno y DS4 Garantizar la continuidad del servicio de
TI se muestra con el menor nivel de control interno.
Tabla 2.6 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el BNF
CONTROL Y MADUREZ PROCESOS C0NTROL MADUREZ

DS1 Definir y adm niveles de servicio 46,9% 26,8%
DS2 Adm servicios de terceros 11,8% 38,1%
DS3 Adm el desempeño y la capacidad 55,8% 50,2%
DS4 Garantizar la continuidad del servicio 11,6% 21,1%
DS8 Adm la mesa de servicio y los incidentes 58,9% 50,3%
DS9 Adm la configuración 37,1% 39,9%
DS10 Adm de problemas 27,2% 64,8%
En la figura 2.3 se muestra la relación que existe entre el nivel de madurez y
nivel de control interno de los procesos en el BNF donde se verifica que en
algunos procesos existe una brecha entre los valores porcentuales de los niveles
de madurez y control interno, lo que indicaría que se debe realizar una revisión a
detalle del cumplimiento de madurez y control interno de los procesos
60
BANCO NACIONAL DE FOMENTO
DS1 Definir y adm

niveles de servicio
70.0%
60.0%
DS10 Adm de 50.0% DS2 Adm servicios
problemas 40.0% de terceros
30.0%
20.0% CONTROL
10.0% MADUREZ
0.0% DS3 Adm el
DS9 Adm la
desempeño y la
configuración
capacidad
DS8 Adm la mesa de DS4 Garantizar la

servicio continuidad
Figura 2.2 Nivel de madurez y control de los procesos en el BNF

BANCO CENTRAL DEL ECUADOR
De acuerdo con la tabla 2.4 donde se tabula los valores de nivel de madurez y
aplicando los pesos de cumplimiento y contribución se determina que el proceso
DS4 Garantizar la continuidad del servicio de TI tiene el mayor nivel de
madurez, mientras que el proceso DS10 Administración de problemas se
muestra con el menor nivel de madurez.
Tabla 2.7 Nivel de Madurez de los procesos de apoyo a los ANS en el BCE
NIVEL
DS1 Definir y adm
niveles de servicio 0,274 0,044 0,000 0,000 0,863 1,18
61
DS2 Adm servicios
de terceros 0.164 0.131 0.665 0.859 0.876 2.70
DS3 Adm el
desempeño y la 0,219 0,504 0,531 0,329 0,164 1,75
capacidad
DS4 Garantizar la
continuidad 2,88
0,24 0,40 0,81 0,62 0,82
DS8 Adm la mesa
de servicio 2,12
0,330 0,660 0,663 0,463 0,000
DS9 Adm la
configuración 0,251 0,436 0,745 0,880 0,219 2,53
DS10 Adm de
problemas 0,264 0,165 0,000 0,200 0,000 0,63
La tabla 2.5 presenta el nivel de control interno de los procesos definidos, DS4
Garantizar la continuidad del servicio de TI tiene el mayor nivel de control
interno, mientras que el proceso DS10 Administración de problemas se
muestra con el menor nivel de control interno.
Tabla 2.8 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el BCE
CONTROL y MADUREZ PROCESOS C0NTROL MADUREZ

nivel de control interno de los procesos donde se verifica que en la mayoría de
los procesos existe un porcentaje similar en el valor porcentual de los niveles
62
BANCO CENTRAL DEL ECUADOR
DS1 Definir y adm

niveles de servicio
70.0%
60.0%
DS10 Adm de 50.0% DS2 Adm servicios
30.0%
20.0%
10.0% CONTROL
0.0% DS3 Adm el
DS9 Adm la MADUREZ
desempeño y la
configuración
capacidad
DS8 Adm la mesa DS4 Garantizar la

de servicio y los continuidad del
incidentes servicio
Figura 2.3 Nivel de madurez y control de los procesos en el BCE

CORPORACIÓN FINANCIERA NACIONAL
De acuerdo con la tabla 2.8 se determina que el proceso DS8 Administrar la
mesa de servicio y los incidentes tiene el mayor nivel de madurez, mientras
que el proceso DS10 Administración de problemas se muestra con el menor
nivel de madurez.
Tabla 2.9 Nivel de Madurez de los procesos de apoyo a los ANS en la CFN
NIVEL
DS1 Definir y adm niveles
de servicio 0,296 0,615 0,429 0,837 0,863 3,04
DS2 Adm servicios de
terceros 0,33 0,66 0,71 0,95 0,77 3,42
DS3 Adm el desempeño y
la capacidad 0,330 0,404 0,495 0,946 0,961 3,14
63
DS4 Garantizar la
continuidad del servicio 3,16
0,33 0,63 0,83 0,66 0,71
DS8 Adm la mesa de
servicio y los incidentes 4,40
0,330 0,660 0,949 1,194 1,267
DS9 Adm la
0,330 0,660 1,000 0,968 0,000 2,96
configuración
DS10 Adm de problemas 0,330 0,660 0,730 0,549 0,548 2,82
Como se muestra en la tabla 2.9, el proceso DS8 Administrar la mesa de
servicio y los incidentes tiene el mayor porcentaje de control interno y DS1
Definir y administrar niveles de servicio se muestra con el menor nivel de
control interno.
Tabla 2.10 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en la
CFN
CONTROL Y MADUREZ PROCESOS C0NTROL MADUREZ

nivel de control interno de los procesos en la CFN donde se verifica que en la
mayoría de los procesos existe un porcentaje similar en el valor porcentual de los
niveles, además se muestra un alto en el nivel de madurez.
64
CORPORACION FINANCIERA NACIONAL
DS1 Definir y adm
niveles de servicio
100.0%
80.0%
DS10 Adm de DS2 Adm servicios
40.0%
20.0%
0.0%
DS3 Adm el
DS9 Adm la
desempeño y la
configuración
capacidad
CONTROL
DS8 Adm la mesa DS4 Garantizar la MADUREZ
de servicio y los continuidad del
incidentes servicio
Figura 2.4 Nivel de madurez y control de los procesos en la CFN

INSTITUTO ECUATORIANO DE CRÉDITO EDUCATIVO Y BECAS
De acuerdo con la tabla 2.12 se determina que el proceso DS8 Administrar la
mesa de servicio y los incidentes tiene el mayor nivel de madurez, a su vez el
proceso DS9 Administrar la configuración se muestra con el menor nivel de
madurez.
Tabla 2.11 Nivel de Madurez de los procesos de apoyo a los ANS en el IECE
NIVEL
DS1 Definir y adm 0,231 0,483 0,363 0,132 0,000
niveles de servicio 1,21
terceros 0,076 0,099 0,499 0,614 0,550 1,84
DS3 Adm el desempeño
y la capacidad 0,087 0,174 0,264 0,375 0,659 1,56
65
DS4 Garantizar la
continuidad del servicio 0,153 0,294 0,314 0,395 0,274 1,43
DS8 Adm la mesa de
servicio y los incidentes 0,164 0,548 0,614 0,528 0,769 2,62
DS9 Adm la
configuración 0,142 0,285 0,000 0,154 0,137 0,72
Como se muestra en la tabla 2.13, el proceso DS1 Definir y administrar
niveles de servicio tiene el mayor porcentaje de control interno y DS9 Adm la
configuración se muestra con el menor nivel de control interno.
Tabla 2.12 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en el
IECE
CONTROL DE MADUREZ PROCESOS C0NTROL MADUREZ

nivel de control interno de los procesos en el IECE donde se confirma que en
algunos procesos existe una brecha entre los valores porcentuales de los niveles
de madurez y control interno, esto indica que se debe realizar una revisión a
detalle del cumplimiento de madurez y control interno de los procesos .
66
DS1 Definir y IECE
adm niveles de
servicio
60.0%
50.0% DS2 Adm
DS10 Adm de
40.0% servicios de
problemas
30.0% terceros
20.0%
10.0% CONTROL
0.0% MADUREZ
DS3 Adm el
DS9 Adm la
desempeño y la
configuración
capacidad
DS8 Adm la DS4 Garantizar

mesa de servicio la continuidad
y los incidentes del servicio
Figura 2.5 Nivel de madurez y control de los procesos en el IECE

BANCO DEL ESTADO
De acuerdo con la tabla 2.12 se determina que el proceso DS2 Adm servicios
de terceros tiene el mayor nivel de madurez, mientras que el proceso DS10
Adm de problemas se muestra con el menor nivel de madurez.
Tabla 2.13 Nivel de Madurez de los procesos de apoyo a los ANS en el BEDE
NIVEL
DS1 Definir y adm 0,330 0,044 0,631 0,971 0,356 2,3
niveles de servicio
terceros 0,121 0,099 0,932 1,168 1,235 3,6
DS3 Adm el desempeño
y la capacidad 0,174 0,395 0,696 0,636 0,247 2,1
DS4 Garantizar la
continuidad del servicio 0,114 0,132 0,797 0,858 1,326 3,2
67
DS8 Adm la mesa de
servicio y los incidentes 0,083 0,383 0,498 0,814 1,018 2,8
DS9 Adm la
configuración 0,251 0,395 0,330 0,527 0,383 1,9
La tabla 2.15 determina que el proceso DS8 Adm la mesa de servicio y los
incidentes tiene el mayor porcentaje de control interno y DS9 Adm la
configuración se muestra con el menor nivel de control interno.
BEDE
CONTROL DE MADUREZ PROCESOS C0NTROL MADUREZ
En la figura 2.6 se muestra la relación existente entre el nivel de madurez y nivel
de control interno de los procesos analizados en el BEDE, donde se verifica que
en la mayoría de los procesos existe un porcentaje equivalente en el valor
porcentual de los niveles.
68
BANCO DEL ESTADO
DS1 Definir y adm

niveles de servicio
90.0%
80.0%
DS10 Adm de 70.0% DS2 Adm servicios de
60.0%
problemas 50.0% terceros
40.0%
30.0%
20.0%
10.0%
0.0%
DS3 Adm el
DS9 Adm la
desempeño y la
configuración
capacidad
DS4 Garantizar la CONTROL

DS8 Adm la mesa de
continuidad del
servicio y los incidentes MADUREZ
servicio
Figura 2.6 Nivel de madurez y control de los procesos en el BEDE

Una vez analizados los procesos por cada institución se realiza una comparación
entre todas las instituciones para determinar similitudes y tendencias que
permitan establecer recomendaciones que podrían ser generales o específicas
para cada una de ellas, obteniéndose los siguientes resultados.
Tabla 2.15 Nivel de Madurez de los procesos de apoyo a los ANS en las IFSP
PROCESOS MADUREZ
BCE CFN BNF IECE BEDE
DS1 Definir y adm niveles de
servicio 1,18 3,04 1,34 1,21 2,33
DS2 Adm servicios de terceros 2,43 3,42 1,91 1,84 3,56
DS3 Adm el desempeño y la
capacidad 1,75 3,14 2,51 1,56 2,15
69
DS4 Garantizar la continuidad del
servicio 2,88 3,16 1,06 1,43 3,23
DS8 Adm la mesa de servicio y los
incidentes 2,12 4,40 2,51 2,62 2,80
DS9 Adm la configuración 2,53 2,96 2,00 0,72 1,89
DS10 Adm de problemas 0,63 2,82 3,24 1,38 2,75
Figura 2.7 Nivel de madurez de los procesos en las IFSP

De la tabla 2.16 y figura 2.7 se puede establecer que las instituciones mantienen
un nivel de madurez equivalente en la mayoría de procesos, a excepción de la
CFN que alcanza un nivel mayor en todos los procesos analizados, esto debido
a su infraestructura tecnológica de monitoreo y control y su integración
automática con la mesa de servicios, lo cual le brinda el soporte tecnológico para
establecer mayor cumplimiento en los procesos definidos.
70
En lo que respecta al control interno de procesos tabla 2.17 y figura 2.8, al
comparar cada uno de los procesos en todas las instituciones, se evidencia que
las brechas de control interno son mayores que las brechas de niveles de
madurez.
Tabla 2.16 Nivel de control y madurez (%) de los procesos de apoyo a los ANS en las
IFSP
PROCESOS CONTROL
DS1 Definir y adm niveles de servicio 22,1% 55,0% 46,9% 49,5% 46,6%
DS2 Adm servicios de terceros 59,1% 65,5% 11,8% 39,2% 71,1%
capacidad 25,4% 66,3% 55,8% 15,2% 43,0%
servicio 61,3% 66,3% 11,6% 13,2% 64,5%
incidentes 29,0% 84,1% 58,9% 45,5% 55,9%
DS9 Adm la configuración 48,7% 72,5% 37,1% 9,7% 37,7%
DS10 Adm de problemas 6,0% 72,3% 27,2% 21,0% 54,9%
71
Figura 2.8 Nivel de control interno de los procesos en las IFSP
En general se observa que el nivel de madurez y nivel de control interno de los
procesos deben mantener una similitud en el valor porcentual y una relación
directa, es decir que a mejor control interno se obtiene un mayor nivel de
madurez.
2.1.1 Comparativo del proceso DS1 Definir y administrar niveles de

servicio.
En la encuesta Anexo 1, con la segunda pregunta se trata de determinar
cuantitativamente el número de acuerdos de niveles de servicio, para clientes
internos o externos que tiene firmados actualmente cada institución, el resultado
se muestra en la tabla 2.18.
72
BNF

Número de acuerdos de
nivel de servicio ANS
firmados con clientes
internos o externos 0 2 0 0 3
Únicamente la CFN y el BEDE tiene firmados acuerdos de niveles de servicio
ANS, aunque los mismos que no tienen un estándar definido. El análisis del
proceso DS1 Definir y administrar niveles de servicio demuestra que las
instituciones que no tienen generados ANS, tienen un nivel bajo de madurez y
de control interno como se detalla en la figura 2.9
MADUREZ
DS1 Definir y adm niveles de servicio
5.00
4.50
4.00
3.50 3.04
3.00 2.33
2.50
2.00 1.34
1.18 1.21
1.50
1.00
0.50
0.00
Figura 2.9 Nivel de madurez proceso DS1 en las IFSP

73
CONTROL INTERNO
DS1 Definir y adm niveles de servicio
100.0%
90.0%
80.0%
70.0%
55.0%
60.0% 46.9% 49.5% 46.6%
50.0%
40.0%
30.0% 22.1%
20.0%
10.0%
0.0%
Figura 2.10 Nivel de control interno proceso DS1 en las IFSP

Si bien este proceso en ninguna de las IFSP resultó ser el de más bajo nivel, si
se evalúa el promedio para cada proceso resulta ser el de más bajo nivel de
madurez de todos los procesos, como lo indica la tabla 2.19
Tabla 2.18 Promedio de Nivel de Madurez de los procesos de apoyo a los ANS en las
IFSP
PROCESOS MADUREZ
BCE CFN BNF IECE BEDE promedio
DS1 Definir y adm niveles de
servicio 1.18 3.04 1.34 1.21 2.33 1.82
DS2 Adm servicios de terceros 2.43 3.42 1.91 1.84 3.56 2.63
capacidad 1.75 3.14 2.51 1.56 2.15 2.22
servicio 2.88 3.16 1.06 1.43 3.23 2.35
incidentes 2.12 4.40 2.51 2.62 2.80 2.89
DS9 Adm la configuración 2.53 2.96 2.00 0.72 1.89 2.02
DS10 Adm de problemas 0.63 2.82 3.24 1.38 2.75 2.16
74
2.2 Análisis cuantitativo de los servicios con arquitectura Web
Los servicios con arquitectura Web son aquellos que una institución presenta a
los usuarios externos o internos para su acceso a través de un navegador de
internet.
El sitio Web de la institución, es el servicio Web fundamental que todas las IFSP
ofrecen a sus clientes internos y externos y son la puerta de acceso a otros
servicios Web que las instituciones exponen para el consumo de los usuarios a
través de internet.
Cada uno de los servicios requiere de una infraestructura de tecnología que
puede tener menor o mayor complejidad dependiendo de la forma como está
diseñado el servicio, el nivel de disponibilidad y seguridad que debe tener, como
norma de cumplimiento interno y para cumplir con las regulaciones de las
instituciones de control, como Superintendencia de Bancos y Contraloría.
Del análisis de la encuesta y consulta en el internet tenemos que todas las
instituciones tienen un sitio Web institucional y la mayoría tiene el servicio de
correo Webmail con acceso desde un navegador.
El siguiente cuadro muestra el número de servicios con arquitectura Web que
tiene cada institución.
75
Tabla 2.19 Servicios con arquitectura Web de cada IFSP
Número de servicios
sobre arquitectura WEB 5 5 3 1 5
que tiene la institución
Número de servicios sobre

arquitectura WEB por institucion
5
0
Figura 2.11 Servicios con arquitectura Web de cada IFSP

2.3 Análisis de los niveles de operación internos OLA
Los acuerdos de nivel de operación (OLA Operational Level Agreement) son
fundamentales para el soporte de los acuerdos de nivel de servicio ANS, por
cuanto la administración de la infraestructura sobre la cual se levanta el servicio
debe ser monitoreada y controlada de manera eficaz y con calidad, Un servicio
con arquitectura Web también requiere de un equipo de soporte en un centro de
atención al cliente donde administrar los temas relacionados con los incidentes y
problemas que se puedan generar en el acceso y ejecución del servicio.
76
El análisis de los niveles de operación internos se lo realiza midiendo el nivel de
acuerdo de la actividad “Los OLAs están en el lugar que permita identificar,
documentar y explicar cómo los servicios serán entregados técnicamente para
apoyar el ANS (s). Se asegura que los OLAs incluyen todos los procesos
técnicos que se utilizan y los ANS que apoyan (un solo OLA puede apoyar varios
ANS).” Que se encuentra en la encuesta de control de procesos en el proceso
DS1
Tabla 2.20 Nivel de acuerdo para los OLAs en las IFSP


Los OLAs están en el lugar que
permita identificar, documentar y
explicar cómo los servicios serán
entregados técnicamente para apoyar
el SLA (s). Se asegura que los OLAs
incluyen todos los procesos técnicos
que se utilizan y los ANS que apoyan
(un solo OLA puede apoyar varios
ANS).
DEFINITIVAMENTE NO 0,01 0,01
UN POCO
EN BUENA MEDIDA 0,66 0,66
DEFINITIVAMENTE SI 1,00
1 Los OLAs están en el lugar

que permita identificar,
0.8
documentar y explicar
0.6 cómo los servicios serán
entregados técnicamente
0.4 para apoyar el SLA (s). Se
asegura que los OLAs
0.2 incluyen todos los procesos
técnicos que se utilizan y
0 los SLA que apoyan (un
BCE CFN BNF IECE BEDE solo O
Figura 2.12 Nivel de acuerdo para los OLAs en las IFSP

77
De acuerdo con la encuesta sobre el proceso descrito y cuyo resultado se
encuentran en las figuras 2.12 y 2.13, se puede deducir que cada institución
pese a que no tenga ANS generados puede iniciar con acuerdos de OLA
internos, principalmente con las áreas de administración y control de
infraestructura y de administración de la mesa de servicio y los incidentes que
son los procesos que más apoyan a la generación de ANS y en promedio
alcanzan un alto nivel de madurez.
NIVEL DE MADUREZ
5.00
4.50
4.00
3.50
DS3 Adm el
3.00
desempeño
2.50
y la
2.00
capacidad
1.50
1.00 DS8 Adm la
0.50 mesa de
0.00 servicio y los
incidentes
Figura 2.13 Nivel de madurez de los servicios DS3 y DS8 en las IFSP
2.4 Análisis de roles y responsabilidades
Considerando que la mayoría de servicios que ofrecen las IFSP y en particular
los servicios con arquitectura Web dependen de los procesos de negocio, se
debe establecer de forma clara los roles y responsabilidades para las actividades
consideradas clave dentro del servicio, lo que permitirá que se tomen las
decisiones correctas en el tiempo justo, para mantener el nivel de servicio
dentro de los parámetros establecidos en el acuerdo.
78
Una herramienta útil establecida por COBIT para el establecimiento de roles y
responsabilidades es generar una matriz RACI ( Responsible, Accountable,
Consulted, Informed) la misma que establece la relación de nivel de
responsabilidad para cada actividad clave entre las unidades organizacionales
de negocio y de TI.
Dado que solo dos instituciones mantienen establecidos acuerdos de niveles de
servicio con sus clientes, y en estos no se definen las matrices de
responsabilidad no es posible realizar un análisis de cómo están actualmente
establecidos los roles y responsabilidades en los acuerdos de niveles de servicio
generados.
2.5 Análisis de contratos de servicios con terceros
COBIT V 4.1 ITIL V3
DS2 Administrar servicios de terceros SD Gestión de Proveedores
Para establecer y gestionar los ANS de forma efectiva es importante que se
considere a los proveedores de servicios externos como un grupo de apoyo
importante en el cumplimiento de los acuerdos de niveles de servicio por cuanto
los servicios de arquitectura Web para clientes externos utilizan el servicio de
internet.
Los proveedores externos de servicios de conexión de internet y de
infraestructura de tecnología deben mantener ANS con altos niveles de
continuidad y rendimiento debido a que forman parte de la cadena de
procesamiento para el servicio.
79
Para el análisis de la situación actual de la administración de los servicios de
terceros, se utiliza encuesta del modelo de madurez de COBIT para el proceso
DS2 Administrar servicios de terceros, cuyos resultados se muestran a
continuación.
Tabla 2.21 Nivel de madurez de DS2 Administración de terceros


DS2 Adm servicios de terceros 2,43 3,42 1,91 1,84 2,12
DS2 Adm servicios de terceros

4.00 3.42 3.56
3.50
3.00 2.43
2.50 1.91 1.84
2.00
1.50
1.00
0.50
0.00
Figura 2.14 Nivel de madurez del servicio DS2 en las IFSP

Este proceso en promedio tiene el segundo nivel de madurez más alto, esto
podría sustentarse en el hecho de que al ser instituciones públicas, se rigen por
leyes y reglamentos de contratación pública que establece los lineamientos
generales al proceso de contratación y control a los contratos establecidos.
80
CAPÍTULO 3: DESARROLLO DE LA GUÍA METODOLÓGICA PARA
GENERAR ANS PARA ARQUITECTURA DE SERVICIOS WEB EN
INSTITUCIONES FINANCIERAS DEL SECTOR PÚBLICO DENTRO DEL
MARCO DE REFERENCIA ITIL V3
3.1 Definición de procedimientos para establecer un ANS
Un ANS es un acuerdo escrito entre una IFSP que ofrece un servicio de TI y sus
clientes internos o externos, definiendo los objetivos clave del servicio y las
responsabilidades de ambas partes. Debe desarrollar una asociación entre las
dos partes para alcanzar acuerdos mutuamente beneficiosos. Un ANS debe
evitar la confrontación y el desprestigio por no cumplir con los acuerdos, ya que
esto dificultaría cualquier mejora posterior en la calidad del servicio.
Para establecer ANS debemos verificar que una IFSP cumpla con algunos
requisitos básicos como son:
 Cultura de Servicio al Cliente. Todos los integrantes de la institución
deben poseer una cultura de relación y responsabilidad con las
necesidades del cliente.
 Actividades de TI orientadas al Negocio. Todos los procesos de TI
deben estar conscientes de su rol, en la atención oportuna de los
requerimientos del cliente ya que un retraso en la respuesta puede
ocasionar pérdida de productividad e ingresos para el cliente y disminuir el
nivel de expectativa del servicio y nivel de satisfacción.
 Compromiso con el proceso y acuerdo de nivel de servicio. Debe
existir el compromiso de la institución con el proceso de aprendizaje de
negociar y generar ANS efectivos y cumplir los mismos.
81
Además se debe definir:
3.1.1 El diseño general del ANS.
Se debe diseñar una estructura de ANS que garantice que todos los servicios y
clientes están cubiertos de la manera más adecuada a las necesidades de la
organización. Esta estructura podría incluir:
 ANS basado en servicio. Cada ANS cubre un servicio específico para
todos clientes de este servicio, ejemplo servicio de correo, en ocasiones se
debe considerar requerimientos específicos para cierto tipo de clientes sin
embargo se puede tener un enfoque eficiente si se considera múltiples
categorías del mismo servicio y clasificarlos como dorado, plata y bronce.
 ANS basado en cliente. Este acuerdo cubre todos los servicios que
utilizan un determinado cliente o grupo de clientes, facilitando la
generación de un solo documento para varios servicios.
 ANS de multi-nivel. En algunas organizaciones se puede adoptar ANS de
tres capas para cubrir necesidades específicas de grupo dentro de la una
institución, por tanto se puede generar ANS de nivel corporativo, entre dos
IFSP que comparten varios servicios, de nivel cliente, para grupos de
usuarios dentro de la institución.
82
Figura 3.1 Acuerdo de Nivel de Servicio de multi-nivel
Fuente: Charles Sturt Universitiy
Es recomendable la generación de plantillas y estándares para la generación de
los ANS, SLR y OLA en la organización, de forma que se facilite su posterior
uso, operación y administración.
Utilizar un vocabulario claro y conciso que no permita ambigüedades ya que
normalmente no es necesario términos legales, además un lenguaje simple
ayuda a un común entendimiento. Se debe incluir un glosario para clarificar
ciertos términos que pueden considerarse como ambiguos.
Para servicios de TI que son provistos por proveedores externos, los objetivos
del servicio se encuentran en los contratos de apoyo, en el ANS o documentos
anexos, en cualquiera de los casos los objetivos acordados deben ser claros,
específicos y no ambiguos.
83
3.1.2 Determinar los participantes en el proceso de ANS
Identificar el grupo de trabajo para el desarrollo e implementación del proceso de
definición y generación de ANSs, es uno de los pasos iniciales para generar un
plan de acción y ejecución que permita alcanzar los objetivos de este proceso.
Este grupo debería estar compuesto por representantes del proveedor, del
cliente o grupo de clientes y en lo pasible de un moderador, además de
representantes de grupos de soporte interno, como mesa de ayuda,
administradores de infraestructura, desarrollo de sistemas, entre otros.
84
Aclaración inicial del ANS y la
comprensión común de los
objetivos
CLIENTE PROVEEDOR
MODERADOR
USUARIO SERVICIOS TI
Servicios Internos
¿Qué servicios de TI son esenciales para
EL CLIENTE?
Sistemas y redes
Aplicaciones
Las personas clave
Soporte / Mesa de Ayuda
Sistemas clave
Disponibilidad
Departamentos clave
tiempos de respuesta a falla
Los momentos y metas clave
¿Cuáles son los sistemas clave de
¿Cuándo se necesita?
negocio?
¿Con qué rapidez usted los necesita
¿Cómo se puede escalar los
restaurados?
problemas?
¿Qué apoyo e información necesita?
¿Cómo manejar los problemas
¿Qué comentarios se necesitan?
principales
¿Cuáles son las políticas clave?
Seguridad, aprovisionamiento, etc
Negociar ANS con objetivos adecuados escritorio estándar
Para satisfacer las necesidades del ¿Qué quiere informar?
cliente y capacidades generales de TI
Establecer mecanismos de reportes
Medir el desempeño actual y comparar contra ANSs
Revisar y aumentar los objetivos de nivel de servicio
Revisar y adaptar los recursos según sea necesario
Figura 3.2 Generación de un Acuerdo de Nivel de Servicio

Fuente: barclayrae.com/.../A%20Guide%20to%20SLAs.doc
85
3.1.3 Identificar los componentes del proceso de ANS
Para establecer un ANS se debe identificar los componentes que el cliente
necesita para su negocio, si bien algunos pueden parecer obvios, no se debe
asumir ninguno y cada uno debe ser analizado y considerado para ser incluidos
o no en la negociación, estos componentes pueden ser:
 Las horas de operación que el cliente necesita o espera, este horario debe
acoplarse al horario de operación definido por la institución financiera que
provee el servicio.
 Determinar cómo se clasificará la prioridad de los reportes de incidentes y
el proceso de escalamiento del incidente en caso de ser necesaria la
atención de los equipos de segundo y tercer nivel. Uno de los parámetros
de decisión podría ser el impacto del incidente sobre la operación del toda
la institución.
 Especificar los componentes de infraestructura tales como mainframes,
servidores, dispositivos de conectividad LAN y WAN, aplicativos Web o
Cliente/Servidor que se soportan actualmente o que pueden ser
soportados a futuro, se debe considerar el cambio de infraestructura que
pueda tener el cliente o proveedor.
 Establecer si el soporte de segundo nivel o tercer nivel es por llamada o
atención en sitio para la solución total del problema, a su vez determinar
los tiempos de respuesta para cada caso, definir la frecuencia de reportes
de seguimiento a casos escalados o no resueltos.
86
 Acordar la información que debe entregar el usuario al abrir el incidente
como nombre, localidad, ID de usuario, tipo de contrato de servicio, entre
otros.
 Describir un procedimiento para las solicitudes de cambio, definiendo la
prioridad en base a categorías de requerimientos y al impacto que puede
tener en el acuerdo ANS.
3.1.4 La revisión de los acuerdos base, OLA y contratos con terceros
Los proveedores de servicio dependen del soporte de equipos técnicos que
están dentro de la empresa o de proveedores externos, un ANS debe considerar
como alinear los acuerdos de operación internos (Operational Level Agreement
OLAs) y los contratos con los proveedores externos con los objetivos del
servicio.
Un OLA debe ser simple pero con objetivos claros y específicos para el
monitoreo de su cumplimiento, y considerar todos los elementos de la cadena
del servicio, el tiempo de procesamiento de incidentes debe ser menor al
estipulado en el ANS ya que en el OLA no se considera tiempos adicionales
incorporados en la mesa de ayuda, los reportes de los OLAs deben ser
revisados con frecuencia para detectar posibles problemas a presentarse en la
infraestructura que puedan afectar al ANS con el cliente y definir la solución del
mismo y su costo.
Los acuerdos de servicio con los clientes ANS, los acuerdos internos OLAs y
acuerdos con los proveedores deben mantenerse actualizados, se deben revisar
87
al menos una vez por año para garantizar que están vigentes y se mantienen
alineados con las necesidades y estrategia de negocio.
Se debe revisar si los acuerdos se mantienen actualizados después de las
órdenes de cambio y si estos cambios no invalidan estos acuerdos.
3.1.5 Elaboración de un acuerdo inicial, requerimientos de nuevos servicios

y generación de SLR
Una vez diseñada y acordada la estructura de los ANS y sus componentes, es
necesario la creación de un primer Acuerdo de Nivel de Requerimiento ( SLR
Service Level Request ) donde esté incluido desde el inicio el cliente para
generar los requerimientos iniciales de operación, rendimiento y administración,
así como su discusión y aprobación.
Es importante la familiarización con sus clientes, conocer a fondo sus
necesidades de negocio, sus procesos y operaciones diarias, nuevas iniciativas
y metas del negocio.
Se debe identificar a todos los posibles grupos de clientes tanto internos como
externos, y generar acuerdos para todos los grupos posibles, no solo para
aquellos en donde el proveedor se considere fuerte.
Dentro de cada grupo se podría elegir un líder, quien pudiera tomar cierto tipo de
decisiones que permita avanzar en la generación del ANS y a su vez comunicar
a los otros integrantes las decisiones que se han establecido para el acuerdo.
88
Con cada grupo de clientes se debe mantener reuniones de trabajo para
establecer el cronograma de desarrollo e implantación del ANS, cada grupo debe
identificar sus criterios para el ANS, parámetros de medición y generación de
reportes y con estas definiciones elaborar el primer borrador del ANS.
Los otros procesos de TI deben ser consultados para determinar las metas
reales que se pueden alcanzar en disponibilidad y rendimiento, para el caso de
existir dudas se deben establecer metas provisionales que se ajustarán dentro
del período de garantía.
El SLR debe ser parte integral del Diseño de Servicio y debe ser considerado en
las etapas de diseño y desarrollo del servicio y en las pruebas de ensayo, puede
ser gradualmente redefinido de acuerdo con el avance del servicio y puede llegar
a convertirse en el ANS inicial para la etapa de pruebas.
Puede existir dificultad para definir los requerimientos iniciales debido a que el
negocio desconoce sus necesidades en términos de capacidad, seguridad,
disponibilidad, y continuidad de los servicios de TI, varias reuniones de
negociación serán necesarias para establecer un balance entre los objetivos
deseados y los alcanzables o factibles.
Otro procesos de TI importantes a tomar en cuenta son la administración de
cambios, administración de la configuración y mesa de ayuda ya que el soporte
del servicio y sus componentes debe ser ejecutado por estos procesos, por tanto
es necesario redefinir o generar nuevos contratos con proveedores y los
Acuerdos de Niveles de Operación (Operational Level Agreement OLA) internos,
89
entrenamiento a los integrantes de la mesa de ayuda, verificando que no exista
una sobrecarga de trabajo a los mismos, caso contrario se debe ampliar los
recursos para dar soporte al nuevo servicio.
Varias reuniones con los clientes o sus representantes son necesarias para
establecer un ANS inicial donde el proveedor de servicio garantice que este es
alcanzable. Deben existir varias reuniones de negociación, en las cuales se
pueden proponer cambios o mejoras generales y generar un nuevo documento
que se envía a todos los integrantes del grupo para una nueva revisión y de no
existir propuesta de cambio se aprobaría el ANS.
El ANS aprobado debe ser difundido a todos los procesos de TI y de negocio.
3.1.6 El Monitoreo del rendimiento del servicio
Un ANS solo debe incluir aquello que pueda ser monitoreado y medido de
común acuerdo entre el proveedor y cliente, la inclusión de artículos o
actividades que no puedan medirse de forma efectiva, puede llevar a disputas o
pérdida de confianza.
Se debe revisar y mejorar la capacidad de monitoreo y procurar estar de acuerdo
con la percepción que el cliente tiene del servicio y es recomendable que se lo
realice en paralelo al desarrollo de un ANS.
El monitoreo se lo debe realizar a todos los componentes del servicio, de
principio a fin (aunque el costo puede ser alto) y se debe solicitar al cliente el
reporte inmediato de cualquier incidente que afecte el servicio.
90
La mesa de ayuda podría ser utilizada para monitorear la percepción de la
disponibilidad del servicio, el tiempo de respuesta y solución de incidentes que
tiene el cliente, para ello se debería modificar los procedimientos de atención de
la mesa de ayuda para que coincidan con los incluidos en los ANS.
Para los casos donde es difícil medir tiempo de respuesta de una transacción en
aplicativos específicos se puede incluir intervalos de tiempo adecuados antes de
que sea reportado como incidente. Por ejemplo se podría incluir que el tiempo
promedio de respuesta:
 X segundos en una red de alta velocidad.
 Y segundos para Internet o enlace remotos.
 si se sobrepasa de Z minutos de tiempo respuesta se debe reportar a la
mesa de ayuda.
Otro acuerdo podría incluir como aceptable un determinado número de
incidentes en un intervalo de tiempo.
En la mesa de ayuda se debe crear las relaciones entre incidentes y servicios y
obtener reportes de incumplimientos de los ANS, para que la Administración de
Problemas realice la correspondiente investigación y corrección del problema,
debido a que los incidentes pueden originarse por múltiples factores y
componentes, es necesario que los problemas sean reportados e investigados
inmediatamente.
91
Una forma de mejorar el monitoreo es la instalación de herramientas automáticas
de monitoreo y correlación de eventos que permitan la generación de alarmas en
caso de sobrepasar tiempos estimados de respuesta, esto permite incrementar
la disponibilidad pero produce un alto costo del servicio.
Es importante que en los ANSs se evalué e implemente un control de los
requerimientos de cambio, con los respectivos procedimientos y nivel de
escalamiento para que los mismos sean registrados y evaluados por el proceso
correspondiente.
3.1.7 La medición y mejora de la satisfacción del cliente
Algunos temas como la percepción y satisfacción que tiene el cliente del servicio
no pueden ser monitoreados y medidos por procedimientos automáticos o
estadísticos por tanto se deben preparar algunos métodos para medir estos
temas.
Para realizar una medida debemos partir de la expectativa de cumplimientos de
los objetivos que tiene el cliente y como estos se están cumpliendo, por tanto se
puede plantear que:
Satisfacción = Percepción – Expectativas (valor >= 0 cliente
satisfecho)
Un ANS es un documento que no modifica la calidad de un servicio, es la cultura
de servicio del proveedor la que permitirá que la percepción de un buen servicio
supere las expectativas del cliente. Por tanto se deben establecer ciertos
métodos para monitorear estos parámetros por medio de:
92
 Encuestas de cumplimiento de servicio con escala de calificación de 1 a 5,
donde 1 es mala calidad y 5 excelente.
 Reuniones con los clientes para revisar el servicio y obtener su
realimentación.
 Reuniones para revisar una implementación realizada o posterior a la
implementación de un cambio solicitado en el servicio.
 Encuestas telefónicas de satisfacción realizadas de forma regular o
aleatoria desde la mesa de ayuda.
 Análisis de los reclamos y elogios.
Se debe asegurar que toda información es procesada y el cliente obtendrá
alguna acción de mejora del servicio, además se debe mantener información
histórica de la satisfacción para comparar si existe variación en la misma y
establecer acciones para rectificar si es necesario.
3.1.8 La generación de reportes de servicio
Una vez aceptados los ANSs se debe iniciar con la generación de reportes de
operación, los formatos, frecuencia y mecanismos de obtención y entrega deben
ser definidos y acordados con los clientes.
Es importante incorporar en los reportes un resumen ejecutivo y de preferencia
gráfico con los resultados de comparar los niveles alcanzados con los niveles
acordados, es recomendable utilizar colores Verde, Naranja y Rojo para
visualizar de forma rápida el cumplimiento o incumplimiento de los mismos.
93
Figura 3.3 reporte de cumplimiento de ANS
Fuente: http://www.dashboardzone.com/wp-content/uploads/2008/07/image-
143.jpg
Cuando existan niveles no apropiados de operación que no permitan cumplir con
los niveles acordados, es necesaria la entrega de reportes que expliquen las
causas y las acciones correctivas que se tomaron para recuperar la operación
normal. Además es necesario obtener reportes de los OLAs y de los
proveedores externos relacionados con el no cumplimiento o degradación del
servicio con ANS aprobado.
Los reportes deben contener información precisa de los procesos de soporte y
reflejar de forma exacta la calidad de servicio que se entrega y que el cliente
pueda percibir esta calidad, aunque para ello se tenga de invertir gran cantidad
de tiempo y recursos.
Es recomendable la utilización de aplicativos para producir los reportes de forma
automática y mantener información histórica del rendimiento y acciones de
mejora.
94
3.1.9 La revisión del servicio y plan de mejora
Se deben establecer reuniones periódicas con los clientes o sus representantes
para revisar los resultados alcanzados en el periodo precedente y para definir
acciones para el siguiente periodo. Se deben revisar aquellas áreas que no
permiten cumplir con los objetivos, establecer las acciones a tomar y
documentarlas, para revisar su implementación y avance en la siguiente reunión.
Si algún servicio no cumple el ANS de forma recurrente, se debe determinar su
causa exacta y definir si se podrá cumplir con el ANS para establecer una
renegociación de los acuerdos de servicio. Se debe revisar si el incumplimiento
es causado por los grupos de soporte interno o proveedores externos para
también revisar estos acuerdos.
Analizar el costo y el impacto de estos incumplimientos de servicio proveerá el
soporte para la generación del Plan de Mejora de Servicios ( SIP Service
Improvement Plan), se debe reportar el número de acciones del plan ejecutadas
con los beneficios obtenidos.
3.1.10 El desarrollo de relaciones y contactos
Es importante el mantenimiento de relaciones de respeto y confianza con los
contactos clave de negocio. A través del catálogo de servicios de negocio, la
SLM puede entender la relación entre los servicios y las unidades de negocio y
los procesos de negocios que dependen de estos servicios, además de su
utilización e importancia. Para asegurar que las relaciones de establezcan de
una manera consistente se podrían ejecutar las siguientes actividades:
95
 Confirmar los auspiciantes, clientes, administradores claves de negocio y
usuarios del servicio.
 Ser flexible y sensible a las necesidades de negocio, clientes y usuarios,
comprender sus necesidades y requerimientos actuales y futuros y
comunicar estos requerimientos o cambios a los otros procesos de
servicios.
 Asegurar una comprensión completa de la estrategia, planes y objetivos de
negocio para asegurar que TI está trabajando en asociación con el negocio
y clientes para desarrollar una relación de largo plazo.
 Obtener la opinión del cliente en forma periódica y una realimentación de la
experiencia del servicio de TI.
 Realizar y completar las encuestas del cliente, realizar los análisis
respectivos y asegurar que las acciones que se necesiten son ejecutadas
para obtener los resultados.
 Trabajar con el negocio, clientes y usuarios para asegurar que TI entrega
los niveles de servicio apropiados para satisfacer las necesidades de
negocio.
 Dar a conocer los beneficios para el negocio de la utilización de nueva
tecnología.
 Facilitar el desarrollo y la negociación de ANSy SLRs apropiados, realistas
y alcanzables entre el negocio y servicio de TI.
3.1.11 La Administración de reclamos y elogios
Se debe incluir actividades y procedimientos para el ingreso y administración de
96
los reclamos y felicitaciones, su registro en la mesa de ayuda es similar a los
incidentes, la definición de reclamos, puntos de contacto y procedimiento de
análisis y administración debe ser acordado con los clientes.
Todo reclamo debe ser procesado y resuelto a satisfacción del cliente en un
tiempo acordado, caso contrario se debe establecer el esquema de
escalamiento, y de ser necesario escalar hasta el administrador principal.
Los reportes deben incluir el número y tipos de reclamo así como las acciones
registradas.
3.2 Definición de documentos para establecer un ANS
Los documentos necesarios para establecer un ANS, varían de acuerdo con el
modelo de acuerdo que se vaya a desarrollar, también se debe considerar la
plataforma tecnológica que utiliza el servicio que se ofrece a los clientes internos
o externos y los grupos de personas que están dando soporte.
Puesto que un ANS está ligado a otros elementos de gestión de TI, un enfoque
integrado con otros procesos es necesario para alcanzar los objetivos y lograr
los beneficios previstos de mejora en la calidad y tiempo de entrega de
servicios.
3.2.1 Catálogo de servicios
Se debe mantener un catálogo de servicios actualizado, como documento que
permita mantener la información de:
97
 Los clientes, su localización, compañías, departamentos, contactos.
 Los servicios que se proveen a cada uno de ellos.
 Los ANS firmados.
 Información de costos y beneficios del cliente y su estatus.
Un buen catálogo de servicios, es una herramienta valiosa para el personal de
apoyo y gestión ya que permite disponer de información de los clientes, servicios
y costos en un solo lugar.
3.2.2 Acuerdos de Nivel Operacional OLAs
Se los puede considerar como ANS internos de TI con menor formalidad, es
importante que los grupos de apoyo que están junto al servicio principal estén
conscientes y se comprometan a cumplir con los ANS.
Un OLA puede ser un documento que se tome como un término de referencia
relacionado con los ANS que da soporte y que ayuda a que el grupo de soporte
cumpla con los términos de escalamiento, objetivos, plazos de entrega y tiempo
de respuesta acordados.
Los OLA también deben establecerse con otros procesos administrativos y de
negocio que conforman la cadena de suministros, por ejemplo adquisiciones
emergentes de equipos.
98
Es importante que los OLAs y ANS sean integrados a las herramientas de
administración de servicios y que se relacionen con la administración de
incidentes, cambios y problemas.
3.2.3 Administración de incidentes, problemas y cambios
Estos procesos son fundamentales para el éxito de los ANSs, ya que asegura el
buen funcionamiento del soporte de segundo nivel, por tanto se debe garantizar
la documentación mínima necesaria para estos procesos.
 Documentación para que los incidentes sean manejados de forma eficiente
y el cliente este operativo lo más pronto posible, incluyendo el
escalamiento y respuesta de los grupos de apoyo de segundo nivel.
 Tener documentado el esquema de atención y solución de problemas de
tal forma que el centro de servicios y soporte de segundo nivel pueda
hacer uso de los documentos para una atención rápida del cliente.
 Tener por escrito la forma en que se implementará de manera segura los
cambios y arreglos menores solicitados.
3.2.4 Proveedores externos
Cuando el servicio requiere de proveedores externos, a estos se los debe
considerar como parte de la cadena de suministros por tanto cada uno de ellos
debe tener un contrato y la documentación de los contratos actualizado.
99
3.3 Definición de roles y responsabilidades
Para que un ANS sea exitoso, es fundamental que se definan los roles y
responsabilidades para las actividades clave a ejecutarse dentro del proceso de
generación y mantenimiento de los acuerdos, cuando los roles están bien
definidos, las organizaciones pueden tomar decisiones acertadas y ejecutarlas
de forma efectiva ya que está claro quién puede generar requerimientos, quien
debe tomar la decisión de ejecutarlos y quien los pone en producción, lo cual les
puede dar una ventaja competitiva en su negocio.
3.3.1 modelo RACI
Para la asignación de responsabilidades en cada una de las actividades se ha
desarrollado un modelo denominado RACI por sus iniciales de los cuatro
principales roles en inglés:
Responsible.- Quien es responsable de la realización del trabajo
Accountable.- Cada persona quien rinde cuentas por su actividad
Consulted.- Personas cuyas opiniones se buscan
Informed.- Personas que conocen el estado actual de las actividades
Ocasionalmente se añaden dos roles adicionales de verificación y aprobación
por lo que el modelo cambia a RACI-VS
Verifies.- Persona o grupo que verifica que se cumple con los criterios de
aceptación
Signsoff .- Persona que aprueba la verificación y autoriza la entrega del producto
100
La estructura del modelo se compone de una matriz en la cual en el lado
izquierdo se detallan las actividades necesarias de realizar y las decisiones a
tomar, mientras que en la parte superior se listan los roles funcionales de
quienes deben ejecutar o tomar decisiones y quienes deben tener conocimiento
de las actividades.
Tabla 3.1 Matriz RACI de un proceso

Fuente:http://www.isaca.org/Knowledge-Center/ cobit/Documents/cobiT4.1spanish.pdf.
Dueño Director Administrador Administrador Administrador

de de TI de ANS de problemas de catalogo
proceso
Actividad 1 A R C I I
Actividad 2 AR C I C C
Actividad 3 I C R C C
Actividad 4 I R R I I
Actividad 5 I I A R I
Para construir la matriz se deben considerar las siguientes recomendaciones:
 Identificar las actividades y procesos.
 Identificar los roles funcionales.
 Establecer reuniones y asignar roles.
 Identificar donde se sobreponen o no existen responsabilidades.
 Distribuir la matriz a los participantes.
 Asegurar que las asignaciones están cumpliéndose.
Se debe realizar un análisis de las actividades y los roles para verificar que en la
matriz RACI se establezca que:
 Existe al menos un A para cada actividad, y procurar que no existan varias
A por actividad ya que puede causar retraso en la toma de decisiones.
 Existe al menos un R en las actividades, cuando existen varios R y la
101
responsabilidad es compartida, cada rol debe conocer claramente su
responsabilidad, caso contrario nadie se hace responsable.
 Varias C en cada actividad, se debe justificar los beneficios y tiempo que
implica obtener la opinión de varios roles.
 Si no existen I y C verificar que los canales de comunicación están abiertos
para mantenerse informado y actualizado con las actividades que ejecuta
cada departamento.
3.3.2 Atributos y competencias de los roles
Para un trabajo eficiente, la persona que ejerce cada rol debe cumplir con
algunas competencias y atributos asociados a la administración del proceso,
como las siguientes:
 Determinar los objetivos y prioridades del negocio.
 Conocer a fondo el papel que TI tiene en el soporte a los objetivos del
negocio.
 Poseer habilidades para atención al cliente.
 Tener conciencia de las capacidades que tiene TI para el negocio.
 Habilidad y conocimiento para implementar las mejores prácticas en su
rol.
Algunos de los atributos generales a todos los roles deben ser:
 Habilidad para comunicarse con todos los niveles sobre el proceso y la
relación con los otros roles.
 Habilidad administrativa para controlar el proceso y personas.
 Habilidad para organizar y asegurar que las actividades serán realizadas.
 Habilidad escrita y verbal para generar reportes.
102
 Habilidad para negociar con los proveedores, clientes y patrocinadores.
 Habilidad para analizar resultados.
3.3.3 Roles y responsabilidades asociadas
Dependiendo del tamaño de la organización, algunos roles son ejecutados por
una persona asignada a cada rol, mientras que en otras puede ser que varios
roles sean ejecutados por la misma persona. Entre los principales roles que
deben existir para generar un ANS están:
3.3.3.1 Propietario del proceso
Es responsable de verificar que el proceso se ejecute de acuerdo con la
documentación del proceso y cumplimiento de los objetivos, para lo cual debería
ejecutar las siguientes tareas:
 Definir los indicadores clave de rendimiento y evaluar la eficiencia del
proceso de acuerdo con el cumplimiento de los ANS.
 Revisar y proponer mejoras al proceso.
 Asegurar que todos los involucrados tengan la suficiente preparación para
las actividades del proceso.
 Verificar que las responsabilidades y cumplimientos regulatorios se
ejecutan.
3.3.3.2 Planificador de TI
Es responsable de la creación y coordinación de los planes de TI, sus objetivos
principales son:
103
 Desarrollar los planes de TI que cumplan con los requerimientos de
negocio.
 Coordinar, revisar y medir el progreso de la implementación de los planes y
estrategias de TI.
 Participación en la creación de los ANS .
 Planificación de la infraestructura pública y privada, externa e interna,
internet o intranet que asegure la provisión de los servicios de negocio.
 Implementar políticas y estrategias para los nuevos proyectos o
aplicaciones estratégicas.
 Recomendar políticas para el uso efectivo de TI en la organización.
 Revisar los costos y presupuestos en conjunto con la administración
Financiera.
 Evaluar nuevas propuestas de tecnología, hardware y software para
asegurar los requerimientos de negocio.
 Revisar el rendimiento y mejoras propuestas en todas las áreas de TI para
asegurar que todos los ANS y metas se cumplan.
 Decidir la calendarización y priorización de los nuevos proyectos o cambios
grandes en los procesos.
 Identificar los aplicativos y servicios con sus ambientes de trabajo para
cumplir con las necesidades de negocio.
 Determinar oportunidades de mejoramiento a través del uso de nueva
tecnología.
 Producir modelos de servicios de TI y de negocio para identificar al
impacto y riesgo.
 Identificar y resolver conflictos asociados a TI.
104
 Asegurar que los planes, roles, responsabilidades están documentados,
actualizados y auditados.
 Mantener un conocimiento general de las capacidades de los productos de
TI .
3.3.3.3 Administrador de Catálogo de servicios
Es responsable por la producción y mantenimiento del Catálogo de servicios
para lo cual debe:
 Asegurar que todos los servicios en operación, y aquellos que están en
desarrollo se encuentran listados dentro del catálogo.
 Asegurar que la información que contiene el catálogo de servicios es
exacta y se encuentre actualizada, está protegida y respaldada.
 Asegurar que la información del catálogo está sincronizada con el
portafolio de servicios.
3.3.3.4 Administrador de Niveles de servicios
Es responsable de asegurar que los objetivos de la administración de niveles de
servicio se cumplan a través de las siguientes responsabilidades:
 Mantenerse actualizado con los cambios de las necesidades del negocio.
 Asegurar que los requerimientos actuales y futuros de los clientes están
identificados y documentados en los ANS.
 Negociar y acordar niveles de servicios a ser entregados con los clientes
con su respectiva documentación formal.
 Negociar y acordar niveles de operación OLA con los grupos que dan
apoyo al servicio.
105
 Asegurar que los reportes de servicio son generados y entregados al
cliente y de existir incumplimientos estos son investigados y se toman
acciones para evitar recurrencia.
 Asegurar que se revisa regularmente con el cliente el cumplimiento del
ANS y existen un seguimiento a las iniciativas propuestas en las reuniones
 Revisar al menos una vez por año, los ANS, OLA y otros documentos de
apoyo .
 Asegurar que todos los cambios son evaluados para medir el impacto
sobre los ANS.
 Mantener la relación y comunicación con los patrocinadores, cliente y
usuarios.
 Definir el proceso de escalamiento para el seguimiento de ANS no
cumplidos.
 Medir, registrar, analizar y mejorar la satisfacción del cliente.
3.3.3.5 Administrador de disponibilidad
Es responsable de asegurar que las metas de disponibilidad se cumplen, para lo
cual debe:
 Asegurar que todos los servicios existentes, entregan los niveles de
disponibilidad acordados en los ANS.
 Asegurar que los nuevos servicios cumplen con el nivel de disponibilidad
que requiere el negocio.
 Apoyar en la investigación y diagnóstico de los incidentes y problemas que
causan la indisponibilidad de componentes y servicios.
 Participar en el diseño de la infraestructura de TI, definiendo los
requerimientos de disponibilidad de hardware y software.
106
 Definir los requerimientos de nuevos sistemas de monitoreo automáticos
de disponibilidad de los componentes de TI.
 Responsable del monitoreo de disponibilidad y comparación con los ANS.
 Mejoramiento proactivo de la disponibilidad de la infraestructura de TI con
un costo justificado que demuestre beneficios para el negocio.
 Asegurar que el proceso de gestión de disponibilidad está asociado a
métodos y técnicas que son revisados y auditados continuamente para la
mejora continua.
 Asegurar que los planes y pruebas de disponibilidad son probados
después de un cambio mayor en el negocio.
3.3.3.6 Administrador de capacidad
Es responsable de cumplir las metas del proceso de administración de
capacidad y tiene entre otras las tareas de:
 Asegurar que existe la capacidad de TI adecuada para cumplir con los
ANS .
 Verificar que la capacidad está de acuerdo con la demanda para asegurar
que la capacidad existente está optimizada.
 Identificar el nivel de utilización de la capacidad actual y nivel máximo que
se puede alcanzar en cada componente.
 Medir la capacidad requerida por los nuevos servicios y sistemas y realizar
un pronóstico de la capacidad requerida a futuro.
 Asegurar que existen niveles apropiados de monitoreo y rendimiento y se
comparan con las metas contenidas en los ANS.
 Identificar e iniciar un afinamiento para optimizar y mejorar la capacidad o
107
rendimiento.
 Evaluar nuevas tecnologías y su impacto en términos de rendimiento y
costo en la organización.
 Evaluar nuevas técnicas y productos de hardware y software que puedan
mejorar la eficiencia del proceso de administración de capacidad.
 Reportar el rendimiento de la capacidad de los componentes y comparar
con las metas definidas en los ANS.
 Determinar los niveles de rendimiento que se pueden mantener con un
costo justificable.
3.3.3.7 Administrador de proveedores
Es responsable de asegurar que los objetivos de la administración de
proveedores se cumplan a través de las siguientes responsabilidades:
 Dar soporte en el desarrollo y revisión de los términos de referencia y
contratos para los proveedores.
 Asegurar que los proveedores de TI cumplen con los términos y
condiciones, las estrategias, procesos y estándares de la organización.
 Asegurar que todos los proveedores entregan un valor agregado al
negocio.
 Asegurar que la base de datos de proveedores es exacta y se encuentre
actualizada, protegida y respaldada.
 Realizar un análisis de riesgo de los contratos y proveedores.
 Revisar los contratos y ANS al menos una vez por año para asegurar que
aun cumplen los requerimientos de la organización.
108
 Asegurar que la información de todos los servicios de soporte de terceros y
la interrelación entre proveedores está actualizada y documentada.
 Actualizar contratos y ANS cuando sea requerido siguiendo el proceso
respectivo.
 Mantener un proceso para seguimiento de disputas contractuales que
asegure que sean tratadas de manera eficiente.
 Monitoreo y reporte de cumplimiento de los ANS, seguimiento de acciones
de mejora.
 Verificar que cada contrato tiene asignado un coordinador por parte del
proveedor.
 Asegurar que los cambios en los servicios de negocio y TI han evaluado el
impacto en los contratos y servicios provistos por proveedores externos.
3.4 Esquema de administración de los ANS
Los ANS aprobados deben administrarse de tal forma que aseguren que son
documentos vivos que son consultados frecuentemente, están en proceso
continuo de mejoramiento y agregan valor a la organización.
3.4.1 Realizar reuniones mensuales con los clientes
Estas reuniones permiten identificar de manera oportuna los cambios o nuevos
equipos en el ambiente de servicio que afecten a un ANS, por tanto estos
parámetros pueden requerir de un adendum al contrato inicial, lo cual puede ser
añadido sin afectar al acuerdo aprobado.
109
3.4.2 Análisis proactivo de las interrupciones del servicio
Permiten analizar las interrupciones del servicio e identificar sus causas, si estas
afectan al ANS puede ser necesario ajustes a los criterios de medición y
capacitación a las áreas que han generado mayor número de incidentes.
3.4.3 Renegociar y ajustar los ANS de acuerdo a los cambios de negocio
Del análisis mensual del servicio e interrupciones puede llegar a determinarse
que es necesario renegociar los ANS y ajustar los reportes para que reflejen los
cambios en las iniciativas, productos y servicio de negocio.
3.4.4 Revisar y actualizar los ANS cada año
En caso de no existir novedades durante un año es igualmente necesario revisar
los ANSs y establecer pruebas de bajo impacto que mejoren nuestra imagen con
el cliente.
110
CAPÍTULO 4: IMPLANTACIÓN DE LA GUÍA METODOLÓGICA A UN
SERVICIO WEB EN UNA IFSP
Para la implantación de la presente guía metodológica a un servicio en una
Institución Financiera del Sector Público se ha revisado los servicios con
arquitectura WEB que cada Institución ofrece y se ha determinado que el
servicio del Portal de Servicios Electrónicos del Banco Central del Ecuador es un
servicio de alto impacto y criticidad que requiere de la generación de Acuerdos
de Niveles de Servicio que siga los estándares de la metodología ITIL versión 3.
El Banco Central del Ecuador de acuerdo con la Ley de Régimen Monetario y
Banco del Estado es el depositario de los fondos públicos y el encaje bancario
por tanto es el agente financiero y fiduciario del Estado y responsable de la
administración de las cuentas corrientes que poseen todas las instituciones
financieras y no financieras, públicas y privadas, por tanto debe brindar las
facilidades adecuadas para la ejecución correcta, oportuna y segura de las
transacciones que se ordenen sobre dichas cuentas.20
El Portal de Servicios Electrónicos ofrece servicios de arquitectura Web para el
acceso de los agentes financieros y no financieros, públicos y privados través
de la red de Internet o de una red privada de comunicaciones del Sistema
Nacional de Pagos SNP administrada por el Banco Central para instrumentar
servicios financieros en línea que apoyen la inclusión financiera y la eficiencia
del sector público en la prestación de servicios.
20
http://www.bce.fin.ec/documentos/ServiciosBCentral/SistemaPagos/LibroAmarilloSistemadePag
os.pdf
111
Para entregar servicios con calidad se requiere el seguimiento de normas y
estándares internacionales ya probados como ITIL V3 que establecen las
mejores prácticas para alcanzar la excelencia en el servicio. Como parte de este
proceso de mejora, la generación de Acuerdos de Niveles de Servicio ANS
permite establecer una relación de confianza, con reglas claras con todos los
partícipes del sistema como muestra la figura 4.1
Figura 4.1 Partícipes del portal de Servicios Electrónicos

Fuente:http://www.bce.fin.ec/documentos/ServiciosBCentral/SistemaPagos/LibroAmarillo
SistemadePagos.pdf
Los mecanismos de pagos se basan en un proceso de compensación o neteo de
órdenes de pago interbancario e interinstitucional, transmitidas a través de
medios electrónicos al Banco Central del Ecuador por las instituciones
participantes.
112
De acuerdo con la guía metodológica, para este caso se define como un
Acuerdo de Nivel de Servicio Basado en Servicio y los participantes son, el
Banco Central del Ecuador como proveedor del servicio y las instituciones del
sector público y privado que realizan transacciones en el Portal de Servicios
Electrónicos como clientes.
4.1 Definición de un servicio para establecer un ANS
El Portal de Servicios Electrónicos es un servicio que está compuesto por varios
módulos donde cada uno de ellos es activado de acuerdo el perfil del cliente que
solicita los servicios y de acuerdo con las actividades que desarrolla cada uno de
los clientes.
Los módulos que componen el Portal de Servicios Electrónicos al momento son:
 ACH Cámaras de Compensación
 SSP Sistema de Pagos del Sector público
 OCP Órdenes de cobro público
 OPE Órdenes de pago del exterior
 SCI Sistema de cobro Interbancario
 SEI Sistema electrónico de intercambio de cheques
 SPI Sistema de pago Interbancario
 SPL Sistema de Pagos en Línea
 TPL Transferencias de pago en línea
4.1.1 Componentes tecnológicos del servicio
El Portal de Servicios Electrónicos está clasificado como un servicio de alta
113
prioridad y criticidad dentro del portafolio de servicios de negocio que ofrece el
BCE a los clientes del sector público y privado por tanto los componentes
tecnológicos están configurados para ofrecer la mayor disponibilidad y
rendimiento, que se complementan con esquemas de seguridad necesarios para
la operación de este tipo de servicios.
Como principio fundamental de disponibilidad el BCE ha definido la instalación y
configuración de dos o más dispositivos en cada una de las capas que
intervienen en el sistema, en el modelo de alta disponibilidad con operación de
los dispositivos en modo ACTIVO- ACTIVO o en modo ACTIVO-STAND BY
dependiendo de la capacidad de configuración de los dispositivos.
Este tipo de configuración permite eliminar puntos únicos de falla e incrementar
el tiempo de operación del servicio ya que de acuerdo con la definición de
confiabilidad de equipos en serie o capas, el sistema total funciona con: el
porcentaje de funcionamiento del eslabón más débil o por la ley del producto,
que es resultado de multiplicar cada uno de porcentajes de confiabilidad de los
componentes individuales Ejem:
Si A=99% , B=98%, C=99%
SISTEMA= 98% ESLABÓN MÁS DEBIL
SISTEMA= 96% LEY DEL PRODUCTO
114
Figura 4.2 Dispositivos de hardware Portal de Servicios Electrónicos
Elaborado por: Edison Rubén Nicolalde
Para los dispositivos configurados en paralelo la confiabilidad del sistema se
calcula considerando la indisponibilidad de cada componente, multiplicando la
indisponibilidad de todos los componentes y este producto restado de uno.21
Confiabilidad = 1 – ( (1-%A)*( 1-%B)* (1-%C))
21
http://www.monografias.com/trabajos62/estadistica-aplicada-mantenimiento/estadistica-
aplicada-mantenimiento2.shtml
115
Si A=99% , B=98%, C=99%
SISTEMA= 1- ((1-0,99)* (1-0,98)* (1-0,99)) = 99,999%
El BCE con el objetivo de alcanzar los más altos niveles de disponibilidad de los
servicios se encuentra en fase de configuración para implementar el concepto de
alta disponibilidad entre los data center de Quito y Guayaquil con lo cual, el
esquema de servicio quedaría configurado como lo muestra la figura 4.3
116
Figura 4.3 Configuración Alta Disponibilidad Geográfica
Como se puede visualizar en los diagramas de las figuras 4.2 y 4.3 el servicio
utiliza varios dispositivos de procesamiento, de comunicaciones, de seguridad y
servicios de proveedores de enlaces de terceros.
4.1.2 Grupos de soporte del servicio
El servicio del Portal de Servicios Electrónicos se apoya en varios procesos de
TI, los mismos que de acuerdo a la estructura organizacional interna de la
Dirección de Informática del BCE, y al esquema de operación actual, estos
117
procesos de TI son responsables de varios procesos de control descritos en el
capítulo 2 que apoyan la generación de ANS , así tenemos que las
responsabilidades de control de actividades de los procesos, son ejecutados por
las unidades organizacionales de acuerdo con la siguiente distribución:
Tabla 4.1 Matriz de distribución de procesos por unidad organizacional

Unidad Organizacional Control de proceso
Servicios Informáticos Administrar mesa de servicio y los incidentes.

Administración del control de problemas
Gestión y Control de Definir y administrar niveles de servicio
Calidad Garantizar la continuidad del servicio de TI
Infraestructura Administrar el desempeño y la capacidad
Tecnológica y Base de Administrar la configuración
Datos
Dirección de Informática Administrar servicios de terceros
Seguridades Garantizar la seguridad de la información
Informáticas
Algunos módulos del servicio, se encuentran disponibles las 24 horas del día, ya
que algunas de las instituciones clientes realizan procesos automáticos de
consulta, transferencia y procesamiento de archivos durante las 24 horas.
La mesa de servicio y atención de incidentes tiene un horario de atención
definido entre las 8h30 y las 18h00, la atención de incidentes y requerimientos
se los recepta en la ciudad de Quito. Los incidentes fuera de este horario son
atendidos por personal de operación del data center, quienes a su vez escalan a
los ingenieros de soporte, en base al cronograma de atención semanal de
soporte que entrega cada unidad organizacional a la Dirección de Informática y a
la criticidad de operación de los módulos que componen el servicio.
118
El cliente que genera un incidente debe informar o especificar:
 Su nombre
 La institución pública o privada y su localidad
 El módulo de servicio que utiliza
 Determinar si su acceso es por Internet o red privada (el cliente de internet
utiliza un link en el servidor Web www.bce.fin.ec, el cliente de red privada
utiliza el acceso al servidor www4.bce.fin.ec, este servidor tiene una
dirección IP privada que el cliente de forma manual debe traducir con el
nombre.)
 Si utiliza el acceso al servidor www4.bce.fin.ec, el cliente debe informar el
proveedor de comunicaciones que utiliza para el enlace.
4.2 Generación de documentos para establecer un ANS
Los documentos de soporte necesarios para una óptima operación del Portal de
Servicios Electrónicos y para la generación de ANS son los siguientes:
4.2.1 Catalogo de clientes y módulos asociados
Para la utilización de los servicios del Portal, los clientes deben seguir los
procedimientos definidos por la Dirección de Servicios Bancarios Nacionales,
quienes administran el servicio de negocio y generan los requerimientos de
seguridades de acceso y conectividad hacia la Dirección de Informática.
El cliente de acuerdo con el número de transacciones que realiza, puede optar
entre el servicio a través de internet que a su vez requiere una tarjeta de
119
coordenadas para la realización de operaciones o el servicio a través de la red
privada, para este caso debe contratar un enlace punto a punto entre el BCE y la
institución solicitante y solicitar un Token para establecer una conexión segura.
De acuerdo con el control de clientes que lo realiza el proceso de negocio y los
procesos de seguridad y conectividad que lo gestiona la Dirección de Informática
se tiene los siguientes tipos de clientes:
Tabla 4.2 Matriz de control de clientes

Instituciones Acceso Acceso red Servicios

Internet privada
Financieras
privadas
Financieras
públicas
Municipios
Cooperativas
En la actualidad no se tienen firmados ANS con ninguno de los clientes externos
o internos de este servicio.
4.2.2 Acuerdos de nivel de operación OLA
De acuerdo con la recomendación de ITIL V3 los acuerdos de nivel de operación
deben establecerse con todos los grupos de apoyo que están en capacidad de
dar soporte al Portal de Servicios Electrónicos, para este caso específico los
grupos relevantes son:
120
Servicios Informáticos, que administra los incidentes, requerimientos y
problemas.
Servicios Informáticos, cuenta con el software de gestión Service Desk
desarrollado por la empresa CA (Computer Associates) el cual se encuentra
configurado para llevar el registro, control, escalamiento y cierre de los
incidentes, requerimientos y problemas, cuenta con una base de conocimiento
que no está actualizada, se mantiene procedimientos de configuración estándar
de los equipos de escritorio, funciona de forma autónoma sin integrarse con las
herramientas de monitoreo que las administra el proceso de Infraestructura.
Para el soporte de los incidentes generados por el Portal de Servicios
Electrónicos, se ha desarrollado una guía, que permite a la mesa de ayuda la
revisión de la actividad de los componentes del sistema y su interrelación entre
los distintos dispositivos con la finalidad de que pueda determinar de forma
específica la capa de operación donde podría estar la falla en caso de caída del
servicio y de esta manera escalar a los técnicos apropiados.
Se ha desarrollado un acuerdo de nivel de operación que se encuentra en el
anexo 1.
Infraestructura tecnológica y base de datos, que administra el desempeño, la
capacidad y la configuración.
Infraestructura tecnológica, cuenta con algunas aplicaciones y procedimientos de
gestión y monitoreo orientado al control de equipos específicos, como son:
 Los servidores y sistema operativo.
121
 Software de bases de datos y componentes.
 los equipos de conectividad switchs, ruteadores y balanceadores.
 Equipos de seguridad, IPS, firewalls.
Cada uno controlando sus equipos específicos sin integrarse con el resto y sin
generar estados de alerta o error automáticos hacia la mesa de ayuda para su
registro y seguimiento de los mismos.
La gestión de configuración se realiza de manera aislada, donde los
especialistas de cada conjunto de dispositivos llevan el control de configuración
de los equipos, existe un esquema centralizado de gestión inicial y están
definiendo los indicadores clave de rendimiento.
Con los antecedentes mencionados se desarrolla un acuerdo inicial de operación
OLA para los procesos que administra esta unidad organizacional Anexo 2.
Los acuerdos de nivel de operación deben son difundidos a los integrantes de
los equipos de apoyo de cada unidad organizacional y a todos los integrantes de
la Dirección de Informática
4.3 Generación de roles y responsabilidades
El Portal de Servicios Electrónicos es un servicio que demanda de varias
actividades clave que están relacionadas con el negocio y con la tecnología, por
tanto es necesario definir los roles y responsabilidades que permitan generar la
matriz RACI para la operación eficiente del servicio lo que su vez permite
122
verificar que TI está alineado con el negocio. Considerando la estructura
organizacional del Banco Central del Ecuador, el servicio de negocio está
administrado por la Dirección de Servicios Bancarios Nacionales y el servicio de
Tecnología es administrado por la Dirección de Informática, por lo que se
definen los roles siguientes:
 Director de Servicios Bancarios Nacionales.
 Administrador del servicio de negocio asociado al Portal.
 Director de Informática.
 Responsable de Servicios Informáticos.
 Responsable de Gestión y Control de Calidad.
 Responsable de Infraestructura Tecnológica y Base de Datos.
 Responsable de Seguridades Informáticas.
 Responsable de Desarrollo de Sistemas.
Las actividades clave necesarias para el correcto funcionamiento del Portal de
Servicios Electrónicos se definen como las siguientes:
 Definir los indicadores clave de rendimiento del Portal del Servicios.
 Asegurar que el proceso de negocio se encuentre optimizado.
 Asegurar que los clientes están plenamente identificados.
 Verificar que los componentes de tecnología se encuentren con la
disponibilidad capacidad y rendimiento adecuados a la demanda actual,
para su utilización óptima.
 Generar un catálogo de módulos y mantenerlo actualizado.
 Verificar que los Acuerdos de Niveles de Operación se cumplan.
123
 Generar reportes automáticos de disponibilidad en base a los aplicativos
de monitoreo de cada capa y comparar con los ANS.
 Proponer nuevas herramientas de integración de los gestores de
administración de las distintas capas de operación.
 Asegurar que todos los componentes se encuentren con contratos de
servicios y ANS definidos con los proveedores.
 Verificar que los canales de comunicación se encuentren con la
disponibilidad contratada.
 Asegurar que todos los integrantes de la mesa de ayuda tengan la
suficiente preparación y conocimiento del servicio.
4.3.1 Matriz RACI
Tabla 4.3 Matriz RACI para servicio del Portal

Roles/Actividades Director Responsable Director de Responsables

DSBN del Portal DI Subprocesos
Definir KPI del
Portal
Asegurar
identificación de
clientes
………..
Asegurar que la
mesa de ayuda
tenga suficiente
conocimiento del
servicio
4.4 Relación con terceros
124
De acuerdo con el diseño y operación de la infraestructura tecnológica utilizada
para proveer el servicio del Portal, existen servicios básicos que se deben
contratar con proveedores externos para garantizar el óptimo funcionamiento.
Enlaces de datos, como ya se mencionó anteriormente, existen dos tipos de
enlaces para la publicación del Portal, el enlace de datos hacia internet, donde el
BCE mantiene un contrato de prestación del servicio con los proveedores CNT y
TELCONET, configurando alta disponibilidad entre los dos proveedores, y
estableciendo ANS que para el caso de CNT está en el 99.8 de disponibilidad
mensual y de 99.9 para el contrato de TELCONET, por lo tanto de acuerdo con
el literal 4.1.4 el nivel de disponibilidad conjunto sería de
Disponibilidad = 1- ((1-0,999)*(1-0.998))
Disponibilidad de conexión por internet = 99.99 %
Para los enlaces de conexión directa punto a punto por la red privada del
Sistema Nacional de Pagos, los enlaces son contratados y administrados por
cada uno de los clientes del servicio quienes establecen el grado de
disponibilidad de los mismos en base al número de operaciones y a la criticidad
de este servicio, configurando el algunos casos alta disponibilidad a través de
conexión por dos proveedores.
Contrato de Soporte de terceros, de acuerdo con el esquema de conectividad
asociado al servicio, este utiliza componentes comunes a otros servicios, por
tanto los contratos de mantenimiento, soporte técnico y actualización de
versiones para cada una de las capas deben estar actualizados y tener un ANS
125
con la empresa que provee el servicio. Así al momento se tiene los siguientes
contratos:
Tabla 4.4 Matriz Nivel de Servicio de los Proveedores

Componente Empresa Soporte Nivel de servicio

Servidores: hardware y COMWARE S.A 7X24X365
sistema operativo
Bases de datos y COMWARE S.A 7X24X365
componentes Sybase
Equipos de red: switchs COMWARE S.A 7X24X365
LAN y SAN, routers ADEXUS S.A.
Dispositivos de seguridad: EBTEL CIA. LTDA. 7X24X365
IPS y firewall LATINUS
Balanceadores de carga: COMPUEQUIP 7X24X365
para data center y para
servidores
4.5 Generación de un ANS para un aplicativo de arquitectura Web en una

IFSP
A continuación se detalla un Acuerdo de Nivel de Servicio para el Portal de
Servicios Electrónicos del Banco Central del Ecuador
126
ACUERDO DE NIVEL DE SERVICIO
Este Acuerdo de Nivel de Servicio establece un compromiso entre los clientes y
la Dirección de Informática (DI) para el soporte técnico del Portal de Servicios
Electrónicos. Este documento y anexos determinan las responsabilidades y
procedimientos de cada una de las partes para asegurar que las necesidades
de los clientes son satisfechas de manera oportuna.22
Este acuerdo contiene las siguientes secciones:
Sección I: Descripción del servicio
Sección II: Requerimientos del servicio
Sección III: Servicios soportados
Sección IV: Costos
Sección V: Mantenimiento del Acuerdo
Sección VI: Responsabilidades de la Dirección de Informática
Sección VI: Responsabilidades de los clientes
Sección VII: Procedimiento para control de cambios
Sección VIII: Historial de versiones y firmas
SECCION I: DESCRIPCION DEL SERVICIO
El Portal de Servicios Electrónicos ofrece servicios de arquitectura Web para el
acceso de los agentes financieros y no financieros, públicos y privados través de
la red de Internet o de la red privada de comunicaciones del Sistema Nacional de
Pagos (SNP) administrada por el Banco Central del Ecuador para instrumentar
22
http://oit.duke.edu/search.php?q=sla+example
127
servicios financieros en línea que apoyen la inclusión financiera y la eficiencia del
sector público y privado en la prestación de servicios.
SECCIÓN II: REQUIRIMIENTOS DEL SERVICIO
FECHA INICIO: ________________________
FECHA EXPIRACION: ______________________
Este acuerdo es válido a partir de la fecha de la firma de las partes y permanece
en efecto durante todo el tiempo de vida de los servicios y / o aplicaciones
compatibles con el Portal de Servicios Electrónicos.
ACUERDO NÚMERO: 1
LOCALIZACIÓN: Casa Matriz
PROYECTO: Reingeniería del Sistema Nacional de Pagos
Los módulos que componen el Portal de Servicios Electrónicos al momento son:
 ACH Cámaras de Compensación
 SSP Sistema de Pagos del Sector público
 OCP Órdenes de cobro público
 OPE Órdenes de pago del exterior
 SCI Sistema de cobro Interbancario
 SEI Sistema electrónico de intercambio de cheques
 SPI Sistema de pago Interbancario
 SPL Sistema de Pagos en Línea
 TPL Transferencias de pago en línea
Tiempo de respuesta del servicio y soporte:
El tiempo de respuesta de los servidores de control de acceso (muestra de la
pantalla de ingreso de usuario y clave) es de 1 seg para los usuarios
128
internos y entre 3 y 10 seg para los usuarios que acceden por internet
(depende de la calidad de servicio de internet que posee el cliente).
El tiempo de respuesta de los servidores de procesamiento (desde el ingreso
de datos de operación y coordenadas hasta resultado de operación con
éxito) es de 10 seg para los usuarios internos y entre 30 y 90 seg para los
usuarios que acceden por internet (depende de la calidad de servicio de
internet que posee el cliente).
La Dirección de Informática a través del subproceso de Servicios
Informáticos responderá a los incidentes registrados por los clientes internos
y externos del Portal de Servicios Electrónicos desde las 8:30 AM a 18:00
PM de Lunes a Viernes (excepto días festivos del país).
Para los clientes internos, los medios de contacto para el reporte de
incidentes son; llamada telefónica a la extensión 2400, acceso Web al
servidor de ServiceDesk (http://servicedesk) y mensaje de correo electrónico
(helpdesk@bce.ec)
Para los clientes externos el reporte de incidentes se registra mediante
llamada telefónica al número 2572522 ext 2400 o mediante correo
electrónico al responsable de negocio del Portal, quien a su vez puede
generar el caso de forma interna.
El tiempo de respuesta a los incidentes registrados, es el siguiente:
129
 30 minutos (durante horas de oficina) para los incidentes clasificados como
urgentes.
alta prioridad.
 120 minutos (durante horas de oficina) para los incidentes clasificados
como media prioridad.
como baja prioridad.
Tabla 4.5 tiempo de respuesta y escalamiento de incidentes

Prioridad Tiempo de Tiempo de

respuesta Escalada
Baja 180 min. 120 min
Media 120 min. 60 min.
Alta 60 min. 30 min.
Urgente 30 min. 15 min.
Tiempo de respuesta durante horas de oficina.
En los casos en que la solución de un incidente no esté disponible en los
tiempos programados y escale por tres veces consecutivas, el grupo de
Servicios Informáticos comunicará al cliente el tiempo estimado de solución.
La clasificación de prioridad la establecerán en conjunto Servicios
Informáticos con los administradores de negocio del Portal de Servicios
Electrónicos.
El esquema de escalamiento es el siguiente:
Segundo Nivel Ingeniero especialista de redes /

hardware / base de datos
130
Tercer Nivel Responsable de Servicios
Informáticos y responsable de
Infraestructura Tecnológica
Cuarto Nivel Director de Informática
Disponibilidad:
El Portal de Servicios Electrónicos se encuentran disponible durante todo el
año de acuerdo con el esquema 7x24x365, con excepción de los periodos de
mantenimiento programado de los componentes de infraestructura o en
casos fortuitos o de fuerza mayor.
En caso de mantenimiento programada la DI notificará a los clientes internos
y a los responsables de negocio para su comunicación a los clientes
externos con 48 horas de anticipación.
En caso de fuerza mayor, se procederá de acuerdo al plan de contingencia y
continuidad administrado por el negocio.
Entrega de Reportes
La Dirección de informática entregara a los clientes internos y a los responsables
de negocio para su difusión a los clientes externos reportes de:
Tabla 4.6 Frecuencia de entrega de reportes

Nombre del reporte Intervalo de Metodo Responsabilidad

tiempo entrega
% de disponibilidad del mensual Correo IT y BDD
Portal electrónico
Capacidad promedio de mensual Correo IT y BDD
procesamiento por electrónico
dispositivo
Reporte de semestral Oficio interno IT y BDD
131
mantenimientos
programados
Copia del Reporte de Cuando se Oficio interno IT y BDD
materialización de riesgo presente
enviada a la Dirección de
Riesgos
Reporte de nuevos clientes mensual Correo Responsable
enrolados electrónico Administración
del Portal
Número de incidentes, mensual Correo Servicios
reportados, resueltos, electrónico Informáticos
escalados
% de tiempo de servicio de mensual Correo IT y BDD
los proveedores de internet electrónico
Respaldos y retención de datos
Los servidores y equipos del Portal de Servicios Electrónicos están sujetos a las
políticas de respaldo y retención de información de acuerdo con el esquema
general de respaldo Abuelo- Padre – Hijo definido por la DI, de este modo las
cintas de respaldo diario se reutilizan cada semana, las semanales cada mes y
las de fin de mes cada se mantienen fuera del edificio Matriz por tres o cinco
años de acuerdo que determine la normativa vigente.
Seguridades
Se establece un doble factor de autenticación compuesto por el número de
cédula y clave del usuario registrado en el sistema de control y una tarjeta de
coordenadas para la verificación de la operación realizada.
SECCIÓN III: SERVICIOS SOPORTADOS
Los servicios soportados dentro del presente acuerdo incluyen:
132
 Control y monitoreo de la infraestructura que participa de forma directa en
el servicio y notificación al área responsable del servicio en caso de
problemas.
 Servicio de mesa de ayuda para el reporte y seguimiento de incidentes.
 Mantenimiento de la base de datos de usuarios y sistemas de control.
 Entrega de reportes según lo estipulado en la SECCIÓN II.
Se excluye del presente acuerdo para los clientes externos:
 La configuración de enlace de internet o enlace de hacia la red privada en
la infraestructura del cliente externo.
SECCIÓN IV: COSTOS
Los costos de operación y mantenimiento de la infraestructura y servicios
asociados están incluidos dentro del presupuesto de gastos e inversión del área
responsable del Portal de Servicios Electrónicos y la Dirección de Informática.
Puesto que se utiliza infraestructura y servicios que son compartidos con otros
procesos Internos, únicamente en el caso de una ampliación importante del
servicio en el Portal, el área responsable deberá incluir en su presupuesto el
valor de componentes de infraestructura ( memoria, almacenamiento o
servidores ) necesarios para soportar el servicio manteniendo la calidad de
acuerdo con las especificaciones de la Dirección de Informática. Por tratarse de
un servicio de una IFSP algunos costos son trasladados al usuario.
SECCIÓN V: MANTENIMIENTO DEL ACUERDO
Revisión del Acuerdo
133
Un representante de cualquiera de las partes podrá presentar en cualquier
momento, por escrito una solicitud para la revisión del Acuerdo al administrador
designado del presente Acuerdo.
El Acuerdo debe ser revisado anualmente. A falta de la realización de una
revisión, el actual Acuerdo permanecerá vigente mientras estén activos los
servicios del Portal.
El Administrador designado incorporará las revisiones al Acuerdo si todas las
partes están de acuerdo entre sí a los cambios propuestos.
Penalización
Una brecha en el cumplimiento del acuerdo puede llevar a las siguientes
consecuencias
 Degradación de la imagen de los servicios de TI hacia los clientes
internos y externos.
 Pérdida de confianza en un servicio clave del Banco Central.
SECCIÓN VI: RESPONSABILIDADES DE LA DIRECCIÓN DE INFORMÁTICA
Son responsabilidades de la Dirección de Informática:
 La administración de los servicios descritos en el presente Acuerdo.
 Cumplir con los tiempos de respuesta determinados, según la prioridad del
incidente.
 Cumplir con la cobertura, disponibilidad y rendimiento del servicio.
 Mantener y mejorar el nivel de conocimiento mediante capacitación
continua de los grupos de apoyo del Portal de Servicios Electrónicos.
 Designar un administrador del Acuerdo quien debe:
134
 Verificar el cumplimiento de los Acuerdos de Nivel de Operación OLA
de los grupos de Apoyo.
 Enviar al responsable del Portal los reportes generados por los grupos
de apoyo, para la distribución a los clientes.
 Administrar las solicitudes de cambio requeridas por las partes.
 Mantener una adecuada comunicación con el responsable del servicio
del Portal, cuando se ejecuten tareas de mejora a la infraestructura
que pueda afectar el servicio.
SECCIÓN VI: RESPONSABILIDADES DE LOS CLIENTES
Las responsabilidades de los clientes asociados con el presente acuerdo son:
 Cumplir con los procedimientos indicados en el presente Acuerdo.
 Para los clientes internos, cumplir con las políticas de buena utilización.
de los recursos informáticos de la institución.
 Designar el responsable de negocio que administra el Portal, quien será
la persona de contacto para coordinar todas las actividades relacionadas
con el presente acuerdo.
 Establecer y coordinar las reuniones periódicas para la revisión de los
reportes y cumplimiento del nivel de servicio
 Solicitar soporte para actividades específicas, fuera del horario
establecido en el Acuerdo, con al menos 48 horas de anticipación.
 Entregar la documentación que puede ser requerida por la DI en
casos de problemas graves, en el plazo máximo 2 horas.
 Seguimiento de los incidentes o problemas que hayan escalado.
135
 Con el administrador del Acuerdo realizar el seguimiento a los
cambios solicitados por las partes.
SECCIÓN VII: PROCEDIMIENTO DE CONTROL DE CAMBIO
Si un cambio al presente acuerdo es requerido por las partes, este debe seguir el
siguiente procedimiento:
Un Requerimiento de Cambio ( RFC Request for Change) será generado por
cada cambio o mejora que desee implementar cualquiera de las partes. Cada
RFC debe contener la descripción exacta del cambio, las razones y alcance del
cambio solicitado y el impacto que tiene sobre la disponibilidad del servicio del
Portal.
Además se debe incluir el proceso de validación del cambio, y la persona
responsable del seguimiento del cambio programado.
Cada una de las partes debe notificar el requerimiento a la otra y la parte
notificada a su vez procederá con el análisis del mismo y responderá sobre la
aceptación o rechazo del mismo en 2 días laborables.
El análisis debe determinar el impacto del cambio en los servicios de producción,
los cambios que se deben realizar al presente Acurdo y los costos asociados con
el cambio.
Para lograr que la indisponibilidad del Portal de Servicios sea la menor posible,
136
se seguirá el siguiente protocolo de comunicación y puesta en producción de los
cambios.23
Tabla 4.7 Frecuencia de entrega de reportes

Fuente: http://oit.duke.edu/enterprise/project-mgt/.../ola.doc
Dirección de
Notificación al
Informática Impacto en el
cliente y Ejemplo
Gestión de negocio
confirmación
cambios
Los cambios Ninguna Activación de cuentas
menores o de acceso al Portal
repetitivos se
consideran parte del
Estandar
flujo normal de
trabajo, sin efecto
sobre el Portal y los
clientes
Los pequeños La DI informará al Instalar parche al SO
cambios que tienen cliente con cinco de un servidor, o
un proceso de días hábiles de dispositivo de red
implementación antelación.
Menor
documentada y Notificación no
probada con poco confirmada del
impacto en el Portal cliente es
aceptable.
Los cambios pueden La DI informará al Nuevo SO, o
afectar a varias cliente con cinco actualización de
aplicaciones y tener días hábiles de versión, cambio de la
Moderada un mediano impacto antelación. El infraestructura de
en el Portal cliente debe conectividad
confirmar la
notificación
Cambios que La DI informará al Reemplazo o cambio
pueden afectar a cliente con diez mayor de un sistema
múltiples días hábiles de
Planificado
aplicaciones a antelación. El
Alta
través de múltiples cliente debe
departamentos, con confirmar la
un impacto notificación
significativo al Portal
Los cambios se La DI informará al Proceso bloqueado
deben realizar con el cliente tan pronto en el servidor - debe
fin de corregir una como sea posible ser corregido antes
Crítica falla en los servicios después de de inicio del copia de
No planificado
(fuera- de TI, que tiene conocer que se seguridad de la hora

horario algún impacto en el requiere un cambio siguiente
atención) Portal. Impacto al de este tipo. Se
Portal sin garantía prefiere la
de corrección confirmación de la
inmediata. notificación.
23
http://oit.duke.edu/enterprise/project-mgt/.../ola.doc
137
Los cambios se Proveedor de Ataque de virus, falla
deben realizar con el servicios le en la red
fin de corregir una informará al cliente
falla de servicios de después de la
TI que tiene un gran implementación del
Emergente
impacto en los cambio. Se prefiere
(Immediata)
negocios de los la confirmación de
clientes. Impacto de la notificación.
negocio requiere
una solución
inmediata.
SECCIÓN VIII: CONTROL DE VERSIONES Y FIRMAS
Con las firmas del presente documento, las partes aceptan los términos y
condiciones de este Acuerdo:
Revisión del Responsable Portal de Servicios Electrónicos
Nombre Cargo funcional firma fecha
Director de Informática
Cliente del Portal de Servicios Electrónicos
138
CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES
La presente investigación se planteó como la búsqueda de una respuesta
práctica a uno de los problemas que ha surgido en las instituciones financieras
del sector público IFSP al iniciar o implementar nuevos servicios que utilizan una
arquitectura Web para el acceso de sus clientes.
Cada uno de estos servicios además de cumplir con todos los requisitos de
calidad de desarrollo de software, debe cumplir con requisitos de calidad,
disponibilidad y velocidad en el servicio, que cumpla con las necesidades y
expectativas de los clientes y que además apoye de manera efectiva a los
objetivos de negocio de cada institución. Es aquí donde en importante seguir
recomendaciones de marcos de trabajo y mejores prácticas internacionales que
se adapten y acoplen a los procesos de las instituciones financieras públicas.
Se ha elegido a ITIL V3 como el marco de trabajo para el desarrollo de la
presente investigación ya que permite establecer “el cómo” realizar las diferentes
actividades que permiten la mejora de la gestión y soporte de servicios de TI.
La propuesta de la presente investigación es desarrollar una guía metodológica
práctica y estándar que permita la generación de acuerdos de niveles de servicio
de forma efectiva entre las IFSP y los clientes internos o externos para servicios
de aplicaciones que se ejecutan sobre plataforma Web.
La investigación inicia con una introducción del concepto de institución financiera
y una visión de la base legal de operación de cada una de las IFSP así como de
139
los marcos de trabajo y mejores prácticas a utilizar en la investigación. Conocer
el porqué de la creación de cada institución, la misión que actualmente
desempeña y los servicios que por ley debe entregar nos permite ubicarnos en el
contexto de operación de una empresa financiera del sector público. Además se
expone las características generales del libro 2 Diseño de Servicios de ITIL V3 y
en particular del proceso de administración de niveles de servicio.
Se realiza la medición del grado de madurez y control de los procesos que
apoyan la creación de acuerdos de niveles de servicio utilizando el marco de
referencia COBIT por intermedio de la encuesta preparada por ISACA y se
obtiene los resultados de medición del grado de madurez de los procesos
definidos.
Se establece la guía metodológica para la creación de ANS considerando los
procedimientos y recomendaciones del marco de trabajo ITIL V3 y la misma se
aplica con la creación de un acuerdo de nivel de servicio para un servicio con
arquitectura Web en el Banco Central del Ecuador.
5.1 Conclusiones
Para la generación de acuerdos de niveles de servicios se debe partir del
conocimiento del nivel de madurez de los procesos internos que soportan y
apoyan el ciclo de vida de un servicio, ya que este conocimiento permitirá
establecer el grado de disponibilidad y velocidad que tendrá el servicio y que
cada IFSP podrá ofrecer a sus clientes.
140
De los resultados obtenidos en la encuesta para la medición del nivel de
madurez y control de los procesos definidos como los de mayor aporte en la
generación de ANS se infiere que el proceso COBIT DS8 Administrar la mesa de
servicio y los incidentes es el que tiene un mayor nivel de madurez y control
interno, esto se da como resultado de que en todas las instituciones existe una
unidad funcional de soporte y apoyo interno la cual en algunos casos se apoya
en software de gestión de incidentes que permite automatizar algunas
actividades asociadas con este proceso.
De manera semejante el análisis de la encuesta permite demostrar que el
proceso DS1 Definir y administrar niveles de servicio es el que tiene en promedio
el menor nivel de madurez en las IFSP, este resultado también se comprueba
con el hecho de que solo dos instituciones han iniciado con la generación y firma
de acuerdos de niveles de servicio dentro de su institución, aunque estos
acuerdos no sigan expresamente las recomendaciones y mejores prácticas de
ITIL V3.
Si bien la aplicación de las recomendaciones y mejores prácticas del marco de
trabajo ITIL V3 y del caso específico de la administración de niveles de servicio y
generación de ANS, depende de cada institución en particular, de sus objetivos
de negocio y del nivel de apoyo que TI brinde a estos objetivos. Las IFSP como
instituciones del estado deben alcanzar altos niveles de calidad en los servicios
que por ley se ha asignado a cada una de ellas y siendo la plataforma Web el
medio de presentación de los servicios a sus clientes, se ha establecido la
presente guía metodológica como un aporte para generar los ANS siguiendo las
141
recomendaciones del marco de trabajo ITIL V3, y alcanzar los niveles de calidad
necesarios para un servicio óptimo y oportuno.
Como un aporte para iniciar o mejorar la generación de ANS y mejorar la calidad
se ha establecido la presente guía para las IFSP como parte de la mejora en la
calidad en los servicios que ofrece sobre arquitectura Web en particular y en
todos los servicios de TI en general.
La elaboración de la guía metodológica siguiendo las recomendaciones del
marco de trabajo ITIL V3 y su utilización en la generación de un ANS para un
servicio de una IFSP permite demostrar la hipótesis planteada para el presente
trabajo de investigación.
El conocimiento de toda la infraestructura tecnológica y de los grupos de apoyo
necesarios para la operación de un servicio con arquitectura Web, permite
establecer un ANS que satisface las necesidades y expectativas de los clientes y
permite garantizar el cumplimiento por parte de la IFSP que ofrece el servicio.
El cumplimiento de un acuerdo se determina con la medición de los indicadores
clave de rendimiento definidos en el mismo, por tanto esta medida debe
realizarse con herramientas de software que permitan automatizar la medición y
generación de reportes.
La aplicación de las recomendaciones y mejores prácticas de ITIL V3 a un
proceso en las IFSP, será el primer paso para proseguir con esta aplicación a los
142
otros procesos que se han definido como básicos y necesarios para apoyar un
ANS.
5.2 Recomendaciones
Para algunas instituciones donde existe una brecha en el valor porcentual entre
el valor de nivel de madurez y el valor de control interno se recomienda la
revisión del proceso específico, y ejecutar las actividades necesarias de mejora
para alcanzar un nivel de similitud entre los dos valores de medida del proceso.
Establecer acciones para mejorar el nivel de madurez del proceso COBIT DS1
Definir y administrar niveles de servicio para cumplir con el objetivo de asegurar
la alineación de servicios claves de TI con la estrategia de negocio en cada
institución.
Se recomienda la utilización del presente análisis y guía metodológica para
iniciar o mejorar la generación de ANS siguiendo las recomendaciones y mejores
prácticas establecidas en el marco de trabajo ITIL V3.
Ampliar la aplicación de las recomendaciones de ITIL V3 a los otros procesos
definidos como básicos en la presente investigación, como soporte y apoyo al
cumplimiento de los ANS que se generen, lo que su vez permitirá la entrega y
mantenimiento de la calidad de los servicios que ofrece cada Institución.
Asociado a cada servicio de TI que ofrece una institución financiera se encuentra
el tema de seguridad de la información que se transmite y procesa por
143
intermedio del servicio Web establecido, por tanto es recomendable un estudio
exclusivo para establecer el nivel de madurez y control, así como las acciones
de mejora en la calidad de este proceso cumpliendo las recomendaciones de
ITIL V3.
Como se ha establecido en la generación de un ANS para una IFSP, se debe
utilizar una amplia variedad de dispositivos y grupos de apoyo para que el
servicio ingrese y se mantenga en producción y pueda ser utilizado por los
clientes, por lo expuesto se recomienda la utilización de software dedicado al
monitoreo de la infraestructura tecnológica y generación de reportes de
disponibilidad y velocidad de acceso al servicio.
Establecer una política de capacitación en ITIL y otros marcos de trabajo a
todos los funcionarios de TI, de manera que todos tengan el conocimiento
necesario para apoyar el mejoramiento continuo de la calidad en los servicios
que TI entrega al negocio para alcanzar los objetivos de la institución.
Por ser marcos de referencias complementarios COBIT e ITIL, sugiero que
dentro de la malla curricular de la Maestría de Gerencia de Tecnologías de la
Información se imparta una materia con enfoque al conocimiento de ITIL como
complemento al conocimiento de la materia de COBIT.
144
BIBLIOGRAFIA Y REFERENCIAS
1. IT Governance Institute, COBIT 4.1 versión en español, Marco de

Trabajo, Objetivos de Control, Directrices Gerenciales, Modelos de
Madurez, 211 p, 2007.
2. Char LaBounty, How to Establish and Maintain Service Level

Agreements,
Help Desk Institute (January 1, 1994), 37 p, ISBN-13: 978-1571250094
3. OGC Office of Government Commerce, ITIL Service Design, The

Stationery Office, United Kingdom, 2007, 352 p., ISBN 978-0113310470
4. http://www.isaca.org/Knowledge-Center/Research/Documents/Aligning
COBIT 4.1, ITILV3 and ISO27002 for Business Benefit.pdf, ITGI and
OGC,2008
5. http://www.best-management-
practice.com/gempdf/itsmf_an_introductory_overview_of_itil_v3.pdf , An
introductory Overview of ITIL V3, UK Chapter of the itSMF, 2007, ISBN
09551245-8-1
6. http://es.wikipedia.org/wiki/Objetivos_de_control_para_la_información_y_t
ecnologías_relacionadas, COBIT 4.1,2007
7. http://www.asambleanacional.gov.ec/documentos/Constitucion-2008.pdf,
Constitución del Ecuador,2008
8. http://asambleanacional.gov.ec/documentos/Ley-Reformatoria-a-Ley-
Regimen-Monetario.pdf, Ley Reformatoria a la ley de Régimen Monetario
y Banco del Estado, 2008
9. http://www.sbs.gob.ec/medios/PORTALDOCS/downloads/estadisticas/Re
portes_gerenciales/2012/reporte_gerencial_dic_12.zip,
reporte_gerencial_dic_12.xls, 2012
145
10. http://www.bce.fin.ec/contenido.php?CNT=ARB0000002, PAGINA
PRINCIPAL » El Banco Central,2013
11. http://www.bce.fin.ec/documentos/ElBancoCentral/leyRegimenMonetario.
pdf, Ley Organica de Regimen Monetario y Banco del Estado,
Codificación, 2008
12. https://www.bnf.fin.ec/index.php?option=com_content&view=article&id=1
&Itemid=23&lang=es, Misión y Visión, 2013
13. http://www.cfn.fin.ec/index.php?option=com_content&view=article&id=5&I
temid=360, Misión, Visión y Valores, 2013
14. http://www.biess.fin.ec/nuestra-institucion/historia, 2013
15. http://www.biess.fin.ec/nuestra-institucion/mision-y-visión, 2013
16. http://www.bancoestado.com/index.php?option=com_content&view=articl
e&id=55&Itemid=62&lang=es, Misión Visión, 2013
17. http://www.bev.fin.ec/index.php/quienes-somos/mision-y-vision, 2013
18. http://www.iece.fin.ec/institucion/mision-vision, 2013
19. http://www.isaca.org/Education/Conferences/Documents/LatinCACS-
ISRM-Presentations/124.pdf, Alineando Cobit e ITIL Para Beneficio del
Negocio y del Gobierno de la TI, Claudio Schicht, 2012
20. http://www.bce.fin.ec/documentos/ServiciosBCentral/SistemaPagos/Libro
AmarilloSistemadePagos.pdf, SISTEMAS DE COMPENSACIÓN Y
LIQUIDACIÓN DE PAGOS Y VALORES EN ECUADOR, 2002
146
21. http://www.monografias.com/trabajos62/estadistica-aplicada-
mantenimiento/estadistica-aplicada-mantenimiento2.shtml, Janes
Massiah, Estadística básica aplicada al mantenimiento - Unidad III, 2009
22. http://oit.duke.edu/search.php?q=sla+example, Information Technology

Duke University, TSM Base SLA FY10.doc, 2009
23. http://oit.duke.edu/enterprise/project-mgt/.../ola.doc, Information

Technology Duke University, Operating Level Agreement (OLA) for.doc,
2009.
147
ANEXO 1
Acuerdo de Nivel de Operación (OLA)
de: Servicios Informáticos de la DI
para: Portal de Servicios Electrónicos de DSBN
Versión 1
Contenido
Descripción general
Este acuerdo de nivel de operación (OLA) documenta los servicios de apoyo en

TI prestados por el subproceso de Servicios Informáticos de la Dirección de
Informática para el apoyo del Portal de Servicios Electrónicos de la Dirección de
Servicios Bancarios Nacionales. El objetivo de este acuerdo es el de documentar
los servicios de apoyo del grupo de Servicios Informáticos de TI para garantizar
la entrega de alta calidad y oportuna de servicios del Portal de Servicios
Electrónicos a clientes internos y clientes externos del sector público y privado.
Partes
Las partes afectadas por este OLA son:
 Subproceso de Servicios Informáticos

 Subproceso de Control de Cuentas Corrientes
 Subproceso de Infraestructura Tecnológica y Base de Datos
Ambiente operación
La operatividad de Servicios Informáticos se basa en el funcionamiento del

aplicativo de administración de incidentes, problemas y requerimientos Service
Desk Manager, desarrollado por CA, (Computer Associates), este aplicativo se
encuentra instalado en un servidor tipo BLADE, modelo BL460c., con 6 GB de
RAM y con sistema operativo Windows 2003.
El aplicativo se utiliza desde una interfaz Web, y permite a los técnicos y

administradores de la mesa de ayuda el ingreso y seguimiento de los
requerimientos, incidentes, problemas y cambios, está integrado con el Directorio
de Novell para el control de acceso de los técnicos, administradores y usuarios
a la aplicación.
Los usuarios pueden ingresar los incidentes directamente por la interfaz web,
llamar a la línea PBX interna ext 2400 que atiende con 6 técnicos, enviar un
correo electrónico a la cuenta helpdesk@bce.ec y realizar el seguimiento de los
mismos por cualquiera de las opciones.
148
Personas de contacto
Servicios Informáticos Servicios Bancarios

Nacionales
José Mejía Dalila Mera
Responsable de servicios Responsable de servicios al
Informáticos cliente
jmejia@bce.ec dmera@bce.ec
2572522 ext 2417 2572522 ext 2128
Terminos y condiciones
Periodo del Acuerdo
Este acuerdo es válido a partir de la fecha de la firma de las partes y

permanece en efecto durante todo el tiempo de vida de los servicios y / o
aplicaciones compatibles con el Portal de Servicios Electrónicos.
Fecha de vigencia:

momento, por escrito una solicitud para la revisión del Acuerdo al
administrador designado del presente Acuerdo.
revisión, el actual Acuerdo permanecerá vigente. El Administrador designado
incorporará las revisiones al Acuerdo si todas las partes están de acuerdo
entre sí a los cambios propuestos.
Última revisión: Próxima revisión:
Horas de cobertura
Los procedimientos de este Acuerdo se siguen desde las 8:30 AM a 18:00

PM de Lunes a Viernes (excepto días festivos del país). Personal de apoyo
de la Dirección de Servicios Bancarios Nacionales puede solicitar la ayuda
de emergencia del Grupo de Servicios Informáticos para asuntos urgentes
durante las horas que no están cubiertos por las horas de cobertura.
Objetivos del servicio
El grupo de Servicios Informáticos responderá los incidentes registrados por

los clientes del Portal de Servicios Electrónicos a través de los tres medios
de contacto; llamada telefónica, acceso Web y mensaje de correo electrónico
dentro del siguiente tiempo de respuesta.

urgentes.
149
alta prioridad.
media prioridad.
Prioridad Tiempo de Escala cada

respuesta

tiempos programados y escale por tres veces consecutivas, el grupo de
Servicios Informáticos comunicará al cliente el tiempo estimado de solución.
La clasificación de prioridad la establecerán en conjunto Servicios
Informáticos con los administradores de negocio del Portal de Servicios
Electrónicos.

Fallas al cumplimiento de términos y condiciones
Los procedimientos de este acuerdo están interesados para asegurar los

niveles de servicio en los términos y condiciones descritos en el acuerdo. Una
falla en el cumplimiento del acuerdo puede llevar a las siguientes
consecuencias
 Degradación de la imagen de los servicios de TI hacia los clientes internos
y externos.
 Pérdida de confianza en un servicio clave del Banco Central.
Servicios soportados y cargos
Servicios Informáticos acuerdo proveer soporte a los usuarios del Portal de

Servicios Electrónicos en los temas relacionados a:
 Verificar que el servicio se encuentre activo.
150
 Determinar si el incidente o problema afecta a un cliente o afecta a la
mayoría.
 Escalar los incidentes y problemas al grupo de infraestructura
correspondiente.
Cargos
No existen cargos declarados específicamente para el soporte del Portal de

Servicios Electrónicos, de requerirse incrementar horas de servicio o
ampliación plataforma tecnológica se debe realizar la respectiva
transferencia de fondos entre las cuentas internas que administra cada área
Responsabilidades de las partes
Las responsabilidades que acuerdan los administradores de Portal son:
 Seguir los procedimientos adecuados de creación de incidentes.

 Determinar la prioridad adecuada (baja, media, alta y urgente) en conjunto
con Servicios Informáticos.
 Programar la atención en eventos especiales fuera de horario, como
instalación de nuevos equipos o nuevas versiones.
 Realizar el seguimiento a los incidentes o problemas que hayan escalado.
 Seguir las políticas de utilización de los recursos informáticos .
 Estar disponible a brindar toda la información que requiere el grupos de
Servicios Informáticos dentro de un tiempo máximo de 1 hora a fin de
resolver un problema.
 Pagar (realizar transferencias entre cuentas internas) de ser necesario.
Las responsabilidades que acuerdan el grupo de Servicios Informáticos son:
 Cumplir los tiempos de respuesta de acuerdo a la prioridad definida en el

OLA.
 Generar y enviar a los Administradores del Portal reportes periódicos del
cumplimientos de las metas de servicio.
 Mantener al grupo de soporte con el entrenamiento apropiado.
 Enviar notificaciones por correo electrónico a los clientes de los
mantenimientos o cambios programados en la infraestructura del servicio
del portal.
 Mantener el servicio de forma continua, entre las 8:30 y 18:00.
Métricas del servicio y reportes
El responsable de Servicios Informáticos remitirá al responsable del Portal de

Servicios Electrónicos un reporte mensual por correo electrónico de los
incidentes y problemas que se han registrado, escalado y resuelto.
Historial de versiones
Las versiones y revisiones al presente Acuerdo, deben registrarse, según al

siguiente esquema
151
Fecha Nombre Localización Responsable
archivo del archivo de la revisión o
versión
Versión 1 es el primer
Acuerdo Versión 1.1 es la
revisión(es) al primer
Acuerdo dentro del año.
Versión 2 es el Acuerdo
del segundo Año
Firmas de aprobación
Con las firmas del documento, las partes aceptan los términos y condiciones de
esta Acuerdo
Revisión del Director de Servicios Bancarios Nacionales
Responsable Portal de Servicios Electrónicos
Responsable de Servicios Informáticos
152
ANEXO 2
Acuerdo de Nivel de Operación (OLA)
de: Infraestructura Tecnológica y Base de Datos de la DI
para: Portal de Servicios Electrónicos de DSBN
Version 1
Contenido
Descripción general
Este acuerdo de nivel de operación (OLA) documenta los servicios de apoyo en

TI prestados por el subproceso de Infraestructura Tecnológica y Base de Datos
(ITyBDD) de la Dirección de Informática (DI) para el servicio del Portal de
Servicios Electrónicos de la Dirección de Servicios Bancarios Nacionales. El
objetivo de este acuerdo es el de documentar los servicios de apoyo del grupo
de ITyBDD de TI para garantizar la entrega con alta calidad y oportuna de
servicios del Portal de Servicios Electrónicos a clientes internos y clientes
externos del sector público y privado.
Partes
Las partes incluidas por este OLA son:
 Subproceso de Infraestructura Tecnológica y Base de Datos

 Subproceso de Sistemas Financieros Nacionales
 Subproceso de Servicios Informáticos
Ambiente operación
La operatividad de Infraestructura Tecnológica y Base de Datos se basa en el

gestionamiento de los componentes de infraestructura del centro de cómputo a
través de aplicativos de administración de los diferentes dominios de
conocimiento como son:
 Redes y Comunicaciones.
 Administración plataforma de Servidores.
 Administración de capa componentes.
 Administración de base de datos.
Los aplicativos de administración y control de las diferentes dominios se

encuentran instalados en servidores se encuentran instalados en servidores tipo
BLADE, modelo BL460c, con 6 GB de RAM y con sistema operativo Windows
2003. Sun-Oracle
Cada aplicativo utiliza ya sea una interfaz Web o cliente-servidor, para que los
administradores ingresen a los sistemas de monitoreo de los dispositivos
asociados a cada dominio de conocimiento, algunos de estos aplicativos
153
generan alarmas que se integran con el sistema de correo interno, los mensajes
de alerta son revisados por los ingenieros de soporte para determinar si debe
abrirse un reporte en la mesa de ayuda para el seguimiento respectivo.
Cada dominio de conocimiento debe revisar semanalmente el correcto

funcionamiento de los dispositivos asociados a su dominio.
Personas de contacto
Infraestructura técnológica y Servicios Financieros

Bases de datos Nacionales
Arturo Bedon Dalila Mera
Responsable de IT Y BDD Responsable de servicios al
@bce.ec cliente
2572522 ext 2410 dmera@bce.ec
2572522 ext 2128
Terminos y condiciones
Periodo del Acuerdo
Este acuerdo es válido a partir de la fecha de la firma de las partes y

permanece en efecto durante todo el tiempo de vida de los servicios y / o
aplicaciones compatibles con el Portal de Servicios Electrónicos.
Fecha de inicio de vigencia:

momento, por escrito una solicitud para la revisión del Acuerdo al
administrador designado del presente Acuerdo.

revisión, el actual Acuerdo permanecerá vigente. El Administrador designado
incorporará las revisiones al Acuerdo si todas las partes están de acuerdo
entre sí a los cambios propuestos.
Última revisión: Próxima revisión:
Horas de cobertura
Los procedimientos de este Acuerdo se siguen 24x5x365 de Lunes a

Viernes, Personal de apoyo de la Dirección de Servicios Bancarios
Nacionales puede solicitar la ayuda de emergencia del Grupo de IT y BDD
para asuntos urgentes durante los días y horas que no están cubiertos por
las horas de cobertura.
Objetivos del servicio
El grupo de IT y BDD responderá a los incidentes registrados por los

clientes del Portal de Servicios Electrónicos a través de los tres medios de
154
contacto; llamada telefónica, acceso Web y mensaje de correo electrónico
dentro del siguiente horario.
urgentes.
alta prioridad.
media prioridad.
Prioridad Tiempo de Escala cada

respuesta

tiempos programados y escale por tres veces consecutivas, el grupo de IT y
BDD comunicará a Servicios Informáticos y este comunicará al cliente el
tiempo estimado de solución.
La clasificación de prioridad la establecerán en conjunto IT y BDD con los
administradores de negocio del Portal de Servicios Electrónicos.

Fallas al cumplimiento de términos y condiciones
Los procedimientos de este acuerdo están interesados para asegurar los

niveles de servicio en los términos y condiciones descritos en el acuerdo. Una
falla en el cumplimiento del acuerdo puede llevar a las siguientes
consecuencias
 Degradación de la imagen de los servicios de TI hacia los clientes internos
y externos.
 Pérdida de confianza en un servicio critico del Banco Central.
Servicios soportados y cargos
IT y BDD acuerda proveer soporte a los usuarios del Portal de Servicios

Electrónicos en los temas relacionados a:
155
 Verificar que el servicio se encuentre activo.
 Determinar si el incidente o problema afecta a un cliente o afecta a la
mayoría.
 Escalar los incidentes y problemas a los grupos de soporte externo.
Cargos
No existen cargos declarados específicamente para el soporte del Portal de

servicios Electrónicos, de requerirse incrementar capacidad o ampliación
plataforma tecnológica se debe realizar la respectiva transferencia de fondos
entre las cuentas internas que administra cada área.
Responsabilidades de las partes
Las responsabilidades que acuerdan los administradores de Portal son:
 Seguir los procedimientos adecuados de creación de incidentes.

 Programar la atención en eventos especiales fuera de horario, como
instalación de nuevos equipos o nuevas versiones.
 Realizar el seguimiento a los incidentes o problemas que hayan escalado.
 Seguir las políticas de utilización de los recursos informáticos.
 Estar disponible a brindar toda la información que requiere el grupos de IT
y BDD dentro de un tiempo máximo de 1 hora a fin de resolver un
problema.
 Pagar (realizar transferencias entre cuentas internas) de ser necesario.
Las responsabilidades que acuerdan el grupo de IT y BDD son:
 Cumplir los tiempos de respuesta de acuerdo a la prioridad definida en el

OLA.
 Generar y enviar a los Administradores del Portal reportes periódicos del
cumplimiento de las metas de servicio.
 Mantener los grupos de dominio de conocimiento con el entrenamiento
apropiado.
 Enviar notificaciones por correo electrónico a Servicio Informáticos, para
que se informe a los clientes de los mantenimientos o cambios
programados en la infraestructura del servicio del portal.
 Mantener el servicio de forma continua, 24x5x365
Métricas del servicio y reportes
El responsable de IT y BDD remitirá al responsable del Portal de Servicios

Electrónicos:
Nombre del reporte Intervalo de Metodo Responsabilidad

tiempo entrega
% Disponibilidad del Portal mensual Correo IT y BDD
electrónico
Capacidad promedio de mensual Correo IT y BDD
procesamiento por electrónico
156
dispositivo
Reporte de mantenimientos semestral Oficio interno IT y BDD
programados
Copia del Reporte de Cuando se Oficio interno IT y BDD
materialización de riesgo presente
enviada a la Dirección de
Riesgos
Reporte de nuevos clientes mensual Correo Responsable
enrolados electrónico Administración
del Portal
Historial de versiones
Las versiones y revisiones al presente Acuerdo, deben registrarse, según al

siguiente esquema
Fecha Nombre Localización Responsable de

archivo del archivo la revisión o
versión
Versión 1 es el primer
Acuerdo
Versión 1.1 es la
revisión(es) al primer
Acuerdo dentro del año.
Versión 2 es el Acuerdo
del segundo Año
Mejoras en el servicio y gestión del cambio
Las actividades programadas por los administradores del Portal para mejora de
servicio o implementación de nuevos módulos deberán ser notificadas mediante
oficio interno al Director de Informática con al menos 3 días de anticipación. La
DI deberá responder a las solicitudes de servicio recibidas con antelación
adecuada dentro de los 2 días siguientes.
El subproceso de IT y BDD notificará con 2 días de anticipación al responsable
del Portal de Servicios los cambios o mejoras en la configuración de los
dispositivos de la infraestructura tecnológica asociados al Portal.
Además notificará el alcance de los cambios, el impacto en la disponibilidad, el
proceso de validación del cambio y los objetivos a lograr y el responsable del
cambio programado.
Para lograr que la indisponibilidad del Portal de Servicios sea la menor posible,
se seguirá el siguiente protocolo de comunicación y puesta en producción de los
cambios:24
Dirección de
Notificación al
Informática Impacto en el
cliente y Ejemplo
Gestión de negocio
confirmación
cambios
24
oit.duke.edu/enterprise/project-mgt/.../ola.doc
157
Los cambios Ninguna Activación de cuentas
menores o de acceso al Portal
repetitivos se
consideran parte del
Estandar
flujo normal de
trabajo, sin efecto
sobre el Portal y los
clientes
Los pequeños La DI informará al Instalar parche al SO
cambios que tienen cliente con cinco de un servidor, o
un proceso de días hábiles de dispositivo de red
implementación antelación.
Menor
documentada y Notificación no
probada con poco confirmada del
Planificado
impacto en el Portal cliente es

aceptable.
Los cambios pueden La DI informará al Nuevo SO, o
afectar a varias cliente con cinco actualización de
aplicaciones y tener días hábiles de versión, cambio de la
Moderada un mediano impacto antelación. El infraestructura de
en el Portal cliente debe conectividad
confirmar la
notificación
Cambios que La DI informará al Reemplazo o cambio
pueden afectar a cliente con diez mayor de un sistema
múltiples días hábiles de
aplicaciones a través antelación. El
Alta
de múltiples cliente debe
departamentos, con confirmar la
un impacto notificación
significativo al Portal
Los cambios se La DI informará al Proceso bloqueado
deben realizar con el cliente tan pronto en el servidor - debe
fin de corregir una como sea posible ser corregido antes
Crítica falla en los servicios después de conocer de inicio del copia de
(fuera- de TI, que tiene que se requiere un seguridad de la hora
horario algún impacto en el cambio de este tipo. siguiente
atención) Portal. Impacto al Se prefiere la
Portal sin garantía confirmación de la
No planificado
de corrección notificación.
inmediata.
Los cambios se Proveedor de Ataque de virus, falla
deben realizar con el servicios le en la red
fin de corregir una informará al cliente
falla de servicios de después de la
Emergente TI que tiene un gran implementación del
(Immediata) impacto en los cambio. Se prefiere
negocios de los la confirmación de
clientes. Impacto de la notificación.
negocio requiere una
solución inmediata.
158
Firmas de aprobación
Con las firmas del presente documento, las partes aceptan los términos y
condiciones de esta Acuerdo
Revisión del Director de Servicios Bancarios Nacionales
Responsable Portal de Servicios Electrónicos
Responsable de Servicios Informáticos
159
ANEXO 3
GLOSARIO
SIGLA TERMINO EN INGLES TERMINO EN ESPAÑOL
ANS Acuerdo de Nivel de Servicio
IFSP Institución Financiera del Sector

Público
SNP Sistema Nacional de Pagos
SLA Service Level Agreement Acuerdo de Nivel de Servicio
ITIL Information Technology Biblioteca de Infraestructura de

Infraestructure Library Tecnologías de Información
COBIT Control Objectives for Information Objetivos de Control para la
and related Technology Información y la Tecnologías
Relacionadas
ISO/IEC IEC International Estándar Organización Internacional de
Organization / International Normalización / Comisión
Electrical Corporation Electrotécnica Internacional.
CMMI Capability maturity model Integración de modelos de madurez
integration de capacidades
DS Deliver and Support Entrega y soporte
KPI Key Performance Indicator Indicador clave de rendimiento
KGI Key Goal Indicator Indicador clave de meta
CSF Critical Success Factor Factor crítico de éxito
OLA Operational Level Agreement Acuerdo de nivel de operación
FAQ Frecuently Asked Questions Preguntas frecuentes
CMDB Configuration Management Base de Datos de la Configuración

DataBase
SLR Service Level Requirement Nivel de Servicio de Requerimiento
OGC Office of Government Commerce
ITGI IT Governance Institute
SLM Service Level Management Administración de Niveles de Servicio
SLR Service Level Request Requerimiento de Nivel de Servicio
RLA Request Level Agreement Acuerdo de Nivel de Requerimiento
ISACA Information Systems Audit and Asociación de Auditoría y Control de

Control Association Sistemas de Información
RFC Request for Change Requerimiento de Cambio
160
ANEXO 4
ENCUESTA EN LAS INSTITUCIONES FINANCIERAS DEL SECTOR PÚBLICO
161
162
163
164
165

Itil - Ans PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Itil - Ans PDF

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR

TESIS DE GRADO PREVIA A LA OBTENCIÓN DEL TÍTULO DE “MAGISTER

EN GERENCIA DE TECNOLOGÍAS DE INFORMACIÓN"

GUÍA METODOLÓGÍCA PARA GENERAR ACUERDOS DE NIVELES

DE SERVICIO (ANS) PARA ARQUITECTURA DE SERVICIOS WEB EN

INSTITUCIONES FINANCIERAS DEL SECTOR PÚBLICO UTILIZANDO

EDISON RUBEN NICOLALDE JAQUE

QUITO, JUNIO 2013

1.1 Introducción .................................................................................... 8

CAPÍTULO 2: GESTIÓN DE LOS ACUERDOS DE NIVELES DE

2.1 Análisis de la situación actual de los ANS en las IFSP ..............................50

3.1 Definición de procedimientos para establecer un ANS.................. 81

4.1 Definición de un servicio para establecer un ANS ................................113

CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES .................... 139

5.1 Conclusiones .........................................................................................140

BIBLIOGRAFIA Y REFERENCIAS .......................................................... 145

ANEXO 1 .................................................................................................. 148

ANEXO 4 .................................................................................................. 161

Tabla 2.2 Matriz para encuesta y cálculo de nivel de madurez COBIT…………………………… 53

Tabla 2.3 COBIT Cálculo de nivel de madurez …………………………………………………….. 56

Tabla 2.4 COBIT Encuesta para medir control interno de un proceso………………………….. 57

Tabla 2.19 Servicios con arquitectura Web de cada IFSP…………………………………………… 76

Tabla 2.20 Nivel de acuerdo para los OLAs en las IFSP…………………………………………….. 77

Tabla 2.21 Nivel de madurez de DS2 Administración de terceros…………………………………. 78

Tabla 3.1 Matriz RACI de un proceso…………………………………………………. … 100

Tabla 4.2 Matriz de control de clientes………………………………………………………………… 119

Tabla 4.3 Matriz RACI para servicio del Portal………………………………………………….….. 123

Tabla 4.4 Matriz Nivel de Servicio de los Proveedores ……………………………………………... 125

Tabla 4.5 tiempo de respuesta y escalamiento de incidentes……………………………………… 129

Tabla 4.6 Frecuencia de entrega de reportes ……………………………………………………….. 130

Tabla 4.7 Frecuencia de entrega de reportes……………………………………………. 136

Figura 1.1 ITIL Rol en el tiempo……………………………………………………………….. 11

Figura 1.2 Libros ITIL V3……………………………………………………………………….. 13

Figura 1.3 Dominios de COBIT V4.1…………………………………………………………. 15

Figura 1.4 Principales actividades del proceso de SLM …………………………………… 43

Figura.2.1 Nivel de Madurez del proceso DS1 para el BNF……………………………….. 56

Figura 2.2 Nivel de madurez y control de los procesos en el BNF………………………... 61

Figura 2.3 Nivel de madurez y control de los procesos en el BCE……………………….. 63

Figura 2.4 Nivel de madurez y control de los procesos en la CFN………………………... 65

Figura 2.5 Nivel de madurez y control de los procesos en el IECE………………………. 67

Figura 2.6 Nivel de madurez y control de los procesos en el BEDE……………………… 69

Figura 2.7 Nivel de madurez de los procesos en las IFSP………………………………… 70

Figura 2.8 Nivel de control interno de los procesos en las IFSP………………………….. 72

Figura 2.9 Nivel de madurez proceso DS1 en las IFSP…………………………………… 73

Figura 2.10 Nivel de control interno proceso DS1 en las IFSP…………………………… 74

Figura 2.11 Servicios con arquitectura Web de cada IFSP……………………………….. 76

Figura 2.12 Nivel de acuerdo para los OLAs en las IFSP………………………………… 77

Figura 2.14 Nivel de madurez del servicio DS2 en las IFSP…………………………….. 80

Figura 3.1 Acuerdo de Nivel de Servicio de multi-nivel…………………………………… 83

Figura 3.2 Generación de un Acuerdo de Nivel de Servicio……………………………… 85

Figura 3.3 reporte de cumplimiento de ANS……………………………………………….. 94

Figura 4.1 Partícipes del portal de Servicios Electrónicos………………………………. 112

Figura 4.2 Dispositivos de hardware Portal de Servicios Electrónicos…………………. 115

Figura 4.3 Configuración Alta Disponibilidad Geográfica………………………………… 117

instituciones del sector financiero privado son intermediarios del mercado

financiero que siendo bancos o sin serlo ofrecen préstamos o facilidades de

financiamiento en dinero, sus servicios de información, aplicaciones y

operaciones financieras son obligatorias e indelegables y están direccionados a

sectores específicos, determinados en la ley o decretos de su creación.

y personas naturales o jurídicas, las IFSP se encuentran impulsando el uso de

Internet como medio de acceso y han desarrollado aplicaciones sobre plataforma

La utilización de las tecnologías de la información TI permite mejorar la

administración de la calidad y la confiabilidad de los servicios y cumplir con los