Escuela Politécnica Nacional: Facultad de Ingeniería en Sistemas

ESCUELA POLITCNICA NACIONAL
FACULTAD DE INGENIERA EN SISTEMAS
ANLISIS DE LA PRESTACIN DE SERVICIOS APOYADOS

POR TI, UTILIZANDO ITIL EN UNA EMPRESA DE SERVICIOS
PBLICOS
PROYECTO PREVIO A LA OBTENCIN DEL TTULO DE INGENIERO EN

SISTEMAS INFORMTICOS Y DE COMPUTACIN
ALMEIDA TOAPANTA JENNY ALEXANDRA

jenny_almeida15@yahoo.es
DIRECTOR: Msc. Ing. JAIME NARANJO

naranjojf@epn.edu.ec
Quito, Febrero 2008
DECLARACIN
Yo, Jenny Alexandra Almeida Toapanta, declaro bajo juramento que el trabajo
aqu descrito es de mi autora; que no ha sido previamente presentada para
ningn grado o calificacin profesional; y, que he consultado las referencias
bibliogrficas que se incluyen en este documento.
A travs de la presente declaro ceder mis derechos de propiedad intelectual

correspondientes a este trabajo, a la Escuela Politcnica Nacional, segn lo
establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la
normatividad institucional vigente.
Jenny Alexandra Almeida Toapanta
ii
CERTIFICACIN
Certifico que el presente trabajo fue desarrollado por Jenny Alexandra Almeida
Toapanta, bajo mi supervisin.
Ing. Jaime Naranjo

DIRECTOR DE PROYECTO
iii
AGRADECIMIENTOS
A Dios, porque aunque tuve muchos tropiezos durante el desarrollo de este proyecto,
siempre me dio la fortaleza para salir adelante.
A mis padres y hermanas, quienes nunca dejaron de apoyarme durante toda esta travesa
universitaria. Dios les pague porque sin ustedes nunca hubiese llegado hasta aqu.
Al Ing. Jaime Naranjo, que mas que mi tutor, se convirti en un gran amigo al que respeto
y admiro mucho. Sus palabras de aliento hicieron que vea al mundo como un camino
lleno de metas por alcanzar.
Al personal de Sistemas de la EEQ S.A., especialmente al Ing. Carlos Benavides, quien me

brind su ayuda sin ningn inters, por lo cual le estar eternamente agradecida.
A mis amigos, Christian, Marce, Tali, Vivi, Sylvita y Miguel, que siempre me han brindado
su cario y ayuda en los momentos que lo he necesitado. Por eso y mucho ms, siempre
los llevar en mi corazn.
A Jorge, quien en poco tiempo se ha convertido en una parte muy importante de mi vida,
gracias por su tiempo, amor y sobre todo paciencia.
En fin, a todas aquellas personas que de alguna u otra forma me ayudaron a crecer no
solo profesionalmente, sino como persona, mil gracias por todo y espero sigamos en
contacto.
Jenny
iv
DEDICATORIA
No puedo ms que dedicar este trabajo a mi familia, que a pesar de no ser perfecta, es la
parte de mi vida que mas amo.
Mis padres, dos seres que me dieron la oportunidad de disfrutar de este mundo, personas
sacrificadas y emprendedoras, mi ejemplo a seguir. Espero nunca decepcionarlos.
Mi hermana Patty, la parte mas equilibrada de la familia, ojal siempre tengas ese eque
para cumplir con tus ideales y no te dejes vencer por los obstculos como hasta ahora.
Mi hermana menor Andy, la rebelde, la que siempre ve la vida sin la menor complicacin,
espero que siempre tengas ese coraje para enfrentar cualquier adversidad en la vida.
Mi Scrapy precioso, que siempre llena de alegra mi vida.
A todos ustedes que Dios les bendiga y a mi me de la oportunidad de demostrarles cuanto

significan para mi.
Jenny
La vida solo puede ser comprendida mirando para atrs, ms solo puede ser vivida mirando para
adelante.
Annimo
CONTENIDO
CAPTULO 1.................................................................................................... 14
ANLISIS DE LA GESTIN DE SERVICIOS CON ITIL................................. 14
1.1
EVALUACIN DE PROCESOS........................................................................ 14
1.1.1
ENFOQUE PROCESAL DE ITIL............................................................................................ 14
1.1.2
SELECCIN DE LOS PROCESOS A SER EVALUADOS EN LA EMPRESA ........................ 16
1.1.2.1
Actividades/Subprocesos a evaluarse por cada proceso seleccionado........................................... 18
1.1.3
REALIDAD DE LA ORGANIZACIN .................................................................................... 21
1.1.4
MAPEO DE LOS PROCESOS MANEJADOS POR ITIL VS. LOS SUBPROCESOS DE LA
DIVISIN DE SISTEMAS...................................................................................................................... 27
1.1.5
APLICACIN DE ITIL PARA EL ANLISIS DE LOS PROCESOS SELECCIONADOS..... 28
1.1.5.1
Clculos aplicados para la obtencin del Porcentaje de Cumplimiento de los Procesos ............... 29
1.1.5.2
Mtodo de Interpretacin de Resultados........................................................ 31
1.1.5.3
Evaluacin de Resultados. ..................................................... 31
1.2
ANLISIS DE ROLES ............................................................................................... 33
1.2.1
MAPEO DE ROLES DE LOS PROCESOS SELECCIONADOS DE ITIL VS. LOS ROLES
MANEJADOS EN LA DIVISIN DE SISTEMAS .................................................................................. 33

1.2.2
APLICACIN DE ITIL PARA EL ANLISIS DE LOS ROLES SELECCIONADOS............... 35
1.2.2.1
Clculos aplicados para la obtencin del porcentaje de cumplimiento de roles ............................ 36
1.2.2.2
Mtodo de Interpretacin de Resultados................................................ 37
1.2.2.3
Evaluacin de Resultados.. .................................................... 38
1.3
ANLISIS DE RIESGOS ............................................................................................ 39
1.3.1
ANLISIS DE ESTIMACIN DE RIESGOS ........................................................................... 39
1.3.1.1
Identificacin de Riesgos. ...................................................... 39
1.3.1.2
Categorizacin de Riesgos.. ....................................................... 39
1.3.1.3
Mtodo de Interpretacin del Impacto de Riesgos............................................. 39
1.3.1.4
Clculos aplicados para la obtencin del Porcentaje de Riesgo .................................................... 40
1.3.1.5
Mtodo de interpretacin de la Probabilidad de Riesgo. .................................................. 41
1.3.1.6
Mtodo de Interpretacin de Riesgos..................................................... 41
1.3.1.7
Evaluacin de Resultados ...................................................... 42
CAPITULO 2.................................................................................................... 43
PRESENTACIN DE RESULTADOS ............................................................. 43
vi
2.1
ELABORACIN DEL INFORME TCNICO ............................................................................ 43
2.1.1
2.2
ACTIVIDADES REALIZADAS PARA EL DESARROLLO DEL INFORME....................... 43
2.1.1.1
Establecimiento de Herramientas para la obtencin de Informacin.....43
2.1.1.2
Sesiones para la obtencin de Informacin....44
2.1.1.3
Anlisis de Resultados...44
2.1.1.4
Presentacin de Resultados...45
2.1.1.4.1
Resultados de la Evaluacin de Procesos...45
2.1.1.4.2
Resultados del Anlisis de Roles ..125
2.1.1.4.3
Resultados de la Anlisis de Riesgos.....162
ELABORACIN DEL INFORME EJECUTIVO...................................................................... 223
CAPITULO 3.................................................................................................. 235

CONCLUSIONES Y RECOMENDACIONES................................................. 235
3.1.
CONCLUSIONES .................................................................................................... 235
3.2.
RECOMENDACIONES ............................................................................................. 236
vii
NDICE DE FIGURAS
FIGURA 1. 1. PULICACIONES DE LIBROS DE ITIL ............................................................................... 14
FIGURA 1. 2. REPRESENTACIN DE UN PROCESO EN BASE A SU ESTRUCTURA SEGN ITIL 29
viii
NDICE DE TABLAS
TABLA 1.1. PROCESOS DE ITIL DE ACUERDO A CADA UNA DE SUS PUBLICACIONES.............. 16
TABLA 1.2. PROCESOS A EVALUAR EN LA EEQ S.A EN BASE A ITIL............................................. 17
TABLA 1.3. ACTIVIDADES/SUBPROCESOS A EVALUAR POR CADA PROCESO SELECCIONADO
......................................................................................................................................................................... 21
TABLA 1.4. PROCESOS APOYADOS POR LAS TI EN LA EEQ S.A..................................................... 23
TABLA 1.5. OBJETIVOS, SUBPROCESOS, RESPONSABLES Y ESTRATEGIAS DEL PROCESO DE
SISTEMAS EN LA EEQ S.A. ........................................................................................................................ 26
TABLA 1.6. MAPEO DE LOS PROCESOS MANEJADOS POR ITIL VS. SUBPROCESOS DE LA
DIVISIN DE SISTEMAS............................................................................................................................. 28
TABLA 1.7. PESOS PARA POSIBLES RESPUESTAS PARA LA EVALUACIN DE PROCESOS ....... 29
TABLA 1.8. INTERPRETACIN DE RESULTADOS PARA EL CUMPLIMIENTO DE UN PROCESO
EN BASE AL CUADRO SUGERIDO POR EL COSO USADO EN AUDITORA INTERNA DE LA E.PN.
......................................................................................................................................................................... 31
TABLA 1.9. ROLES IDENTIFICADOS EN BASE A LOS MANEJADOS POR ITIL.............................. 35
TABLA 1.10. CUADRO DE PESOS PARA POSIBLES RESPUESTAS PARA EL ANLISIS DE ROLES
......................................................................................................................................................................... 36
TABLA 1.11. TABLA DE CATEGORIZACIN DE RIESGOS .................................................................. 39
TABLA 1.12. TABLA DE IMPACTO DE RIESGOS ................................................................................... 40
TABLA 1.13. INTERPRETACIN DE RESULTADOS DE LA PROBABILIDAD DE RIESGO EN BASE
AL CUADRO SUGERIDO POR EL COSO USADO EN AUDITORA INTERNA DE LA E.PN. ............. 41
TABLA 1.14. INTERPRETACIN DE RIESGOS BASADO EN EL DOCUMENTO "EVALUACIN DE
RIESGOS LABORALES DEL SINDICATO PROTECTOR DE TRABAJO NACIONAL" - MADRID.
1996................................................................................................................................................................. 41
TABLA 2.1. HERRAMIENTAS PARA LA OBTENCIN DE INFORMACIN ...................................... 43
TABLA 2.2. RESULTADO OBTENIDO DE LA APLICACIN DE LA ENCUESTA Y ENTREVISTA
ELABORADAS PARA LA ADMINISTRACIN DE LA FUNCIN SERVICE DESK............................ 49
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE INCIDENTES. ................................ 54
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE PROBLEMAS................................. 61
DEL PROCESO DE ADMINISTRACIN DE LA CONFIGURACIN...................................................... 69
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE CAMBIOS....................................... 76
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE VERSIONES................................... 83
ix

ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE LOS NIVELES DE SERVICIO. ..... 89
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI.
......................................................................................................................................................................... 97
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE LA CAPACIDAD ......................... 104
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE LA DISPONIBILIDAD. ............... 111
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE LA CONTINUIDAD..................... 118
ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE LA SEGURIDAD. ........................ 125
TABLA 2.14. RESULTADO OBTENIDO DE LA APLICACIN DE LA GUA ELABORADA PARA LA
FUNCIN DE SERVICE DESK. ................................................................................................................. 129
ADMINISTRACIN DE INCIDENTES...................................................................................................... 132
ADMINISTRACIN DE PROBLEMAS. .................................................................................................... 135
ADMINISTRACIN DE LA CONFIGURACIN...................................................................................... 138
ADMINISTRACIN DE CAMBIOS........................................................................................................... 142
ADMINISTRACIN DE VERSIONES. ...................................................................................................... 145
ADMINISTRACIN DE LOS NIVELES DE SERVICIO. ......................................................................... 147
ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI. ................................................................. 149
ADMINISTRACIN DE LA CAPACIDAD ............................................................................................... 153
ADMINISTRACION DE LA DISPONIBILIDAD....................................................................................... 155
ADMINISTRACIN DE LA CONTINUIDAD........................................................................................... 159
ADMINISTRACIN DE LA SEGURIDAD................................................................................................ 161
TABLA 2.26. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN
DEL SERVICE DESK. ................................................................................................................................. 164

DE INCIDENTES. ........................................................................................................................................ 168
DE PROBLEMAS......................................................................................................................................... 171
DE LA CONFIGURACIN. ........................................................................................................................ 178
DE CAMBIOS. ............................................................................................................................................. 185
DE VERSIONES........................................................................................................................................... 190
DE LOS NIVELES DE SERVICIO.............................................................................................................. 196
FINANCIERA DE LOS SERVICIOS TI...................................................................................................... 200
DE LA CAPACIDAD ................................................................................................................................... 206
DE LA DISPONIBILIDAD. ......................................................................................................................... 212
DE LA CONTINUIDAD. ............................................................................................................................. 216
DE LA SEGURIDAD. .................................................................................................................................. 222
TABLA 2.38. RESULTADO DEL CUMPLIMIENTO DE LOS PROCESOS EVALUADOS................... 229
TABLA 2.39. RESULTADO DEL CUMPLIMIENTO DE ROLES EVALUADOS.................................. 233
xi
RESUMEN
La evaluacin de la prestacin de servicios apoyados por TI1 en la Empresa

Elctrica Quito S.A. ha sido elaborada con el propsito de conocer su nivel de
cumplimiento en base a la administracin de procesos establecidos, tomados
como referencia de las mejores prcticas de ITIL2.
Por otro lado, se realiza la identificacin de roles de acuerdo a los procesos

sealados, tambin bajo el criterio de ITIL.
funciones asentadas a
Estos sern comparados con las
los miembros de la Divisin de Sistemas en la
organizacin para su evaluacin.
La obtencin de informacin para el presente estudio es mediante el uso de

herramientas, las mismas que para su elaboracin se han enfocado en el
cumplimiento de actividades segn el proceso y rol analizado.
Adicionalmente, se da lugar al anlisis de riesgos para cada proceso, basado en

la probabilidad de que estos se hagan realidad de acuerdo a los resultados
obtenidos anteriormente.
Para la presentacin de resultados, se genera un informe tcnico y uno ejecutivo

con el fin de que dichos documentos sirvan de apoyo a la empresa.
Por ltimo se establecen las respectivas conclusiones y se plantean las

recomendaciones acerca del presente proyecto de titulacin.
TI
[Tecnology Information, Tecnologas de Infomacin]
ITIL [Information Technology Infrastructure Library, Biblioteca de la Infraestructura de las Tecnologas de
la Informacin]
2
xii
PRESENTACIN
Este proyecto consiste en el anlisis de la gestin de servicios apoyados por TI

en la Empresa Elctrica Quito S. A., a partir de la utilizacin del marco referencial
ITIL V2.
Este documento est dividido en 3 captulos:
Captulo 1. Corresponde a la evaluacin de la organizacin enfocada al anlisis

de procesos, roles y riesgos relacionados con la gestin de servicios apoyados
por TI.
Aqu se dio paso a la aplicacin de encuestas, entrevistas y guas
elaboradas para la obtencin de la informacin.
Captulo 2. Como resultado de la evaluacin anterior se elaboran dos

documentos, estos son un informe tcnico y uno ejecutivo.
Captulo 3. Se detallan las conclusiones que se ha sacado al evaluar los

procesos de la organizacin, al igual que las recomendaciones, para que se
mejore el manejo de los mismos de acuerdo a las necesidades del negocio.
Cabe recalcar que los anexos fueron presentados en un medio magntico debido
a la magnitud del trabajo.
xiii
14
CAPTULO 1.
ANLISIS DE LA GESTIN DE SERVICIOS CON ITIL
1.1 EVALUACIN DE PROCESOS
1.1.1 ENFOQUE PROCESAL DE ITIL
Actualmente se considera a ITIL como un marco de referencia que describe los

procesos requeridos para el manejo eficiente y efectivo de la infraestructura,
garantizando los niveles de servicio establecidos con la organizacin y sus
clientes, independientemente de la industria o de la tecnologa.3
La versin dos de ITIL propone un conjunto de 7 libros, los mismos que se

muestran en la figura a continuacin:
FIGURA 1. 1. PULICACIONES DE LIBROS DE ITIL

Fuente: Planning to Implement ITSM 2.0 (2002, p.4)
A detalle los procesos de cada uno de los libros indicados son los siguientes:
Fuente: OGC, Planning to Implement ITSM 2.0, Copyright 2002, Version 2.0, Editorial TSO.
15
LIBROS
DESCRIPCIN
Describe la forma
como el cliente
puede tener acceso
Soporte a
a los servicios
Servicios
adecuados para
contribuir a su
negocio.
PROCESOS
Funcin Service Desk
Administracin de Incidentes
Administracin de Problemas
Administracin de la
Configuracin
Administracin de Cambios
Administracin de Versiones.
Administracin de los Niveles
de Servicio.
Describe los servicios

Entrega de
Servicios
que necesita el
cliente y lo esencial
para proporcionar
esos servicios.
Administracin de la
Capacidad.
Administracin Financiera de
los Servicios TI.
Administracin de la
Continuidad del Servicio.
Administracin de la
Disponibilidad.
Cubre los aspectos
Administracin de la Seguridad.
relacionados con la
Gestin de la
Seguridad
administracin del
aseguramiento
lgico de la
informacin.
Identifica los
Gestin del servicio de redes.
requerimientos del
Gestin del servicio de
Gestin
negocio a travs de la
de la
realizacin de pruebas,
Infraestructura
instalacin, desarrollo y
soporte de los
componentes y los
operaciones.
Gestin del servicio de
instalacin.
Gestin de aceptacin de
ordenadores.
16
Gestin de centros
servicios TI.
distribuidos.
Gestin de sistemas.
Se encarga del
Gestin de
Aplicaciones
control y manejo de
las aplicaciones
operativas y en fase
Soporte
al ciclo de vida del
software.
Anlisis de un servicio TI para su
uso operativo.
de desarrollo.
Gestin de la Continuidad del
Negocio.
Presta atencin al
La Perspectiva
de Negocio
conocimiento de la
provisin de servicios TI.
Asociaciones y
externalizacin.
Gestin de cambios para la
supervivencia.
Gestin de la adaptacin del
negocio a los cambios
radicales.
Planificacin de
la
implementacin
de la Gestin de
Servicios
Identifica como una
Mejora Continua.
organizacin puede
Experiencia en la planificacin de
esperar
programas para optimizar la
beneficiarse de ITIL,
gestin de servicios de TI.
y que hacer para

recoger
estos
beneficios.
TABLA 1.1. PROCESOS DE ITIL DE ACUERDO A CADA UNA DE SUS PUBLICACIONES
Fuente: Planning to Implement ITSM V. 2.0, 2002
Elaborado por: La Autora
1.1.2
SELECCIN DE LOS PROCESOS A SER EVALUADOS EN LA EMPRESA
Para la evaluacin de los procesos apoyados por las tecnologas de informacin,

se ha tomado los dos ms representativos o llamados Corazn de ITIL, que son
17
Soporte y Entrega de Servicios, as como tambin Gestin de la Seguridad, con el

fin de enfocar la evaluacin hacia el objetivo estratgico de la empresa que es el
Uso y Desarrollo de Tecnologa de Punta.
Cabe recalcar, que la seleccin de procesos ha sido realizada en base a los

requerimientos de la Divisin de Sistemas de la organizacin.
Los procesos a ser evaluados, de acuerdo a cada libro seran los siguientes:
LIBROS
PROCESOS A EVALUAR
Funcin Service Desk.
Administracin de Incidentes.
IMPLEMENTADO
FORMALMENTE
Si
No
X
X
Soporte a
Administracin de Problemas.
Servicios
Administracin de la Configuracin
Administracin de Cambios.
Administracin de Versiones.
Administracin de los Niveles de

Servicio.
Entrega de
Servicios
Administracin de la Capacidad.
Administracin Financiera de los
Servicios TI.
Administracin de la Continuidad
del Servicio.
X
X
X
Administracin de la Disponibilidad.
Administracin de la Seguridad.
Gestin de
la
Seguridad
TABLA 1.2. PROCESOS A EVALUAR EN LA EEQ S.A EN BASE A ITIL.
18
1.1.2.1 Actividades/Subprocesos a evaluarse por cada proceso seleccionado.
PROCESOS
Funcin Service Desk
ACTIVIDADES/SUBPROCESOS
Ser el punto nico de contacto de TI hacia los

usuarios internos y externos.
Registrar
dar
seguimiento
incidentes,
requerimientos y cambios estndares.
Evaluacin inicial de requerimientos e incidentes.
Enlace con proveedores.
Administrar
expectativas
definidas
en
los
acuerdos de servicio.
Promover los servicios.
Administracin de
Deteccin y registro de incidentes.
Incidentes
Clasificacin y soporte inicial del incidente.
Investigacin y diagnstico del incidente.
Cierre del incidente.
Monitoreo,
seguimiento
comunicacin
manejo de incidentes.
Administracin de
Problemas
Control de problemas.
o Identificacin y registro.
o Clasificacin y asignacin.
o Investigacin y diagnstico.
o Solucin y cierre.
Control de errores conocidos.

o Identificacin y registro de errores.
o Investigacin de la solucin.
del
19
o Definicin de la solucin seleccionada.

o Evaluacin del problema.
o Cierre de errores y problemas asociados.
Administracin proactiva de problemas.
Administracin de la
Planeacin.
Configuracin
Identificacin
de
los
elementos
de
la
infraestructura.
Control del proceso.
Monitoreo del estatus.
Verificacin.
Reportes.
Administracin de
Registro de una peticin de cambio.
Cambios
Aceptacin.
Clasificacin, categora y prioridad.
Planeacin, impacto y recursos para el cambio.
Coordinacin para la implantacin del cambio.
Evaluacin y cierre.
Definicin de poltica y planeacin de una
Administracin de
Versiones
versin.
Diseo y desarrollo o compra.
Contruccin/Configuracin.
Prueba y aceptacin.
Planeacin roll out.
Comunicacin, preparacin y capacitacin.
Distribucin e instalacin.
20
Administracin de los
Identificar necesidades.
Niveles de Servicio
Definir servicios y requerimientos.
Realizar negociaciones y contratos a nivel interno

y externo (SLA4, OLA5, UC6).
Monitoreo.
Reportes.
Revisin y mantenimiento de contratos.
Administracin Financiera
Presupuesto.
de los Servicios TI
Contabilidad.
Cargos.
Reportes.
Administracin de la
Administracin de la Capacidad del negocio.
Capacidad
Administracin de la Capacidad del servicio.
Administracin de la Capacidad de los recursos.
Administracin de la
Iniciacin (definicin del alcance).
Continuidad del Servicio
Requerimientos y estrategia a seguir.
Implementacin de planes de recuperacin.
Administracin de la operacin.
Planeacin.
Administracin de la
Disponibilidad
o Requerimientos de disponibilidad.
o Diseo de la disponibilidad y recuperacin
de la infraestructura TI.
SLA [Service Level Agreement, Acuerdo de Nivel de Servicio]

OLA [Operational Level Agreement, Acuerdo de Nivel Operacional]
6
UC [Underpinning Contract, Contrato de Servicio Acordado]
5
21
o Aspectos de seguridad.
o Definicin de metas para la confiabilidad,
mantenimiento y servicio.
o Desarrollo del plan de disponibilidad.
Monitoreo.
o Medicin y reportes.
Administracin de la
Planear polticas internas de seguridad.
Seguridad
Implementar.
Evaluar.
Mantener.
Controlar.
TABLA 1.3. ACTIVIDADES/SUBPROCESOS A EVALUAR POR CADA PROCESO

SELECCIONADO
Fuentes: Service Support, Copyright 2000, Version 1.3, Service Delivery, Copyright 2001, Version
2.1, Security Management, Copyright 1998, Version Beta.
1.1.3
REALIDAD DE LA ORGANIZACIN
La Empresa Elctrica Quito, S.A. [EEQ. S.A.], es una empresa de servicios

pblicos, que busca proporcionar servicios de calidad,
para esto est
adaptando ITIL como un marco de referencia en el cual guiarse.
El objetivo estratgico de la empresa apunta al Uso y Desarrollo de Tecnologa

de Punta, en donde la Divisin de Sistemas apoya a este como rea,
desarrollando proyectos y aplicaciones que apoyen a los procesos operativos y
administrativos de la organizacin soportados en una infraestructura informtica
de alta disponibilidad y ltima tecnologa, as como tambin aplicando procesos
alineados a la calidad del servicio al usuario.
22
Los procesos en la EEQ S.A. estn organizados de tal forma que representan la
estructura de la organizacin, la misma que se detalla en el Anexo A.
A continuacin se muestra en la Tabla 1.4 los procesos apoyados por las

tecnologas de informacin en la EEQ. S.A., con su respectivo responsable y
objetivos a largo plazo.
MACROPROCESO: SUMINISTRO DE ENERGA
PROCESO
RESPONSABLE
OBJETIVOS A LARGO PLAZO

Disponer de energa suficiente y
sustentable.
Clientes satisfechos.
Recurso
humano
capacitado,
comprometido y motivado.
Gestin de la
Direccin
Gestin Profesional.
Gerente General
Finanzas sanas.
Rendicin
de
cuentas
auditora social.
Uso y Desarrollo de Tecnologa
de Punta.
Cumplimiento
del
Plan
Estratgico.
Planificacin de la
Expansin del
Sistema de
Potencia
Gestin de
Recursos
Finanzas sanas.
Jefe Divisin de
Planificacin
Rendicin de cuentas y
auditora social.
Director de
Finanzas
Finanzas sanas.
Compra/Venta de
energa en el MEM
Director Tcnico
sustentable.
23
Generacin de la
Energa Elctrica
Trmica
Proceso de
Transmisin
Director Tcnico
Finanzas sanas.
Director Tcnico Clientes satisfechos.

Proceso de
Distribucin
Director de
Distribucin
sustentable.
Finanzas sanas.
Proceso de
Comercializacin
Director de
Comercializacin
Finanzas sanas.
Recurso humano capacitado,
Proceso de
Relaciones
Industriales
Director de
Relaciones
Industriales
comprometido y motivado.
Gestin profesional.
Finanzas sanas
Proceso de
Sistemas
Jefe Divisin de Uso y desarrollo de tecnologa

Sistemas
de punta.
TABLA 1.4. PROCESOS APOYADOS POR LAS TI EN LA EEQ S.A.

Fuente: En base al Plan Estratgico de la EEQ S.A. 2006-2010
Informacin mas ampliada acerca de los procesos manejados en la EEQ S.A. y

de sus objetivos a largo y corto plazo se encuentra en el Anexo C.
Para poder tener conocimiento de cmo se apoyan a dichos procesos se
analizar los objetivos a corto plazo manejados por la Divisin de Sistemas, as
como tambin sus subprocesos, persona responsable
muestra en la Tabla 1.5 a continuacin:
y estrategias. Esto se
24
OBJETIVOS
SUBPROCESOS
RESPONSABLE
ESTRATEGIAS
No
1
Definicin
Implementacin del sistema de mantenimiento de
centrales y subestaciones.
Implantar y potencializar el sistema de atencin al
cliente en el mbito empresarial.
Analizar, disear, construir e implementar el sistema
3 de digitalizacin de documentos de clientes en el

mbito empresarial.
Apoyar en el desarrollo
de proyectos que
Ingeniera de
Administrador del Grupo de
requieren
Software
Ingeniera de Software
automatizacin
Implementar el sistema de recaudacin en lnea en

agencias rurales.
Analizar,
disear
implantar
aplicaciones
con
tecnologa mvil.
Implementar el sistema de registro y control de
seguimiento de trmites a nivel empresarial.
Implementar el sistema de gestin de informacin
financiera.
Analizar, desarrollar e implementar el sistema de
8 automatizacin SGC.
25
Hardware y
comunicaciones

Soporte de Infraestructura
Informtica
Soporte e
Investigacin de
Software
Informtica
Hardware y
Ejecutar proyectos de
infraestructura
informtica
comunicaciones
Soporte e
investigacin de
Informtica
10
Implantar
nuevos
sistemas
de
seguridad
en
comunicaciones y redes.
Actualizar tecnolgicamente estaciones de trabajo de

los usuarios.
11 Inventario de hardware y software.
12 Utilizacin de software de tecnologa abierta.
Software
Hardware y
comunicaciones
Administracin
de sistemas y
bases de datos
Administracin
de sistemas y
bases de datos

13
Informtica
Sistemas y Bases de Datos

Instalar infraestructura de comunicaciones y redes de

alta disponibilidad y rendimiento.
Implantar nuevos sistemas de seguridad para control
14 de acceso a sistemas, mantenimiento y desarrollo de

sistemas y polticas.
15
Instalar
infraestructura
de
disponibilidad y rendimiento.
servidores
de
alta
26
Creacin, estructuracin e implantacin del rea de

Sistemas
Jefe Divisin de Sistemas
16 help desk como nico punto de atencin al cliente

interno.
Ejecutar proyectos de
mejora en los sistemas

Sistemas
informticos para
soporte al uso interno.
17
Informtica
Soporte
Informtico e
Investigacin de
software

Informtica
18
Implantacin de software especializado para Mesa de

Ayuda (Help Desk).
Implantar un sistema de encuestas para medir la

satisfaccin del usuario interno de sistemas.
TABLA 1.5. OBJETIVOS, SUBPROCESOS, RESPONSABLES Y ESTRATEGIAS DEL PROCESO DE SISTEMAS EN LA EEQ S.A.
Fuente: En base al Plan Estratgico de la EEQ S.A. 2006-2010 y al documento Funciones Orga_Propuesto_06-02-2007
27
1.1.4
MAPEO DE LOS PROCESOS MANEJADOS POR ITIL VS. LOS

SUBPROCESOS DE LA DIVISIN DE SISTEMAS.
A continuacin se muestra en la Tabla 1.6, la relacin que existe entre los

procesos de ITIL seleccionados para la evaluacin con los subprocesos de la
Divisin de Sistemas que sirven como apoyo a los servicios TI manejados en la
empresa.
PROCESOS DE ITIL
Funcin Service Desk

Administracin de
Incidentes
Administracin de
SUBPROCESO DE LA DIVISION DE
SISTEMAS
Soporte e investigacin de Software
12
Sistemas
16, 17
Soporte e Investigacin de Software
10
Problemas
Administracin de la
Configuracin
Administracin de
Cambios
Administracin de
Versiones
11
10
1, 2, 3, 4, 5, 6, 7, 8
Hardware y comunicaciones
9, 11, 13
Sistemas
17
Soporte Informtico e Investigacin
Niveles de Servicio
de software
de los Servicios TI
Administracin de la
Capacidad
Administracin de la
Disponibilidad
10
Administracin Financiera
JUSTIFICACIN
BASADA EN EL
NMERO DE
ESTRATEGIA USADA
18
No existe
10
13
28
Administracin de la
Continuidad
Administracin de la
Seguridad
Soporte e investigacin de Software
12
Administracin de sistemas y bases
14,15
de datos
TABLA 1.6. MAPEO DE LOS PROCESOS MANEJADOS POR ITIL VS. SUBPROCESOS DE LA
DIVISIN DE SISTEMAS.
Como se puede observar, no existe un subproceso que pueda ser relacionado

con el proceso de Administracin Financiera de los Servicios TI manejado por
ITIL. En este caso, se orientar la evaluacin hacia las actividades manejadas
por el Departamento de Planificacin Informtica al realizar la planeacin de un
proyecto en funcin de los recursos necesarios para llevarlos a cabo.
1.1.5
APLICACIN DE ITIL PARA EL ANLISIS DE
LOS PROCESOS
SELECCIONADOS.
De acuerdo a los procesos seleccionados, el anlisis de estos consistir en

determinar su nivel de cumplimiento, basado en la aplicacin de encuestas y
entrevistas, las mismas que se exponen en el Anexo D y E respectivamente.
Para la elaboracin de las encuestas se ha tomado como gua los componentes

de un proceso, segn el marco de referencia ITIL.
muestran en la Figura 1.2.
Dichos componentes se
29
Controles del Proceso

Meta del
Proceso
Dueo
del
Proceso
Calidad,
Indicadores, KPIs
Proceso
Actividades y Subprocesos
Entradas
Salidas
Gente y
Roles
Recursos:
equipo,
Tecnologa
Facilidades del Proceso

FIGURA 1. 2. REPRESENTACIN DE UN PROCESO EN BASE A SU ESTRUCTURA SEGN
ITIL
1.1.5.1 Clculos aplicados para la obtencin del Porcentaje de Cumplimiento de los

Procesos
Para poder obtener resultados acorde a la realidad de la empresa se han aplicado
pesos a cada una de las posibles respuestas en las encuestas usadas para la
obtencin de informacin. Estos pesos se exponen en la Tabla 1.7.
POSIBLE RESPUESTA PESO ASIGNADO

Si
100%
Parcialmente
50%
No
0%
S/R
0%
TABLA 1.7. PESOS PARA POSIBLES RESPUESTAS PARA LA EVALUACIN DE PROCESOS

30
Los clculos que se aplicaran a cada una de las preguntas de las encuestas para
la obtencin de porcentajes de cumplimiento del proceso o procesos evaluados
son los siguientes:
Para obtener el 100% de respuestas o total de respuestas se realizar la

siguiente operacin:
Total = (# Resp. Si + # Resp. No + # Resp. Parcial + # S/R) * 100
En donde:
# Resp. Si: Nmero de respuestas de si.
# Resp. No: Nmero de respuestas de no.
# Resp. Parcial: Nmero de respuestas de parcialmente.
# S/R: Nmero de preguntas sin respuesta.
Para obtener el porcentaje de respuesta parcial, se aplicar cada uno de los

pesos de la Tabla 1.4 de la siguiente forma:
Porcentaje parcial =
# Resp. Si * 100 + (# Resp. No + # S/R) * 0

+ # Resp. Parcial * 50
En donde:
# S/R: Nmero de preguntas sin respuesta.
Una vez obtenidos los dos valores anteriores procedemos a hacer la siguiente
regla de tres:
31
Total
100 %
Porcentaje Parcial
Por lo tanto el valor de X es el porcentaje de cumplimiento de un proceso

especfico.
1.1.5.2 Mtodo de Interpretacin de Resultados

Una vez obtenido los valores de los porcentajes de cumplimiento de cada proceso
se determinar la criticidad de cada uno de stos en base a la Tabla 1.8, en
donde los rangos presentados han sido seleccionados de tal forma que tengamos
un criterio ms fino y ms aplicable a cada una de las preguntas de las encuestas
usadas.
Dicha tabla se presenta a continuacin:
NOMENCLATURA
B
CALIF. %
BAJO
GC
NR
MB
15%
50%
MM
MODERADO MODERADO
51%
59%
MB
MA
MA
MODERADO ALTO
60%
66%
MM
MM
67%
75%
MA
MB
GC
GRADO DE CONFIANZA
76%
95%
NR
NIVEL DE RIESGO
MODERADO BAJO
ALTO
TABLA 1.8. INTERPRETACIN DE RESULTADOS PARA EL CUMPLIMIENTO DE UN

PROCESO EN BASE AL CUADRO SUGERIDO POR EL COSO7 USADO EN AUDITORA
INTERNA DE LA E.PN.
1.1.5.3 Evaluacin de Resultados

La evaluacin de los resultados se realizar considerando a cada proceso como
un objeto de medicin, cuyo procedimiento de estudio ser el siguiente:
7
COSO [Committee of Sponsoring Organizations of the Treadway Commission, Comit de Organizaciones

Patrocinadoras de la Comisin de Intercambio ]
32
1. Se realizar la tabulacin de resultados de las encuestas aplicadas para el

levantamiento de la informacin relacionada con el proceso a evaluarse.
2. Una vez tabulados los resultados, se aplicarn los clculos indicados en la

seccin 1.1.5.1 con el fin de obtener su porcentaje de cumplimiento.
3. Se ordenarn las preguntas de acuerdo a su porcentaje de cumplimiento.

Dicho ordenamiento ser en forma ascendente.
4. Se identificarn los factores crticos de cumplimiento en base al mtodo de

interpretacin establecido en la seccin 1.1.5.2.
5. Se realizar una interpretacin grfica de los resultados tomando como

referencia el aporte de cada uno al cumplimiento del proceso.
6. Se identificar la media de cumplimiento del proceso evaluado.
7. Se darn recomendaciones que permitan mejorar al menos en un porcentaje

los factores crticos detectados.
La presentacin de los resultados de esta evaluacin puede se visualizada en la

seccin 2.1.1.4.1
Informe Tcnico.
del Captulo 2 de este proyecto, ya que forman parte del
33
1.2 ANLISIS DE ROLES

1.2.1
MAPEO DE ROLES DE LOS PROCESOS SELECCIONADOS DE ITIL VS.

LOS ROLES MANEJADOS EN LA DIVISIN DE SISTEMAS
A continuacin se muestra en la Tabla 1.9, la relacin establecida entre los roles

identificados en los procesos antes seleccionados en base a ITIL con los
existentes en la Divisin de Sistemas. Estos ltimos sern referidos en base al
Anexo B, en donde se pueden tambin identificar las funciones a cumplir por cada
uno de estos, las mismas que servirn como justificacin de dicha relacin.
Se sobreentiende que el resto de personal de la empresa que utilicen los servicios

TI, son los usuarios de la Divisin de Sistemas.
PROCESOS ROLES DE LOS PROCESOS

DE ITIL
Administracin del Service

Desk
Desk
Funcin Service
DE ITIL
ROLES DE LA DIVISION DE
SISTEMAS EEQ S.A.
Administrador del Grupo de Soporte

de Infraestructura Informtica
Equipo de Help Desk que es parte

Equipo de Service Desk
del
Grupo
de
Soporte
de
Infraestructura Informtica
Problemas
Admin. de
Admin. de Incidentes
Administracin de
Incidentes

Equipo de Help Desk que es parte
Manejo de Incidentes
del
Grupo
de
Soporte
de
Soporte 2do Nivel
Administracin de
Problemas
Soporte de Problemas
Grupo de Soporte de Infraestructura

Informtica
Informtica
Configuracin
Admin. de la
34
Administracin de la
Configuracin
Custodia de la
Configuracin
Informtica
Admin. de Cambios
Consejo Asesor de
Cambios
Administrador
del
Grupo
de
Grupo
de
Administrador
del
Ingeniera de Software, Jefe de

Sistemas
Comit de Emergencia del

Consejo Asesor de
Jefe de Sistemas
de Servicio
Servicios TI
Versiones
los Niveles
Financiera de los
Capacidad
Admin. de
Admin. de la
Admin.
Admin. de
Cambios
Administracin de
Versiones
Soporte en Sitio
niveles de servicio
Administrador
del
Grupo
de
Grupo de Ingeniera de Software
Administrador
del
Grupo
de
Planificacin Informtica
Administracin de finanzas
para el rea de TI
Administracin de la
Capacidad
No existe

Administracin de la red,
Grupo
de
Administracin
sistemas y aplicaciones
hardware y comunicaciones
de
Disponibilidad
Admin. de la
35
Administracin de la
Disponibilidad
Continuidad
Admin. de la
Administracin de la
continuidad
Lderes y miembros de
Soporte
de
Directorio y Gerencia General

Divisin de Sistemas en su conjunto
Administradores
de
cada
equipos para el manejo de Departamento de la Divisin de

la continuidad
Seguridad
Directores y Gerentes
Admin. de la
Administrador
Sistemas
Administracin de la
Seguridad.
Administrador
del
Grupo
de
TABLA 1.9. ROLES IDENTIFICADOS EN BASE A LOS MANEJADOS POR ITIL

Como se puede observar, no existe una persona o grupo de personas que se

encarguen o se los pueda relacionar con la Administracin Financiera de los
Servicios TI manejado por ITIL. En este caso, se orientar la evaluacin de dicho
rol a las funciones desempeadas para la planeacin de un proyecto.
1.2.2
APLICACIN
DE
ITIL
PARA
EL
ANLISIS
DE
LOS
ROLES
SELECCIONADOS
De acuerdo a los roles seleccionados, el anlisis de estos consistir en determinar
su nivel de cumplimiento, basado en la aplicacin de guas, las mismas que se
exponen en el Anexo G.
36
Para la elaboracin de estas guas se ha tomado como base las funciones que
deben cumplir las personas involucradas por cada proceso evaluado segn el
marco de referencia ITIL y se les ha agrupado de acuerdo a un rol especfico.
La informacin para completar las guas elaboradas, ser tomada de la estructura

funcional de la Divisin de Sistemas de la EEQS.A expuesta en el Anexo B, as
como tambin las encuestas y entrevistas utilizadas en la seccin 1.1, las mismas
que se detallan en los Anexos D y E respectivamente.
1.2.2.1 Clculos aplicados para la obtencin del porcentaje de cumplimiento de roles

Para obtener resultados acorde a la realidad de la empresa se han aplicado pesos
a cada una de las posibles respuestas de las funciones presentadas por cada rol
en cada una de las guas. Estos pesos se exponen en la Tabla 1.10.
POSIBLE RESPUESTA PESO ASIGNADO

Si
100%
Parcialmente
50%
No
0%
TABLA 1.10. CUADRO DE PESOS PARA POSIBLES RESPUESTAS PARA EL ANLISIS DE

ROLES
Los clculos que se aplicaran a cada una de las funciones que se debe cumplir
para la obtencin de porcentajes de cumplimiento por cada unos de los roles
evaluados son los siguientes:
Para obtener el 100% de respuestas o total de respuestas se realizar la

siguiente operacin:
Total = (# Resp. Si + # Resp. No + # Resp. Parcial) * 100
En donde:
37

Para obtener el porcentaje de respuesta parcial, se aplicar cada uno de los

pesos de la tabla 1.18 de la siguiente forma:
Porcentaje parcial = # Resp. Si * 100 + # Resp. No * 0
+
# Resp. Parcial * 50
En donde:
Una vez obtenidos los dos valores anteriores procedemos a hacer la

siguiente regla de tres:
Total
100%
Porcentaje Parcial
Por lo tanto el valor de X es el
porcentaje de cumplimiento de las
funciones correspondientes a un rol especfico.
1.2.2.2 Mtodo de Interpretacin de Resultados

Para la interpretacin de resultados, una vez obtenido los valores de los
porcentajes de cumplimiento de cada uno de los roles,
se
determinar la
criticidad de estos en base a la Tabla 1.8 usada en la seccin 1.1.5.2 para el

anlisis correspondiente.
38
La evaluacin de los resultados obtenidos tras la aplicacin de las guas se

realizar considerando nuevamente a cada proceso como un objeto de medicin,
en el cual sus parmetros sern los roles definidos para este.
El procedimiento de evaluacin ser el siguiente:
1. Se agrupar las funciones establecidas en las guas aplicadas y se realizar la

tabulacin de resultados por cada rol establecido para el proceso evaluado.
2. Una vez tabulados los resultados, se aplicarn los clculos indicados en la

seccin 1.2.2.1 con el fin de obtener su porcentaje de cumplimiento.
3. Se ordenarn los roles de acuerdo a su porcentaje de cumplimiento. Dicho

ordenamiento ser en forma ascendente.
4. Se identificarn los factores crticos de cumplimiento de cada rol tomando

como referencia las funciones establecidas en las guas.
El mtodo de
interpretacin de estos resultados ser el establecido en la seccin 1.2.2.2.
5. Se realizar una interpretacin grfica de los resultados tomando como

referencia el aporte de cada rol al cumplimiento del proceso.
6. Se identificar la media de cumplimiento del proceso evaluado en funcin de

los roles.
7. Se darn recomendaciones que permitan mejorar al menos en un porcentaje

los factores crticos detectados.
La presentacin de los resultados de este anlisis puede se visualizada en la

seccin 2.1.1.4.2
Informe Tcnico.
39
1.3 ANLISIS DE RIESGOS

1.3.1
ANLISIS DE ESTIMACIN DE RIESGOS
1.3.1.1 Identificacin de Riesgos

La identificacin de riesgos se realizar en base a los anlisis realizados en los
dos puntos anteriores.
1.3.1.2 Categorizacin de Riesgos

La categorizacin riesgos ser en base a la Tabla 1.11 expuesta a continuacin:
Smbolo
Descripcin
BU
Implica un riesgo del negocio.
TE
Implica riesgo tecnolgico
BG
Implica riesgo de presupuesto.
DE
Implica riesgo de manejo de desarrollo del proceso.
PE
Implica riesgo de personal.
TABLA 1.11. TABLA DE CATEGORIZACIN DE RIESGOS

Fuente: Basado en la Elaboracin de un Anlisis de Riesgos tomado de Pressman R., Ingeniera del
Software, 4ta Edicin
1.3.1.3 Mtodo de Interpretacin del Impacto de Riesgos

La descripcin del valor del impacto asignado a cada riesgo, ser de acuerdo a la
Tabla 1.12 mostrada a continuacin:
40
Impacto
Valor del Impacto
Catastrfico
Significado
Dejar de cumplir las actividades de un proceso
provocara el fracaso del mismo.
Crtico
degradara el rendimiento del mismo hasta un punto

donde el xito de este sea cuestionable.
Marginal
provocara una mnima o pequea reduccin en el

rendimiento del mismo.
TABLA 1.12. TABLA DE IMPACTO DE RIESGOS

Fuente: Basado en la Tabla de Evaluacin del Impacto tomado de Pressman R., Ingeniera del Software
4ta Edicin
1.3.1.4 Clculos aplicados para la obtencin del Porcentaje de Riesgo

Se determinar el valor del riesgo basado en la siguiente frmula:
RIESGO = Probabilidad2 * Impacto
De donde:
La Probabilidad2 est dada por la probabilidad de que el riesgo se

haga realidad, la misma que ser asignada por la autora de este
proyecto tomando como referencia los resultados de los anlisis
anteriores. A este valor para ser usado correctamente en la frmula se
debe aplicar la siguiente conversin:
Probabilidad2= Probabilidad asignada %
100%
El impacto ser asignado de acuerdo a la Tabla 1.12, tomando en

cuenta las consecuencias que podra traer a la empresa el seguir
manejando los procesos evaluados como hasta ahora.
41
1.3.1.5 Mtodo de interpretacin de la Probabilidad de Riesgo

La criticidad de cada uno de los valores de probabilidad determinados ser
interpretada de acuerdo a la Tabla 1.13 que se muestra a continuacin:
NOMENCLATURA
CALIF.
PR
BAJO
0,15
0, 50
MB
0,51
0,59
MB
MM
MODERADO BAJO
MODERADO MODERADO
0,60
0,66
MM
MA
MODERADO ALTO
0,67
0,75
MA
0,76
0,95
PR
ALTO
PROBABILIDAD DE RIESGO
TABLA 1.13. INTERPRETACIN DE RESULTADOS DE LA PROBABILIDAD DE RIESGO EN

BASE AL CUADRO SUGERIDO POR EL COSO USADO EN AUDITORA INTERNA DE LA
E.PN.
1.3.1.6 Mtodo de Interpretacin de Riesgos

Una vez establecido los valores tanto para la probabilidad como para el impacto
se podr definir la criticidad del riesgo en base a Tabla 1.14.
Dicha tabla se presenta a continuacin:
PROBABILIDAD
Marginal
(1)
IMPACTO
Crtico
(2)
Catastrfico
(3)
Baja
(0,15 0,50)
Riesgo Trivial
Riesgo Tolerable
Riesgo Moderado
Media
(0,51 - 0,75)
Riesgo Tolerable
Riesgo Moderado
Riesgo Importante
Alta
(0,76 0,95)
Riesgo Moderado
Riesgo Importante
Riesgo Intolerable
TABLA 1.14. INTERPRETACIN DE RIESGOS BASADO EN EL DOCUMENTO

"EVALUACIN DE RIESGOS LABORALES DEL SINDICATO PROTECTOR DE
TRABAJO NACIONAL" - MADRID. 1996.
42

La evaluacin de resultados ser realizada en base a la elaboracin de tablas de
riesgos para cada uno de los procesos seleccionados como objeto de medicin.
El procedimiento de desarrollo de dichas tablas se describe a continuacin:
1. Se identificar los riesgos que posiblemente podran afectar a cada proceso en

la implementacin y mantenimiento de estos de acuerdo a los anlisis
anteriores.
2. Se realizar una categorizacin de cada riesgo basado en la Tabla 1.11.
3. Se asignar un valor de probabilidad de que el riesgo se haga realidad al

mismo que se aplicarn los clculos correspondientes tal como se muestra en
la seccin 1.3.1.4.
4. Se asignar un valor de impacto para cada riesgo, tomado como referencia la

descripcin de cada uno, tal como se encuentra en la seccin 1.3.1.3.
5. Se determinar el valor del riesgo de acuerdo a los clculos sealados en la

seccin 1.3.1.4.
6. Se ordenarn los datos encontrados de acuerdo al anlisis anterior en funcin

del riesgo.
7. Se darn medidas de salvaguarda a cada riesgo con el objetivo de reducirlos

al menos a un nivel tolerable.
La presentacin de los resultados de este anlisis puede se visualizada en la

seccin 2.1.1.4.3
Informe Tcnico.
43
CAPITULO 2.
PRESENTACIN DE RESULTADOS
2.1
ELABORACIN DEL INFORME TCNICO
Este informe permitir tener una visin ms amplia de cmo se han estado
manejando los procesos seleccionados como objetos de medicin en la
organizacin, an cuando la mayora de estos no hayan sido implementados
formalmente.
Este informe se estructurar de modo que permita visualizar los procedimientos

realizados para la obtencin de resultados una vez aplicadas las herramientas
para la obtencin de informacin, as como tambin el anlisis respectivo de
acuerdo a los criterios considerados en el Captulo 1.
2.1.1
ACTIVIDADES REALIZADAS PARA EL DESARROLLO DEL INFORME

TCNICO
2.1.1.1
Establecimiento de Herramientas para la obtencin de Informacin
Las herramientas para la obtencin de la informacin sern asignadas de acuerdo

al tipo de anlisis requerido tal como se muestra en la Tabla 2.1.
TIPO DE ANLSIS
HERRAMIENTA
UBICACIN
Encuestas
Anexos D y E
Entrevistas
respectivamente
Anlisis de Roles
Guas de evaluacin
Anlisis de Riesgos
Observacin y deduccin
Evaluacin de Procesos
Anexo G
-
TABLA 2.1. HERRAMIENTAS PARA LA OBTENCIN DE INFORMACIN

44
2.1.1.2
Sesiones para la Obtencin de Informacin
Las sesiones para la obtencin de la informacin fueron establecidas en un

acuerdo mutuo con el Ing. Carlos Benavides, Jefe del Grupo de Planificacin
Informtica, al mismo que se le ha entregado los resultados obtenidos tras cada
tipo de anlisis realizado para la revisin respectiva de este.
Las fechas entre las cuales se realiz la recoleccin de informacin fueron desde
el da 2 de octubre de 2007 hasta el da 16 de enero del presente ao,
Se realizaron alrededor de 2 sesiones por semana a partir de la fecha antes

mencionada, en las cuales el primer da se haca la entrega de las encuestas
relacionadas con el proceso a ser evaluado, mientras que en el segundo da se
realizaba la entrevista con relacin al mismo. La recoleccin de las encuestas,
una vez llenadas por las personas del rea de TI era en la segunda sesin.
2.1.1.3
Anlisis de Resultados
El anlisis de resultados ser realizado en base a los procedimientos establecidos

en las secciones 1.1.5.3, 1.2.2.3 y 1.3.1.7 dentro del Captulo 1 de este proyecto
de titulacin.
45
2.1.1.4
Presentacin de Resultados
2.1.1.4.1
Resultados de la Evaluacin de Procesos
PROCESOS OPERATIVOS O DE SOPORTE A SERVICIOS
OBJETO: GESTIN DE SERVICE DESK

TABULACIN DE RESULTADOS
ORDEN POR NMERO DE PREGUNTA
#
PREG.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
SI
NO
PARC
S/R
5
3
5
4
6
4
0
2
0
1
1
1
3
3
3
3
1
2
0
0
0
0
0
1
%
CUMPLIM.
81,25
56,25
81,25
68,75
81,25
62,5
3
1
3
0
4
5
0
0
0
5
6
6
0
2
5
4
3
3
0
0
1
5
4
5
5
0
0
0
0
3
5
1
2
1
0
8
8
7
0
0
0
3
3
0
2
2
1
7
4
5
0
2
1
1
3
7
2
6
2
2
3
5
3
3
0
0
1
3
2
2
4
3
3
1
3
4
1
4
2
3
2
2
2
5
1
6
2
0
0
1
1
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
50
25
56,25
31,25
68,75
81,25
0
0
6,25
81,25
87,5
87,5
25
43,75
81,25
56,25
56,25
62,5
6,25
25
25
81,25
62,5
75
75
31,25
6,25
37,5
12,5
ORDEN POR PORCENTAJE DE

CUMPLIMIENTO DEL SERVICE DESK
%
#
SI NO PARC S/R
CUMPLIM.
PREG.
13
0
8
0
0
0
14
0
8
0
0
0
39
0
8
0
0
0
15
0
7
1
0
6,25
25
0
7
1
0
6,25
33
0
7
1
0
6,25
40
35
8
19
26
27
36
37
10
32
34
20
45
7
2
9
22
23
6
24
29
38
42
44
4
11
30
31
43
0
0
1
0
0
1
1
2
0
0
0
2
3
3
3
3
4
3
4
3
4
4
4
5
4
4
5
5
5
7
6
5
3
4
5
5
6
2
3
2
3
3
3
2
1
2
2
1
1
2
2
2
3
1
1
1
1
1
1
2
2
4
4
2
2
0
5
5
6
3
1
2
3
3
1
3
2
4
2
2
2
0
3
3
2
2
2
0
0
0
1
0
0
0
0
1
0
0
0
1
0
0
1
1
0
1
0
0
0
0
0
0
0
0
0
0
6,25
12,5
25
25
25
25
25
25
31,25
31,25
37,5
43,75
43,75
50
56,25
56,25
56,25
56,25
62,5
62,5
62,5
62,5
62,5
62,5
68,75
68,75
75
75
75
46
36
37
38
39
40
41
42
43
44
45
1
2
4
0
0
6
4
5
5
3
5
6
2
8
7
1
2
1
3
3
2
0
2
0
1
1
2
2
0
1
0
0
0
0
0
0
0
0
0
1
25
25
62,5
0
6,25
81,25
62,5
75
62,5
43,75
1
3
5
12
16
21
28
41
17
18
5
5
6
5
5
5
5
6
6
6
0
0
1
0
0
0
0
1
0
0
3
3
1
3
3
3
3
1
2
2
0
0
0
0
0
0
0
0
0
0
81,25
81,25
81,25
81,25
81,25
81,25
81,25
81,25
87,5
87,5
GRFICO
PORCENTAJE DE CUMPLIMIENTO DEL SERVICE DESK
100
90
80
70
60
50
40
30
20
10
0
1
9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DEL SERVICE DESK
MEDIA
49,2%
Los factores crticos detectados en la administracin del Service Desk son:
El Service Desk no maneja costos de los servicios prestados.
El Service Desk no da soporte a la integracin y administracin de cambios a

travs de negocios distribuidos y tecnologa.
No se evala la calidad de prestacin de servicios por parte de la persona

que dio el soporte.
Se maneja en un mnimo porcentaje el registro y seguimiento de incidentes,

requerimientos y cambios estndares.
La evaluacin de la satisfaccin de los clientes es casi nula.
El Service Desk no tiene relacin con proveedores de servicios para dar

mantenimiento externo.
El Service Desk no dispone de toda la informacin de servicios de la
47
empresa.
El Service Desk ayuda a identificar oportunidades de negocio tan solo en un

25%.
El Service Desk administra vagamente las expectativas definidas en los

acuerdos de nivel de servicio.
No se da un sondeo apropiado a los clientes para conocer sus expectativas

y necesidades.
La comunicacin con los clientes y usuarios con respecto
a cambios
planeados y de corto plazo es ineficiente.
No existe una persona duea del manejo del Service Desk.
Se ha estructurado una tcnica de interrogacin
para la obtencin de
informacin de un usuario o cliente, sin embargo a nivel de la empresa la

mayor parte de usuarios o clientes desconoce dicha tcnica.
No se conoce en profundidad los servicios y productos ofrecidos.
No se manejan estrictos protocolos de interaccin con el cliente.
Los reportes del funcionamiento del Service Desk no se los realiza de una
manera apropiada.
El servicio prestado por el Service Desk no ayuda a asegurar en su totalidad

una larga permanencia y satisfaccin del cliente.
RECOMENDACIONES
El Service Desk aunque tenga definido las funciones que debe desempear
dentro de la empresa, no trabaja como el nico punto de contacto entre la
Divisin de Sistemas y sus clientes, el cual debera ser su objetivo principal.
Para lograrlo se debera capacitar a todo el personal de la empresa, para que
estn al tanto de cual es el procedimiento para poder obtener ayuda en caso de
un incidente, tratando de no tener contacto directamente con las reas de
segundo nivel que vendran a ser Soporte, Planificacin, Administracin de
Bases de Datos
e Ingeniera de Software, o en su defecto, se debera
promocionar el Service Desk y una forma de hacerlo sera a travs del sistema
de correo electrnico ya que este es manejado por todos los miembros de la
48
institucin.
Para poder ofrecer una mejor prestacin de servicios a los usuarios y clientes, el
Service Desk debera tener en su poder toda la informacin de servicios
manejados en la empresa incluyendo el costo de los mismos, para esto, se
debera elaborar un catlogo de servicios, en donde se describiran los servicios
ofrecidos de manera no tcnica y comprensible para clientes y personal no
especializado, para que de esta manera, cuando alguna persona que forma
parte de esta rea se ausente, otra podra reemplazarla sin mayor dificultad ya
que esto le servira como gua para orientar y dirigir a los clientes en caso de
necesitar algn tipo de ayuda.
Otro tema importante del que no debe descuidarse el Service Desk, es el llevar
un registro de toda la interaccin con los clientes, con el fin de poder conocer
sus expectativas y necesidades. Este registro puede lograrse mediante la
obtencin de datos al momento de solicitar ayuda por parte del cliente para
resolver un incidente.
Los datos necesarios para poder seguir teniendo
contacto con este a lo largo de todo el proceso de resolucin de dicho incidente

seran nombre y telfono o nmero de extensin principalmente.
Otra opcin
para conocer las necesidades de los clientes sera que cada cierto tiempo se
distribuyan encuestas con temas en los cuales el cliente podra opinar
libremente dando su punto de vista.
Para saber si los servicios prestados estn siendo desempeados de manera

ptima, se debera tener una forma de evaluacin a las personas que lo
proporcionan. Se puede optar por cerrar cada incidente o consulta con una serie
de preguntas que permitan registrar la opinin del cliente respecto a la atencin
recibida, su satisfaccin respecto a la solucin ofrecida, etc. Toda esta
informacin debe ser recopilada y analizada peridicamente para mejorar la
calidad del servicio.
Aunque se realice escalacin para la solucin de un incidente, el Service Desk

debera tener contacto con proveedores en caso de ser necesario, ya que estos
49
vendran a representar la tercera lnea de soporte. Para poder manejar este tipo
de situaciones se debera definir exactamente cules seran los trminos en los
cuales el Service Desk tendra que contactarlos.
Por otra parte el Service Desk debe mantener puntualmente informados a los
usuarios de los cambios a realizarse ya sea a corto o largo plazo. Una forma
aconsejable de hacerlo es usando el servicio de mensajera interna de la
empresa.
Se debera generar informes del funcionamiento del Service Desk al menos una
vez por semana con el objetivo de poder determinar que tan bien funciona este
y poder realizar las mejoras pertinentes. Los puntos ms relevantes de dicho
informe seran por ejemplo si se lograron atender favorablemente todas las
peticiones de servicio, cuntas fueron resueltas por este primer nivel, cuntas
fueron escaladas a un segundo y tercer nivel, as como tambin el nmero de
llamadas gestionadas por cada miembro del Service Desk.
Es muy importante que se asigne a una persona duea de la funcin de Service

Desk, ya que sta se encargara de dirigir al grupo, esta persona podra ser la
misma encargada del funcionamiento del proceso de administracin de
incidentes.
De todo lo anterior se recomienda que no se implemente un Service Desk lo

ms rpidamente, sino que en principio se alineen los objetivos del Service
Desk con
los procesos de negocio, para que de esta forma se
mejore la
satisfaccin de los clientes, se optimice la imagen externa de la organizacin,

as como tambin se de lugar a la identificacin de nuevas oportunidades de
negocio.
TABLA 2.2. RESULTADO OBTENIDO DE LA APLICACIN DE LA ENCUESTA Y
ENTREVISTA ELABORADAS PARA LA ADMINISTRACIN DE LA FUNCIN SERVICE
DESK.
50
OBJETO: ADMINISTRACIN DE INCIDENTES
CUMPLIMIENTO DE LA ADMINISTRACIN
DE INCIDENTES
%
#
SI NO PARC S/R
CUMPLIM.
PREG.
5
2
4
1
0
35,7
25
3
3
0
1
42,9
31
3
4
0
0
42,9
32
3
4
0
0
42,9
37
0
1
6
0
42,9
10
3
3
1
0
50,0
23
3
3
1
0
50,0
14
3
2
2
0
57,1
16
4
3
0
0
57,1
3
4
2
1
0
64,3
4
3
1
3
0
64,3
8
3
1
3
0
64,3
15
3
1
3
0
64,3
17
4
2
1
0
64,3
30
4
2
1
0
64,3
33
4
2
1
0
64,3
39
3
1
3
0
64,3
6
5
2
0
0
71,4
24
5
2
0
0
71,4
26
4
1
2
0
71,4
1
5
1
1
0
78,6
7
4
0
3
0
78,6
11
5
1
1
0
78,6
12
5
1
1
0
78,6
13
4
0
3
0
78,6
29
5
1
1
0
78,6
9
6
1
0
0
85,7
19
6
0
0
1
85,7
22
5
0
2
0
85,7
34
5
0
2
0
85,7
35
5
0
2
0
85,7
38
5
0
2
0
85,7
40
5
0
2
0
85,7
2
6
0
1
0
92,9
18
6
0
1
0
92,9
20
6
0
1
0
92,9
21
6
0
1
0
92,9
36
6
0
1
0
92,9
27
7
0
0
0
100,0
28
7
0
0
0
100,0

#
PREG.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
SI
NO
PARC
S/R
5
6
4
3
2
5
4
3
6
3
5
5
4
3
3
4
4
6
6
6
6
5
3
5
3
4
7
7
5
4
3
3
4
5
5
6
0
5
3
5
1
0
2
1
4
2
0
1
1
3
1
1
0
2
1
3
2
0
0
0
0
0
3
2
3
1
0
0
1
2
4
4
2
0
0
0
1
0
1
0
1
1
1
3
1
0
3
3
0
1
1
1
3
2
3
0
1
1
0
1
1
2
1
0
0
2
0
0
1
1
0
0
1
2
2
1
6
2
3
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
%
CUMPLIM.
78,6
92,9
64,3
64,3
35,7
71,4
78,6
64,3
85,7
50,0
78,6
78,6
78,6
57,1
64,3
57,1
64,3
92,9
85,7
92,9
92,9
85,7
50,0
71,4
42,9
71,4
100,0
100,0
78,6
64,3
42,9
42,9
64,3
85,7
85,7
92,9
42,9
85,7
64,3
85,7
51
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE LA ADMINISTRACIN DE INCIDENTES
100
90
80
70
60
50
40
30
20
10
0
1
11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE INCIDENTES
MEDIA
72%
Los factores crticos detectados en la administracin de incidentes son:
La integracin de los procesos de administracin de problemas y la funcin

Service Desk es inapreciable para la planificacin de la administracin de
incidentes.
Los incidentes son clasificados moderadamente.
La reclasificacin de un incidente cuando es necesario, no se lo lleva a cabo

en un porcentaje razonable.
Existe una persona que conoce como debe funcionar la Administracin de

Incidentes pero no se la reconoce como la duea del proceso.
No existe alguna persona que administre la escalacin de incidentes.
Se realiza identificacin proactiva de incidentes en un porcentaje muy bajo.
No se manejan documentos formales para solicitar un cambio cuando es

necesario.
No se realiza una evaluacin exhaustiva de los detalles de un incidente.
RECOMENDACIONES
La Administracin de Incidentes no debe confundirse con la Administracin de

Problemas, pues a diferencia de esta ltima, no se preocupa de encontrar y
analizar
las
causas
subyacentes
un
determinado
incidente
sino
52
exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una

fuerte interrelacin entre ambas, por lo tanto para realizar la planificacin de
cualquiera de las dos es necesario tomar en cuenta la otra parte. De igual
forma la Administracin de Incidentes requiere un estrecho contacto con los
usuarios, por lo que el Service Desk tambin juega un papel esencial en la
planificacin antes mencionada. Por lo tanto, es recomendable definir en la
planificacin el alcance que tendr la administracin de incidentes, cuando el
Service Desk le servir de apoyo y cuando un incidente se ha convertido en
problema para ser tratado por la Administracin de Problemas.
La clasificacin de incidentes debe ser un tema manejado perfectamente por

las personas a cargo de la administracin de incidentes, ya que dependiendo de
esta clasificacin se podr asignar a la persona adecuada para resolverlos,
caso contrario se estara exponiendo a la empresa a una prdida tanto de
tiempo como de recursos. Para poder lograr una adecuada clasificacin de
incidentes es recomendable determinar primero el nivel de prioridad para la
resolucin, tambin se debe tomar en cuenta factores tales como el tiempo de
resolucin esperado y los recursos necesarios, as como tambin se debe
realizar una adecuada asignacin del incidente a una categora.
De ser
necesario, se debe reclasificar a un incidente, ya que,
se pueden
encontrar soluciones temporales que restauren aceptablemente los niveles de

servicio y que permitan retrasar el cierre del incidente, con el fin de mas
adelante realizar un anlisis mas minucioso para poder determinar cual fue la
causa de dicho incidente, esto ltimo lo realizara la Administracin de
Problemas.
El cliente debe mantenerse informado de todo el proceso de resolucin de un

incidente, para poder lograrlo, se requerira sus datos tales como nombre,
telfono, fax, rea de la empresa en donde trabaja, que son necesarios para
poder seguir teniendo contacto con el, es por esta razn que se recomienda que
se redisee la herramienta usada ya que no proporciona ningn campo para el
registro de datos del cliente adems de su nombre. En caso que el rediseo
53
represente un cambio muy costoso para la empresa, se debera adecuar la

herramienta para poder registrar esta informacin extra. Si se realiza cualquier
tipo de cambio lo recomendable es que se capacite al rea encargada del
registro de incidentes para no olvidar obtener todos los datos necesarios para
poder dar seguimiento a este.
Debe existir una persona que se le asigne el cargo de Dueo de la

Administracin de Incidentes, ya que este sera el encargado de vigilar que
todos los involucrados con el proceso lleven a cabo el trabajo asignado
correctamente.
Lo recomendable es que sea el mismo que administra el
Service Desk o alguien que forme parte de este grupo, en caso de que la carga
de trabajo sea muy grande, se podra optar por otra persona, tomando en
cuenta que no trabaje en el rea de Soporte de la Divisin de Sistemas, ya que
estos representan una parte del segundo nivel de soporte.
Otra de las
obligaciones del dueo de este proceso sera el definir correctamente cundo y

en qu direccin se debera escalar para poder resolver un incidente, siempre y
cuando el Service Desk no sea capaz de hacerlo.
Una de las metas que deberan haberse planteado al implementar la

Administracin de Incidentes sera el poder llegar a manejar un alto porcentaje
de identificacin proactiva de incidentes, sin embargo hasta el momento no lo
han logrado ya que dan prioridad a brindar una solucin temporal a un incidente
en lugar de la evaluacin de los detalles del mismo.
Por esta razn es
recomendable el realizar una recopilacin de toda la informacin relacionada

con el incidente para ms adelante poder realizar un anlisis de tendencias que
permita identificar algunos incidentes potenciales, para que de esta forma no se
conviertan en problemas.
Cualquier cambio que requiera una modificacin de la infraestructura para poder

resolver un incidente debe requerir un documento formal, ya que puede afectar
de alguna manera al comportamiento normal de la empresa ya sea al instante o
a largo plazo, por lo tanto, una buena sugerencia es el poder manejar
un
documento donde se registren los detalles de la solicitud de un cambio
54
cualquiera, bajo un formato establecido segn ciertas normas, considerando los

recursos necesarios, cules seran las consecuencias de dicho cambio, en
cunto tiempo se lo llevara a cabo y el dinero que se invertira de ser necesario.
ENTREVISTA ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE
INCIDENTES.
OBJETO: ADMINISTRACIN DE PROBLEMAS
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
0
0
0
0
0
0
0
0
0
0
0
0
0
6
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
7
7
7
2
7
2
7
3
7
2
1
0
0
1
7
7
1
5
6
7
7
7
2
7
7
1
6
0
2
5
0
0
0
5
0
5
0
4
0
5
6
7
1
6
0
0
6
2
1
0
0
0
5
0
0
6
0
7
5
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
35,7
0,0
0,0
0,0
35,7
0,0
35,7
0,0
28,6
0,0
35,7
42,9
50,0
92,9
42,9
0,0
0,0
42,9
14,3
7,1
0,0
0,0
0,0
35,7
0,0
0,0
42,9
0,0
50,0
35,7
ORDEN POR PORCENTAJE DE CUMPLIMIENTO

DE LA ADMINISTRACIN DE PROBLEMAS
%
#
SI
NO PARC S/R
CUMPLIM.
PREG.
2
3
4
6
8
10
16
17
21
22
23
25
26
28
31
32
33
34
35
36
37
38
39
40
42
43
49
50
51
52
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
7
7
7
7
7
7
7
7
7
7
7
7
7
6
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
55
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
6
0
0
0
0
0
0
0
0
7
7
7
7
7
7
7
7
7
7
1
7
7
6
0
1
2
0
7
7
7
7
1
7
7
7
0
0
0
0
0
0
0
0
0
0
6
0
0
1
7
6
4
0
0
0
0
0
6
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
42,9
0,0
0,0
7,1
50,0
42,9
28,6
85,7
0,0
0,0
0,0
0,0
42,9
0,0
0,0
0,0
54
55
56
20
44
19
9
47
1
5
7
11
24
30
12
15
18
27
41
46
53
13
29
45
48
14
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
6
6
7
7
7
6
6
5
3
2
2
2
2
2
2
2
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
1
1
2
4
4
5
5
5
5
5
5
6
6
6
6
6
6
6
7
7
7
0
1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0,0
0,0
0,0
7,1
7,1
14,3
28,6
28,6
35,7
35,7
35,7
35,7
35,7
35,7
42,9
42,9
42,9
42,9
42,9
42,9
42,9
50,0
50,0
50,0
85,7
92,9
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE LA ADMINISTRACIN DE PROBLEMAS
100
90
80
70
60
50
40
30
20
10
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE PROBLEMAS
MEDIA
16,6 %
Los factores crticos detectados en la administracin de problemas son:
No se desarrolla y da mantenimiento al control de errores y problemas.
56
No se han definido parmetros para el registro de problemas, ya que se trata

a estos como incidentes y viceversa.
El registro de problemas como tal, no se lo realiza, y peor an el registro de la

solucin de este o cierre del mismo.
No se realiza una clasificacin de problemas.
No se identifican problemas a causa de la recurrencia de incidentes.
No se lleva un conteo de incidentes de un problema relacionado.
No se realiza un entrenamiento al cliente una vez identificado el rea con

mayor cantidad de problemas.
El porcentaje de investigacin de la causa de un problema es del 7%.
No se realiza una investigacin de la solucin dada a un problema una vez

encontrada la causa de su error.
No se realiza un registro del progreso de la resolucin de un error.
No se define la mejor solucin para la resolucin de un error.
No se manejan documentos formales para realizar una peticin de cambio

cuando es necesario, para resolver un problema.
Una vez hecho un cambio para resolver un problema, no se realiza una

evaluacin para ver si se ha podido resolver la causa raz de este.
No se realiza un anlisis para determinar si los beneficios obtenidos por los

cambios realizados justifican los costes asociados.
No se hace un anlisis ni una evaluacin de la administracin proactiva de

problemas.
No se identifican tendencias.
No se proporciona informacin a la organizacin acerca de cmo se manejan

los problemas.
No se lleva un top 10 de los incidentes del da anterior.
No se ha identificado el rea que recibe mayor soporte para la solucin de

problemas.
No se realizan auditoras peridicas para controlar la Administracin de

Problemas.
No se ha establecido los tiempos de disponibilidad y de investigacin de

problemas.
57
No se realizan informes de calidad de productos y servicios.
No se publican los errores conocidos para que estn a disposicin de todo el

personal de la empresa.
Todas las reas involucradas en la infraestructura de TI colaboran en un

mnimo porcentaje para la identificacin de problemas reales y potenciales.
No se realiza un entrenamiento adecuado al equipo de trabajo que maneja

los problemas.
Se diagnostica a breves rasgos cual fue el motivo de un incidente.
Los mismos problemas no siempre son resueltos.
No siempre se informa al cliente que solicit ayuda en cuanto a un problema,

cul fue la solucin efectuada para resolver el mismo.
Se usa un sistema para el control de problemas y errores.
No existe un monitoreo del proceso de Administracin de Problemas.
No existe una persona duea del proceso de Administracin de Problemas.
No se reporta a ninguna persona cual fue el resultado de la administracin de

problemas.
La Administracin de Problemas coopera
para el mejoramiento de los
tiempos de respuesta del Service Desk.
Se proporciona informacin a la gerencia acerca de la Administracin de

Problemas.
RECOMENDACIONES
Lo ms importante que debe tomarse en cuenta, es no confundir incidentes con

problemas, ya que puede existir un conflicto con la prioridad de las dos partes a
causa de que el primero busca resolver lo ms pronto posible un incidente,
mientras que el otro necesita tiempo para poder encontrar la causa que originara
el problema.
Por lo tanto para el desarrollo y mantenimiento al control de
errores y problemas, se debera tomar en cuenta como se estn manejando los

incidentes, mas no confundirlos con este proceso.
La deteccin de problemas se la podra realizar mediante la recurrencia de
58
incidentes, para esto se podra aprovechar sin mayor dificultad el sistema usado
para el registro de incidentes, aadindole a la herramienta contadores de estos
ltimos, con el fin de poder soltar una alarma al momento de llegar a un
parmetro determinado previo a un anlisis. Una vez que se haya detectado el
problema se lo entrega al equipo preparado para poder manejar todo el proceso
concerniente a este.
Al igual que en incidentes, es necesario realizar una clasificacin del problema,

para esto se debe tomar en cuenta desde las caractersticas generales de ste,
tales como si es un problema de hardware o software, que reas funcionales se
ven afectadas hasta los detalles sobre los diferentes elementos de configuracin
involucrados en el mismo. Otro factor esencial es la determinacin de la prioridad
del problema, se debe determinar tanto a partir de la urgencia como de su
impacto. Una vez clasificado y determinada su prioridad se deben de asignar los
recursos necesarios para su solucin.
Para el registro de los problemas, se podra igualmente usar el sistema de

registro de incidentes hacindole las modificaciones pertinentes para que no
exista confusin en cuanto al manejo de los dos procesos. Para el registro sera
muy conveniente y necesario, identificar a un problema con algn tipo de
nomenclatura, identificar cul fue el incidente recurrente que lo origin, cual es la
solucin temporal dada hasta poder encontrar la causa de este, una vez
encontrada la causa tambin registrarla al igual que el cierre del mismo. El
registro de problemas tambin servira al momento en que se de nuevamente un
incidente con las mismas caractersticas ya que se lo relacionara directamente
con un problema y se aplicara la solucin pertinente, de esta forma se ganara
tiempo ya que se podra resolverlo en primera lnea de soporte, es decir, no
pasara mas all del contacto con el Service Desk.
Es muy importante realizar un estudio para determinar la causa de un problema,

en vista de que se podra disminuir la recurrencia de incidentes y problemas o en
su defecto eliminarlos completamente. An cuando no se le dedique tiempo
completo a esto, es de suma importancia establecer horarios para dicha
59
investigacin, lo recomendable sera hacer un anlisis previo para conocer en

qu franja horaria existe menor afluencia de peticiones de servicio.
Una vez establecida la causa raz de un problema, se debe hacer un anlisis de

la solucin temporal dada para resolver el incidente que lo origin, ya que los
motivos tomados en cuenta para plantear dicha solucin, tal vez no sean los que
realmente lo ocasionaron. Para esto se debe tomar en cuenta su posible
impacto, viabilidad y conveniencia. Una vez realizado este estudio es
recomendable que se aplique la nueva solucin ya que con esto se evitaran ms
problemas de ese tipo.
De ser factible los errores conocidos y sus soluciones deberan ser publicados
en una pgina web, tomando como referencia de datos el repositorio usado para
el registro de incidentes y problemas, de tal forma que pueda ser accesada por
cualquier persona que forma parte de la empresa. Para esto tambin se debera
tomar las medidas de seguridad respectivas, de tal forma que no se pueda
alterar la informacin.
Es necesario establecer una estrecha colaboracin entre la Gestin de

Incidentes y la de Problemas. Sin sta la Gestin de Incidentes no dispondr de
toda la informacin necesaria para la rpida solucin de los incidentes y la
Gestin de Problemas carecer de la informacin necesaria para determinar,
clasificar y resolver los problemas. Por lo tanto el mantener actualizadas las
bases de datos asociadas requiere un compromiso por parte de todos los
agentes implicados que frecuentemente requiere un seguimiento cercano de los
responsables de la infraestructura TI.
Se debera realizar un anlisis para determinar cul es el rea que presenta el

mayor nmero de problemas, para determinar este nmero, sera fcil el poder
usar la herramienta de registro, sin embargo como todava no se realiza los
cambios pertinentes, se podra valer del nmero de llamadas de peticiones de
servicio.
60
En caso de que sea necesario un cambio en la infraestructura para poder

resolver algn problema, es necesario que se maneje documentos formales para
solicitar dicho cambio, con el fin de que sea analizado por las personas
respectivas en base a parmetros tales como los recursos necesarios,
financiamiento, componentes afectados, etc. Si el cambio fue aprobado y se lo
ejecut, es necesario realizar un anlisis para ver si en realidad se pudo dar fin
al problema detectado, en caso de no ser as, se tendra que seguir
investigando por que se origina este, aunque debe tomarse muy en cuenta que
el hecho de haber solicitado un cambio es porque realmente se tiene la certeza
al menos en un 90% que se solucionar el problema respectivo.
Con el objetivo de prevenir incidentes potenciales, se debera realizar
identificacin de tendencias, una forma de hacerlo sera monitorizando la
infraestructura TI y analizando su configuracin. Aunque esto represente una
actividad que tome una cantidad de tiempo representativa a la larga podra evitar
un nmero alto de problemas y prdida de recursos.
Para que la gente interesada en saber como se est manejando este proceso
conozca de los ltimos movimientos realizados, se deberan generar informes
que documenten no slo los orgenes y soluciones a un problema sino que
tambin sirvan de soporte a la estructura TI en su conjunto.
Algo muy importante para tomar en cuenta, es el entrenamiento que se debe dar
a las personas que forman parte del equipo de soporte de problemas, ya que
posiblemente sea el mismo encargado del soporte de incidentes, de esta forma
se podra evitar inconvenientes al tratar de cumplir con los objetivos de ambas
partes.
Dicho entrenamiento debe drseles tomando en cuenta todo el
procedimiento a realizarse desde que un incidente ha sido reportado hasta que

el problema ocasionado por este ha sido solucionado (siempre tomando en
cuenta los registros de todo el proceso).
Por otra parte no es recomendable que el administrador o la persona duea del

proceso de problemas sea la misma de incidentes, ya que los objetivos de estos
61
procesos son opuestos.

PROBLEMAS.
OBJETO: ADMINISTRACIN DE LA CONFIGURACIN
%
#
PREG.
SI
NO
PARC
S/R
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
0
0
3
0
1
0
0
0
0
0
0
1
3
0
0
1
1
0
0
1
3
0
0
1
0
0
0
0
0
2
0
0
0
1
0
0
3
0
2
0
3
3
3
3
0
0
3
3
1
0
2
0
0
0
3
0
0
3
3
3
3
1
1
3
3
3
2
2
0
0
2
1
3
0
0
0
0
2
0
0
0
1
2
1
3
2
0
0
3
2
0
0
0
0
2
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

CUMPLIMIENTO DE LA ADMINISTRACIN DE
LA CONFIGURACIN
%
CUMPLIM.
#
PREG.
SI
NO
PARC
S/R
CUMPLIM.
33,3
33,3
100,0
0,0
66,7
16,7
50,0
0,0
0,0
0,0
0,0
66,7
100,0
0,0
0,0
50,0
66,7
16,7
50,0
66,7
100,0
0,0
50,0
66,7
0,0
0,0
0,0
0,0
33,3
66,7
0,0
0,0
0,0
4
8
9
10
11
14
15
22
25
26
27
28
31
32
33
36
37
39
40
43
44
45
46
47
49
51
53
58
6
18
59
61
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
1
3
3
3
3
3
3
3
3
3
3
2
2
2
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
16,7
16,7
16,7
16,7
33,3
62
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
0
1
0
0
0
1
0
1
1
0
0
0
0
0
0
0
3
0
1
0
0
0
0
0
0
0
2
0
0
0
3
3
1
0
3
0
0
3
3
3
3
3
0
3
0
3
0
3
1
1
1
1
3
2
0
2
2
2
0
0
2
0
0
2
2
0
0
0
0
0
3
0
0
0
2
0
2
2
2
2
0
1
1
1
1
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
33,3
66,7
0,0
0,0
33,3
33,3
0,0
66,7
66,7
0,0
0,0
0,0
0,0
0,0
50,0
0,0
100,0
0,0
66,7
0,0
33,3
33,3
33,3
33,3
0,0
16,7
83,3
16,7
2
29
34
38
54
55
56
57
7
16
19
23
48
5
12
17
20
24
30
35
41
42
52
60
3
13
21
50
0
0
0
0
0
0
0
0
0
1
0
0
0
1
1
1
1
1
2
1
1
1
1
2
3
3
3
3
0
1
0
1
1
1
1
1
0
1
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
2
2
2
2
2
2
2
2
3
1
3
3
3
2
2
2
2
2
0
2
2
2
2
1
0
0
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
33,3
33,3
33,3
33,3
33,3
33,3
33,3
33,3
50,0
50,0
50,0
50,0
50,0
66,7
66,7
66,7
66,7
66,7
66,7
66,7
66,7
66,7
66,7
83,3
100,0
100,0
100,0
100,0
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE LA ADMINISTRACIN DE LA
CONFIGURACIN
100
90
80
70
60
50
40
30
20
10
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE LA CONFIGURACIN
63
MEDIA
29,5%
Los factores crticos detectados en la administracin de la configuracin son:
No se tiene documentado lneas de referencia.
No se han determinado los objetivos, estrategias y polticas de la

Administracin de la Configuracin.
No se tiene desarrollado un Plan de la Administracin de la Configuracin.
No se ha determinado el alcance y nivel de detalle del proceso de

configuracin.
No se maneja una CMDB8 que ayude a la obtencin ms rpida de la

informacin de empleados, proveedores, proyectos, aplicaciones y equipos
de soporte, al igual que una base de datos para el registro de los CIs9.
No se ha realizado un anlisis previo para la construccin de la CMDB.
No se realiza un control a la recepcin, identificacin almacenaje y retiro de

todo CI.
Los cambios de CIs no se hacen en base a documentos formales.
Los cambios de los CIs y sus registros no son rastreables.
Luego de un cambio mayor no se hacen auditoras para determinar el

correcto funcionamiento de la infraestructura.
No se ha tomado en cuenta el entorno para la identificacin de CIs.
No se ha definido cul es el impacto potencial de un cambio en un CI.
No se han definido estatus de un CI.
No se realizan evaluaciones para determinar el estado de los CIs.
No se conoce el estado actual de los componentes de la infraestructura.
El costo no es considerado un CI.
No se documentan los CIs.
No existe una persona duea del proceso de la Administracin de la

Configuracin.
Los costos definidos para la administracin de la configuracin no incluyen

salarios, herramientas de soporte y entrenamiento de los miembros del
equipo.
8
9
CMDB [Configuration Management Data Base, Base de Datos de la Administracin de la Configuracin]

CI
[Configuration Item, Elemento de la Configuracin]
64
No se ha invertido en ninguna herramienta de software para el control de la

La alta administracin sirve de apoyo al proceso en un mnimo porcentaje.
No se elaboran informes del proceso de Administracin de la Configuracin.
No se tiene un plan de contingencias debidamente documentado.
La administracin de la Configuracin ha contribuido de forma escasa en el

ahorro de licencias.
El proceso de la administracin de la Configuracin en cierta medida se

percibe como burocrtico.
No se tiene bien documentado los procedimientos apoyados por TI de la

empresa.
No siempre se verifica las versiones de TI antes de llevarlas al ambiente de

operacin.
No existe una persona especfica que se encargue de la custodia de las

copias de software y documentacin de los CIs.
La evaluacin de los sistemas existentes y la implementacin de nuevos

sistemas en la empresa casi no se la realiza.
No se tiene una adecuada coordinacin con los procesos de la

Administracin de Cambios y de Versiones.
Se elaboran reportes incompletos sobre configuraciones no autorizadas y/o

sin licencia.
No se tiene un manual de usuario de todas las aplicaciones que corren en la

empresa.
No se ha realizado una total identificacin de las interrelaciones entre CIs.
No siempre se da prioridad a ciertos CIs que son necesarios.
En muchas ocasiones no se asegura que los cambios a mtodos y procesos

de la Administracin de la Configuracin estn aprobados y comunicados
antes de ser puestos en ejecucin.
10
Fuentes: a) http://www.bmc.com/remedy/
b) http://documents.bmc.com/products/documents/59/45/65945/65945.pdf
11
Fuente: a) http://www-306.ibm.com/software/ar/tivoli/products/ccmdb/
65
RECOMENDACIONES
Es recomendable el implementar este proceso, ya que es obligatorio en caso

de querer conseguir una certificacin ISO20000.
Para poder lograr una correcta Administracin de la Configuracin es necesario
establecer objetivos, estrategias y polticas para poder tener control sobre las
actividades a desempearse. Lo ideal sera que esto conste en un Plan de la
Administracin e la Configuracin para que se formalice el proceso.
Es muy importante hacer conciencia de que la CMDB no es una simple base de

datos en donde se guarda los activos de la empresa, sino es una base de datos
slida que representa el modelo lgico de la infraestructura TI, es por esta razn
que se recomienda tomar el tiempo necesario para su construccin, tomando en
cuenta que el objetivo es ayudar a la administracin de incidentes, problemas,
cambios y versiones, as como tambin a la obtencin mas rpida de la
informacin de empleados, proveedores, proyectos y equipos de soporte. En
caso de necesitarse se puede valer de una herramienta de software para la
implementacin de esta, una opcin es REMEDY10 o TIVOLI11.
Las caractersticas a tomarse en cuenta para la formacin de la CMDB son

aquellas basadas en el negocio de la empresa, es por esta razn que lo
primero que se debera hacer es el determinar cules elementos dentro de la
infraestructura manejada son los candidatos para formar parte de este
repositorio, por ejemplo, en cuanto a hardware se puede hablar de PCs,
impresoras, routers, monitores, as como sus componentes tarjetas de red,
teclados, lectores de CDs, etc, en cuanto a software se tienen los sistemas
operativos, aplicaciones, protocolos de red, por ltimo, algo muy importante
que no debe olvidarse es la documentacin por ejemplo manuales, plan
estratgico, plan informtico, RFCs, acuerdos de niveles de servicio, etc. Es
muy importante que la identificacin de cada CI sea nica y si es posible
interpretable por los usuarios.
66
En caso de no querer ingresar nuevamente datos ya establecidos en otra base

de datos, se puede simplemente dar una referencia de donde se encuentra
dicha informacin.
Otra cosa muy importante, para una correcta implementacin de la CMDB es el

considerar las relaciones entre los elementos de configuracin ya que se podra
determinar de esta forma el impacto que tiene cuando uno de estos no est
funcionando correctamente o si al cambiarlo afecta directa o indirectamente a
otro CI.
Tambin es necesario que se defina el nivel de desglose de los elementos de la

configuracin que vendran a formar parte de la CMDB. Para este desglose es
recomendable tomar en cuenta que no se debe hacer una mera enumeracin
del stock de piezas, sino, obtener una imagen global de la infraestructura de TI
de la organizacin. Por ejemplo al intentar describir la red WAN de alguna
empresa, se dira que est formado de la red LAN1 y LAN2, la red LAN1 tiene el
ROUTER1, a este router estn conectadas las PC1, PC2 y PC3, cada una de
estas PCs estn compuestas por un monitor, disco duro, memoria ram, etc.
Para cada uno de estos elementos se puede especificar la fecha de compra,
fabricante, propietario, costo, estado y otras descripciones que sean necesarias
de acuerdo al criterio de los administradores del proceso.
Hablando del estado de los componentes de la infraestructura,
para
determinarlo, se podra considerar la fecha en la cual fueron adquiridos para

tomar en cuenta la devaluacin de estos, por otra parte se tendra que ver si
todava logran satisfacer las necesidades del negocio.
Los indicadores que se deberan definirse para la medicin de la CMDB una vez
construida, podran ser: nmero de CIs no autorizados, incidentes y problemas
generados por informacin de configuracin errnea, errores en los elementos
de configuracin, tiempo que demora para aprobar un cambio, ahorros de
licencias y fallas en cambios como resultado de informacin equivocada.
67
Para conocer el estado de cada componente de la infraestructura a lo largo de

su ciclo de vida puede ser de gran utilidad el uso de herramientas de software
que ofrezcan representaciones visuales organizadas por filtros tales como
fabricante, responsable, costos, etc, o en su defecto como ya se tiene
conocimiento del motor de base de datos ORACLE, se podra implementar la
CMDB usando esta herramienta y luego obtener los reportes necesarios usando
FORMS.
Para poder tener un control del almacenaje, retiro o cambio de algn CI que
forme parte de la CMDB se deben usar documentos formales que constaten
dicho movimiento, e incluso estos documentos deberan formar parte de la
CMDB con una nomenclatura de identificacin nica, de esta forma se podra
rastrear el cambio realizado. Una buena idea en caso de haberse generado
algn error a causa de un cambio en la CMDB, es el realizar lneas de
referencia, ya que se podra recuperar sin ningn problema el estado anterior
de esta. Otro punto importante a tomar en cuenta para realizar un cambio
representativo en la CMDB, es el establecer franjas horarias a lo largo del da
para hacerlo, ya que tal vez podra influir en los tiempos de respuesta del
repositorio al ser utilizado por otras personas que requieran informacin
almacenada en esta base d datos.
Se recomienda realizar auditoras para verificar si la informacin registrada en la

CMDB coincide con la configuracin real de la infraestructura TI de la
organizacin.
Estas deben realizarse en cierta frecuencia al menos tras la
implementacin de una nueva CMDB, antes y despus de cambios mayores en

la infraestructura, si existen fundadas sospechas de que la informacin
almacenada en la CMDB es incorrecta o incompleta.
Dichas auditoras
deberan dar especial atencin a aspectos tales como el uso correcto de la

nomenclatura de los CIs, informacin de cambios realizados y que el estado de
los CIs estn actualizados.
Se deben generar informes del proceso de administracin de la configuracin,

una vez que lo pongan en prctica, ya que dichos informes pueden servir para
68
que la alta administracin ponga ms inters en la parte tecnolgica de la

empresa. Dicho informe debe constar de los resultados de la monitorizacin a
la CMDB, posibles mejoras a estos resultados y los costos que implican estos
cambios. Para determinar los costos es aconsejable tomar en cuenta los
salarios, herramientas de soporte y entrenamiento del equipo asignado para la
administracin del proceso de configuracin.
Se debera establecer un Plan de Contingencias que tome en cuenta de una

manera global a todos los elementos de la configuracin que forman parte de la
CMDB. Este debera tener por objetivo el salvaguardar toda la informacin, lo
que se podra explicar en un lenguaje no tcnico a travs de una serie de
procedimientos establecidos una vez realizado un estudio pertinente.
No deben olvidar en definir correctamente los procedimientos apoyados por TI,

los mismos que convendra documentarlos con el propsito de ser un elemento
que pase a ser parte de CMDB. Dicho documento debera estar al alcance de
todo el personal de la empresa, de no ser posible, al menos debera estarlo del
Service Desk.
Es importante que se decrete una persona que se haga cargo de la

administracin de este proceso, ya que esta se encargar de coordinar todas
las actividades pertinentes para poder lograr los objetivos planteados en el Plan
de la Administracin de la Configuracin. Se recomienda no asignar este rol a la
persona encargada de la administracin de los procesos de cambios o de
versiones, ya que los objetivos de estos podran confundirse y no se llegara a
realizar en eficientemente estos tres procesos.
As como se debe nombrar una persona encargada de la administracin del

proceso de la administracin de la configuracin, tambin es necesario el
asignar a otra la custodia de la CMDB, es decir que registre, organice, almacene
y distribuya aspectos relaciones con esta base de datos, oficialmente sera
quien mueve la CMDB. Se recomienda que estos roles sean manejados por
personas diferentes ya que no podran con la carga de trabajo.
69
Es recomendable el tener una adecuada coordinacin con los procesos de la

configuracin, cambios y versiones, ya que el proceso de cambios autoriza un
cambio, el proceso de versiones notifica dicho cambio
y el proceso de la
configuracin lo registra en la CMDB.

ENTREVISTA DEL PROCESO DE ADMINISTRACIN DE LA CONFIGURACIN.
OBJETO: ADMINISTRACIN DE CAMBIOS

CAMBIOS
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
2
4
0
0
0
0
0
0
1
0
0
0
0
4
0
0
5
0
0
0
5
0
0
0
0
0
0
0
0
0
1
4
1
5
0
5
0
1
0
5
0
0
1
4
0
5
5
1
0
5
1
5
5
5
5
5
3
1
3
1
4
0
5
0
4
4
5
0
5
1
4
0
0
0
0
4
0
0
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
70,0
90,0
30,0
10,0
40,0
0,0
50,0
0,0
60,0
40,0
50,0
0,0
50,0
90,0
40,0
0,0
100,0
0,0
0,0
40,0
100,0
0,0
40,0
0,0
0,0
0,0
0,0
0,0
6
8
12
16
18
19
22
24
25
26
27
28
29
31
32
34
37
39
40
41
42
51
52
53
54
4
3
5
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5
5
5
4
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
4
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
3
4
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
10,0
30,0
40,0
70
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
0
4
0
0
5
0
0
1
0
0
0
0
0
0
4
1
1
0
4
1
5
4
0
0
0
0
2
4
1
5
0
1
5
0
5
5
0
5
1
0
5
1
5
5
5
5
0
0
0
1
0
1
0
0
5
5
5
5
0
0
0
0
1
0
0
1
0
0
0
0
4
4
0
4
0
0
0
0
1
4
3
4
1
3
0
1
0
0
0
0
3
1
4
0
4
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0,0
90,0
0,0
0,0
100,0
0,0
40,0
60,0
0,0
40,0
0,0
0,0
0,0
0,0
90,0
60,0
50,0
40,0
90,0
50,0
100,0
90,0
0,0
0,0
0,0
0,0
70,0
90,0
60,0
100,0
40,0
60,0
10
15
20
23
35
38
46
59
7
11
13
45
48
9
36
44
57
60
1
55
2
14
30
43
47
50
56
17
21
33
49
58
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
2
2
4
4
4
4
4
4
4
5
5
5
5
5
1
1
1
1
1
1
1
1
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4
4
4
4
4
4
4
4
5
5
5
3
3
4
4
4
4
4
3
3
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
40,0
40,0
40,0
40,0
40,0
40,0
40,0
40,0
50,0
50,0
50,0
50,0
50,0
60,0
60,0
60,0
60,0
60,0
70,0
70,0
90,0
90,0
90,0
90,0
90,0
90,0
90,0
100,0
100,0
100,0
100,0
100,0
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE LA ADMINISTRACIN DE CAMBIOS
100
90
80
70
60
50
40
30
20
10
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59
Nmero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE CAMBIOS
71
MEDIA
37%
Los factores crticos detectados en la administracin de cambios son:
No se hace una distincin entre Peticin de Cambio y Pedido de Servicio.
No se manejan RFCs12 como tal, sin embargo al realizarse un cambio

representativo si se generan documentos solicitando la aprobacin de dicho
cambio.
La informacin de una peticin de cambio no es manejada electrnicamente.
Las peticiones de cambio no contienen el efecto de no implementar un

cambio.
Solo en ciertas ocasiones se determina la dificultad e impacto de una

peticin de cambio aprobado.
No se manejan referencias cruzadas de una peticin de cambio con el

nmero de reporte de un problema.
Los costos y recursos de un cambio no son registrados en un peticin de

cambio.
No se desarrolla una justificacin basada en el negocio con el fin de obtener

aprobacin de una peticin de cambio.
Solo el 50% de las peticiones de cambio emitidas contiene la razn por la

cual se requiere un cambio.
Las peticiones de cambio no siempre contienen la descripcin de todos los

tems a ser cambiados.
No se tienen criterios de aceptacin de una peticin de cambio.
No siempre todos los miembros de la organizacin estn autorizados para

hacer un documento que registre una peticin de cambio.
No se considera tipos de cambios en la organizacin.
No se construyen modelos de cambios para ser implementados.
No se tiene un procedimiento aparte de los comunes para realizar un cambio

urgente.
Se tiene un programa de cambios futuros medianamente aceptable.
No se emiten los programas de cambios futuros va Service Desk.
No se tiene un registro de cmo manejar cambios estndares, cambios
12
RFC [Request for Change, Peticin de Cambio].
72
urgentes y cambios mayores.
No existe una persona duea del proceso de Administracin de Cambios.
No se tiene un Consejo Asesor de Cambios ni un Consejo Asesor de

Cambios de Emergencia.
No se tiene una disponibilidad de servicio proyectada.
Al realizar un cambio de emergencia no se dispone de la misma informacin

que se dispondra tras un cambio normal.
No se actualiza el registro de cambio en la CMDB13, ya que no se ha

equipado a la empresa con una.
No se generan reportes peridicos de la administracin de un cambio.
No se usa mtodos estandarizados y procedimientos para asegurar un

eficiente manejo de todos los cambios.
No existe coordinacin con la Administracin de Versiones para la

planeacin de una versin.
El alcance de la Administracin de Cambios procura ir en paralelo con la

La administracin de cambios no es una actividad de tiempo completo.
No siempre se usan identificadores para un cambio.
Se evala la pertinencia de un cambio en un mnimo porcentaje.
No siempre se categoriza a las peticiones de cambio dependiendo de su

urgencia e impacto.
El monitoreo de todo el proceso de cambio es casi inapreciable al igual que

la monitorizacin tras un cambio realizado.
No siempre se tiene el acceso a usuarios al entorno de pruebas de un

cambio para hacer una valoracin ante de enviarlo a produccin.
La menor parte del tiempo el ambiente de pruebas para un cambio es

realista.
13
14
Las pruebas post implementacin de un cambio no se las realiza siempre.

CI
73
RECOMENDACIONES
Lo primero que debe realizarse es una diferenciacin entre Peticin de Cambio

y Pedido de Servicio, ya que
la ltima no implica una falla o cambio de
infraestructura, solamente se basa en una queja o falla de servicio de carcter

humano, por otra parte la Peticin de Cambio es un documento usado para
registrar los detalles de una solicitud de cambio a cualquier CI14. Una vez hecha
esta diferenciacin, es recomendable entrenar a todo el personal de la empresa
para que aprendan acerca del tema y puedan reportar un incidente o generar
una peticin de cambio dado el caso, al inicio tal vez les cueste adaptarse, pero
all debera entrar el apoyo de Service Desk para asesorarlos.
Las peticiones de cambio pueden ser registradas en documentos, pero lo ms

recomendable sera manejarlas en forma electrnica, por ejemplo en la intranet
de la organizacin. Los puntos mas importantes a tomarse en cuenta para el
formulario, seran: el nmero de solicitud, descripcin de los elementos de la
configuracin a cambiar, razn para el cambio, efecto de no implementar el
cambio, versin del artculo a ser cambiado, nombre, localizacin y nmero de
telfono de la persona que propone el cambio, fecha en la que se propuso el
cambio, prioridad del
cambio, una referencia del reporte del problema que
genera el cambio, evaluacin del impacto y recursos (que pueden estar en

formularios separados de ser necesario), firma de autorizacin (podra ser
electrnica), fecha y hora de autorizacin, implementacin programada, detalles
del responsable de implementar el cambio, plan de back-up, fecha y hora de la
implementacin real, fecha de revisin, resultados de la revisin (incluida la
contra referencia a la nueva peticin de cambio de ser necesario), estatus de la
peticin de cambio.
As como es adecuado manejar formalmente una peticin de cambio a travs de

formularios, es aconsejable el poder definir criterios de aceptacin de los
mismos, para que las personas encargadas de aprobar dicho cambio sean
imparciales y no den ningn tipo de preferencia a otra basndose en criterios
74
personales. Es recomendable tambin evaluar su pertinencia, en ese caso el

RFC puede ser rechazado o se puede solicitar su modificacin si se considera
que algunos aspectos de la misma no son susceptibles de mejora. En cualquier
caso, esta debe ser devuelta al departamento o persona que lo solicit.
Es aconsejable tambin tomar en cuenta el efecto de no implementar un

cambio, ya que al requerirse uno de urgencia y no ser atendido como se
debera, podra empeorarse el problema y causar daos irreparables a la
infraestructura, pudiendo traer gastos grandes a la empresa.
Para un mejor control del proceso de Administracin de Cambios, es una buena

idea el definir tipos de cambios, ya que en base a estos se definir si es
necesario o no que se realice una reunin de un equipo para aprobarlos. Los
tipos de cambios a tomarse en cuenta seran por ejemplo los estndares que no
necesitan aprobacin ya que estos fueron establecidos para manejarse en base
a un procedimiento definido, el mismo que debe ser dado a conocer por el
Service Desk, otro tipo de cambios seran los normales que deberan ser
tratadas por un grupo especfico al igual que los cambios urgentes. Para cada
uno de los tipos de cambios asignados, es aconsejable establecer un
procedimiento formal para poder llevarlos a cabo.
Otro punto muy importante es la prioridad de un cambio, una

establecerlo, sera basndose
forma de
en el mnimo tiempo de cada del servicio
durante la realizacin de este, con el fin de que no exista una interrupcin que
genere algn tipo de conflicto en el negocio. Otra forma sera el tomar en cuenta
la conveniencia de dicho cambio a la fecha, ya que tal vez implique una
inversin muy grande y la empresa no pueda cubrirla. Por ms bsicos que
sean los criterios para determinar el rango de posibles prioridades es
recomendable que tomen en cuenta las siguientes: baja, normal, alta y urgente,
siendo esta ltima la que reciba ms atencin ya que posiblemente se ha
producido un deterioro grave de servicio y debe ser atendido.
75
Si un cambio ha sido aprobado exitosamente, es recomendable el realizar

pruebas de dicho cambio antes de implementarlo en el ambiente de operacin,
para obtener resultados acorde con la realidad, es aconsejable que el ambiente
de pruebas tambin lo sea, aunque esto represente una inversin en ciertos
casos.
Para saber si el cambio ser exitoso, estas pruebas deberan ser
realizadas por las personas que han solicitado el cambio bajo la supervisin de
la persona encargada de llevarlo a cabo, ya que ellas mejor que nadie sabrn si
los resultados obtenidos cumplirn con el objetivo del cambio.
A medida que el cambio proceda por su ciclo de vida, la solicitud de cambio

debera ser actualizada, para que la persona que inici el cambio est al tanto
de su estatus. Es una buena idea que los recursos actuales utilizados y los
costes incurridos sean registrados como parte del expediente, as como tambin
es aconsejable realizar un monitoreo tras la implementacin del cambio para
verificar que realmente se ha logrado solucionar el problema de forma definitiva.
Es de suma importancia, que se defina una persona duea del proceso de la

Administracin de Cambios, ya que esta sera la responsable de que el equipo
destinado para la aprobacin de algn cambio se rena, adems de asegurarse
que se est llevando el proceso de acuerdo a los objetivos planteados. Es
recomendable que esta persona sea quien dirija las reuniones para poder tener
ms control en cuanto al manejo del proceso.
Por otra parte, como ya se dijo anteriormente, dependiendo del tipo de cambio
es recomendable destinar personal capacitado para aprobarlo, as pues, se
debe establecer un Consejo Asesor de Cambios el cual sera el nombre formal
para el equipo reservado a atender problemas normales, este debera ser
conformado por el Jefe de Sistemas o una persona que pueda tomar decisiones
a ese nivel y la persona que dirige el negocio que podra ser el Gerente o alguna
persona propuesta por este, tambin es recomendable el formar un Comit de
Emergencia del Consejo Asesor de Cambios que vendra a tratar cambios
urgentes, este debera estar conformado por personas de la Divisin de
76
Sistemas y gente que conforme el primer grupo, por ltimo es una buena idea
el formar un Consejo de Administracin que validarn la inversin de un cambio
considerado mayor, este sera conformado por el Gerente y sus subordinados
considerados de Alto Nivel.
Se deberan proporcionar reportes regulares de la Administracin de Cambios a

la Alta Administracin, clientes y usuarios. Es probable que distintos niveles de
direccin requieran distintos niveles de informacin, as que es recomendable
tomar en cuenta el lenguaje usado, los puntos de los que se va a hablar y el
tiempo establecido para la elaboracin de dicho informe, por ejemplo la Alta
Administracin es probable que slo necesite un resumen trimestral de la
direccin del proceso, mientras que el Jefe o dueo del proceso puede necesitar
un informe detallado semanal de cmo se lleva el mismo, as como tambin
clientes y usuarios tendran su informe de acuerdo a cmo fue llevado a cabo el
cambio solicitado.
Por otra parte, el Service Desk debe servir como soporte al proceso funcionando
como voceador de nuevos cambios a realizarse a futuro, aunque estos tambin
podran ser informados mediante el servicio de mensajera interna de la
empresa.
Por ltimo y no menos importante, es el tener una buena relacin con los
integrantes del equipo destinados al manejo de versiones, ya que estos sern
los encargados de poner en marcha el cambio aprobado, as como tambin los
del equipo del proceso de la administracin de la configuracin se encargarn
del registro de dichos cambios.
ENTREVISTA ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE CAMBIOS.
77
OBJETO: ADMINISTRACIN DE VERSIONES
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
1
1
4
0
0
0
1
1
0
0
1
1
5
5
5
0
5
0
4
2
4
0
0
0
0
0
4
1
1
1
0
2
0
0
0
5
4
0
5
0
0
0
0
0
5
0
5
0
1
5
5
0
1
0
0
0
5
0
5
0
0
0
5
5
5
3
0
0
1
0
0
5
0
5
5
5
0
0
5
0
2
3
3
4
0
0
5
0
4
3
0
0
4
3
0
0
0
0
0
0
1
3
1
0
0
0
2
4
1
3
4
4
0
3
0
0
0
0
1
0
0
3
2
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
50
60
80
0
50
0
60
50
0
0
60
50
100
100
100
0
100
0
90
70
90
0
0
0
20
40
90
50
60
60
0
70
0
0
0
100
90
0
100
30
20

DE VERSIONES
# PREG. SI NO
4
6
9
10
16
18
22
23
24
31
33
34
35
38
44
45
25
41
40
26
46
1
5
8
12
28
43
2
7
11
29
30
20
32
3
19
21
27
37
13
14
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
1
1
0
1
1
1
1
1
2
2
4
4
4
4
4
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
3
3
2
0
1
0
0
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
PARC
S/R
%
CUMPLIM.
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
2
3
4
4
3
5
3
3
3
5
4
4
4
4
4
3
3
0
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
20
20
30
40
40
50
50
50
50
50
50
60
60
60
60
60
70
70
80
90
90
90
90
100
100
78
42
43
44
45
46
47
5
0
0
0
0
5
0
0
5
5
1
0
0
5
0
0
4
0
0
0
0
0
0
0
100
50
0
0
40
100
15
17
36
39
42
47
5
5
5
5
5
5
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
100
100
100
100
100
100
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE LA ADMINISTRACIN DE VERSIONES
100
90
80
70
60
50
40
30
20
10
0
1
11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE VERSIONES
MEDIA
45,3%
Los factores crticos detectados en la administracin de versiones son:
El DHS15 no contiene repuestos funcionales de los componentes de la

infraestructura.
No se tienen criterios de unidad de versin.
No se clasifica a las versiones de acuerdo a su impacto en la infraestructura

TI.
No se han definido estados con respecto a la evolucin de una versin.
Las especificaciones funcionales y tcnicas de una versin no estn

determinadas en un RFC16.
Nunca se compra una versin de software, an cuando en ciertas ocasiones

sea necesario.
15
16
No se desarrollan planes de back-out.
DHS [Definitive Hardware Store, Almacn de Hardware Definitivo]

RFC [Request for Change, Peticin de Cambio]
79
Los procedimientos de rollout no son documentados.
Luego de implementar una versin, no se actualiza la CMDB17, ya que

carecen de esta.
No se tiene una pgina de FAQs18 para los usuarios.
No existe una persona duea del proceso de Administracin de Versiones.
Se tiene una biblioteca de software pero no trabaja con el rigor de un DSL19.
No existe alguna persona encargada de controlar que la DSL est

debidamente actualizada.
No se realizan pruebas de aceptacin de versiones antes de llevarlas al

ambiente de operacin.
El porcentaje de versiones completas realizadas en los ltimos tiempos fue

de un 20%.
El porcentaje de versiones delta realizadas en los ltimos tiempos fue de

30%.
No se realizan reportes a la alta administracin sobre el proceso de la

administracin de versiones.
Se tiene solo ciertas especificaciones del hardware de la empresa.
No siempre se definen qu CIs20 se vern directa o indirectamente

implicados durante y tras el lanzamiento de una nueva versin.
Muy pocas veces se realiza una lista de errores detectados.
No se realizan auditoras a las estaciones de los usuarios con la persistencia

que deberan.
RECOMENDACIONES
El DHS debe almacenar equipos crticos para el negocio, por lo tanto estos
componentes y montajes de repuesto deben mantenerse al mismo nivel que los
sistemas que actualmente funcionan en la organizacin.
Detalles de estos
componentes y sus respectivos contenidos y construcciones se deben registrar
17
18
19
20

FAQ [Frequently Asked Questions, Preguntas Frecuentes]
DSL [Definitive Software Library, Biblioteca de Software Definitivo]
CI
80
comprensiblemente
en
algn
repositorio
destinado
al
manejo
de
la
infraestructura, de esta forma, se podra utilizar estos de manera controlada

cuando se necesiten sistemas adicionales o en la recuperacin de Incidencias
mayores. Una vez que su uso (temporal) haya terminado, deben ser devueltos
al DHS o se deben obtener sus sustitutos.
En cuanto a la DSL, esta puede ser tratada como una coleccin de medios
electrnicos en distintos formatos de software; archivos y documentacin
electrnica (o en papel), y lo mas lgico sera que sea la nica entidad de
software almacenada, sin embargo, por motivos de seguridad de informacin
ante un posible desastre, es recomendable que se realicen copias de esta y
sean distribuidas en distintos lugares tales como un banco, en un centro de
contingencia, cerca de desarrollo, etc. En tal caso, es muy importante mantener
actualizada la DSL al igual que las copias respectivas.
Dentro del proceso de Administracin de Versiones una de las actividades

elementales a realizarse sera definir criterios de una unidad de versin tanto
para hardware, software y documentacin. Como pueden llegar a existir
mltiples versiones es conveniente definir una referencia o cdigo que los
identifique unvocamente.
Para poder realizar una buena gestin de versiones, es recomendable el

clasificarlas de acuerdo a su impacto en la infraestructura,
un ejemplo de
clasificacin sera versiones mayores, menores y de emergencia, en donde al

igual que en la Administracin de Cambios se debe asignar personal adecuado
para el manejo de cada una de estas. Tambin es una buena idea el asignar
estados a una versin a lo largo de su ciclo de vida, estos podran ser:
desarrollo, prueba, produccin y archivado. En fin, para definir cada uno de
estos trminos se debera tomar en cuenta que sean aplicables tanto a
hardware, software y documentacin.
81
Es muy importante que se especifiquen los aspectos tcnicos y funcionales de

una versin en un documento formal para poder identificar hasta que punto
puede satisfacer las necesidades del o los usuarios designados a trabajar con
esta nueva versin, haciendo referencia tambin al cambio que la origin, al
igual que los elementos de la configuracin afectados directa o indirectamente
tras el lanzamiento de esta. En caso de empezar a funcionar formalmente el
proceso de administracin de cambios, se podra usar las RFCs para tal
registro.
Antes de cada despliegue de versin, es importante que se elabore un plan de

distribucin e implementacin. En este plan, se deben considerar el impacto
para los usuarios y las fuentes necesarias.
An cuando las versiones de software sean desarrolladas en la empresa, en

ciertas ocasiones se debera considerar la compra de estas, especialmente
cuando el tiempo no apremie las circunstancias.
Se sobreentiende que en
ciertas ocasiones el financiamiento destinado al mantenimiento de esta sera

mayor, pero vale la pena si se puede
controlar algn problema que pueda
dejar fuera de funcionamiento a la infraestructura manejada.
Se debera documentar la implementacin de versiones, con esto quedara

constancia que se ha realizado este proceso. Parte de esta documentacin,
debera ser la aceptacin del cliente una vez probada la nueva versin, con esto
se podra tener un respaldo en caso de existir algn tipo de reclamo en cuanto
al funcionamiento de esta.
A su vez, es de suma importancia que dichos
clientes puedan tener acceso a los manuales de usuario o guas de

mantenimiento para el hardware, una forma de hacerlo sera creando una
pgina web donde se los publiquen de acuerdo a las versiones realizadas.
Es importante definir una persona que se encargue de la direccin de este

proceso, tomando en cuenta que no sea la misma persona encargada del
proceso de Cambios ya que podra darse lugar a un conflicto en cuanto a los
82
objetivos a cumplir por cada uno de estos. En tal caso, podra ser una buena
sugerencia
que quien cumpla este papel sea una persona que ya est
familiarizada de alguna forma con el control de estas actividades. Por otra parte,
en caso de no querer gastar ms recursos para formar un equipo de personas
que se encargue del mantenimiento y soporte de versiones liberadas, sera
recomendable que se asigne esta labor al grupo de Soporte.
Para que el funcionamiento de una nueva versin implementada sea el correcto,

es recomendable realizar pruebas de aceptacin de esta antes de llevarla al
ambiente de operacin. Para examinar si cumple con los requisitos propuestos
por el cliente o persona que haya solicitado un cambio en la infraestructura y se
pretenda controlarlo con esta nueva versin, se recomienda que esta persona
sea parte del grupo asignado para la prueba, tomando en cuenta que el
ambiente para dicha prueba sea mas exacto posible al real.
Aunque no se manejen Planes de Back-Out, es necesario establecer algn tipo

de documento estableciendo las acciones que deben tomarse para restaurar el
servicio en caso de que la liberacin de una versin no funcione como se la
plane. Dicho documento debe realizarse antes de enviar la versin al ambiente
de operacin, caso contrario podra encadenar una serie de incidentes por la
falta de organizacin del proceso.
Como parte de este documento puede
sealarse que para solucionar errores se lleve a cabo un procedimiento de

Back-Up para que una versin archivada se pueda utilizar inmediatamente.
El porcentaje realizado de versiones delta y de versiones completas, podra ser

el reflejo de una poca preocupacin por el mejoramiento de la infraestructura
actual o el desconocimiento de esta, es por esta razn que se recomienda el
realizar un sondeo de todo componente de la infraestructura para poder
determinar su estado, realizar una lista de errores detectados y efectuar las
mejoras respectivas.
Entrando un poco ms en el tema de deteccin de
errores, se aconseja realizar auditoras frecuentes a las estaciones de los

usuarios, de esta forma se podra ver si las versiones de software manejadas
83
estn actualizadas, si se trabaja con herramientas aprobadas, si el log de

sucesos no tiene tantos errores reportados, etc.
Por ltimo, es una buena idea el generar informes de la gestin del proceso de
versiones a la alta administracin tomando en cuenta qu beneficios ha trado la
nueva versin a la organizacin, ya que podra ser una forma de justificar la
inversin realizada.
VERSIONES.
PROCESOS TCTICOS O DE ENTREGA DE SERVICIOS
OBJETO: ADMINISTRACIN DE LOS NIVELES DE SERVICIO
#
PREG.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SI NO
1
0
1
1
0
0
0
0
0
0
0
0
0
1
0
0
4
1
0
4
1
1
4
4
4
4
4
4
4
4
4
0
1
4
0
0

DE LOS NIVELES DE SERVICIO
PARC
S/R
%
CUMPLIM.
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
3
0
2
2
0
0
0
0
0
0
0
0
0
3
3
0
0
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
62,5
0
50
50
0
0
0
0
0
0
0
0
0
62,5
37,5
0
100
62,5
2
5
6
7
8
9
10
11
12
13
16
20
21
22
23
24
25
26
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
84
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
4
4
4
4
4
4
4
1
1
0
4
4
4
4
4
1
4
0
4
4
4
0
0
0
0
0
0
0
0
0
0
0
3
3
3
0
0
0
0
0
3
0
4
0
0
0
3
4
4
3
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
37,5
37,5
37,5
0
0
0
0
0
37,5
0
50
0
0
0
37,5
50
50
62,5
31
32
33
34
36
38
39
40
15
27
28
29
35
41
3
4
37
42
43
1
14
18
19
44
17
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
0
0
0
1
1
1
1
1
4
4
4
4
4
4
4
4
4
1
1
1
0
1
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3
3
3
3
3
3
2
2
4
4
4
3
3
3
3
3
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
37,5
37,5
37,5
37,5
37,5
37,5
50
50
50
50
50
62,5
62,5
62,5
62,5
62,5
100
GRAFICO
PORCENTAJE DE CUMPLIMIENTO DE LA ADMINISTRACIN DEL NIVEL DE
SERVICIO
100
90
80
70
60
50
40
30
20
10
0
1
11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DEL NIVEL DE SERVICIO
MEDIA
20,2%
Los factores crticos detectados en la administracin de los niveles de servicio
son:
No se tiene correctamente definidos los servicios ofrecidos tanto interna
85
como externamente.
No se tiene un catlogo de servicios.
No se tiene definido la disponibilidad de cada servicio.
No se manejan listas de requerimientos de servicios solicitados.
No se tiene definido quin o quines son los responsables de la

documentacin de requerimientos de servicios.
En la documentacin de requerimientos de servicio no incluyen informacin

detallado sobre las necesidades del cliente.
No se manejan hojas de especificaciones de servicio o similares.
No se maneja especificacin escrita
de los objetivos diseados para
garantizar los niveles de servicio acordado.
No se tienen procedimientos de monitorizacin de proveedores.
No se manejan SLAs21 o documentos formales similares.
Los SLAs, OLAs22 y UCs23 no son entregados al administrador de incidentes.
No se ha elaborado un SIP24 o similar.
No se cuenta con herramientas para la monitorizacin de la calidad del

servicio.
No existe ninguna persona duea del proceso de Administracin de Niveles

de Servicio.
No se han realizado encuestas para determinar la satisfaccin del cliente en

cuanto a la calidad del servicio.
No se han identificado indicadores de desempeo para evaluar la calidad de

servicio.
No se tienen OLAS bien definidos, especialmente en cuanto a los

responsables de estos.
No siempre se manejan UCs al tratar con proveedores externos de servicios

TI.
Se realiza mnimamente el monitoreo de los niveles de servicio en

operacin.
21

23
24
SIP [Service Improvement Plan, Plan de Mejora de Servicio]
22
86
No se manejan reportes de seguimiento al igual que reportes estadsticos de

rendimiento o tipo RAG25 en un porcentaje aceptable.
No se tienen documentados todos los servicios TI ofrecidos.
Solo ciertos servicios ofrecidos se centran en el cliente y su negocio y no en

la tecnologa.
Se revisa el desempeo de la organizacin de TI solo en un 50%.
RECOMENDACIONES
Dentro de este proceso, lo primordial es el definir los servicios ofrecidos tanto

interna como externamente, enfocndose mas en el cliente y su negocio que en
la tecnologa. Para manejar esto, es recomendable elaborar un catlogo de
servicios, que corresponde a hacer un men de todos los servicios ofrecidos,
considerando, que para construirlo se debe usar el lenguaje del negocio, de tal
forma que cualquier persona que necesite leerlo pueda entenderlo sin ningn
problema. Entre los parmetros establecidos para elaborar el catlogo se
debera tomar en cuenta, obviamente el nombre del servicio, las personas que
estn a cargo de este, as como tambin las personas que lo reciben, las
especificaciones bsicas para mantener arriba dicho servicio y el acuerdo de
servicio determinado con los clientes. Una vez realizado dicho catlogo, es
necesario que sea entregado al Service Desk, para que este tenga una gua
para poder brindar un soporte mas adecuado, ya que es parte fundamental de la
interaccin entre el cliente.
Se deberan manejar listas de requerimientos de servicio, con el fin de poder

estar al tanto de las necesidades de los clientes y cuales son sus expectativas
con respecto al servicio que se les entrega. Otra forma de determinar este
factor, sera el manejar encuestas, para esto se da un ejemplo en el Anexo F.
25
26
RAG [Red Ambar Green, Rojo Ambar Verde]

Fuentes: a) http://h20229.www2.hp.com/products/sdesk/ds/sdesk_ds_slm.pdf
b) http://h20229.www2.hp.com/products/sdesk/ds/sdesk_ds.pdf
87
Una vez que el cliente ha establecido los requerimientos necesarios para el

servicio que necesita, es aconsejable realizar documentos tcnicos de mbito
interno, los cuales sern manejados por las personas a cargo de las tecnologas
de informacin. Estos documentos deben de alguna forma delimitar y precisar
los servicios ofrecidos al cliente, as como tambin evaluar los recursos
necesarios para ofrecer el servicio requerido con un nivel de calidad suficiente y
determinar si es necesario el outsourcing de determinados procesos.
Para poder mantener un control adecuado de los servicios, es recomendable

manejar acuerdos escritos entre la Direccin de Sistemas y los clientes TI,
definiendo las claves de los objetivos y las responsabilidades del servicio, por
ambas partes. Tambin se deber enfatizar en los acuerdos, para no utilizarlos
como una forma de hacer chantaje por ninguna de las partes. Estos acuerdos
deben ser entregados al Administrador de Incidentes para llevar un control
adecuado. Es recomendable que dichos documentos estn en un promedio de
7 2 hojas, de preferencia se debe procurar no usar un lenguaje tan tcnico.
Por otra parte, se debera definir correctamente acuerdos de nivel operacional

entre todas las reas de la Divisin de Sistemas, especificando los
responsables de cada uno de los procedimientos relacionados para atender al
negocio actuando como una sola unidad de apoyo a los servicios ofrecidos.
Como es de suponerse para elaborar este acuerdo operacional se puede usar
sin problema un lenguaje tcnico.
Se deberan implementar procedimientos para monitorizar a los proveedores

para ver si los servicios convenidos estn siendo brindados tal como se ha
establecido en los contratos. Una forma de hacerlo en forma general, tal vez
sera el identificar el nmero de incidentes ocurridos con tal servicio en el
transcurso de una semana o en el tiempo que sea mas prudente de acuerdo al
servicio proporcionado, en caso de ser el proveedor de Internet se podra
identificar si el ancho de banda ofrecido realmente es el acordado, en cuanto a
las actualizaciones de las licencias de los equipos si se las hace de acuerdo a
88
los tiempos establecidos.

Para poder tener control sobre los servicios ofrecidos en cuanto se refiere al
manejo de avances tecnolgicos, sera una buena idea el establecer un Plan de
Mejora del Servicio, en donde adems de recoger medidas correctivas a fallos
detectados en los niveles de servicio ocasionados por el mal funcionamiento de
la infraestructura actual, se establezcan soluciones basadas en estas nuevas
tecnologas. Este plan debera ser enviado a la alta administracin para su
aprobacin, especialmente por el tema de inversin.
Es una buena idea el
ejecutare este plan formalmente en forma de proyecto al menos una vez al ao.
Por otra parte, aunque se tenga una herramienta que pueda observar la
disponibilidad de un servicio basado en enlaces de conexin, se debe procurar
implementar una herramienta que pueda monitorizar la calidad de servicio
basado en el cumplimiento de los acuerdos establecidos, dicha herramienta
deber tener los siguientes indicadores como mnimo: el nmero o porcentaje
de metas de servicio alcanzadas, el porcentaje de incumplimientos cubiertos en
el Plan de Mejora, tendencias identificadas con respecto al nivel de servicio
actual, frecuencia e impacto de los incidentes responsables de la degradacin
del servicio, tiempos de respuesta y costes reales del servicio ofrecido. En
caso de no querer implementarla es una buena idea adquirir la herramienta
OPENVIEW SERVICE DESK 26 o en su defecto tomarla como referencia para
elaborarla.
Por otra parte, es recomendable realizar un seguimiento del desempeo de la

organizacin TI basada en la monitorizacin realizada, sus resultados y el grado
de satisfaccin de los clientes con el servicio prestado. Una vez realizado esto,
se deben elaborar los respectivos informes para poder tener una referencia de
cmo se ha ido avanzando en el comportamiento de la infraestructura a medida
que se han implementado mejoras.
89
An cuando se manejen de cierta forma reportes estadsticos de rendimiento

basados en un modelo de semforo, es necesario que se definan exactamente
los parmetros bajo los cuales deben ser elaborados, tomando en cuenta cules
seran sus lmites de aceptacin, ya que de no hacerlo se podra dar lugar a
errores en la interpretacin de estos. Es aconsejable al manejar este tipo de
reportes, que todos los parmetros establecidos sean considerados de forma
afirmativa, entendindose esto que si se obtienen ms respuestas positivas la
administracin est bien realizada.
Como una recomendacin fundamental es el asignar a una persona que se

encargue del manejo de los acuerdos de servicio, al igual que el mantenimiento
del Plan de Mejora. Para esta asignacin es necesario que se tome en cuenta
que la persona sea capaz y de preferencia con experiencia en el negocio, al
igual que un adecuado sentido de persuasin.

ENTREVISTA ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE LOS
NIVELES DE SERVICIO.
OBJETO: ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI

FINANCIERA DE LOS SERVICIOS TI
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
1
2
3
4
5
6
7
8
5
0
0
4
4
5
0
0
0
5
5
0
0
0
2
5
0
0
0
1
1
0
3
0
0
0
0
0
0
0
0
0
100
0
0
90
90
100
30
0
2
3
8
9
10
11
13
14
0
0
0
0
0
0
0
0
5
5
5
5
5
5
5
5
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
90
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
55
0
0
0
0
0
0
0
5
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
5
5
5
1
5
5
5
0
5
5
5
5
5
5
0
1
0
4
5
5
5
5
5
5
5
5
5
5
5
4
4
5
5
1
5
0
5
5
5
5
5
5
5
5
5
5
5
0
0
0
4
0
0
0
0
0
0
0
0
0
0
4
3
5
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
3
0
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
40
0
0
0
100
0
0
0
0
0
0
60
50
50
0
0
0
0
0
0
0
0
0
0
0
0
10
0
0
0
30
0
60
0
0
0
0
0
0
0
0
0
0
0
15
17
18
19
20
21
22
24
27
28
29
30
31
32
33
34
35
36
37
38
40
41
42
44
46
47
48
49
50
51
52
53
54
55
39
7
43
12
25
26
23
45
4
5
1
6
16
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
1
4
4
5
5
5
5
5
5
5
5
5
5
5
4
5
5
5
5
5
5
5
5
5
5
5
4
5
5
5
5
5
5
5
5
5
5
5
5
5
4
2
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
3
3
4
3
5
4
4
1
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
10
30
30
40
50
50
60
60
90
90
100
100
100
91
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE LA ADMINISTRACIN DE FINANZAS
100
90
80
70
60
50
40
30
20
10
0
1 3 5
7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE FINANZAS
MEDIA
14,7%
Los factores crticos detectados en la administracin financiera de los servicios TI
son:
El rea de TI no opera como una unidad de negocio.
No se ha definido una fijacin de polticas financieras para el rea de TI.
No se han elaborado polticas de fijacin de precios para los servicios TI

ofrecidos.
No se tiene ningn mtodo para calcular el costo de los servicios TI.
La organizacin no dispone de la informacin financiera precisa para la toma

de decisiones.
No se tiene definido cunto de los gastos de los servicios TI ofrecidos son

para el rea de TI.
No se tiene definido cules son los elementos de coste de los servicios TI.
No se asegura que los servicios TI estn suficientemente financiados.
No se evala los costes reales asociados a la prestacin de servicios.
No se realiza una comparacin de los costes reales con los presupuestados.
No se maneja un plan de reduccin de costes por servicio.
No se hace una comparacin de Gastos vs. Ingresos para saber como se

manejan los fondos para los servicios TI.
No se realiza una evaluacin de la eficiencia financiera de cada uno de los
92
servicios TI prestados.
Los gastos manejados para TI no se hacen de acuerdo a los requerimientos

de los servicios establecidos.
No se tiene un sistema de monitoreo de costos que proporcionen detalles de

estos.
No se contabilizan los gastos del rea de TI por servicios o clientes.
No se distribuyen los costos de los servicios TI a clientes externos e internos.
No se han determinado tipos de costos de acuerdo a los elementos de costos

de los servicios TI.
No se han identificado costos directos, indirectos, fijos, variables, de capital ni

de operacin para el rea de TI.
No ser recuperan los costos de los servicios TI.
La informacin manejada de costos de TI no sirve de apoyo a la estimacin de

niveles de capacidad y disponibilidad.
No se tienen niveles para la recuperacin de la inversin de TI.
No se ha realizado un monitoreo para verificar que los usuarios comprendan

por qu se deberan cobrar los servicios proporcionados por TI.
No se tiene polticas de cobro por servicios TI proporcionados a los clientes

internos y externos.
No se realiza una evaluacin ROI27 de los servicios TI.
No se realizan reportes financieros de TI.
No existe una persona duea del proceso de Administracin Financiera de los

Servicios TI.
No existe una persona destinada a trabajar con administradores y financieros

en el desarrollo de las polticas para presupuestos, contabilidad y cargos para
TI.
El presupuesto elaborado para el rea de TI est basado en un presupuesto

desde cero solo en un 30%.
En ciertas ocasiones, el costo de proporcionar un servicio impacta en el

alcance de los acuerdos de servicio.
27
No se evala cuidadosamente las necesidades del cliente dentro de un

ROI [Return Of Investment, Retorno de la Inversin]
93
margen aceptable.
No siempre se planifica el gasto e inversin de los servicios TI a largo plazo.
Los gastos en servicios e infraestructuras TI no estn correctamente alineados

con los procesos de negocio.
RECOMENDACIONES
Para que el rea de TI pueda funcionar como una unidad de negocio exitosa, es
indispensable que exista una muy buena relacin entre las personas a cargo de
los procesos de Administracin de los Niveles de Servicio y Finanzas, ya que el
primero ser quien ponga los lmites de negocio y el segundo har los clculos
para cobrarlos, aunque esto no representa un pago formal por el servicio, sino
una forma de recuperacin de los costos de los servicios TI ofrecidos.
Para asignar precios a los servicios TI prestados internamente, se podra hacer

los clculos respectivos tomando en cuenta cuanto costara el pagar por dichos
servicios si fueran adquiridos externamente.
Tambin es una buena idea
comparar estos resultados con las inversiones realizadas para la obtencin de

equipos destinados para suministrar servicios, con el fin de obtener el margen de
utilidad.
Es recomendable que se defina cunto de los gastos de los servicios TI son

especficamente para el rea de TI, ya que por lo general ven a esta rea como
un gasto, sin embargo es necesario hacer conciencia de que la mayor parte de
las inversiones realizadas es para resolver problemas destinados a otras reas de
la empresa con el fin de que se mejore los tiempos de las actividades
desempeadas automatizando los procesos. Tambin es aconsejable el realizar
un estudio de cuanto tiempo les tomara hacer los procesos manualmente, con el
fin de que se justifique dichas inversiones.
Es aconsejable el identificar los denominados elementos de coste que se pueden

clasificar de forma genrica en: costes de hardware, software y de personal. Si
se requiere un anlisis de costes, ms detallado, los elementos de coste tpicos
94
dentro de cada tipo de coste podran ser:

Tipo de Coste
Hardware
Elementos de Coste
CPUs, almacenaje de discos, perifricos, WANs,
PCs, porttiles, servidores.
Software
Sistemas operativos, herramientas de programacin,

aplicaciones, bases de datos, herramientas de
productividad
personal,
herramientas
de
monitorizacin.
Personal
Costes de nminas, autos de empresa, costes de

situacin.
Alojamiento
Oficinas, almacenaje, reas seguras.
Transferencias
Asesoramiento, servicios de seguridad, recuperacin

de desastre, servicios externos, utilidades.
Otra forma de manejar los costos de los servicios, sera el distribuirlos de acuerdo
a clientes externos e internos y en tal caso el poder determinar cules son los que
han requerido mayor soporte a lo largo de un periodo de tiempo determinado.
Los procesos de Gestin Financiera TI deben tener un dueo, es decir una

persona responsable de desarrollarlos y revisarlos, adems debe ser capaz de
aceptar que algunos de estos procesos son heredados del Departamento
Financiero. Es recomendable que para la asignacin de este rol se evite drselo a
gente con tareas administrativas, ya que normalmente no tienen tiempo ni
conocimientos necesarios para gestionar las tareas requeridas. Tampoco es
recomendable que el Administrador de Finanzas sea el mismo de Niveles de
Servicio por la carga de trabajo que tienen estas dos entidades.
Es indispensable que toda la organizacin disponga de la informacin financiera

precisa del rea de TI, con el propsito de poder tomar decisiones en cuanto al
manejo del presupuesto destinado para esta. Para poderse dar a conocer esta
informacin se podra valer de la ayuda brindada por el Service Desk.
95
Es recomendable el realizar una evaluacin al manejo de las finanzas para los

servicios TI, ya que tal vez podra ser que se est dando prioridad a un cambio
que represente una gran inversin, por lo que hay que tomar en cuenta que el
dinero no se termina antes de que finalice el periodo, ya que se podran tener
otros proyectos pendientes. Por otra parte, cuando se tenga cierto porcentaje de
sobrantes de fondos, tal vez no sea un buen indicador para decir que se manej
correctamente la administracin de finanzas, tal vez pueda ser que se dej de
hacer un proyecto y realmente los fondos finales no son suficientes para poder
lograr implementarlo.
Esta evaluacin debe hacerse al menos cada vez que un
proyecto sea implantado, con el fin de tener un control ms exacto del mismo.
Es aconsejable el realizar una comparacin de los costes reales
para la
implementacin de los servicios contra los presupuestados, as como tambin

entre gastos e ingresos, ya que de esta forma se podran obtener respuestas en
cuanto a si se manej favorablemente el dinero destinado para los proyectos de
TI y si existi restantes de fondos con los que de antemano se podra contar para
la implementacin de prximos proyectos.
Dicha comparacin se la puede
realizar al menos una vez al ao junto al informe de metas
logradas
exitosamente conforme al Plan Operativo.
Sera una buena idea el poder implementar un sistema de monitoreo de costos

con el fin de a lo largo del ao ir asignando cargos a cada uno de los clientes
dependiendo de los cambios realizados, para esto se podra tomar como
referencia al sistema manejado para el registro de versiones, es decir se hara
una relacin de cual fue el costo determinado con la nueva versin.
Aunque en ITIL, la recuperacin de la inversin de los servicios TI o manejo de

cargos es una actividad opcional, sera recomendable adoptarla, ya que podra
influenciar en el comportamiento de clientes internos y externos del rea de TI, en
cuanto a su percepcin de cmo debera ser tratada la infraestructura de la
empresa y que el mantenimiento de esta no solo le corresponde a la Divisin de
Sistemas, sino que de una u otra forma ellos tambin estn involucrados. El
nivel de cobro de servicios que podra ser aplicado a la empresa sera de tipo
96
informativo, es decir que no existe ningn pago por parte del rea involucrada
hacia el rea de TI, sino que simplemente se haga conocer cunto se gast al
ao en el mantenimiento de todos los servicios manejados por cada cliente. Tal
vez otra forma que se podra aplicar cargos sera el hacer que el rea de TI
asimile la deuda generada para la implementacin de un cambio para un rea
cliente de esta, en donde mas adelante se podra cobrar por el mantenimiento
ofrecido a este cambio, de donde se le descontar al rea involucrada de su
presupuesto
y se lo asignara al presupuesto del rea TI.
Esto sera ms
complicado de manejarse especialmente en el sentido de educar al personal para

que no lo mal interprete, pero podra tratarse.
La forma en que lleguen los
reportes de cargos a cada uno de los clientes de TI o reas involucradas, sera al

finalizar el ao tambin dentro de los reportes de cumplimiento del Plan
Operativo.
En caso de que se implemente la poltica de cargos, sera aconsejable el realizar

un monitoreo para verificar que los usuarios entiendan por qu se van a cobrar
los servicios proporcionados por TI.
Una forma de hacerlo es el manejo de
encuestas. En caso de que dichas encuestas no tengan una respuesta favorable,

se debera realizar charlas a nivel organizacional con el propsito de sembrar
esta conciencia. Las personas que brinden estas charlas tendrn que ser muy
convincentes y estar al tanto de todo lo concerniente al tema.
Por otra parte, es fundamental que se manejen reportes del comportamiento

financiero del rea de TI anualmente, con el fin de poder tener una referencia
para poder establecer el nuevo presupuesto. Entre la documentacin generada
cabra destacar: resmenes contables, anlisis de eficiencia de cada uno de los
servicios TI, inversiones TI basados en el histrico del negocio y en previsiones
de evolucin de la tecnologa y reduccin de costes por servicio.
Aunque es una buena idea el poder tomar como referencia el presupuesto del
ao pasado para poder determinar el del prximo, puede representarse en
algunos casos como un arma de doble filo, ya que podra variar extremamente la
tecnologa y al querer adquirirla para mejorar proyectos puede generar un costo
97
muy grande, por lo tanto se recomienda el realizar un presupuesto desde cero, en

donde se tome en cuenta gastos de servicios e infraestructuras TI correctamente
alineados con el negocio. Esto se puede hacer una vez estudiadas las proformas
presentadas en los concursos respectivos.
Aunque resulta prcticamente imposible establecer un clculo exacto del ROI, se
debe establecer parmetros que permitan identificar el valor que obtiene el rea
de TI como resultado del coste que invierte para dar a conocer como se deben
manejar los servicios TI brindados.
Para esto, se podra aplicar el siguiente
mtodo, tome el ahorro obtenido de brindar el servicio internamente, reste a esta

cantidad los costes de mantenimiento o capacitacin y, a continuacin, divida el
resultado entre el total de costes para brindar el mantenimiento o capacitacin
necesaria.
ENTREVISTA ELABORADAS PARA EL PROCESO DE ADMINISTRACIN FINANCIERA
DE LOS SERVICIOS TI.
OBJETO: ADMINISTRACIN DE LA CAPACIDAD
# PREG.
SI
1
2
3
4
5
6
7
8
9
10
11
12
13
1
1
0
0
0
1
1
0
2
2
1
0
0
NO PARC S/R % CUMPLIM.
2
1
2
1
3
0
0
3
0
0
0
0
0
0
1
1
2
0
2
2
0
1
1
2
2
3
0
0
0
0
0
0
0
0
0
0
0
1
0
33,3
50,0
16,7
33,3
0,0
66,7
66,7
0,0
83,3
83,3
66,7
33,3
50,0

LA CAPACIDAD
#
SI
NO PARC S/R % CUMPLIM.
PREG.
5
0
3
0
0
0,0
8
0
3
0
0
0,0
14
0
3
0
0
0,0
18
0
3
0
0
0,0
22
0
3
0
0
0,0
23
0
3
0
0
0,0
26
0
3
0
0
0,0
27
0
3
0
0
0,0
34
0
3
0
0
0,0
35
0
3
0
0
0,0
36
0
3
0
0
0,0
37
0
3
0
0
0,0
38
0
3
0
0
0,0
98
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
1
2
3
0
1
0
0
0
0
3
1
0
0
0
0
1
0
2
0
0
0
0
0
0
0
0
0
0
1
0
0
0
3
0
0
0
3
3
0
0
3
3
1
0
0
0
0
0
3
3
3
3
3
3
3
3
3
0
2
1
0
0
2
2
3
0
0
0
2
0
0
2
3
2
3
1
3
0
0
0
0
0
0
0
0
0
2
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
66,7
83,3
100,0
0,0
66,7
33,3
50,0
0,0
0,0
100,0
66,7
0,0
0,0
33,3
50,0
66,7
50,0
83,3
50,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
66,7
40
41
42
3
1
4
12
20
28
2
13
21
29
31
33
6
7
11
15
19
25
30
43
9
10
16
32
17
24
0
0
0
0
1
0
0
0
0
1
0
0
0
0
0
1
1
1
1
1
1
1
1
2
2
2
2
3
3
3
3
3
2
2
1
0
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
2
2
2
2
1
3
3
3
3
3
2
2
2
2
2
2
2
2
1
1
1
1
0
0
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0,0
0,0
0,0
16,7
33,3
33,3
33,3
33,3
33,3
50,0
50,0
50,0
50,0
50,0
50,0
66,7
66,7
66,7
66,7
66,7
66,7
66,7
66,7
83,3
83,3
83,3
83,3
100,0
100,0
GRFICO
CAPACIDAD
100
90
80
70
60
50
40
30
20
10
0
1
9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE LA CAPACIDAD
MEDIA
36%
99
Los factores crticos detectados en la administracin de la capacidad son:
No se traduce las necesidades del negocio en capacidad requerida.
No se realizan modelos ni simulaciones sobre diferentes escenarios, para

llevar a cabo previsiones
de carga y respuesta de la infraestructura
informtica.
No se realiza monitoreo de los servicios.
No se apoya en cuanto a la determinacin de la estrategia de distribucin de

versiones.
No se realizan benchmarks con prototipos reales para asegurar la capacidad

y el rendimiento de la futura infraestructura.
No se han establecido baselines y perfiles para el uso de los componentes

en la organizacin.
No se realizan auditoras peridicas de la capacidad de TI.
No re se realizan reportes de capacidad.
No se tiene una CDB28 ni algo similar.
No existe una persona duea del proceso de administracin de la capacidad.
No se dan recomendaciones financieras tomando en cuenta la capacidad de

la infraestructura.
No se evala el impacto en el negocio y el rendimiento de TI al hacer un

cambio.
No se identifica y evala las tecnologas que proporcionen economas de

escala.
No se conoce bien el estado actual de la tecnologa en la organizacin.
La infraestructura informtica est adecuada a los requisitos de los acuerdos

de servicio en un mnimo porcentaje.
No siempre se informa las tendencias de uso de recursos y desempeo a

corto, mediano y largo plazo.
No est establecido adecuadamente los niveles de monitoreo de recursos y

desempeo de sistemas.
No se realizan peridicamente reportes sobre el uso actual de los recursos,

tendencias y pronsticos.
28
CDB [Capacity Data Base, Base de Datos de Capacidad]
100
No se conoce a detalle los planes de negocio.
No se mide eficientemente el rendimiento de la infraestructura informtica.
No se realiza supervisin de licencias en un porcentaje adecuado.
No se apoya lo suficiente a los niveles de servicio para asegurar que el

desempeo y los objetivos para nuevos requerimientos en cuanto
relacionados con la capacidad se logren.
RECOMENDACIONES
Para una correcta gestin de la capacidad en la organizacin es recomendable

el traducir las necesidades del negocio en capacidad requerida, con el fin de
evitar que se realicen inversiones innecesarias en tecnologas que no estn
adecuadas a las necesidades reales del negocio o estn sobredimensionadas, o
por el contrario, evitar situaciones en las que la productividad se ve mermada
por un insuficiente o deficiente uso de las tecnologas existentes.
Esta
informacin sobre los costes de la capacidad actual y prevista se puede

registrar en el Plan Operativo manejado actualmente, ya que ayudar para la
elaboracin de los presupuestos y previsiones financieras de manera realista.
Aunque, en principio, el Plan Operativo puede tener una vigencia anual, es
importante que se monitorice su cumplimiento para adoptar medidas correctivas
en cuanto se detecten desviaciones importantes del mismo. Es aconsejable
que este trabajo lo realicen
en conjunto el Administrador de Red, el
Administrador de Sistemas y el Administrador de Aplicaciones.
Por otro lado, es recomendable el realizar modelos y simulaciones sobre

diferentes escenarios para llevar a cabo previsiones de carga y respuesta de la
infraestructura. Estos modelos deben ser lo ms cercano a la realidad, ya que
caso contrario no serviran de nada. Aunque el nivel de detalle de modelado
depender tambin de los costes relacionados con el mismo, no se debera ver
a esto como un gasto innecesario, ya que se podran detectar incidentes antes
de enviar a los nuevos sistemas o nuevos equipos adquiridos al ambiente de
101
operacin. Otra forma de asegurar la capacidad requerida, podra ser el realizar

benchmarks con prototipos reales, sin embargo en cualquiera de los casos se
debe ver si el presupuesto es el adecuado para ejecutarlos.
Es aconsejable que se realice un monitoreo constante de los servicios ofrecidos,

ya que gracias a este se puede evaluar el rendimiento y capacidad de la
infraestructura TI, para que de esta forma con los datos obtenidos pueden ser
evaluados en cuanto a la conveniencia de adoptar acciones correctivas tales
como aumento de componentes de infraestructura. Este monitoreo debe incluir,
adems de aspectos tcnicos todos aquellos relativos a licencias y aspectos de
carcter administrativo.
Es muy importante tomar en cuenta al momento de actualizar algo en la

infraestructura
de
la
empresa,
definir
correctamente
cules
son
los
componentes a actualizar (por ejemplo, incremento de memoria o el ancho de

banda, adquirir almacenamiento o procesadores ms rpidos), al igual que se
debe tomar en cuenta el no actualizar demasiado pronto, ya que es caro,
tampoco se debe realizar esta actualizacin muy tarde, ya que podran
producirse cuellos de botella, ejecuciones inconsistentes, y finalmente la
insatisfaccin del cliente y oportunidades de negocio perdidas, por ltimo
tambin hay que considerar el costo de esta actualizacin.
Dentro de la planificacin para la administracin de la capacidad, es

aconsejable el definir perfiles para el uso de componentes de la organizacin,
ya que al saber quin y cmo va a manejar un componente se podr tener un
mejor control de estos, e incluso se podra elaborar reportes incluso diarios de
cmo de su comportamiento.
Por otra parte, es recomendable el realizar auditoras peridicas que analicen la

infraestructura TI, ya que se podra dar lugar a que algn usuario aun cuando su
equipo de trabajo no funcione bien, no lo haya reportado y en un determinado
tiempo pueda resultar un problema para poder continuar con sus actividades, o
tal vez puede darse el caso que las licencias estn a punto de expirar. Dicha
102
auditora es aconsejable realizarla por lo menos una vez cada tres meses como
mnimo.
Una vez realizada una auditora o seguimiento del comportamiento de la
infraestructura, ms que una recomendacin, es una obligacin el realizar
reportes de cmo est funcionando dicha infraestructura, ya que con esto se
podra tomar acciones de mejora inmediatas en caso de que no funcione como
se espera. Estos reportes deberan al menos constar de los siguientes puntos:
uso de recursos, desviaciones de la capacidad real sobre la planificada,
anlisis de tendencias en el uso de la capacidad, mtricas establecidas para el
anlisis de la capacidad y resultados de la monitorizacin del rendimiento y el
impacto en la calidad del servicio, disponibilidad y otros procesos TI.
Algunos indicadores clave entre los que se podra
determinar el
comportamiento de la infraestructura podran ser: la correcta previsin de las

necesidades de capacidad, la reduccin de los costes asociados a la
capacidad, el aumento en los niveles de disponibilidad y de seguridad, el
aumento de la satisfaccin de los usuarios internos y externos del rea de TI,
as como tambin el cumplimiento de los acuerdos de nivel de servicio.
Se podra tomar en cuenta el manejo independiente de una base de datos cuyo

objetivo sera el registro de toda la informacin de negocio, financiera, tcnica y
de servicio que reciba y genere la capacidad de la infraestructura y sus
elementos en la organizacin. De no ser posible, es recomendable al menos el
relacionar toda esta informacin con la base de datos destinada para el manejo
de versiones, ya que de esta forma se podran manejar baselines, en donde
servira de mucha ayuda al momento de existir algn error con nueva tecnologa
o servicio implementado.
Para que todo el proceso de capacidad marche de forma organizada, es

recomendable el establecer una persona que administre todas las actividades
concernientes al manejo de este. La persona que podra ocupar este puesto
podra ser alguna dentro el equipo de bases de datos.
103
La administracin de la capacidad tambin servira de apoyo en cuanto a como

se debe manejar el presupuesto para TI, por lo tanto es recomendable el
mantener una buena relacin con el equipo destinado a realizar dicho
presupuesto, esto con el fin de no tener
ningn tipo de inconveniente al
requerirse.
Antes de implementar un cambio en la infraestructura, es recomendable el

realizar una evaluacin para ver cual sera el impacto de este en el negocio y el
rendimiento de TI. As como tambin el generar formalmente una peticin de
cambio para que se desencadene todo el proceso necesario para la
implementacin del mismo con el fin de que cumpla los objetivos previstos.
Es recomendable el aplicar una adecuada gestin de la demanda, que es la

encargada en estos casos de redistribuir la capacidad para asegurar que los
servicios crticos no se ven afectados o, cuando menos, lo sean en la menor
medida posible. Para llevar a cabo esta tarea de forma eficiente es
imprescindible que se conozca las prioridades del negocio del cliente y pueda
actuar en consecuencia.
A fin de poder obtener una Plan Operativo que ayude al mejor desenvolvimiento
de la infraestructura, es recomendable el estar a la vanguardia de la tecnologa,
especialmente si estas proporcionan economas de escala. Una forma de
hacerlo sera suscribindose a canales de noticias, foros o canales de correo
en donde se manejen temas relacionados a esto.
Es recomendable mantener un control constante de las licencias manejadas a

nivel de toda la organizacin, ya que en caso de expirarse, en ciertos casos se
podra dar lugar al cobro de multas e incluso retiro de software y hardware en
casos extremos. Por otro lado, tambin se debera hacer un monitoreo para
conocer si los usuarios estn manejando tanto software como hardware
actualizado con respecto a la infraestructura actual de la empresa.
104
Por ltimo, se debe hacer conciencia entre todos los miembros de la

organizacin para apoyar al uso adecuado de las tecnologas con el fin de poder
lograr los niveles de servicio esperados. Para esto se puede dar capacitacin
cada vez que se realice un cambio mayor en la infraestructura.
ENTREVISTA ELABORADAS PARA EL PROCESO DE ADMINISTRACIN DE LA
CAPACIDAD
OBJETO: ADMINISTRACIN DE LA DISPONIBILIDAD

#
PREG.
SI
2
3
1
1
4
5

LA DISPONIBILIDAD
S/R
% CUMPLIM.
#
PREG.
SI
66,7
0,0
0
0
2
2
0
0
66,7
66,7
11
13
0
0
3
3
0
0
0
0
0,0
0,0
3
1
0
0
0
2
0
0
100,0
66,7
17
19
0
0
3
3
0
0
0
0
0,0
0,0
6
7
1
0
0
3
2
0
0
0
66,7
0,0
20
21
0
0
3
3
0
0
0
0
0,0
0,0
8
9
0
3
1
0
2
0
0
0
33,3
100,0
23
26
0
0
3
3
0
0
0
0
0,0
0,0
10
11
1
0
0
3
2
0
0
0
66,7
0,0
30
31
0
0
3
3
0
0
0
0
0,0
0,0
12
13
0
0
0
3
3
0
0
0
50,0
0,0
32
33
0
0
3
3
0
0
0
0
0,0
0,0
14
15
2
1
0
0
1
2
0
0
83,3
66,7
34
35
0
0
3
3
0
0
0
0
0,0
0,0
16
17
1
0
0
3
2
0
0
0
66,7
0,0
36
37
0
0
3
3
0
0
0
0
0,0
0,0
18
19
0
0
0
3
3
0
0
0
50,0
0,0
38
39
0
0
3
3
0
0
0
0
0,0
0,0
20
21
0
0
3
3
0
0
0
0
0,0
0,0
42
43
0
0
3
3
0
0
0
0
0,0
0,0
22
23
0
0
1
3
2
0
0
0
33,3
0,0
46
47
0
0
3
3
0
0
0
0
0,0
0,0
24
25
0
1
0
0
3
2
0
0
50,0
66,7
48
49
0
0
3
3
0
0
0
0
0,0
0,0
26
27
0
1
3
0
0
2
0
0
0,0
66,7
51
53
0
0
2
3
0
0
1
0
0,0
0,0
NO PARC
NO PARC
S/R % CUMPLIM.
105
28
29
2
0
0
1
1
2
0
0
83,3
33,3
40
44
0
0
2
2
1
1
0
0
16,7
16,7
30
31
0
0
3
3
0
0
0
0
0,0
0,0
8
22
0
0
1
1
2
2
0
0
33,3
33,3
32
33
0
0
3
3
0
0
0
0
0,0
0,0
29
45
0
0
1
1
2
2
0
0
33,3
33,3
34
35
0
0
3
3
0
0
0
0
0,0
0,0
52
12
0
0
0
0
2
3
1
0
33,3
50,0
36
37
0
0
3
3
0
0
0
0
0,0
0,0
18
24
0
0
0
0
3
3
0
0
50,0
50,0
38
39
0
0
3
3
0
0
0
0
0,0
0,0
1
2
1
1
0
0
2
2
0
0
66,7
66,7
40
41
0
3
2
0
1
0
0
0
16,7
100,0
3
5
1
1
0
0
2
2
0
0
66,7
66,7
42
43
0
0
3
3
0
0
0
0
0,0
0,0
6
10
1
1
0
0
2
2
0
0
66,7
66,7
44
45
0
0
2
1
1
2
0
0
16,7
33,3
15
16
1
1
0
0
2
2
0
0
66,7
66,7
46
47
0
0
3
3
0
0
0
0
0,0
0,0
25
27
1
1
0
0
2
2
0
0
66,7
66,7
48
49
0
0
3
3
0
0
0
0
0,0
0,0
50
14
1
2
0
0
2
1
0
0
66,7
83,3
50
51
1
0
0
2
2
0
0
1
66,7
0,0
28
4
2
3
0
0
1
0
0
0
83,3
100,0
52
53
0
0
0
3
2
0
1
0
33,3
0,0
9
41
3
3
0
0
0
0
0
0
100,0
100,0
GRFICO
DISPONIBILIDAD
100
90
80
70
60
50
40
30
20
10
0
1
10 13
16 19
22
25 28
31 34 37
40 43
46 49 52
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE LA DISPONIBILIDAD
MEDIA
29,2%
Los factores crticos detectados en la administracin de la disponibilidad son:
106
No se ha definido un proceso a seguir para administrar la disponibilidad de

servicios.
La disponibilidad propuesta para los servicios no se encuentra en lnea.
No se ha definido cul es la resistencia de la infraestructura TI.
No se generan reportes de disponibilidad, confiabilidad y mantenimiento

alcanzado.
No se asegura que los servicios TI estn diseados de tal manera que los
niveles de servicio sean alcanzados.
No se ha desarrollado un Plan de Disponibilidad.
No se tienen definidos mtodos ni tcnicas para evaluar la disponibilidad.
No se han determinado franjas horarias de disponibilidad de los servicios TI.
La informacin acerca de la disponibilidad de un servicio no se encuentra

definida en un SLA29 o algn documento similar.
No se ha definido la confiabilidad de servicios.
No se tienen definidos tiempos de flexibilidad de los servicios.
No se evala el impacto de la falla de un componente.
No se tiene definido un rbol de fallas.
No se tiene un mtodo establecido para el anlisis y administracin de

riesgos.
No se realiza un anlisis de interrupcin de sistemas.
No se han determinado mtricas que permitan medir con precisin las

diferentes fases del ciclo de vida de la interrupcin de un servicio.
No se evala la capacidad de servicio de los proveedores internos y externos

de TI.
Los procesos de mantenimiento no estn documentados en un OLA30 o

similares.
No se maneja una AMDB31 o alguna base de datos que ayude al proceso de

administracin de la disponibilidad.
29
No existe ninguna persona duea del proceso de Administracin de la

31
AMDB [Availability Management Data Base, Base de Datos de la Administracin de la Disponibilidad]
30
107
Disponibilidad.
No se cuenta con herramientas y recursos para la administracin de la

disponibilidad.
No se tiene Planes de Mejora de Disponibilidad.
Solo en ciertas ocasiones se tiene un puesto de observacin tcnica.
No todos los servicios estn documentados en un UC32.
No siempre se determinan los requerimientos de disponibilidad antes de

realizar la planificacin de esta.
No se realizan constantemente mediciones de disponibilidad.
No siempre se consulta al cliente en que franja horaria la interrupcin del

servicio afectar menos a sus actividades de negocio.
Se realiza un diseo de la disponibilidad y recuperacin de la infraestructura

de TI al considerar un cambio en un 50%.
Se considera solo parcialmente aspectos de seguridad al realizar la

planificacin de la disponibilidad de un servicio.
Se colabora en un 50% con el diseo de servicios para asegurar su

disponibilidad presente y futura.
RECOMENDACIONES
Nada afecta tanto a la imagen del rea de TI y la satisfaccin de los usuarios

como la falta de disponibilidad de los servicios ofrecidos, por lo tanto se
recomienda el establecer procedimientos que permitan mantenerla, sin tener que
depender del personal a cargo.
Para llevar a cabo eficientemente este proceso, es recomendable que se

identifique las actividades clave de disponibilidad para el negocio como son los
intervalos razonables de interrupcin de los diferentes servicios dependiendo de
sus respectivos impactos, los protocolos de mantenimiento y revisin de los
servicios TI, as como tambin las
32
33
franjas horarias de disponibilidad de los
UC
[Underpinning Contract, Contrato de Servicio Acordado]
Fuentes: a) http://www.uksuperweb.co.uk/wugfeatures.html
b) http://www.ipswitch.com/Support/WhatsUp/guide/v602/3alerts%20and%20notifs2.html
108
servicios TI (24/7, 12/5, etc.). Dicha informacin debe ser plasmada como un
Plan de Disponibilidad para poder evaluarlo y conocer de esta forma como se
est llevando el manejo de los servicios con respecto a este tema. Obviamente
esta informacin debe ser actualizada constantemente.
An cuando de cierta forma se ha definido la disponibilidad de los servicios, esta

informacin no se encuentra publicada para que sirva de ayuda al mejor manejo
de los recursos para de esta forma, entre todo el personal poder obtener el
porcentaje de disponibilidad planificado.
Se recomienda realizar informes de disponibilidad, confiabilidad y mantenimiento

cada cierto tiempo con el fin de conocer cmo ha sido el comportamiento de la
infraestructura, pudindose relacionar esto con las incidencias. Al informar al
negocio de estos datos, se debera usar el lenguaje que usa el negocio.
Para verificar la disponibilidad de los servicios es recomendable tomar en cuenta

que para el cliente los puntos de entrega son en el escritorio y no dentro del
departamento lo que tambin resulta en una percepcin diferente de la
disponibilidad entregada. El rea de TI piensa que entrega un 98% pero en
realidad, en el escritorio del cliente, eso no ocurre, por el hecho de que un
servicio de principio a final se construye sobre varios componentes y de que la
disponibilidad del servicio es por lo tanto un resultado de la disponibilidad de
todos esos componentes juntos.
Aunque resulta un tanto difcil establecer un clculo exacto de disponibilidad, se

debe establecer parmetros que permitan identificar este valor. Para esto, se
podra aplicar el siguiente mtodo, tome el tiempo acordado de servicio, reste a
esta cantidad el tiempo de interrupcin del servicio durante las franjas horarias
de disponibilidad acordadas, a continuacin, divida el resultado entre el tiempo
de interrupcin del servicio durante las franjas horarias de disponibilidad
acordadas y por ltimo multiplique por 100.
Es indispensable que al momento de establecer los acuerdos de nivel de
109
servicio, se tomen en cuenta los requisitos de disponibilidad, para lo que estos

debe encontrase en lnea tanto con los necesidades reales del negocio como
con las posibilidades de la infraestructura TI.
Para evaluar la vulnerabilidad de fallo dentro de los niveles de disponibilidad de

los servicios TI, se recomienda que el diseo propuesto de la infraestructura de
TI y la organizacin de soporte (proveedores internos y externos) estn sujetos a
un anlisis formal de riesgo para definir hasta donde la organizacin es
vulnerable a una amenaza.
Este anlisis debe realizarse al menos
mensualmente.
Entre las tcnicas para poder determinar la disponibilidad de un componente en

la infraestructura, adems del anlisis de riesgos el mas recomendable de
acuerdo a la estructura de la empresa, es el implementar un puesto de
observacin tcnica, con esto se podra monitorear el desempeo de un servicio
antes de que falle. Para esto se puede determinar ciertos parmetros dentro de
los
cuales se considera
que un componente funciona correctamente
establecindolos en un reporte tipo semforo.
Independientemente de las interrupciones del servicio causadas por incidencias

es recomendable realizar labores de mantenimiento y/o actualizacin de
servicios.
Para esto se debe realizar un cronograma para realizar estas
actividades ya que la interrupcin de estas puede afectar a la disponibilidad del

servicio. En aquellos casos en que los servicios no son 24/7 es obvio que,
siempre que ello sea posible, deben aprovecharse las franjas horarias de
inactividad para realizar las tareas que implican una degradacin o interrupcin
del servicio.
Si el servicio es 24/7 y la interrupcin es necesaria se debe
consultar con el cliente en que franja horaria la interrupcin del servicio afectar
menos a sus actividades de negocio e informar con la antelacin suficiente a
todos los agentes implicados. Este mantenimiento debera ser reportado en un
acuerdo de nivel operativo o algn documento similar. Tambin es aconsejable
que al encontrarse ciertas fallas que no generen una interrupcin inmediata en
los componentes de la infraestructura, se genere un Plan de Mejora de
110
Disponibilidad, en donde se ofrezcan cambios basados en el perfeccionamiento

de dichos componentes, ya que caso contrario pueden llegar a causar daos de
mayor magnitud en los servicios y en el peor de los casos quedar inutilizable.
Es importante determinar mtricas que permitan medir con precisin las

diferentes fases del ciclo de vida de la interrupcin del servicio. El cliente debe
conocer estas mtricas y dar su conformidad a las mismas para evitar
malentendidos. En algunos casos es difcil determinar si el sistema est cado o
en funcionamiento y la interpretacin puede diferir entre proveedores y clientes,
por lo tanto, ests mtricas deben de poder expresarse en trminos que el
cliente pueda entender.
Por otra parte, es
aconsejable el evaluar los servicios proporcionados por
proveedores externos de TI. Para esto se debe tomar en cuenta los trminos
establecidos en los contratos y verificar su cumplimiento de acuerdo a
indicadores tales como
tiempos de deteccin y respuesta a los fallos, tiempos
de reparacin y recuperacin del servicio y el tiempo medio de servicio entre

fallos.
De ser posible, se debera implementar una base de datos que
contenga
informacin valiosa para determinar la disponibilidad de los elementos de la

configuracin.
Es aconsejable que para la correcta administracin de la disponibilidad, se

defina una persona duea del proceso, asegurando que los servicios TI estn
diseados de tal manera que los niveles de servicio sean alcanzados (en
trminos de disponibilidad, confiabilidad, mantenimiento y recuperacin),
adems que sea la encargada generar reportes de esta gestin. La persona que
podra desempear este rol sera alguien relacionado con el rea de Redes,
basndonos en su experiencia.
Aunque WhatsUp Gold33 es una solucin de mapeado, monitorizacin,
notificacin, e informes de rendimiento para redes, es recomendable que se
111
busquen nuevas alternativas que permitan determinar la disponibilidad de un

servicio antes de que este sea interrumpido, o en su defecto, se debera trabajar
con la ltima versin para poder adquirir mas recursos.
Por otro lado, es recomendable determinar cundo el servicio estar disponible,

basado en el quin y cmo va a utilizarlo, ya que cualquier fallo en una de ellas
afectar gravemente a la otra. Esto tambin debera ser manejado en su Plan
de Disponibilidad.
DISPONIBILIDAD.
OBJETO: ADMINISTRACIN DE LA CONTINUIDAD
ORDEN POR PORCENTAJE DE CUMPLIMIENTO

DE LA ADMINISTRACIN DE CONTINUIDAD
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
0
0
1
1
0
0
1
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
2
2
0
2
0
2
0
2
0
2
1
3
3
3
3
3
3
2
2
1
3
3
0
0
3
1
2
1
3
0
1
1
2
0
0
0
0
0
0
1
1
1
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
50,0
50,0
33,3
33,3
50,0
16,7
66,7
16,7
50,0
0,0
83,3
16,7
33,3
0,0
0,0
0,0
0,0
0,0
0,0
16,7
16,7
16,7
10
14
15
16
17
18
19
23
25
26
27
29
31
32
34
35
41
6
8
12
20
21
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
2
2
2
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
16,7
16,7
16,7
16,7
16,7
112
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
0
0
0
0
0
0
0
0
0
0
1
0
0
3
0
0
0
0
0
0
1
3
0
1
2
1
0
1
3
1
3
2
3
3
3
1
3
2
3
3
1
3
3
0
1
2
2
2
3
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
2
0
1
0
0
0
0
0
0
2
1
1
1
0
2
2
0
3
2
1
2
3
2
0
2
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0,0
16,7
0,0
0,0
0,0
33,3
0,0
16,7
0,0
0,0
33,3
0,0
0,0
100,0
33,3
16,7
16,7
16,7
0,0
33,3
66,7
100,0
50,0
66,7
83,3
66,7
50,0
66,7
100,0
66,7
22
24
30
38
39
40
3
4
13
28
33
37
42
1
2
5
9
45
49
7
43
46
48
50
52
11
47
36
44
51
0
0
0
0
0
0
1
1
0
0
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
2
2
3
3
3
1
2
2
2
2
2
2
2
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
0
0
2
2
0
2
2
3
3
3
3
3
3
2
2
2
2
2
2
1
1
0
0
0
1
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
GRFICO
CONTINUIDAD
100
90
80
70
60
50
40
30
20
10
0
1
10 13
16 19 22
25 28 31
34 37 40 43 46 49 52
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE LA CONTINUIDAD
MEDIA
30,4%
16,7
16,7
16,7
16,7
16,7
16,7
33,3
33,3
33,3
33,3
33,3
33,3
33,3
50,0
50,0
50,0
50,0
50,0
50,0
66,7
66,7
66,7
66,7
66,7
66,7
83,3
83,3
100,0
100,0
100,0
113
Los factores crticos detectados en la administracin de la continuidad son:
No se maneja un Plan de Gestin de Emergencias.
No se realizan pruebas iniciales de desempeo antes ni despus de entregar

al ambiente de operacin el plan de recuperacin y prevencin de riesgos.
No se realizan auditoras ni revisiones frecuentes al plan de recuperacin y

prevencin.
No se ha realizado una comunicacin adecuada del plan de recuperacin y

prevencin.
No se realizan simulacros para diferentes tipos de desastres.
No son suficientes las medidas tomadas en el plan de recuperacin para la

continuidad de los servicios.
Al requerirse un cambio en el plan, no se usan RFCs34 para solicitar dicho

cambio.
No existe una persona duea del proceso de continuidad.
No existe una persona encargada de la asignacin del personal y recursos

para llevar a cabo la administracin de la continuidad.
No se realizan informes de las actividades de prevencin y recuperacin

realizadas.
No se han establecido protocolos de actuacin en situacin de crisis.
No existe alguna persona que de aceptacin de planes y reportes de pruebas.
No se realiza un recuento de daos posteriores a un desastre.
No se realizan reportes tras una crisis.
No se realizan estimados de la probabilidad de las posibles amenazas.
Se ha realizado una organizacin y planeacin antes de la implementacin de

la continuidad con respecto a los servicios ofrecidos en un mnimo porcentaje.
Los planes de prevencin y recuperacin no estn adecuadamente

actualizados.
El rea de TI no est capacitada para la implementacin e los planes de

prevencin y recuperacin.
Los planes no son los adecuados a las necesidades del negocio.
Las personas a cargo del proceso de continuidad no tienen unas
34
RFC [Request For Change, Peticin de Cambio]
114
responsabilidades bajo condiciones normales y otras durante una crisis.
No siempre se comunica y mantiene la alerta de una crisis.
No se contrata servicios necesarios para prevenir desastres.
Nunca se ha puesto en ejecucin el plan de recuperacin para ver si funciona

correctamente.
No se ha realizado un anlisis formal del impacto en el negocio de una

supuesta interrupcin de los diferentes servicios TI.
Se asegura el conocimiento
y formacin del personal respecto a los
procedimientos asociados solo en un mnimo porcentaje.
No siempre se asignan recursos suficientes a la continuidad del servicio.
No se ha realizado un anlisis del costo de los procesos.
Muy pocas veces se ocupan de las negociaciones y relaciones pblicas

durante una crisis.
El porcentaje de recuperaciones de servicios que no se realice en un periodo

de tiempo de 24 a 72 horas es de 33%.
Se considera parcialmente a la continuidad como un proyecto en la

organizacin.
No se ha definido bien un alcance y objetivo de la administracin de la

No se realiza una evaluacin constante de riesgos, vulnerabilidades y

amenazas a los que est expuesta la infraestructura TI.
No se tiene un Plan de Prevencin de Riesgos que minimice del todo el

impacto de un desastre en la infraestructura TI.
El porcentaje de recuperaciones de servicios basado en arreglos con otra

organizacin es del 50%.
No se realizan pruebas y auditoras constantes para ver si las vulnerabilidades

realmente fueron controladas.
RECOMENDACIONES
Las
crisis
suelen
provocar
reacciones
de
pnico
que
pueden
ser
contraproducentes y a veces incluso ms dainas que las provocadas por el
115
incidente que las caus. Por ello es imprescindible que en caso de situacin de
emergencia estn claramente definidas las responsabilidades y funciones del
personal as como los protocolos de accin correspondientes en un documento
formal. En dicho documento se deben registrar la evaluacin del impacto de la
contingencia en la infraestructura TI, la asignacin de funciones de emergencia al
personal de servicio TI, la comunicacin a los usuarios internos y externos del
rea e TI de una grave interrupcin o degradacin del servicio, los procedimientos
de contacto y la colaboracin con los proveedores involucrados.
Aunque se tenga definido un Plan de Recuperacin y Prevencin de Riesgos, es

aconsejable que se realicen pruebas inciales de desempeo, ya que se debe
comprobar que las acciones planteadas en dichos planes, sean las mas ptimas y
en verdad puedan salvar a la infraestructura de TI de una crisis. Obviamente
estos planes tambin deben ser actualizados, al menos cada ao, ya que de
acuerdo al comportamiento de la empresa se van implementando nuevos
proyectos que tambin deberan ser considerados como posibles sistemas
afectados. Por otra parte tambin se deberan realizar auditoras a estos
documentos con el fin de que se compruebe que toda la infraestructura y servicios
TI estn incluidos en el plan hasta la fecha.
Una buena idea tambin es el
realizar pruebas sorpresa de este plan para conocer si todas las personas
involucradas de llevarlo a cabo saben cul es su rol en el proceso de
recuperacin de sistemas y servicios.
Los procedimientos de recuperacin tomados en cuenta para
el Plan de
Recuperacin respectivo, pueden depender de la importancia de la contingencia y

de la opcin de recuperacin asociada, pero en general es recomendable tomar
en cuenta la asignacin de personal y recursos, instalaciones y hardware
alternativos, procedimientos de recuperacin de datos, contratos de colaboracin
con otras organizaciones, protocolos de comunicacin con los clientes.
Por otra parte, no es suficiente el establecer medidas de recuperacin a un

desastre, sino que tambin es recomendable el establecer medidas para evitar o
minimizar el impacto de un desastre en la infraestructura TI. Entre las medidas
116
habituales se aconseja las siguientes: almacenamiento de datos distribuidos,

polticas de back-ups, duplicacin de sistemas crticos y sistemas de seguridad
pasivos.
Tambin es aconsejable realizar estimados de probabilidad de
amenazas, con el fin de poder estar alerta. Todo esto debe ser registrado en un
Plan de Prevencin de Riesgos, e cual al igual del Plan de Emergencia y de
Recuperacin deben ser actualizados constantemente.
Al ser estos planes parte de la infraestructura, es aconsejable que para realizar

cambios sobre estos, se realicen peticiones formales de cambio, con el fin de que
quede un registro de quien solicita el cambio y cuales son las razones para este.
No existe una persona duea del proceso de la Administracin de la Continuidad,
sin embargo de alguna forma las personas en el rea de redes tratan de cubrir
esta actividad, aunque sera recomendable que se asigne a alguien para liderar al
equipo en caso de ocurrir algn tipo de amenaza.
En tal caso, podra
desempear este papel el Administrador de Redes.
Por otra parte, se debe formar un Consejo o Equipo, en donde se asignen los
recursos y personal, as como tambin la definicin de las polticas establecidas
en los planes. En este grupo podran participar gente de todas las reas de la
Divisin de Sistemas, con el fin de poder tener un desglose ms grande de todos
los recursos utilizados para que un servicio funcione.
Como otra accin importante se recomienda realizar informes de las actividades

de prevencin y recuperacin realizadas, con el fin de mejorar
Una recomendacin muy importante, es el realizar un recuento de los daos

posteriores a un desastre y plasmarlos en un reporte, para que, dependiendo de
la situacin la Gerencia pueda tomar medidas de mejora, las cuales muchos
casos tal vez impliquen cambio de equipos.
Por otra parte, no simplemente se debe implementar los planes de prevencin y

recuperacin, sino que se debe dar capacitacin de cmo se deben llevar a cabo,
caso contrario, an cuando se tengan los mejores procedimientos no van a ser
117
desarrollados de manera eficientemente debido al desconocimiento de las

personas con respecto al proceso. Esta capacitacin debera ser realizada al
realizarse un cambio a dichos planes.
As como tambin se debe sembrar
conciencia de que las actividades durante una crisis necesariamente no sern las
mismas durante su periodo normal de trabajo, necesitando as ms compromiso
por parte de las personas involucradas.
Por otro lado, es aconsejable el comunicar de una crisis a los clientes y usuarios,
ya que al obtener un servicio deficiente, tal vez se pueda dar lugar a que no se
tenga un control sobre la administracin de dichos servicios o tal vez se
malinterprete y se pueda dar una mala imagen. La forma de comunicacin sera
por parte del Service Desk, aunque tambin se podra usar el servicio de
mensajera interna.
Aunque la infraestructura de la empresa supere a muchas en cuanto se refiere a

tecnologa, tambin es necesario tomar en cuenta que deben estar a la par con
los proyectos establecidos, con el fin de que estos no tengan ningn problema de
la continuidad del servicio.
Tambin es una buena idea el realizar un anlisis de los costos de los procesos
relacionados para mantener la continuidad de los servicios, ya que se podra
realizar una comparacin entre lo que cuesta obtener equipos que permitan
mantener la continuidad vs. lo que representara que se pierda un servicio en
cuanto al negocio.
Es aconsejable realizar una evaluacin constante de riesgos, vulnerabilidades y

amenazas a los que est expuesta la infraestructura, especialmente en lo que
tiene que ver con virus o e mal manejo de los usuarios. Con respecto al control
de virus, an cuando se tenga una herramienta, se debera estar a la vanguardia
de cmo prevenir cualquier virus que no sea detectado suscribindose a foros o
sitios donde se de este tipo de soporte. Con respecto a al mal manejo por parte
de los usuarios, es necesario brindar capacitacin constante.
118
Es recomendable que las recuperaciones de los servicios se las realice mximo

en un tiempo de 24 horas, ya que podra acarrear una serie de incidentes que
podran terminar en la prdida total del servicio trayendo un problema grave al
negocio. Una forma de asegurar que esto se de, es que se manejen documentos
formales de acuerdos de nivel de servicio tanto entre el rea de TI y sus clientes,
as como tambin con los proveedores externos, en donde se especifique que el
tiempo mximo que un servicio puede mantenerse en stand by.
Por ltimo se debe procurar solo en ocasiones en donde sea de carcter crtico el
depender de otra empresa para solucionar problemas que afecten a la
continuidad de un servicio, ya que es mas complicado el ir coordinando las
actividades especialmente en situaciones de crisis.

CONTINUIDAD.
PROCESO DE GESTIN DE LA SEGURIDAD

OBJETO: ADMINISTRACIN DE LA SEGURIDAD

LA SEGURIDAD
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
#
PREG.
SI
NO
PARC
S/R
%
CUMPLIM.
1
2
3
4
5
6
7
8
9
10
11
2
0
0
2
0
0
0
3
3
3
3
1
0
1
0
0
0
0
0
0
0
0
0
3
2
1
3
3
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
66,7
50,0
33,3
83,3
50,0
50,0
50,0
100,0
100,0
100,0
100,0
14
19
29
35
40
44
47
49
13
15
16
0
0
0
0
0
0
0
0
0
0
0
3
3
3
3
3
3
3
3
2
2
2
0
0
0
0
0
0
0
0
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
0,0
16,7
16,7
16,7
119
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
0
0
0
0
3
1
0
0
0
0
0
0
0
1
0
0
0
3
0
0
1
0
0
0
0
0
1
0
0
1
0
0
0
0
0
1
0
1
1
1
0
2
3
2
2
0
1
3
0
1
1
1
1
0
0
1
2
3
0
0
0
2
1
3
2
1
0
2
3
0
0
1
3
1
1
3
1
3
0
0
0
2
1
0
1
1
0
1
0
3
1
2
2
2
3
2
2
1
0
0
3
3
0
2
0
1
2
3
0
0
3
2
2
0
2
2
0
1
0
2
2
2
1
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
16,7
0,0
16,7
16,7
100,0
50,0
0,0
50,0
16,7
33,3
33,3
33,3
50,0
66,7
33,3
16,7
0,0
100,0
50,0
50,0
33,3
33,3
0,0
16,7
33,3
50,0
33,3
0,0
50,0
66,7
33,3
0,0
33,3
33,3
0,0
50,0
0,0
66,7
66,7
66,7
16,7
28
36
53
3
22
23
24
27
33
34
37
39
43
45
46
2
5
6
7
18
20
25
31
32
38
41
1
26
42
50
51
52
4
48
8
9
10
11
12
17
30
GRFICO
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
2
1
1
1
1
1
2
2
3
3
3
3
3
3
3
2
2
2
1
1
1
1
1
2
1
1
2
1
1
1
0
0
0
0
1
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
2
2
2
2
2
0
2
2
0
2
2
2
3
3
3
3
1
3
3
3
3
3
3
0
2
2
2
2
2
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
16,7
16,7
16,7
33,3
33,3
33,3
33,3
33,3
33,3
33,3
33,3
33,3
33,3
33,3
33,3
50,0
50,0
50,0
50,0
50,0
50,0
50,0
50,0
50,0
50,0
50,0
66,7
66,7
66,7
66,7
66,7
66,7
83,3
83,3
100,0
100,0
100,0
100,0
100,0
100,0
100,0
120

SEGURIDAD
100
90
80
70
60
50
40
30
20
10
0
1
10
13
16
19
22
25
28
31
34
37
40
43
46
49
52
Nm ero de Pregunta
PORCENTAJE DE CUMPLIMIENTO DE LA ADM. DE LA SEGURIDAD
MEDIA
43,4%
Los factores crticos detectados en la administracin de la seguridad son:
No se tienen programas de formacin en cuanto al manejo de la seguridad.
Los empleados no firman acuerdos de confidencialidad correspondientes a

su cargo y responsabilidad.
Existe despreocupacin por la seguridad del personal por lo que sabe del
negocio.
No se realizan auditoras externas a los proveedores de los servicios TI.
No se ha realizado la integracin a las estrategias oficiales de seguridad de

la informacin por parte del cliente.
No se conoce los estndares de seguridad asociados a cada servicio.
No se informa a los clientes y la organizacin TI de posibles vulnerabilidades

o errores procedimentales.
No se generan reportes con respecto al cumplimiento de SLAs35, UCs36 y

OLAs37.
Se manejan procedimientos de anlisis de riesgos en un mnimo porcentaje.
No se tiene definido que informes de seguridad deben ser emitidos
35

OLA [Operacional Level Agreement, Acuerdo de Nivel Operacional]
37
36
121
peridicamente.
Solo se han definido de manera parcial los recursos necesarios para la

administracin de la seguridad.
No se ha implementado el Plan de Seguridad.
No se realiza una clasificacin y administracin exhaustiva de los recursos

para buscar cuales son los mas crticos.
Se realizan autoevaluaciones para ver si se manejen correctamente
las
polticas de seguridad con escasa frecuencia.
El Service Desk dispone solo de cierta informacin de seguridad para

asesorar en al aplicacin de los protocolos de seguridad y acceso a la
informacin.
Se cumplen los requisitos de seguridad establecido en SLAs, OLAs y UCs

en un porcentaje muy bajo.
El mantenimiento al Plan de Seguridad es inapreciable.
No se monitoriza, ni se evala el cumplimiento del Plan de Seguridad.
No se han definido mtricas que permitan evaluar los niveles de seguridad

acordados en el Plan de Seguridad.
Se supervisa proactivamente los niveles de seguridad en un porcentaje bajo.
La Administracin de Incidentes y Problemas no ayudan mucho a la

identificacin de incidentes de seguridad.
Muy pocas veces, la persona que realiza las autoevaluaciones es la misma

considerada duea del proceso de la Administracin de la Seguridad.
El proveedor de servicio de TI no siempre es quien implementa los

requerimientos de seguridad establecidos en un SLA.
Se tiene a los equipos y procedimientos de seguridad actualizados en un

33%.
No siempre se elevan RFCs38 o documentos formales para mejorar los

niveles de seguridad adecundolos a nuevos desarrollos tecnolgicos.
El cliente determina los niveles de seguridad solo el 50% de las ocasiones.
No todas las polticas de seguridad estn alineadas con las del negocio en
su conjunto.
38
RFC [Request For Change, Peticiones de Cambio]
122
Estas polticas se encargan de que coordinen correctamente todos los

procesos TI.
En las polticas se han establecido y asignado recursos y responsabilidades.
No todo el personal conoce y acepta las medidas de seguridad establecidas,

as como sus responsabilidades al respecto.
No se tiene un Plan de Seguridad bien definido.
No siempre se aplica las medidas de seguridad establecidas en la poltica y

Plan de Seguridad.
No se tiene correctamente definido cules son las soluciones de incidentes

de seguridad.
No se evalan los incidentes de seguridad en su totalidad.
Existe una persona responsable de la operacin efectiva del proceso de

seguridad, pero no siempre se le considera como tal.
Solo se ha realizado asignacin de responsabilidades con respecto a la

seguridad en un 50%.
RECOMENDACIONES
Es recomendable que se establezcan polticas de seguridad, tomando en

cuenta a los clientes de TI, ya que a final de cuentas son ellos quienes
establecen los requerimientos para algn servicio, sobreentendindose que
estos deben estar alineados con el negocio.
En particular dichas polticas
deben determinar: la relacin con la poltica general del negocio, los protocolos
de acceso a la informacin, los procedimientos de anlisis de riesgos, los
programas de formacin, el nivel de monitorizacin de la seguridad, qu
informes deben ser emitidos peridicamente, la estructura y responsables del
proceso de Gestin de la Seguridad, los procesos y procedimientos empleados,
los responsables de cada subproceso, los auditores externos e internos de
seguridad, as como tambin los recursos necesarios en cuanto a software,
hardware y personal.
Esto es aconsejable que quede establecido en un
documento formal.
Para poder mantener un control mas adecuado del manejo de la informacin de
123
empresa se aconseja que los empleados firmen acuerdos de confidencialidad

correspondientes a su cargo y responsabilidad.
Es recomendable que se realicen auditoras a los proveedores de los servicios

de TI con el fin de detectar alguna accin que est fuera de las actividades
normales definidas, de ser as, el procedimiento adecuado sera denunciar a la
empresa comprometida, cancelar los tratos realizadas con esta y buscar nuevos
proveedores.
Aunque los estndares de seguridad asociados a cada servicio sean conocidos

de alguna manera por ciertas personas del rea de Sistemas, es necesario que
esta informacin se haga pblica, especialmente la que est relacionada
directamente con los usuarios. Para esto es buena idea el realizar charlas o
plasmar toda esta informacin en un documento que sea manejado por el
Service Desk.
Por otra parte, se debera informar a toda la organizacin TI y sus clientes de

posibles vulnerabilidades o errores procedimentales de seguridad, as como
tambin la forma de controlar estos en caso de que se presenten. Esto debera
estar definido en un documento el cual podra ser distribuido por el Service Desk
o en su defecto usar la mensajera interna para dar a conocer esta informacin.
En cuanto a los acuerdos de servicio tanto a nivel de clientes y proveedores

externos, as como tambin entre las reas de Sistemas, es recomendable que
se generen reportes de cumplimiento. Por otra parte, para poder cumplir con
dichos acuerdos, se debe realizar un anlisis real de la infraestructura de la
empresa, con el fin de poder adecuarlos a los servicios manejados.
Es recomendable que un Plan de Seguridad sea desarrollado anualmente en

colaboracin con las reas de Administracin de Bases de Datos y Redes
especialmente. Este plan debe disearse para ofrecer un mejor y ms seguro
servicio al cliente y nunca como un obstculo para el desarrollo de sus
actividades de negocio, adems debe ser monitorizado y evaluado en cuanto a
124
su cumplimiento.
Siempre que sea posible deben definirse mtricas e indicadores clave que
permitan evaluar los niveles de seguridad acordados. Algunos a tomarse en
cuenta seran el nmero de incidentes y problemas de seguridad, si se miden
los niveles reales de seguridad, si los aspectos de seguridad estn cubiertos en
los acuerdos de niveles de servicio y por ltimo pero mas importante si est
mejorando la opinin que la organizacin tiene de TI.
Se recomienda manejar documentos formales de peticiones de cambio en
respuesta a problemas de seguridad, para asegurar confidencialidad e
integridad de los datos de seguridad y para mantener la seguridad cuando se
lanza software a un entorno vivo.
Por otra parte, se debe asignar a una persona que se haga cargo del proceso
de la administracin de la seguridad, la misma que debe encargarse de realizar
supervisiones constantes de los niveles de seguridad, analizando tendencias,
nuevos riesgos y vulnerabilidades, as como tambin, decidir en cada momento
lo que se va a hacer y como lo va a hacer. Con respecto a la identificacin de
nuevos riesgos y vulnerabilidades, se podran manejar ejercicios internos en el
rea.
Es recomendable y mas bien una necesidad para el buen manejo de la

seguridad, que el rea de gestin de la empresa reconozca la autoridad de la
Gestin de la Seguridad respecto a todas estas cuestiones y que incluso
permita que sta proponga medidas disciplinarias vinculantes cuando los
empleados u otro personal relacionado con la seguridad de los servicios
incumpla con sus responsabilidades.
Aunque la tecnologa de la empresa es la mas favorable para suministrar los

servicios requeridos, es necesario que los procedimientos de seguridad sean
actualizados constantemente, especialmente en cuanto al control de la nueva
tecnologa adquirida.
125
Con respecto a la seguridad legal, se la maneja de tal forma que todo el

software dentro de la empresa tiene licencias e incluso se tiene un sistema de
monitoreo para detectar software sin licencia, sin embargo no existe una
persona a cargo de esta actividad, por lo tanto se recomienda que para asignar
este rol, se busque a alguien que est familiarizado con los programas que
maneja el usuario, as como tambin que conozca del proceso de adquisicin y
mantenimiento de licencias.
Es indispensable el preservar la informacin tomando en cuenta el manejo de

back-ups en otro lugar
adems de los que existen tanto en la propia
organizacin como en el banco, tal vez una tercera opcin podra ser el
contratar los servicios de una empresa dedicada a brindar este tipo de servicios.
Por otro lado aunque se tenga un lector biomtrico para el ingreso a cuarto fro
se debe controlar que este funcione adecuadamente y en caso de no ser as
reportar el incidente a la persona a cargo, mediante un documento formal de
solicitud de cambio para poder realizar las acciones pertinentes.
SEGURIDAD.
2.1.1.4.2
Resultados del Anlisis de Roles

ROLES DE LOS PROCESOS OPERATIVOS O DE SOPORTE A
SERVICIOS
OBJETO: ADMINISTRACIN DE SERVICE DESK
ORDEN POR NMERO DE ROL
#
ROL
ROL
CUMPLIMIENTO
DE FUNCIONES
PORCENTAJE DE
CUMPLIMIENTO
DEL ROL

CUMPLIMIENTO DE ROLES PARA LA
FUNCIN SERVICE DESK
CUMPLIMIENTO
#
DE FUNCIONES
PORCENTAJE
ROL
DE
CUMPLIMIENTO
126
Administracin
del
Service Desk
Equipo de
Service Desk
DEL ROL
SI
NO
PARC
62,5
54,5
SI
NO
PARC
CUMPLIMIENTO
DEL ROL
54,5
62,5
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE ROLES DE LA FUNCIN
SERVICE DESK
100
90
80
70
60
50
40
30
20
10
0
Administracin de Service Desk

Rol
PORCENTAJE DE CUMPLIMIENTO DEL ROL
MEDIA
58,5 %
Los factores crticos detectados de acuerdo al incumplimiento de funciones de cada uno
los roles establecidos para la funcin Service Desk son lo siguientes:
Administracin de Service Desk
No siempre se tiene la habilidad de comprender que los problemas del cliente

afectan al negocio.
La conduccin del Proceso de Gestin de Incidentes no es muy adecuada para

lograr la efectividad y eficiencia esperada.
No se usan mtodos para dirigir al Equipo de Service Desk con el fin de brindar un
servicio de calidad.
No se realiza seguimiento a incidentes y quejas cuando ya son asignados a

soporte de segundo o tercer nivel.
No se mantiene informado al usuario sobre estatus y progresos con respecto a

algn incidente reportado.
Muy pocas veces realiza procedimientos de monitoreo y escalacin de incidentes
127
relacionados con los acuerdos de nivel de servicio.
Casi nunca se realiza una administracin de todo el ciclo de vida de una solicitud,
especialmente en lo que se refiere a la verificacin.
No siempre
se comunica a los usuarios internos y externos de los cambios
planeados y de corto plazo.
Muy
pocas
veces
se
proporciona
la
administracin
informacin
recomendaciones para la mejora del servicio.
No
se destacan las necesidades de capacitacin para los clientes internos y
externos.
Casi no contribuyen a la identificacin de problemas.
RECOMENDACIONES
Dentro de la administracin del Service Desk, es de vital importancia que se asigne a

una persona que se encargue de hacer cumplir los objetivos propuestos para el buen
funcionamiento de este servicio, especialmente en lo que se refiere a la interaccin con
los usuarios. Es recomendable que se considere que la persona designada a ocupar
este puesto sea capaz de comprender que todos los problemas que el cliente tenga con
el servicio proporcionado pueden afectar al negocio ya sea de forma inmediata o a largo
plazo.
En cuanto a la conduccin del proceso de administracin de incidentes, es necesario que
se establezcan cierto tipo de ndices
para ver si se cumple con las expectativas
esperadas, al igual que definir los protocolos de interaccin con el cliente: guiones,
checklists, entre otros.
Por otra parte el equipo de Service Desk debera ser conformado por un nmero mnimo
de 5 personas considerando el nmero de usuarios que tiene la empresa al momento.
Por otro lado, es muy importante que las personas que forman actualmente parte del
Equipo de Service Desk, no se limiten a la recepcin de llamadas, registro de incidentes
y en ciertos casos a la resolucin de estos (siempre y cuando no ameriten una
escalacin), sino que den seguimiento a todo el proceso de solucin, con el fin de que
se mantenga contacto con el usuario hasta tener la seguridad que dicho incidente ha
128
sido resuelto satisfactoriamente basndose en la aceptacin del mismo , e incluso sera

buena idea el considerar que uno de ellos se dedique exclusivamente a realizar esta
actividad, una forma de hacerlo sera mediante el uso del correo interno de la empresa o
va telefnica.
Es importante que no se dependa de la gente que trabaja en el Equipo de Service Desk,

para el correcto funcionamiento de este, sino que se desarrollen ciertos documentos que
sirvan como gua o estndares para la resolucin de incidentes.
Estos documentos se
deben semejarse lo ms que puedan a la realidad de la empresa.
Otra labor que no deben descuidar las personas pertenecientes a este equipo es el
comunicar a los usuarios tanto internos como externos de los cambios planeados, as
como tambin los de corto plazo, con el fin de que estos tomen medidas preventivas
para continuar con sus actividades normales como por ejemplo el respaldo de la
informacin, o en caso de ser necesario pidan capacitacin de los nuevos proyectos
establecidos.
Es recomendable que la gente del Equipo de Service Desk proporcione a la persona
encargada de la Administracin de este servicio, informacin de los incidentes
reportados, con el fin de poder tener una bitcora en la cual puedan guiarse para ver
como se est manejando esta funcin, o en su defecto destacar las necesidades de
capacitacin para los clientes tanto internos como externos.
El grupo de Service Desk debera contribuir a la identificacin de problemas, con el fin de

que ms adelante se asigne a algn grupo dedicado a investigar la causa de estos y se
identifique una solucin que permita eliminarlos definitivamente.
Por ltimo, se recomienda que se genere un nuevo cargo dentro de los establecidos,
refirindose al equipo de Service Desk, cuyo perfil sera que aporte conocimientos
tcnicos afianzados y experiencia en Instalacin de equipos, soporte en sitio
y en
remoto, configuracin de equipos, entre otros, sin embargo lo mas importante es que
sean personas dinmicas, con facilidad para integrarse en un equipo de trabajo y que
tengan facilidad para interactuar con usuarios.
129
TABLA 2.14. RESULTADO OBTENIDO DE LA APLICACIN DE LA GUA ELABORADA PARA

LA FUNCIN DE SERVICE DESK.

CUMPLIMIENTO PORCENTAJE DE
DE FUNCIONES
CUMPLIMIENTO
SI
NO PARC
DEL ROL

CUMPLIMIENTO DE ROLES PARA EL
PROCESO DE LA ADMINISTRACIN DE
INCIDENTES
#
DE FUNCIONES
CUMPLIMIENTO
ROL
SI NO
PARC
DEL ROL
#
ROL
ROL
Administracin
de Incidentes
50,0
50,0
Manejo de
Incidentes
83,3
50,0
Soporte 2do
Nivel
50,0
83,3
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE ROLES PARA EL
PROCESO DE ADMINISTRACIN DE INCIDENTES
100
90
80
70
60
50
40
30
20
10
0
Soporte 2do Nivel
Rol
MEDIA
61,1 %
Los factores crticos detectados de acuerdo de acuerdo al incumplimiento de funciones
de cada uno de los roles establecidos para el proceso de Administracin de Incidentes
130
son lo siguientes:
No siempre se monitorea la efectividad y eficiencia del proceso de administracin

de incidentes.
No se genera informacin muy detallada para la administracin de incidentes.
No siempre se identifica recomendaciones de mejora para la administracin de

incidentes.
Las personas que forman parte del equipo que maneja incidentes, no brinda
mantenimiento al sistema de administracin de incidentes.
No se realiza monitoreo del estatus y progreso de un incidente.
El cierre de incidentes no siempre lo realiza la persona que lo registr.
Soporte 2do Nivel
No se realiza monitoreo de incidentes ni de los elementos de configuracin

afectados.
No se realiza deteccin de posibles problemas para asignarlos al equipo de

Administracin de Problemas para su solucin.
RECOMENDACIONES
Es recomendable que se asigne a una persona que acte como Administradora del
proceso, ya que esta sera la encargada del monitoreo de la efectividad del mismo. Una
sugerencia es que se asigne este rol a la misma persona encargada de la Administracin
del Service Desk.
De igual forma, sera recomendable que se delegue como grupo oficial de manejo de
incidentes al Equipo de Service Desk y no al personal del Grupo de Soporte de
Infraestructura Informtica, ya que este vendra a ser uno de los que conformara el
131
Soporte de 2do Nivel.
Por otro lado, las personas encargadas del manejo de los incidentes, deberan mantener
informados a los usuarios de todo el proceso de resolucin de estos. Para poder lograr
esta actividad se podra usar, como ya se dijo anteriormente, el correo interno de la
empresa o en su defecto el telfono. Para poder llevar a cabo esto ltimo es necesario
que la persona que registra el incidente reportado pida estos datos al usuario
involucrado.
En cuanto se refiere al cierre de incidentes, este debera ser realizado por las personas
que lo registran cuando este es reportado. Es recomendable que este procedimiento
sea realizado una vez que el usuario relacionado con dicho incidente considere que
puede trabajar de forma normal y no va a tener ningn tipo de interrupciones debido a
este.
Aunque directamente el grupo de Administracin de Incidentes no est relacionado con

la elaboracin de la herramienta usada para el registro de incidentes, se debera tomar
las medidas necesarias para colaborar al menos en un porcentaje en el mantenimiento
de dicha herramienta con el fin de mejorarla en caso de ser posible.
Por otra parte, una vez que se ha realizado la escalacin de un incidente a un grupo de
soporte, es recomendable que las personas que conforman este ltimo, tomen muy en
cuenta los elementos de configuracin relacionados, especialmente en el caso de que se
necesite hacer un cambio a la infraestructura para resolverlo, con el propsito de poder
tomar medidas preventivas para evitar alguna prdida de informacin o en su defecto
que otros componentes empiecen a fallar.
Se recomienda que el grupo de Soporte de 2do nivel (conformado por los miembros de
la
Divisin de Sistemas a excepcin del Service Desk), se dediquen no solo a la
atencin rpida de un incidente, sino a investigar mas a fondo la causa de este para
poder determinar una solucin que lo elimine de una vez por todas. Es aconsejable que
en caso de no querer realizar esta actividad, se asigne un grupo especfico para llevarla
a cabo.
132

LA ADMINISTRACIN DE INCIDENTES.

DE FUNCIONES
CUMPLIMIENTO
SI
NO PARC
DEL ROL

PROCESO DE ADMINISTRACIN DE
PROBLEMAS
#
DE FUNCIONES
CUMPLIMIENTO
ROL
SI NO PARC
DEL ROL
#
ROL
ROL
Administracin
de Problemas
41,7
12,5
Soporte de
Problemas
12,5
41,7
GRFICO
PROCESO DE ADMINISTRACIN DE PROBLEMAS
100
90
80
70
60
50
40
30
20
10
0
Rol
MEDIA
27,1 %
de los roles establecidos para el proceso de Administracin de Problemas
siguientes:
son lo
133
No existe una persona que desarrolle y de mantenimiento al control de errores y

problemas de una manera formal.
No se aseguran de la eficiencia y efectividad del control de problemas y errores.
No proporciona ninguna informacin relacionada con problemas a la gerencia.
No se ha realizado la obtencin de recursos necesarios para la administracin de

problemas.
No manejan un sistema de control de problemas y errores.
No se realiza un anlisis y evaluacin de la efectividad de la administracin

proactiva de problemas.
No existe una persona o grupo de personas destinado a la investigacin de

problemas para convertirlos en errores conocidos.
No se monitorea el proceso para eliminar errores conocidos.
No se identifican tendencias.
No se comunica mejoras y arreglos rpidos a la Administracin de Incidentes.
RECOMENDACIONES
En caso de que se haga efectiva la recomendacin de implementar la Administracin de

Problemas en la empresa, o al menos se haga hincapi en hacer una diferencia entre
incidentes y problemas, es aconsejable que se delegue una persona que se encargue de
dirigir este proceso. Este rol podra ser asignado a alguna de las personas del Grupo de
Soporte de Infraestructura Informtica especialmente alguien que tenga el perfil de
Tcnico de Soporte ya que estos
manejan
de alguna forma el anlisis de las
necesidades de los usuarios y podra servir como gua al momento de querer definir una
posible causa de algn incidente. Es importante que la persona que desempee este
cargo no sea la misma que administre el Service Desk o el proceso de Incidentes, ya que
tal vez se de preferencia a la solucin rpida de un incidente y no a la investigacin de la
causa que lo origin.
134
Por otra parte, para poder asegurar la eficiencia y efectividad del control de problemas y
errores, el administrador del proceso, debera establecer polticas basadas en la mejora
de la prestacin de los servicios ofrecidos.
Es importante que el administrador asignado para dirigir el proceso, realice los trmites
respectivos para la adquisicin de recursos necesarios con el de gestionar eficiente
dicho proceso, especialmente cuando se trata de cambios grandes en la infraestructura
de la organizacin. Uno de las primeras peticiones a realizarse, debera ser el que se
desarrolle un mdulo que permita interactuar con la informacin de incidentes, con el
propsito de que en base a estos se puedan identificar y registrar problemas, al igual que
errores definidos una vez encontrada su causa, as como tambin la solucin definitiva
encontrada luego del respectivo anlisis.
Una vez establecido el control de problemas, se debera generar informacin

representativa para la gerencia con el fin de que se justifique de alguna forma la
inversin realizada con respecto a los recursos para el mantenimiento de los servicios TI.
Para conformar el grupo de Soporte de Problemas tambin se podra pensar en alguien

que forme parte del Grupo de Soporte de la Infraestructura Informtica. Este podra
estar conformado por 3 personas y su principal funcin sera el realizar el monitoreo del
proceso con el propsito de eliminar errores en los servicios, una vez conocida la causa
que lo origin, as como tambin identificar tendencias, para lo cual se podran basar en
el nmero de incidentes con sntomas similares.
Un mtodo que podra llevar a cabo el grupo de soporte de problemas para realizar la
investigacin de la causa de un indeterminado nmero de incidentes podra ser el
siguiente: Primero definir el problema que se quiere solucionar, hacer una lluvia de ideas
de todas las posibles causas del problema, organizar los resultados de la lluvia de ideas
en categoras racionales y si es posible construir un diagrama causa y efecto que
muestre de manera precisa las relaciones entre todos los datos de cada categora.
Por otro lado, es necesario mantener una buena coordinacin entre los procesos de
problemas e incidentes ya que el primero depende del segundo, especialmente en la
135
obtencin de informacin tanto del cliente como del comportamiento del servicio
proporcionado.
LA ADMINISTRACIN DE PROBLEMAS.

CUMPLIMIENTO
DE FUNCIONES
SI
NO PARC
PORCENTAJE DE
CUMPLIMIENTO
DEL ROL

PROCESO DE ADMINISTRACIN DE LA
CONFIGURACIN
#
DE FUNCIONES
CUMPLIMIENTO
ROL
SI NO PARC
DEL ROL
#
ROL
ROL
Administracin
de la
Configuracin
5,6
5,6
Custodia de la
Configuracin
25,0
25,0
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE ROLES DEL PROCESO DE
ADMINISTRACIN DE LA CONFIGURACIN
100
90
80
70
60
50
40
30
20
10
0
Custodia de la Configuracin
Rol
MEDIA
15,3 %
136
de los roles establecidos para el proceso de Administracin de la Configuracin son lo

siguientes:
No existe ninguna persona que se haga cargo de la administracin de la

configuracin, por lo tanto no se ha determinado el alcance y nivel de detalle de
este proceso.
No se asegura que los cambios a mtodos y procesos de la administracin de la

configuracin estn aprobados y comunicados antes de ser puestos en ejecucin.
No se ha desarrollado algn sistema de identificacin de elementos de

configuracin y polticas para su nombramiento.
No se ha desarrollado alguna interfaz con otros procesos de la administracin de

servicios basados en ITIL.
No siempre se evala los sistemas existentes.
No se ha planeado, ni implementado una CMDB39.
No se crean reportes de la administracin del proceso de la configuracin.
No se realizan auditoras de configuracin.
Custodia de la Configuracin
Existe una persona que se dedique a la custodia de todas las copias de software,
sin embargo no del resto de elementos de la configuracin
(hardware y
documentacin).
No se controla la recepcin, identificacin, almacenaje y retiro de los elementos de

la configuracin.
No se tiene informacin del estatus de los elementos de configuracin.
No se organiza, registra ni distribuye aspectos relacionados con la Administracin

de la Configuracin.
39
137
RECOMENDACIONES
Es recomendable que se asigne una persona que se encargue de la administracin de
este proceso, tomando en cuenta que esta deber tener un buen conocimiento de la
organizacin, de su cultura y de sus recursos, as como tambin de sus limitaciones
potenciales. Una sugerencia podra ser que esta persona sea electa mediante una
votacin por parte de los Jefes de cada grupo conformado dentro de la Divisin de
Sistemas.
Como ya se sabe, dentro del proceso de la Administracin de la Configuracin, una de las
actividades a realizarse es la construccin de la CMDB, esta estar cargo del
administrador designado, sin embargo para definir los elementos que formarn parte de
este repositorio es aconsejable que tambin los Jefes de los Grupos de la Divisin de
Sistemas den su punto de vista ya que en conjunto, estos manejan a fin de cuentas todo
lo referente a la infraestructura TI. Es recomendable tambin poner a consideracin si se
va a controlar los detalles de los usuarios internos y externos de TI, as como tambin
las unidades de negocio de la empresa.
Por otra parte, la definicin del alcance de la gestin formal de la configuracin debera
ser manejada por el administrador, tomando en cuenta que esto no significa determinar
qu cantidad de datos ni qu tipos de elementos se deben almacenar dentro del
repositorio destinado al control del proceso, sino determinar polticas que definan qu
objetos de dicha base de datos son necesarios administrarlos completamente o cules
son relaciones, as como tambin cules requieren una administracin a nivel de
inventario o activos. Se aconseja que para definir estos criterios se tome en cuenta el
objetivo del negocio y la criticidad de los servicios TI prestados.
De igual forma, se
deberan establecer polticas con respecto a la relacin con los dems procesos de ITIL,
ya que al tener como objeto principal la base de datos de los elementos fundamentales
para la gestin de la infraestructura de la empresa, todos los grupos de la Divisin de
Sistemas estaran involucrados directa o indirectamente en el uso o mantenimiento de
este repositorio. Dichas polticas deberan estar enfocadas en cuanto a los cambios que
se podran realizar a la CMDB.
Con el fin de que no exista ningn tipo de conflicto en cuanto se refiere a los cambios
138
realizados a la CMDB, es recomendable que se creen perfiles para las personas que
pueden tener acceso a la misma, en este caso las nicas tendran que ser el
Administrador y la persona encargada de la custodia de dicho repositorio. Por otra parte,
el administrador de este proceso tambin debe asegurarse que los cambios a mtodos
relacionados con este proceso, sean aprobados y comunicados antes de que sean
puestos en ejecucin en la CMDB.
Otra actividad a cargo del Administrador del proceso es el evaluar constantemente los
sistemas existentes, ya que gracias a esto se podr determinar si la documentacin
relacionada con dichos sistemas est actualizada, incluyendo diseos y manuales de
usuario.
Tambin es necesario que se realicen auditoras a la base de datos destinada al
almacenamiento de los elementos de la configuracin con el fin de confirmar si el estado
o condicin de dichos elementos estn acorde a la realidad de la empresa hasta la fecha
actual. En caso de no tener resultados favorables, el administrador debe asignar la tarea
de actualizar la base de datos al miembro o miembros del equipo dedicado a la custodia
de la configuracin.
Por otro lado,
es necesario que exista una persona responsable del movimiento de
cualquier elemento perteneciente a la CMDB. Puede ser una buena idea que se asigne
este papel a alguien dentro del Grupo de Sistemas y Bases de Datos o tal vez al mismo
Jefe de dicho grupo, sin embargo debe tomarse en cuenta la carga de trabajo que
representa el desempear este rol. Este tambin estar encargado de la custodia de
todos los elementos de la infraestructura, as como tambin de sus copias,
preocupndose del control de su estado, su actualizacin y el reporte pertinente al
administrador del proceso, con el propsito de que este ltimo informe cmo es el
comportamiento de la infraestructura hasta un determinado periodo, en donde a partir de
este se tomen las medidas respectivas para mejorarla.

LA ADMINISTRACIN DE LA CONFIGURACIN.
139

DE FUNCIONES
CUMPLIMIENTO
SI
NO PARC
DEL ROL

CAMBIOS
#
DE FUNCIONES
CUMPLIMIENTO
ROL
SI NO PARC
DEL ROL
#
ROL
ROL
Administracin
de Cambios
28,6
28,6
Consejo Asesor
de Cambios
50,0
50,0
Comit de
Emergencia del
Consejo Asesor
de Cambios
50,0
50,0
GRFICO
PROCESO DE ADMINISTRACIN DE CAMBIOS
100
90
80
70
60
50
40
30
20
10
0
Consejo Asesor de Cambios
Comit de Emergencia del

Rol
140
MEDIA
42,9 %
Los factores crticos detectados de acuerdo a los roles establecidos para el proceso de
Administracin de la Cambios son lo siguientes:
No siempre se registra una prioridad para las peticiones de cambio rechazando una
peticin de cambio totalmente imprctica.
No se registra y documenta las peticiones de cambio.
No se publica una agenda de reuniones para aprobar un cambio.
No existe alguna persona que decida qu gente asistir a qu reuniones para

aprobar un cambio.
No se clasifican las peticiones de cambio dependiendo de su naturaleza.
No siempre se realiza reuniones del CAB o del CAB/EC para peticiones de cambio
urgentes.
No existe una persona que autorice los cambios aceptados en las reuniones de
aprobacin.
No se manejan registros de todos los cambios relacionados con la infraestructura

TI en la empresa, solo de los considerados cambios grandes.
No se revisa todos los cambios implementados con el fin de asegurar su

cumplimiento.
No existe una persona que retire cambios implementados que hayan fallado.
No se realiza el cierre de peticiones de cambio.
No se generan reportes peridicos de la administracin de cambios.
No existe una persona designada a la revisin de las peticiones de cambio.
No siempre la autorizacin de los cambios la realiza la misma persona.
No existe una persona que participe formalmente en la programacin de cambios.
No se da consejo en cualquier aspecto relacionado con cambios urgentes.
Comit de Emergencia del Consejo Asesor de Cambios
No existe una persona o grupo de personas que evalen y aprueben peticiones de

cambio urgentes.
141
No hay un grupo destinado a la implementacin de cambios urgentes.
RECOMENDACIONES
Se recomienda que se asigne un administrador que pueda hacerse cargo de las

actividades formales en cuanto al manejo de cambios en la empresa. Es aconsejable que
la persona encargada de cumplir con este rol, sea nominada en una reunin con todos los
Jefes de Grupo de la Divisin de Sistemas incluyendo el mismo Jefe de toda la Divisin.
Una sugerencia podra ser que se busque la persona dentro del perfil de Ingeniero en
Sistemas manejado actualmente, ya que tiene experiencia realizando labores de
planificacin y supervisin, por lo tanto podra tener un criterio en cuanto a ver cuales son
los cambios que podran mejorar la infraestructura de TI, as como tambin la prestacin
de servicios. Como ayuda para que el administrador designado pueda controlar cules
son peticiones consideradas totalmente imprcticas, se debera mantener un estndar de
los cambios permitidos sin necesidad de algn tipo de aprobacin por parte de la Alta
Administracin por el tema de manejo de inversiones.
Este administrador tambin debe registrar todas las peticiones de cambio que ha recibido
con el fin de tener constancia de que han sido atendidas. En caso de que estas sean
rechazadas o aceptadas, tambin es tarea de este hacerle conocer a la persona que
realiza dicha peticin cul fue la respuesta de esta. Para esto puede valerse del Service
Desk.
En caso de que un cambio sea considerado grande dentro de la infraestructura de la

empresa, es necesario que esta persona se encargue de la publicacin de reuniones para
aprobarlo, as como tambin de decidir que personas asisitirn a dichas reuniones, con el
fin de tener una visin mas clara de cuales seran las consecuencias si se diera lugar a la
implementacin de dicho cambio. Obviamente la persona encargada de presidir la reunin
sera la administradora del proceso, la misma que se encargar de presentar las
peticiones de cambio clasificadas de acuerdo a la naturaleza del problema.
Para la
invitacin a las reuniones el administrador podra valerse del correo interno de la empresa
o del Service Desk.
142
Es recomendable que la persona encargada de la administracin de los cambios revise

todos los cambios implementados con el fin de asegurar su cumplimiento y en caso de
que presenten algn tipo de problema en la entrega de los servicios prestados reparar el
error o asignar a alguien que lo haga. En caso de que dicho problema sea grave debe
tener la habilidad de retirar dicho cambio e implementar el base line que se tena
anteriormente de la infraestructura.
Por otro lado, ms que una recomendacin, es una obligacin del administrador realizar
reportes peridicos al Jefe de la Divisin de Sistemas de la gestin de cambios que ha
venido realizando. Estos reportes deberan ser elaborados al menos una vez al mes con
el fin de que se pueda tener un control mas adecuado de la infraestructura manejada.
Tambin es aconsejable el formar un Consejo que sirva como Asesor para la aprobacin
de cambios, especialmente si acarrea una inversin muy grande para la empresa. Es
aconsejable que este est conformado por el Jefe de la Divisin de Sistemas y la persona
que dirige el negocio que podra ser el Gerente o alguna persona propuesta por este.
Este grupo de personas deben ser partcipes junto con el administrador del proceso en la
programacin de un cambio, ya que para esto se necesitara de gente que lo implemente,
y, de ser el caso, recursos que permitan administrarlo correctamente.
Por otro lado se aconseja para casos de emergencia formar un Comit del Consejo
Asesor de Cambios que vendra a tratar cambios urgentes, este debera estar conformado
por personas de la Divisin de Sistemas (depende del incidente) y gente que forme parte
del Consejo Asesor de Cambios. Estas personas tienen la obligacin no solo de aprobar
un cambio en esas condiciones, sino de evaluarlo de acuerdo a las condiciones de la
empresa, as como tambin de implementarlo.
La persona encargada de considerar
cules seran las personas indicadas para conformar este grupo sera el administrador del
proceso y el criterio de eleccin sera de acuerdo a la naturaleza del incidente a ser
resuelto por el cambio.
LA ADMINISTRACIN DE CAMBIOS
143

CUMPLIMIENTO
DE FUNCIONES
PORCENTAJE
DE
CUMPLIMIENTO
NO PARC
DEL ROL

PROCESO DE LA ADMINISTRACIN
DE VERSIONES
CUMPLIMIENTO PORCENTAJE
#
DE
DE FUNCIONES
ROL
CUMPLIMIENTO
SI NO PARC
DEL ROL
#
ROL
ROL
Administracin
de Versiones
75,0
75,0
Soporte en
Sitio
100,0
100,0
SI
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE ROLES PARA LA
ADMINISTRACIN DE VERSIONES
100
90
80
70
60
50
40
30
20
10
0
Administracin de Versiones
Soporte en Sitio
Rol
MEDIA
87,5 %
144
Administracin de Versiones son lo siguientes:
Administracin de Versiones
Se ha establecido y se mantiene polticas de liberacin slo de versiones de

software.
No siempre se controla las actividades dentro del proceso de versiones.
RECOMENDACIONES
Si bien es cierto existe un Administrador del Grupo de Ingeniera de Software dedicado al

desarrollo y mantenimiento de los sistemas manejados en la empresa, as como tambin
un Administrador del Grupo de Soporte de la Infraestructura que de alguna forma controla
lo que tiene que ver con hardware, ninguno de estos tiene un control formal sobre la
documentacin que debera ser manejada por cada rea, por lo tanto, resulta una buena
idea que cada administrador mencionado, asigne a alguna persona dentro del grupo a su
cargo para que maneje la documentacin respectiva de acuerdo
al elemento de
infraestructura manipulado.
Aunque la documentacin, refirindose con esto, a los planes estratgicos, informticos,

de capacitacin, de contingencias, etc., no sea considerada como un elemento formal que
necesite ser administrado, es necesario que este tambin sea actualizado al menos una
vez al ao. La persona que se encargara de tal labor podra ser alguien que sea parte
del Grupo de Planificacin Informtica.
Por otra parte, debera considerarse a alguien que controle el cumplimiento de estas
actividades por parte de las personas antes mencionadas. Para esto, podra realizar
auditoras sorpresa con el fin de que siempre se mantenga registrados los ltimos
cambios realizados a la infraestructura TI. La persona encargada de la supervisin de las
actividades del proceso de versiones podra ser el Jefe del Grupo de Planificacin
Informtica.
Es recomendable que el administrador del proceso asignado, establezca polticas de
145
liberacin de versiones para los tres elementos de la infraestructura como son software,
hardware y documentacin, con el fin de que se pueda mantener un control formal de
estos.
En el caso del software puede ser una buena idea basarse en los mdulos
elaborados para satisfacer nuevas necesidades de clientes, en el caso del hardware

deberan valerse de la actualizacin de licencias en su defecto el cambio de algn
elemento de hardware cuyo funcionamiento es deficiente, en el caso de la documentacin
podran controlar las versiones de acuerdo a la elaboracin de nuevos planes a
consecuencia de que los anteriores han expirado.
As como el administrador de este proceso se encargara de que se cumplan las polticas

establecidas
en cuanto a la elaboracin de nuevas versiones,
tambin debera
encargarse de que el grupo de Soporte en Sitio, cumpla con su trabajo. Una forma de
controlarlo podra ser llenando formularios de satisfaccin del servicio por parte del
usuario o en su defecto podran hacerlo a travs de las peticiones de servicio que se
hagan al
Service Desk, es decir mientras mas peticiones existan es que no se ha
manejado la nueva implementacin satisfactoriamente.

LA ADMINISTRACIN DE VERSIONES.
ROLES DE LOS PROCESOS TCTICOS O DE ENTREGA DE

SERVICIOS
#
ROL
ROL
Administracin
de los Niveles
de Servicio
DE FUNCIONES
CUMPLIMIENTO
SI
NO PARC
DEL ROL
30,0
GRFICO

LOS NIVELES DE SERVICIO
#
DE FUNCIONES
CUMPLIMIENTO
ROL
SI NO
PARC
DEL ROL
1
30,0
146
PORCENTAJE DE CUMPLIMIENTO DE ROLES DE LA

ADMINISTRACIN DE NIVELES DE SERVICIO
100
90
80
70
60
50
40
30
20
10
0
Administracin de los Niveles de Servicio
Rol
MEDIA
30 %
Administracin de los Niveles de Servicio son lo siguientes:
Administracin de Niveles de Servicio
No existe una persona que constantemente negocie con los clientes en nombre de
TI y con las reas de TI en nombre del negocio.
No se ha elaborado un catlogo de servicios.
No se ha definido correctamente la estructura de acuerdos de nivel de servicios en

la organizacin.
No se ha elaborado un Programa de Mejora del Servicio.
No siempre se realiza una revisin del desempeo de la organizacin con respecto

a la infraestructura TI.
RECOMENDACIONES
Para una correcta gestin del proceso de los Niveles de Servicio, es recomendable que
se asigne una persona que dirija las actividades relacionadas con este, basadas en un
ciclo constante de acordar, supervisar y obtener reportes para lograr la mejora de los
servicios TI alineados a las necesidades del negocio, as como tambin establecer cual
sera la contribucin por cada grupo de la Divisin de Sistemas para poder mantener en
147
ptimo funcionamiento dichos servicios. Es aconsejable que esta persona sea electa
mediante votacin en una reunin con los Jefes de los grupos antes mencionados,
considerando que debe tener experiencia en el negocio.
Por otra parte, sera de gran utilidad que se defina una estructura de acuerdos de nivel
de servicio formales para la Divisin de Sistemas tanto con clientes internos como
externos, as como tambin con proveedores, detallando cuales son las obligaciones de
parte y parte, as como tambin sealando ciertas clusulas que podran estar en
trminos de cargos por incumplimiento .
Otra actividad a cargo del administrador del proceso, es la elaboracin de un catlogo de

servicios, el mismo que debe poner a disposicin del Service Desk. Es recomendable
que este catlogo sea realizado con un lenguaje no tcnico y como mnimo conste de los
siguientes datos: descripcin del servicio, quien lo proporciona, quien lo usa, cmo
debera ser el procedimiento a seguir en caso de requerirse algn tipo de soporte con
respecto a este, el costo por brindar dicho servicio (establecido por el Administrador de
Finanzas para el rea de TI) y alguna otra informacin relevante al mismo.
Por otro lado tambin es aconsejable el elaborar un Programa de Mejora de Servicio en

el que se definan ndices de cumplimiento de cada uno de los servicios tomando en
cuenta las metas por acuerdos de nivel de servicio establecidos.
Este debera ser
elaborado al inicio de cada ao y debe ser puesto en ejecucin a lo largo de este, con el
fin de que al menos cada seis meses se evale el desempeo de la organizacin con
respecto a la infraestructura TI y en caso de que los resultados no sean favorables
implementar medidas que permitan mejorarlos.
LA ADMINISTRACIN DE LOS NIVELES DE SERVICIO.
OBJETO: ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI.


148
FINANCIERA DE LOS SERVICIOS TI

DE FUNCIONES
CUMPLIMIENTO
SI
NO PARC
DEL ROL
#
ROL
ROL
Administracin
de Finanzas
para el rea de
TI
#
ROL
0,0
CUMPLIMIENTO
DE FUNCIONES
SI NO
PARC
PORCENTAJE DE
CUMPLIMIENTO
DEL ROL
0,0
GRFICO
PORCENTAJE DE CUMPLIMIENTO DE ROLES PARA LA
ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI
100
90
80
70
60
50
40
30
20
10
0
Administracin de Finanzas para el rea de TI
Rol
MEDIA
0%
Administracin Financiera de los Servicios TI son lo siguientes:
Administracin de Finanzas para el rea de TI
No existe una persona que trabaje con los administradores y financieros en el

desarrollo de las polticas de presupuestos, contabilidad y cargos para los servicios
TI.
No existen responsables en cuanto al presupuesto, contabilidad y cargos de los

servicios TI.
Ninguna persona ha implementado el proceso de Administracin Financiera de los

servicios TI.
RECOMENDACIONES
Auque el presupuesto para la Divisin de Sistemas sea elaborado por el Jefe de Grupo
de Planificacin Informtica, es necesario que alguna otra persona se haga cargo del
149
manejo del proceso de la administracin financiera de los servicios TI como tal, es decir,
que se encargue de la contabilidad y de la ejecucin de cargos para el rea de TI. Es
recomendable que para poder elegir a esta persona se tome en cuenta su conocimiento
en cuanto al manejo de los recursos para los servicios TI, as como tambin el manejo
de la contabilidad. Es aconsejable que no se delegue este papel directamente a alguien
dentro del rea financiera de la empresa ya que va a dar prioridad al manejo de dinero
en lugar de la mejora de la prestacin de servicios.
En caso de ser necesario, al menos en los primeros meses, se aconseja que la persona
administradora del proceso, se apoye en la ayuda de una persona que forme parte del
rea dedicada a la
gestin financiera de toda la empresa para elaborar la lista de
precios de servicios, as como tambin la elaboracin de registros en cuanto al

presupuesto, contabilidad y cargos para el rea de TI.
Para las polticas de cargos, es aconsejable que estas sean definidas en conjunto con
los Jefes de la Divisin de Sistemas y el administrador del proceso de finanzas delegado,
ya que estas deberan ser realizadas tomando en cuenta los acuerdos de servicio
establecidos. Tales cargos deberan ser manejados de tal forma que sean favorables
para Sistemas, es decir, aunque no se manejen directamente actividades de
recuperacin de los costos de los servicios basados en pagos por cada cliente, podran
manejarse de tal forma que el presupuesto para el rea de trabajo en la cual est
involucrado dicho usuario sea disminuido y distribuido al presupuesto para el rea de TI.
Por otro lado esta persona tambin debe encargarse de que todos los usuarios de la
empresa tengan conocimiento del manejo de estos cargos, para lo cual sera una buena
idea apoyarse en el Service Desk.
LA ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI.


PROCESO DE LA ADMINISTRACIN DE LA
CAPACIDAD
150
#
ROL
1
ROL
Administracin
de la
Capacidad
Administracin
de la Red,
Sistemas y
Aplicaciones
CUMPLIMIENTO
DE FUNCIONES
SI
NO PARC
PORCENTAJE DE
CUMPLIMIENTO
DEL ROL
#
ROL
CUMPLIMIENTO
DE FUNCIONES
SI NO PARC
PORCENTAJE DE
CUMPLIMIENTO
DEL ROL
27,8
27,8
100,0
100,0
GRFICO
ADMINISTRACIN DE LA CAPACIDAD
100
90
80
70
60
50
40
30
20
10
0
Administracin de la Capacidad
Administracin de Redes, Sistemas y

Aplicaciones
Rol
MEDIA
63,9 %
Administracin de la Capacidad son lo siguientes:
Administracin de la Capacidad
No existe una persona que se encargue de establecer los niveles adecuados de

monitoreo de recursos y desempeo de sistemas.
No se ha asignado a nadie el desarrollo de un Plan de Capacidad de acuerdo al

ciclo de planeacin del negocio.
Ningn individuo se encarga de documentar las necesidades de cualquier

incremento o reduccin en el hardware basado en los requisitos de servicio por
parte de los clientes.
No se ha delegado una persona especfica para realizar auditoras peridicas al

proceso de administracin de la capacidad.
151
De vez en cuando se realizan reportes del uso actual de los recursos, sin embargo
no existe una persona que se encargue de forma peridica de esta labor.
No existe una persona especfica que administre el proceso de la capacidad.
No existe una persona que administre la base de datos dedicada a la coleccin de

datos de la capacidad.
No siempre se evalan los cambios en cuanto a la capacidad de los recursos TI.
RECOMENDACIONES
Aunque por parte del Jefe del Grupo de Soporte de Infraestructura Informtica se realicen
tareas de monitoreo del funcionamiento de la red, es recomendable que tambin
establezca niveles adecuados de monitoreo para el resto de recursos de infraestructura
TI desde las PCs, todos los perifricos como son las impresoras as como tambin de los
sistemas operativos y software de red, desarrollos internos, as como tambin paquetes
comprados. Dicho monitoreo en caso de ser posible, debera extenderse al recurso
humano, pero solo en el caso en que este represente un retraso del tiempo de respuesta
a los servicios ofrecidos, como por ejemplo que el Service Desk no puede atender las
gestiones en lnea por parte de usuarios debido a que no existe suficiente personal.
En caso de que la carga de trabajo resulte muy grande para el Jefe del Grupo de Soporte
de Infraestructura Informtica, refirindose a que adems de las tareas diarias que debe
cumplir para el buen funcionamiento de su rea, realice las establecidas como
Administrador de la Capacidad, es recomendable que se designe a otra persona este rol,
la misma que podra salir del mismo grupo de trabajo.
Por otra parte, es aconsejable que esta persona produzca planes de Capacidad
alineados con los planes empresariales cclicos de la organizacin, identificando los
requerimientos de la capacidad lo suficientemente temprano como para tener en cuenta
los tiempos de obtencin de dichos recursos. En caso de que no se desee cumplir con
esta tarea, podra seguirse tratando la obtencin de recursos por medio del Plan
Operativo que se desarrolla anualmente, pero en su defecto tendran que realizarse
informes de todo el comportamiento de la infraestructura que permitan justificar como la
obtencin de los ltimos componentes han mejorado la entrega de servicios a los
clientes.
152
Otra responsabilidad del administrador del proceso es el asegurar que se implementen

de modo puntual los requisitos de negocio para los servicios de TI.
Esto se puede
alcanzar usando los datos existentes relacionados con la utilizacin de recursos actuales
de varios servicios. Esto tambin servira para marcar tendencias, predecir o modelar
futuros requisitos.
Aunque resulte un poco fuera de lugar en principio, tambin es recomendable

documentar las necesidades de cualquier incremento o reduccin en los componentes
de hardware basados en los requisitos de servicio por parte de clientes. Aunque estas
no sean aprobadas, podran servir como una bitcora de incidentes relacionados con un
cliente especfico que a la larga podran ser resueltos usando los componentes que
actualmente se tienen en la empresa.
Es recomendable que la persona que cumple o cumplira con el rol de Administrador de

la Capacidad realice auditoras a la Administracin de Redes, Sistemas y Aplicaciones
con el propsito de dar recomendaciones en cuanto a la afinacin de los sistemas, as
como tambin a la direccin del rea de TI, de forma que ayude a asegurar el uso ptimo
de todo el hardware y el sistema operacional de los recursos del software. Estas
auditoras deberan ser realizadas al menos cada tres meses con el fin de poder tener un
control ms adecuado con mnimos riesgos de fallos en el funcionamiento de los
servicios prestados.
Por otro lado, se aconseja que se realice la administracin de una base de datos
destinada al almacenamiento de toda la informacin referente a la capacidad de la
empresa, con el fin de poder realizar estadsticas de funcionamiento mas detallado de
cada componente.
Es necesario que el estado que dichos elementos destinados a
formar parte de este repositorio sea actualizado constantemente, esta labor como es
obvio tambin debera ser desempeada por el administrador del proceso.
Otro tema que debera formar parte de la administracin de la capacidad, es el evaluar

constantemente los cambios realizados en cuanto a los recursos usados para la entrega
de servicios, esperando con esto el detectar posibles fallos y dado el caso aplicar
153
medidas correctivas inmediatamente, optando incluso por deshacer dichos cambios

hasta buscar nuevas formas de implementacin para este.
LA ADMINISTRACIN DE LA CAPACIDAD
#
ROL
ROL
Administracin
de la
Disponibilidad
DE FUNCIONES
CUMPLIMIENTO
SI
NO PARC
DEL ROL

DISPONIBILIDAD
#
DE FUNCIONES
CUMPLIMIENTO
ROL
SI NO
PARC
DEL ROL
1
25,0
25,0
GRFICO
ADMINISTRACIN DE LA DISPONIBILIDAD
100
90
80
70
60
50
40
30
20
10
0
Administracin de la Disponibilidad
Rol
MEDIA
25 %
154
Administracin de la Disponibilidad son lo siguientes:

Administracin de la Disponibilidad
No existe una persona que defina y desarrolle el proceso de la Disponibilidad.
No se ha asignado alguna persona que se encargue de la optimizacin de la

infraestructura de TI.
No hay alguien que se encargue de que los servicios de TI estn diseados de tal
manera que los niveles de servicio sean cumplidos.
Ningn individuo que trabaje con los servicios TI, genera reportes de disponibilidad.
RECOMENDACIONES
Para poder tener control de la disponibilidad de los servicios TI, es recomendable que se
asigne una persona que cumpla con las funciones de administrador para el proceso. De
acuerdo a los perfiles manejados en la organizacin se podra tomar en cuenta para
desempear este rol a alguna persona que forme parte de la Seccin dedicada a la
Administracin de Hardware y Comunicaciones de la Divisin de Sistemas, tomando en
cuenta que debe presentar como mnimo las habilidades siguientes: Tener experiencia
prctica en la gestin de procesos, tener experiencia prctica en tcnicas y mtodos de
mejora continua, tener un buen entendimiento de principios y procesos estadsticos y
analticos, as como tambin poseer un buen conocimiento de las tecnologas TI
disponibles y futuras.
Por otra parte, esta persona dentro de sus funciones, debera dar lugar a la optimizacin
de la infraestructura TI, la misma que debe estar basada no solamente en el
mejoramiento de los equipos, sino tambin en el mejoramiento del control del proceso,
mediante el establecimiento de polticas orientadas hacia el registro e inspeccin del
comportamiento de los mismos, as como tambin a la generacin de reportes de la
disponibilidad y mantenimiento alcanzado, as como tambin de recuperaciones
realizadas. Se recomienda que dichos reportes sean realizados en base a mtricas
puntualizadas de acuerdo a cada servicio prestado.
Es recomendable que el administrador designado tambin se haga cargo de el
155
cumplimiento de los niveles acordados para la entrega de servicios TI, especialmente

por parte de la Divisin de Sistemas y en el caso de presentarse fallas, restablecer el
funcionamiento normal de dichos servicios en el tiempo establecido.
LA ADMINISTRACION DE LA DISPONIBILIDAD.

DE FUNCIONES CUMPLIMIENTO
SI NO PARC
DEL ROL

CONTINUIDAD
#
DE FUNCIONES
CUMPLIMIENTO
ROL
SI NO
PARC
DEL ROL
#
ROL
ROL
Directores y
Gerentes
72,2
25,0
Administracin de
la Continuidad
42,9
42,9
Lderes y
miembros de
Equipos para el
manejo de la
Continuidad
25,0
72,2
GRFICO
ADMINISTRACIN DE LA CONTINUIDAD
100
90
80
70
60
50
40
30
20
10
0
Direccin y Gerencia
Administracin de la
Continuidad
Lderes y miembros de
Equipos
Rol
MEDIA
49,1 %
156
Administracin de la Continuidad son lo siguientes:
Direccin y Gerencia
No se realiza aceptacin de pruebas conforme a la continuidad de los servicios

ofrecidos.
No se ha realizado una correcta asignacin de personal y recursos para la

administracin de la continuidad con respecto a los servicios TI entregados.
No se ha asignado una persona que dirija y autorice actividades para el control de

la continuidad de los servicios.
No siempre se realizan negociaciones y relaciones pblicas durante una crisis,

especialmente por el factor econmico.
Administracin de la Continuidad
No existe una persona que tome bajo su responsabilidad el proceso de continuidad

y lidere a los equipos destinados a mantener el funcionamiento de servicios.
No se realiza la definicin de entregables con respecto a la continuidad de los

servicios TI.
No siempre se da lugar a la contratacin de servicios necesarios para la

No siempre se administra pruebas, evaluaciones y reportes acerca de la

Muy pocas veces se realiza reportes de la continuidad de servicios.
Lderes y Miembros de Equipos para el manejo de la Continuidad
No se desarrollan documentos y entregables.
No se negocian los servicios.
No siempre se implementan reportes de pruebas o revisiones realizadas a los
157
servicios.
No se ejecutan procedimientos definidos para la continuidad de servicios en su

totalidad.
No se implementan planes de recuperacin.
No se realizan reportes despus de una crisis sobre la continuidad de los servicios.
RECOMENDACIONES
Es recomendable que para tener una respuesta favorable en cuanto al manejo del
proceso de continuidad de servicios, se tenga un completo apoyo por parte de la
Direccin y la Gerencia de la empresa. Estas entidades, adems del soporte econmico
hacia la obtencin de recursos, deberan realizar una asignacin del personal, el cual se
haga cargo de la administracin de la continuidad del negocio basado en el
mantenimiento de servicios TI.
Para esto podra valerse de la ayuda del rea de
Recursos Humanos de la empresa.
Por otra parte tambin se aconseja que la Alta Administracin participe en la aceptacin
de pruebas realizadas para la implementacin de un nuevo servicio, as como tambin
en la direccin de actividades para el control de la continuidad del negocio. En el caso de
este ltimo, se recomienda que se asigne responsabilidades en cuanto a la elaboracin
de entregables de acuerdo al comportamiento de los servicios en la empresa.
Se aconseja que antes de cualquier
actividad a desarrollarse durante una crisis,
especialmente si esta tiene que ver con algn desembolso de dinero, se la haga conocer
a las personas que conforman la Direccin y Gerencia de la empresa, ya que estas
podran realizar negociaciones convenientes para resolver dicho incidente. Por otro lado,
esta entidad sera la encargada de comunicar y mantener la alerta de la crisis hasta que
crea pertinente, segn los informes que se le presenten una vez aplicada la solucin,
para esto puede valerse de la ayuda del Service Desk.
Es recomendable que se asigne el papel de Administrador de la Continuidad a alguna

persona que tenga experiencia en el nivel de gestin del rea de TI, as como tambin
158
que tenga habilidad para convertir los requerimientos de recuperacin empresarial a

requerimientos tcnicos y especficos, sin descuidar que debe tener buenos
conocimientos tcnicos de TI para capacitar la asistencia de calidad en los
procedimientos, por esta razn sera una buena idea que se asigne este rol al Jefe de la
Divisin de Sistemas o en su defecto al Jefe del Grupo de Planificacin Informtica.
Esta persona estar a cargo de la definicin de entregables con respecto a la continuidad

de servicios, los mismo que pueden ser reportes sobre auditoras al trabajo realizado a
cada grupo encargado de mantener los servicios arriba y en perfecto estado, as como
tambin de las pruebas realizadas a nuevos cambios implementados en la infraestructura
TI. Estos tambin deberan ser entregados a la Alta Administracin para que se justifique
de cierta forma las inversiones realizadas para esta rea. Los grupos a los cuales hago
mencin podran ser relacionados con los Departamentos de la Divisin de Sistemas.
Por otro lado, aunque entre las actividades a desarrollar por parte del Jefe de Grupo de
Planificacin Informtica, est la implementacin de Planes de Recuperacin mas
comnmente conocidos como Planes de Contingencia, no se los ha desarrollado, es por
esta razn que se recomienda hacer cumplir en primer lugar las tareas establecidas en el
documento Funciones Orga_Propuesto_06-02-2007, antes de asignar unas nuevas. Esto
no significa que no importa que estas actividades no sean cumplidas en dos aos y luego
se asignen nuevas responsabilidades, sino que por parte del Jefe de la Divisin se haga
una auditora lo mas pronto posible tomando como referencia dichas actividades para ver
cual es su porcentaje de cumplimento.
En cuanto se refiere a los reportes, estos Por otro lado, esta persona que funcionara
como administradora del proceso, debe dar lugar a la contratacin de servicios bajo
ciertas normas de cumplimiento, especialmente relacionadas con el mantenimiento de las
estaciones de trabajo de los usuarios, refirindose con esto al Internet, al control de virus,
etc.
Es aconsejable que los lderes y miembros de los equipos para el manejo de la

continuidad (relacionando una vez ms a estos con los Departamentos de la Divisin de
Sistemas), realicen actividades de negociacin en cuanto a los servicios prestados, es
159
decir definan cul es el aporte de cada uno para mantener un servicio en excelente
funcionamiento. Esto debe quedar establecido en las Acuerdos de Nivel Operacional
manejados bajo el proceso de Administracin de Nivel de Servicio.
Este grupo de personas tambin debe tener en cuenta la ejecucin de procedimientos

relacionados con la continuidad de servicios, como son la evaluacin de riesgos y el
posible impacto en el negocio al no implementar algn cambio para un servicio.
Por otra parte es responsabilidad de cada grupo de la Divisin de Sistemas el generar

reportes sobre el manejo de los servicios durante y tras una crisis con el fin de poder
determinar cual ha sido el costo involucrado con la recuperacin de los mismos.
LA ADMINISTRACIN DE LA CONTINUIDAD.
ROLES DEL PROCESO DE GESTIN DE LA SEGURIDAD

#
ROL
ROL
Administracin
de la
Seguridad
CUMPLIMIENTO
DE FUNCIONES
SI
0
PORCENTAJE
DE
CUMPLIMIENTO
NO PARC
DEL ROL
3
25,0
GRFICO

DE LA SEGURIDAD
CUMPLIMIENTO PORCENTAJE
#
DE FUNCIONES
DE
ROL
CUMPLIMIENTO
SI NO PARC
DEL ROL
1
25,0
160

ADMINISTRACIN DE LA SEGURIDAD
100
90
80
70
60
50
40
30
20
10
0
Administracin de la Seguridad
Rol
MEDIA
25 %
Administracin de la Seguridad son lo siguientes:
Administracin de la Seguridad
No existe un responsable formal de la operacin efectiva del proceso de la

seguridad.
No se realiza una correcta integracin de las estrategias oficiales de seguridad de

la informacin por parte del cliente.
No se ha elaborado un Plan de Seguridad.
No siempre se realizan auditoras de seguridad internas y externas.
No se realizan informes de seguridad.
RECOMENDACIONES
Aunque en principio, se considere al Jefe de Grupo de Sistemas y Bases de Datos como

la persona a cargo de la administracin de la seguridad en la empresa, las actividades
desarrolladas por este no cumplen con los objetivos establecidos para el control del
Proceso de Gestin de la Seguridad como tal, por esta razn se recomienda establecer
polticas formales de seguridad para la operacin efectiva de dicho proceso, las mismas
que no deberan basarse solamente en la creacin de perfiles para el control de acceso
161
de alguna base de datos, sino tambin en el nivel de seguridad convenido en los

acuerdos de servicio con los clientes, as como tambin en requerimientos externos
definidos en contratos y leyes, tomando en cuenta que la entrega de la seguridad al
menos a nivel bsico sea independiente de externos.
Es necesario que se realicen actividades de integracin de los clientes en cuanto se

refiere a la seguridad de la informacin, para esto se aconseja que los empleados firmen
acuerdos de confidencialidad correspondientes a su cargo y responsabilidad.
Se recomienda que se elabore un Plan de Seguridad, en el cual deberan definirse

mtricas e indicadores clave que permitan evaluar los niveles de seguridad acordados.
Por otra parte, es aconsejable que se realicen auditoras de seguridad internas y externas
relacionadas con la confidencialidad, integridad y disponibilidad de la informacin
manejada en la empresa, especialmente la relacionada con sus clientes. Estas auditoras
deberan ser ejecutadas al menos cada mes, pero por razones de carga de trabajo
podran ser elaboradas cada tres meses.
Mas que una recomendacin, es una obligacin por parte del Administrador de la
Seguridad el realizar reportes al menos cada seis meses indicando cmo se ha manejado
el proceso de seguridad, en base a posibles amenazas detectadas y las actividades
realizadas para que no se de lugar a una crisis. Por otra parte tambin se deben realizar
informes del cumplimiento de las mtricas establecidas en el Plan de Seguridad, es
aconsejable que este sea desarrollado cada ao.

LA ADMINISTRACIN DE LA SEGURIDAD.
162
2.1.1.4.3 Resultados del Anlisis de Riesgos
PROCESOS OPERATIVOS O DE SOPORTE A SERVICIOS

OBJETO: ADMINISTRACIN DE SERVICE DESK
TABLA DE RIESGO
#
Riesgo
Categora
Probabilidad Impacto Riesgo
1. No contar con procedimientos

escritos
para
el
Medidas de Salvaguarda
correcto
Implementar
un
catlogo
de
servicios o documento similar,
funcionamiento de la funcin.
creando
DE
0,9
1,8
procedimientos
de
atencin a estos.
Hacer conocer de la existencia de

este
catlogo
toda
la
organizacin.
2. Usuarios que se resistan al uso

de
este
servicio
desconocimiento del mismo.
por
Promocionar el Service Desk por

el correo interno, pgina web o
PE
0,85
1,7
servicio
de
telefona
de
la
organizacin.
Establecer polticas en las que
163
claramente se diga que la nica
forma de solicitar algn tipo de
ayuda de tipo tecnolgico es a
travs del Service Desk.
Hacer conocer estas polticas a

todo
el
personal
de
la
organizacin.
Hacer
cumplir
las
polticas
establecidas (sin excepciones).
3. Uso de lenguaje tcnico por

parte del personal de Service
Desk al comunicarse con los
Contratar personal que pueda

relacionarse con los usuarios.
PE
0,4
0,8
usuarios.
Enviar a seminarios de relaciones

humanas al personal de Service
Desk.
4. Falta
de organizacin
en
el
manejo de incidentes debido al

aumento de usuarios.
BU
0,2
Realizar
un
estimado
de
los
posibles usuarios y balancear la
0,6
carga de trabajo entre todos los

miembros del Service Desk.
5. Clientes
insatisfechos
servicio brindado.
con
el
PE
0,2
0,4
Capacitar al personal de Service

Desk.
164
6. Errores en el manejo de la
Mantener actualizado al personal
funcin por falta de actualizacin
de Service Desk sobre nuevos
en la informacin manipulada,
servicios implementados.
as como tambin por la falta de

control
de
tecnolgicas
las
herramientas
usadas
por
personal del Service Desk. .
el
DE
0,1
Establecer el procedimiento de
atencin de dichos servicios en el
0,2
catlogo antes mencionado.
Capacitar al personal de Service

Desk sobre el manejo de todos
los medios establecidos para el
contacto con los usuarios.
TABLA 2.26. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DEL SERVICE DESK.
165
TABLA DE RIESGO
#
Riesgo
Categora
Probabilidad Impacto
Riesgo
1. Falta de atencin a incidentes
Realizar un estudio basado
reportados, debido a insuficiente
en el nmero de incidentes
personal o falta de capacitacin
recibidos
del mismo.
como tambin en el nmero
diariamente
as
de incidentes resueltos por

esta rea.
DE
0,55
Realizar pruebas sorpresas

del personal para ver si est
1,65
capacitado.
Solicitar
un
actualizacin
curso
de
en cuanto a
las nuevas tecnologas.
Investigar cules son los

ltimos virus encontrados
as
como
tambin
soluciones pertinentes.
las
166
2. Desconocimiento de la resolucin
de un incidente debido a la falta
Establecer claramente cual

es el incidente a resolver.
de seguimiento de procedimientos
tanto por parte del usuario como
Definir
tiempos
para
la
resolucin de un incidente.
del personal del rea de TI.

PE
0,8
1,6
Mantener la comunicacin
con el usuario hasta que
este
pueda
seguir
trabajando normalmente en
vista de que el incidente ha
sido resuelto.
3. Clientes insatisfechos por mala o

lenta gestin de sus incidentes.
Tener contacto constante

con los clientes hasta que
los incidentes hayan sido
resueltos correctamente.
PE
0,2
0,4
Realizar evaluaciones por

parte
del
cliente
para
conocer el nivel de atencin

que
recibi
al
solicitar
ayuda.
4. Incidentes mal registrados.
PE
0,15
0,3
Registrar todos los campos
167
necesarios de un incidente
reportado
dando
un
comprobarlo
resumen
de
registro al usuario que lo

reporta antes de realizar
cualquier
actividad
para
resolverlo.
5. Errores en el manejo del proceso

debido a la mala interpretacin de
Escuchar
atentamente
al
usuario.
un incidente o a escalaciones
equivocadas.
Definir formularios en base

a preguntas del negocio que
permitan conocer cual es la
necesidad del usuario.
PE
0,05
0,1
Establecer
los
tipos
de
incidentes que pueden ser

escalados dependiendo del
rea de soporte de segundo
nivel.
Evaluar el incidente antes

de escalarlo.
168
TABLA 2.27. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE INCIDENTES.
TABLA DE RIESGO
#
Riesgo
Categora
Riesgo
1. Confusiones en el manejo de
Seleccionar
en
incidentes y problemas por parte
requerimientos
del
personas
administrador
designado
debido a la falta de coordinacin

entre
los
dos
base
la
las
encargadas
de
dirigir los procesos.
procesos
relacionados.
Establecer metas a cumplir

dependiendo del proceso con
PE
0,8
2,4
el fin de que sean evaluadas.
Definir polticas de manejo de

incidentes y cundo estos
deben
ser
tratados
como
problemas.
Establecer dichas polticas en

un
documento
formal
que
169
sirva
como
gua
en
el
proceso.
2. Tratar
problemas
como
incidentes.
Definir claramente qu es un
problema y qu un incidente.
DE
0,95
1,9
Hacer
conocer
estos
conceptos a nivel de toda la

organizacin.
3. Tiempos
encontrar
ms
largos
la
solucin
para
de
problemas debido a la falta de
Modificar la herramienta para

la gestin de incidentes dando
DE
0,95
1,9
lugar a un nuevo mdulo que
manejo de alguna herramienta
permita administrar problemas
para su administracin.
en base a incidentes.
4. No se implemente el proceso
formalmente.
Establecer las actividades de

gestin de problemas, as
DE
0,9 %
como tambin su alcance y
1,8
sus responsables.
Realizar reportes mensuales

del manejo de dicho proceso.
5. Decadencia de los servicios TI

brindados
por
la
falta
de
PE
0,6
1,8
Capacitar al equipo dedicado

a la bsqueda de la causa de
170
solucin de un problema o la
problemas.
Inexistencia de revisiones post

implementacin de la misma.
Suscribirse
relacionados
foros
con
temas
afines.
Definir
tiempos
revisin
para
de
la
alguna
implementacin como parte

del ciclo de identificacin de
una solucin.
6. Comunicacin
errores
deficiente
conocidos
de
sus
Asignar a alguien que se

encargue
de
realizar
soluciones
del
ambiente
de
auditoras del manejo de todo
desarrollo
al
ambiente
de
el proceso.
produccin debido a la falta de

control del proceso.
PE
0,8
1,6
Generar
informes
de
cumplimiento del proceso.
Dar capacitacin para mejorar

el manejo de la comunicacin
de errores conocidos y sus
soluciones.
7. Elevado costo para dar solucin
BG
0,5
1,0
Hacer anlisis de costo -
171
a un problema.
beneficio basado en lo que

representara
problema
resolver
fuera
de
el
la
organizacin.
Decidir que opcin conviene

ms a la empresa.
8. Ineficiencia
del
proceso
al
establecer soluciones que no

sean
adecuadas
para
Definir claramente cual es el

problema.
la
resolucin de un problema.
Hacer una lluvia de todas las

posibles causas del problema.
PE
0,4
0,8
Organizar
las
ideas
en
categoras racionales.
Construir
un
diagrama
de
causa efecto.
Capacitar
dedicado
al
al
personal
manejo
problemas e incidentes.
TABLA 2.28. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE PROBLEMAS.
de
172
TABLA DE RIESGO
#
Riesgo
Categora
1.
Mal manejo del proceso debido a
Riesgo
Realizar un cuidadoso anlisis
un alcance y nivel de detalle de
de los recursos ya existentes
los elementos de configuracin
antes
de
alcance y nivel de detalle para
la
infraestructura
TI
mal
definidos.
de
establecer
su
ser administrados.
DE
0,98
2,94
Definir hasta que punto los

elementos de la configuracin
van a ser desglosados para
ser
administrados
factores
aconsejable
estadsticos
no
(para
es
muy
detallado).
2.
Falta de gestin de la informacin

relacionada con la infraestructura
TI debido a la no implementacin
de una base de datos (CMDB).
DE
0,95
2,85
Realizar un estudio sealando

los pros y los contras en
cuanto a la implementacin de
una base de datos para la
173
gestin de la informacin de la
configuracin.
Establecer los tiempos de

mejora para la gestin de los
procesos de ITIL que se
desea implementar y los ya
implementados al desarrollar
este repositorio.
3.
No
tomar
en
cuenta
la
documentacin como parte de los

elementos de la infraestructura.
DE
0,95
Incorporar
al
documentacin
1,9
menos
la
asociada
proyectos, acuerdos de nivel

de servicio y licencias.
4.
El
costo
para
desarrollar
En lugar de comprar licencias
ejecutar este proceso sea muy
de
elevado.
implementacin de la CMDB,
BG
0,95
1,9
software
para
la
realizar el desarrollo de un
mdulo que permita realizar
este trabajo (tiempo mayor de
trabajo
para
la
implementacin del proceso).
174
Realizar un concurso en el
cual
se
establezca
presupuesto
para
la
como
obtencin
un
mnimo
de
un
software que permita realizar

la administracin de la CMDB.
5.
La
CMDB
sea
una
mera
enumeracin del stock de piezas.
Programar correctamente los

elementos de configuracin
necesarios para formar parte
de la CMDB con el fin de
evitar
duplicaciones
ausencia de los mismos.

DE
0,75
1,5
Adems de tomar en cuenta

los elementos propios de la
base
de
datos
configuracin
se
de
la
debe
establecer las relaciones que

hay entre estos.
Definir las caractersticas de

los
elementos
de
175
configuracin.
Esto servira
para establecer que uso de se

le
debera
dar
esa
informacin.
Tomar en cuenta el costo de

cada uno de los elementos de
configuracin.
6.
No se implemente el proceso
formalmente.
Hacer un estudio de cuanto

apoyara la implementacin
del
proceso
para
la
planeacin financiera y de
gastos.
DE
0,75
1,5
Designar un responsable que

dirija el proceso.
Generar reportes frecuentes

de cmo se est manejando
el proceso.

gestin de la configuracin,
as como tambin su alcance
176
y sus responsables.
No
realizar
profundidad
una
o
excesiva
detalle
en
cuanto al manejo del proceso.
Educar al personal de la
organizacin sobre el manejo
de este proceso.

7.
Implementacin
de
cambios
Establecer un procedimiento
errneos en la infraestructura TI
de aceptacin de cambios
por falta de conocimiento de la
basado
situacin actual de la misma.
formales.
DE
0,5
en
documentos
Realizar auditoras en cuanto

al manejo y funcionamiento
1,5
actual de los elementos de la

infraestructura.
Realizar
informes
de
la
auditora realizada.
Implementar un una base de
177
datos
que permita controlar
todos los movimientos de la

infraestructura TI.
Mantener
cambios
historiales
realizados
de
a
la
CMDB.
8.
Falta de compromiso de la alta

administracin.
Sembrar conciencia entre la

Alta Administracin acerca de
los beneficios que acarrea la
BU
0,5
1,0
Gestin de la Configuracin
aunque no sean inmediatos.
Realizar estudios que apoyen

esta iniciativa.
9.
Existencia
de
errores
en
el
Definir una persona que se
manejo del proceso causados por
encargue
la falta de actualizacin de los
actualizar los elementos de la
elementos de la configuracin en
la CMDB.
PE
0,4
0,8
del
manejo
de
CMDB.
Realizar
auditoras
para
asegurar que la informacin

registrada
coincide
con
la
178
configuracin
estructura
real
TI
de
de
la
la
organizacin.
TABLA 2.29. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE LA CONFIGURACIN.
TABLA DE RIESGO
#
1.
Riesgo
Categora
Riesgo
Resistencia de las personas a

seguir
los
Definir
cambios
estndares
procedimientos
con el fin de que no siempre el
definidos para el establecimiento
personal tenga que pasar por
de un cambio.
PE
0,90
2,70
todo el proceso establecido

para solicitar cambio.
Hacer conocer a todos los

miembros de la organizacin
179
cual es el procedimiento a
seguir ya sea con cambios
estndares
cambios
urgentes (Se puede usar el

correo interno o la pgina web
de la empresa).
2.
Resistencia
de
los
usuarios
internos y externos a cambios.
Concienciar en los usuarios

que los cambios sern para el
progreso
PE
0,75
de
la
institucin
aunque en principio les resulte
2,25
en ciertos casos un poco difcil

de acoplarse a estos.
Realizar
capacitaciones
inmediatas a los cambios.

3.
Cambios mal registrados
Manejar
formularios
electrnicos
PE
0,85
1,70
peticiones
para
de
cambio,
las
con
campos especficos en los

cuales permitan conocer los
estados de este.
180
Manejar histricos de cambios.
Realizar auditoras con el fin

de detectar cambios en la
infraestructura y en caso de
detectar
cambios
registrados,
no
realizar
el
procedimiento respectivo para

su registro.
Capacitar al personal acerca

de
los
procedimientos
de
registro de cambios.
4.
No se implemente formalmente el
proceso.
Realizar un estudio basado en

el apoyo del proceso a la
organizacin.
BU
0,70
1,4

gestin de cambios, as como
tambin su alcance y sus
responsables.
Educar
al
personal
de
la
organizacin sobre el manejo
181
de este proceso.

5.
El proceso se vuelva burocrtico.
Establecer
procedimientos
basados en lo posible en el
manejo
DE
0,6
de
cambios
estndares, los mismos que
1,2
deben ser manejados por el

Service Desk.
Hacer
cumplir
estos
procedimientos.
6.
Existencia
de
errores
tras
la
implementacin de un cambio.
Establecer un ambiente de
prueba no solo para cambios
de
software,
cualquier
DE
0,45
sino
elemento
para
de
la
infraestructura a excepcin de
0,90
la documentacin.
Implementar
una
base
de
datos que contenga todos los

elementos de la infraestructura
182
y sus relaciones con el fin de
poder ver cual es el impacto
de un cambio dependiendo del
elemento involucrado.
Definir
polticas
de
mantenimiento antes de la
implementacin de un cambio.
Hacer conocer estas polticas.
Realizar
un
monitoreo
constante de los cambios.
Capacitar tanto al personal

que implementa los cambios
como a los usuarios.
7.
Falta de atencin a un cambio

debido
que
las
personas
dichas reuniones.
encargadas no pueden reunirse

para su aceptacin.
Definir una persona que dirija
BU
0,40
0,80
Establecer al menos un da de
la semana y hora fija para
realizar
las
aceptacin
de
reuniones
de
cambios
(al
menos de los no urgentes ni
183
estndares).
En caso de que realmente las

personas autorizadas para la
aprobacin de cambios no
puedan asistir, delegar a otras
que estn al corriente de cmo
funciona el proceso.
Realizar
reportes
de
las
reuniones efectuadas.
8.
Falta de implementacin de un
cambio por falta de tecnologa.
Hacer un estudio basado en

por
qu
necesitan
nuevos
equipos, cul sera el impacto

de no conseguirlos, cunto se
necesita para obtenerlos y
TE
0,25
0,75
presentarlo
la
Alta
Administracin (Realizar una

peticin de cambio formal).
Resolver
el
problema
que
origin el pedido de cambio

implementando
alguna
184
solucin temporal hasta que la
obtencin de nuevos equipos
se haga realidad.
Realizar concursos para
la
adquisicin de nuevos equipos

basados en un presupuesto
elaborado anualmente.
9.
Prdida de informacin por falta
Tener un servidor dedicado a
de procedimientos de seguridad
correr procesos automticos
establecidos
para la recoleccin de back-
antes de
realizar
algn cambio.
ups, al menos de los equipos

ms importantes (Establecer
tiempos para la corrida de
PE
0,30
estos procesos).
0,60
Realizar la revisin de estos

back-ups al menos cada dos
semanas.
Establecer
medidas
de
mantenimiento antes de la
implementacin
de
los
185
cambios.
TABLA 2.30. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE CAMBIOS.
TABLA DE RIESGO
#
Riesgo
Categora
1.
Prdida de informacin debido a
Riesgo
Establecer un lugar fsico al
la falta de lugares estratgicos
menos
para
almacenamiento
de
equipos
para
el
de
la
el
almacenamiento
de
versiones de esta.
DE
0,85
1,70
para
crticos
el
los
negocio.
Realizar
copias
configuracin de equipos en
medios
de
almacenamiento
externo.
En
la
aplicacin
manejada
186
para el almacenamiento de
versiones
de
software,
establecer un campo o una

referencia para el manejo de
manuales
de
relacionados
usuarios
con
dicha
aplicacin.
2.
Tendencia a evadir el proceso

por parte del rea de TI.
Definir claramente funciones

para cada miembro de soporte
en sitio.
Realizar
informe
PE
0,6
1,2
mensualmente
de
las
un
actividades
realizadas por parte de cada

miembro del rea de TI (En
dicho informe debe constar en
caso de haber realizado un
cambio
la
identificacin
registro de la nueva versin).

3.
Errores en el manejo de una

nueva
versin
por parte
de
PE
0,4
1,2
Realizar manuales de usuario

tanto para nuevas aplicaciones
187
usuarios debido a la falta de
realizadas, as como tambin
capacitacin de la misma.
nuevas configuraciones.
Publicar en pginas web los

manuales de tal forma que
todos los miembros de la
organizacin puedan tener
la mano esta informacin.

4.
No
implementar
el
proceso
formalmente.
Establecer
procedimientos
formales para el manejo del

proceso.
DE
0,5
1,0
Documentar
estos
procedimientos.

el proceso.

5.
Confusin en la identificacin de
una versin.
DE
0,5
1,0
Establecer
unidades
de
versin tanto para hardware,

software y documentacin que
identifiquen
claramente
la
188
magnitud
de
realizado
un
cambio
cualquiera
de
estos.
Definir cuntos cambios se va

a integrar a un elemento de la
infraestructura para formar una
versin que pueda ser llevada
al ambiente de operacin.
6.
Mayor nmero de incidentes con
Realizar
auditoras
las
las estaciones de trabajo debido
estaciones de trabajo de los
a la falta de compromiso del
usuarios al menos cada tres
usuario a no introducir software
meses.
no autorizado.
PE
0,8
Desinstalar
inmediatamente
software no autorizado al ser
0,8
encontrado, especialmente si
no
contribuye
al
trabajo
realizado por el usuario.
Realizar charlas a los usuarios

fomentando la cultura de no
instalar software que no tenga
189
licencia o pueda ser controlado
de alguna forma por el rea de
TI.
7.
Mal
funcionamiento
de
las
Implementar
polticas
de
versiones usadas por el personal
liberacin en las mismas que
debido
se de lugar al mantenimiento
su
falta
de
actualizacin.
de las versiones (Este debe

ser
realizado
antes
de
la
implementacin de la versin
en produccin).
PE
0,2
0,6
Documentar estas polticas.
Comunicar
sobre
estas
polticas a todo el personal de

la organizacin, especialmente
los
relacionados
con
los
cambios a realizarse.
Realizar una gua de todas las

estaciones
de
trabajo
de
usuarios en las cuales se

deban realizar actualizaciones
190
de versiones con el fin de
mantener un control de estas.
Hacer firmar estas guas por el

usuario una vez implementada
dicha
versin,
as
como
tambin una vez recibidas las

indicaciones pertinentes para
su uso.

encuentre a la cabeza del
proceso de versiones con el fin
de que controle el trabajo
realizado por
las personas
encargadas
de
la
implementacin
de
estas
especialmente
en
las
trabajo
del
estaciones
de
usuario.
TABLA 2.31. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE VERSIONES.
191
PROCESOS TCTICOS O DE ENTREGA DE SERVICIOS

Riesgo
Categora
1.
Mala administracin del proceso
Riesgo
Manejar un Plan Estratgico el
por la falta de conocimiento en
mismo que debe ser puesto en
cuanto al negocio por la persona
conocimiento
que lo dirige.
personas que forman parte de
de
todas
las
la organizacin.
PE
0,7
2,1
La comunicacin de este plan

puede ser realizada mediante
el
correo
interno
de
la
organizacin o por el Service

Desk.
Poner
consideracin
la
eleccin de otra persona para

el manejo del proceso.
2.
Desconocimiento
de
los
DE
1,0
2,0
Definir los servicios que el
192
procedimientos para acceder a
rea de TI puede entregar, as
algn servicio por parte de los
como tambin quienes son sus
usuarios, debido a la falta de
responsables directos tanto en
documentos
la
formales
que
manejen esta informacin.
entrega
como
en
la
recepcin de estos.
Definir cmo pueden acceder

o pedir algn tipo de soporte
relacionado con algn servicio.
Hacer
conocer
esta
informacin
toda
organizacin,
puede
la
ser
travs del Service Desk, o

implementando
una
pgina
informativa.
3.
No se implemente el proceso
formalmente.
Establecer
procedimientos

DE
0,75
1,5
proceso.
Documentar
estos
procedimientos.
193
el proceso.

4.
Acuerdos
de
servicio
no
Hacer conocer los niveles de
respetados por el usuario o por
servicio a travs del Service
el personal del rea de TI.
Desk o del correo interno de

la organizacin.

encargue de verificar que los
acuerdos de nivel de servicio
estn siendo cumplidos tanto
DE
0,7
1,4
por usuarios como por el

personal del rea de TI.
Establecer penalizaciones por

escrito de acuerdo al tipo de
faltas
servicio
realizadas
los
acuerdos
de
que
puedan
ser
tanto
por
los
usuarios como por el personal

del rea de TI.
194
Establecer formularios en los

cuales se
puedan registrar
estas faltas.
Verificar
que
penalizaciones
las
han
sido
cumplidas.
5.
Dificultad
para
expectativas
del
expresar
las
cliente
en
Usar un formulario mediante el

cual
estndares cuantificables.
se
pueda
identificar
cuales son las necesidades del

cliente.
DE
0,6
Establecer de acuerdo a las

necesidades detectadas qu
1,2
elementos de la infraestructura
son necesarios para cubrirlas.
Definir un costo para cada

uno de los servicios de forma
que se pueda controlar cada
uno de estos.
6.
Falta
de
apoyo
de
la
Alta
Administracin ya que considera
TE
0,50
1,0
Realizar
un
estudio
que
permita visualizar claramente
195
a este proceso como un gasto.
cul sera el beneficio de

implementar el proceso.
Definir un presupuesto basado

en los recursos necesarios
para la implementacin de
este.
7.
Objetivos del proceso orientados

ms
las
tecnologas
de
Basarse en los servicios que

se desea implementar para
informacin que al negocio.
adquirir
elementos
de
infraestructura TI.
DE
0,45
Realizar
reportes
funcionamiento
0,90
del
de
cada
servicio al menos cada tres

meses.
En caso de que se tengan

recursos
relegados,
reasignarlos a otro servicio

que lo necesite.
8.
No relacionar de manera efectiva

los costos con los servicios.
DE
0,20
0,40
Definir
prioridades
servicios.
en
los
196
Asignar los recursos a cada

servicio de acuerdo al orden
de prioridad definido.
TABLA 2.32. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE LOS NIVELES DE SERVICIO.
OBJETO: ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI.
TABLA DE RIESGO
#
1.
Riesgo
Falta
de
apoyo
Categora
de
la
Riesgo
Alta
Administracin.
Realizar
un
estudio
que
permita visualizar claramente

cul sera el beneficio de
BU
0,95
2,85
implementar el proceso. Dicho

estudio debe basarse en la
definicin
de
presupuestos
para TI, de los cuales su
197
mayor parte ha sido destinado
para la implementacin de
requerimientos de otras reas
y no para el uso de interno de
esta.
2.
Usuarios
negados
la
aceptacin de cargos.
Hacer conocer a todos los

miembros de la organizacin
cunto del presupuesto del
rea de TI es destinado para
cubrir
sus
acuerdo
necesidades
a
los
de
servicios
brindados.
PE
0,95
2,85
Realizar un estudio de cul

sera la aceptacin del manejo
de cargos en la empresa y si
de verdad este sera favorable
para la misma.
Realizar charlas en las cuales

se les de a conocer a los
usuarios
cmo
sera
el
198
procedimiento para el manejo
de cargos.
3.
Falta de criterio para definir los

precios de los servicios TI.
Establecer
basados
los
en
servicios
los
relacionados
DE
0,85
con
adquisicin
1,7
gastos
de
la
recursos
(hardware, software, personal

y
transferencias)
desarrollo,
para
su
implantacin
mantenimiento.
4.
Dificultad para llevar a cabo el

proceso
debido
al
establecimiento de mecanismos
Establecer
cules
son
objetivos
principales
los
al
implementar el proceso.
de control muy complejos.

DE
0,6
1,2
Realizar
polticas
de
establecimiento de costos de
servicios TI basados en las
que se tiene bajo la custodia
del rea financiera para los
servicios brindados a nivel de
organizacin.
199
Realizar un estudio para definir

qu reas son las que ms
gasto traen a la empresa.

el proceso.
5.
Costos de contabilidad exceden

los beneficios.
Comparar
cules
iniciativas
son las ms alineadas a los

objetivos de la empresa y ver
cul
BG
0,4
1,2
es
la
inversin
que
representara adquirirlas.
Realizar un anlisis basado en

el
tiempo
recuperar
que
demorar
la
inversin
realizada y qu se har para

conseguir este objetivo.
6.
No
encontrar
familiarizado
contabilidad.
con
personal
TI
Capacitar a la persona o grupo

de personas
PE
0,5
1,0
del rea de TI
encargados del control del

proceso,
enfocados
especialmente
al
manejo
de
200
contabilidad.
Realizar
un
concurso
para
contratacin de una persona

que conozca de los dos temas.
TABLA 2.33. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN FINANCIERA DE LOS SERVICIOS TI
TABLA DE RIESGO
#
Riesgo
1.
No se implemente formalmente
Categora
Riesgo
el proceso.
Establecer
procedimientos

DE
0,65
1,3
proceso por escrito.

el proceso.
201
2.
Incorrecta
monitorizacin
del
Realizar un estudio de los
rendimiento de los elementos de
recursos necesarios tanto para
la infraestructura debido a su
la implementacin del proceso
complejidad o a la falta de
como
recursos.
mismo.
para
el
control
del
Definir en el Plan Operativo la

obtencin de dichos recursos,
as
como
tambin
la
justificacin de los mismos,

TE
0,6
1,2
basados en el retorno que

tendrn
estos
para
la
organizacin.
Realizar
un
anlisis
por
servicios de los equipos que

sirven de apoyo a cada uno de
estos.
Reasignar
acuerdo
recursos
a
las
de
nuevas
necesidades de la empresa
202
tomando en cuenta la facilidad
de administracin de estos.
Suscribirse
revistas
de
tecnologa, con el fin de poder

obtener
informacin
de
tendencias tecnolgicas que

puedan ser aplicadas para el
mejoramiento del proceso.
3.
Administracin del proceso poco

coherente
desconocimiento
por
del
el
los equipos que se encuentran
estado
actual de la tecnologa usada en

la organizacin.
Llevar un inventario de todos
DE
0,4
1,2
implantados
en
la
organizacin,
con
su
respectivo estado.
Realizar auditoras al menos

cada seis meses con el fin de
actualizar dicho inventario.
4.
Costos injustificables para la

capacidad existente.
BG
0,35
1,05
Definir claramente los equipos

necesarios para mantener los
203
servicios TI en las mejores
condiciones
con
las
respectivas justificaciones.
Pedir informes a la persona

encargada
del
presupuesto
para TI, especificando
cmo
fue distribuido este de acuerdo

a los equipos adquiridos.
Una
vez
revisados
los
informes, realizar reportes de

verificabilidad en los que se
detallen
inconsistencias
en
caso de encontrarlas.
5.
Interrupciones de servicios por

errores de funcionamiento de
hardware o software.
Mantener un control de los

recursos
TE
0,35
1,05
designados
un
servicio basados en su estado,

su ltima actualizacin y el
porcentaje de utilizacin de
este.
204
Mantener
un
monitoreo
constante de estos recursos

en base a herramientas.
En lo posible tener equipos

que puedan ser usados como
reemplazos de los anteriores
ante un dao grande.
6.
Falta de administracin de la
Definir
los
elementos
que
informacin relacionada con la
vendran a formar parte de
capacidad de los elementos de
este repositorio basados en
la infraestructura por la ausencia
que deben generar reportes de
de una base de datos dedicada
su funcionamiento, como por
al
almacenamiento
informacin.
de
esta
DE
0,5
1,0
ejemplo
datos
servidor
red,
predicciones
detalles
servicios,
tcnicos
y
y
de
detalles
de
y
clientes,
predicciones
de
volmenes
de
negocio y datos financieros.
Otros informes son el Plan de
205
Capacidad
informes
de
Gestin y tcnicos.
7.
Falta de compromiso de la Alta
Realizar un informe a la Alta
Administracin para implementar
Administracin
rigurosamente
cmo
los
procedimientos asociados.
ayudar
este
al
puntualizando
proceso
control
puede
de
los
elementos de infraestructura
adquiridos con el fin de dar la
mejor prestacin de servicios a
los usuarios.
BU
0,45
0,9
Definir
cmo
sera
la
recuperacin de los costos

invertidos.
Definir informes de manejo del

proceso a ser entregados cada
cierto
tiempo
para
hacer
constancia de que el proceso

est
correctamente.
funcionando
206
8.
Bajo rendimiento en los servicios
Realizar
un
TI implementados por asignacin
requerimientos
inadecuada
servicio
de
recursos
(hardware, software y personal)
que
anlisis
para
vaya
de
cada
ser
implantado.
a cada uno de estos.
Realizar pruebas antes de la

implantacin de un servicio
basado en el manejo tanto de
TE
0,25
0,75
hardware como de software.
Las
pruebas
deben
ser
realizadas por las personas

que manejarn
directamente
el nuevo proyecto, bajo la

supervisin
de
alguien
del
departamento de sistemas a
cargo del funcionamiento del
mismo.
TABLA 2.34. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE LA CAPACIDAD
207
TABLA DE RIESGO
#
Riesgo
1.
Interrupciones de servicios a
Categora
Riesgo
Definir
unas
polticas
de
de
la
causa de la dependencia que
mantenimiento
tienen de proveedores de los
disponibilidad al menos a un
equipos para su mantenimiento.
nivel bsico con el fin de no

depender
DE
0,50
1,0
tanto
de
los
proveedores para su solucin.
Pedir cursos de capacitacin

de los recursos adquiridos a
los proveedores respectivos o
en su defecto manuales que
permitan la comprensin de
cmo deben ser configurados.
2.
No se implemente formalmente
el proceso.
DE
0,5
1,0
Realizar un anlisis basado en

cules
seran
consecuencias
las
de
no
implementar el proceso en la
208
empresa.
Definir
que
claramente
puedan
ser
polticas
medidas
mediante
indicadores
realizar
evaluaciones
para
al
manejo del proceso.
Incluir la elaboracin del Plan

de Disponibilidad dentro de las
actividades a desempearse,
al igual que la generacin de
reportes para evaluar como
est funcionando el proceso.
Delegar
responsables
que
manejen el proceso.
3.
Errores
servicios
en
TI
el
manejo
de
causa
del
desconocimiento de estos por

parte de los usuarios.
Elaborar un formulario con

preguntas
DE
0,45
0,9
puedan
especficas
evaluar
que
el
conocimiento de los usuarios

con respecto al servicio TI
brindado.
Dicho formulario
209
puede ser manejado dentro de
la intranet de la organizacin.
Implementar
una
pgina
informativa del procedimiento

de uso de todos los servicios
TI proporcionados.
4.
Criterios
no
adecuados
para
recuperacin de los servicios.
En caso de ya haber aplicado

medidas
contraproducentes
para la recuperacin de algn

servicio
retirarlo
inmediatamente.
DE
0,3
0,9
Realizar
un
Plan
de
Disponibilidad en el cual se
manejen
criterios
de
recuperacin de servicios, los

mismos
que
sern
establecidos en base a todos

los posibles implicados.
5.
Bajo rendimiento de los servicios
DE
0,4
0,8
Definir qu contribucin brinda
210
debido a la falta de organizacin
cada rea de TI a los servicios
por parte de las reas de TI para
TI prestados a nivel de toda la
el
empresa.
mantenimiento
de
la
disponibilidad de los servicios

brindados.
Esta
definicin
debe
estar
hecha en base a los recursos

implicados, as como tambin
el personal a cargo del control
del mismo.
6.
Insatisfaccin del cliente por los

servicios brindados.
Tener
permitan
herramientas
a
travs
que
de
un
monitoreo constante detectar

si un equipo o estacin de
trabajo no est funcionando
PE
0,25
normalmente.
0,75
Brindar soporte inmediato al

detectar
fallas
en
su
funcionamiento.
Realizar registros de estas

fallas y soluciones brindadas
211
para posibles interrupciones
de servicio detectados mas
adelante.
7.
No contar con herramientas y

recursos
requeridos
para
Determinar
dentro
de
requerimientos
administrar el proceso.
los
de
disponibilidad
herramientas
que permitan administrar el

proceso de manera favorable.
TE
0,3
Realizar
la
adquisicin
de
dichas herramientas mediante
0,6
concursos
que
permitan
determinar la mejor opcin en

base
las
expectativas
esperadas con el manejo de la

misma.
8.
Los objetivos de disponibilidad

no
estn
alineados
con
las
DE
0,1
0,3
Buscar proveedores en lnea.
Implementar un formulario que

permita evaluar la concepcin
212
necesidades de los usuarios.
que tienen los clientes de los

servicios
prestados
actualmente.
En base a los resultados de la

aplicacin de estos formularios
definir
cules
son
las
necesidades de los usuarios.
Establecer objetivos para el

proceso enfocados en resolver
las necesidades detectadas.
Implementar
soluciones
dichas necesidades, tomando

en cuenta la disponibilidad de
servicios.
TABLA 2.35. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE LA DISPONIBILIDAD.
213
TABLA DE RIESGO
#
Riesgo
1.
No restauracin de los servicios
Categora
Riesgo
Establecer en forma escrita
tras una crisis debido a la falta
procedimientos
de implementacin de un plan
restauracin de un servicio
de contingencias.
bajo cualquier situacin que
para
la
saque al mismo de operacin.
Dichos procedimientos deben

tomar en cuenta el aporte de
DE
1,0
todas
3,0
las
personas
relacionadas con los servicios

afectados.
Hacer
conocer
procedimientos
organizacin
a
a
estos
toda
travs
la
del
Service Desk o una pgina

informativa manejada a nivel
interno.
214
2.
Asumir que la infraestructura TI
Implementar un ambiente de
estar siempre libre de cualquier
pruebas que permita detectar
peligro.
vulnerabilidades
sistemas
TE
0,5
1,0
de
los
seguridades
implementadas
en
la
organizacin.
Dar soluciones que permitan

corregir estas situaciones.
3.
los servicios tras una crisis.
4.
Elevados costos para restaurar

BG
0,5
1,0
para casos de emergencia.
Falta de entrega de servicios TI

a causa de daos frecuentes de
los enlaces de comunicacin por
Falta
de
compromiso
administracin.
Tener
contratos
con
los
proveedores en los cuales se

TE
0,5
1,0
tomen medidas considerando
el mal clima.
5.
Mantener un fondo de reserva
este tipo de incidentes.
de
la
BU
0,3
0,9

Administracin
cmo
este
puntualizando
proceso
puede
215
ayudar
a la deteccin de
posibles
riesgos,
vulnerabilidades y amenazas a
la infraestructura TI.
Definir
cmo
sera
la

invertidos en el proceso.

cierto
tiempo
para
hacer

est
funcionando
correctamente.
6.
Funcionamiento incorrecto de los

servicios
TI
causa
del
infraestructura TI.
desconocimiento de errores en
algunos
componentes
de
la
infraestructura TI y aplicaciones.
Monitorear frecuentemente la
DE
0,2
0,4
Tener
un
equipo
que
se
dedique a la realizacin de
pruebas en torno al correcto
funcionamiento
de
los
216
componentes
de
la
infraestructura TI as como
tambin de aplicaciones.
7.
Falta de control del proceso

debido a la falta de recursos.
Determinar
dentro
requerimientos
proceso
de
de
las
los
este
herramientas
necesarias
para
su
administracin.
BG
0,15
Realizar
la
adquisicin
de
dichas herramientas mediante
0,3
concursos
que
permitan
determinar la mejor opcin en

base
las
expectativas
esperadas con el manejo de la

misma.
Buscar proveedores en lnea.
TABLA 2.36. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE LA CONTINUIDAD.
217
PROCESOS DE GESTIN DE LA SEGURIDAD

TABLA DE RIESGO
Riesgo
1.
Resistencia del usuario a la
Categora
Riesgo
reglamentacin de seguridad.
Hacer conocer al usuario que

las
medidas
de
seguridad
establecidas
sern
monitoreadas.
Establecer penalizaciones de
la falta de cumplimiento de
PE
0,85
2,55
medidas de seguridad en las

que
el
usuario
est
directamente involucrado, tales

como
confidencialidad
en
cuanto a sus contraseas o el

cambio de las mismas cada
cierto tiempo.
2.
Falta de conocimiento de los
DE
0,8
2,4
Realizar
reuniones
que
218
usuarios acerca de las medidas
permitan
de seguridad a causa de que se
consideracin
considera innecesario.
realizar la comunicacin de
las
poner
medidas
cmo
bsicas
a
se
de
seguridad a los usuarios.
Para
mantener
la
confidencialidad en cuanto a
posibles cambios relacionados
con la seguridad de un usuario
especfico se debera usar el
correo interno.
Establecer
planes
de
capacitacin
anuales
con
respecto a las medidas de

seguridad establecidas en la
organizacin.
3.
Falta de control del proceso

debido
implementacin
la
falta
de
de
procedimientos formales para su
DE
1,0
2,0
Elaborar un Plan de Seguridad

en base a detalles tales como
la
confidencialidad,
la
integridad, y la disponibilidad
219
ejecucin.
de la informacin.
Tambin
es
establecer
necesario
medidas
verificabilidad
de
de
que
lo
anterior se cumpla.
Es
indispensable
mantener
actualizada esta informacin.
Realizar
autoevaluaciones
enfocados a cmo se manejan

las
medidas
de
seguridad
establecidas.
Realizar auditoras internas y

externas
enfocadas
al
cumplimiento de este plan.
Establecer
medidas
correctivas de acuerdo a los

resultados obtenidos.
4.
No tomar en cuenta al personal

(por lo que sabe del negocio)
dentro
de
las
medidas
de
DE
0,85
1,7
Firmar
acuerdos
confidencialidad
de
de
la
informacin perteneciente a la
220
seguridad establecidas.
5.
empresa.
Riesgos de seguridad causados

por errores humanos dentro de
Realizar
auditoras
la
informacin almacenada.
la organizacin.
Realizar
correcciones
equivocaciones detectadas
hacer
conocer
de
este
incidente a la persona que

PE
0,8
1,6
manipul esta informacin.
Realizar capacitacin de las

aplicaciones manejadas.
Implementar
control
polticas
de
de
descargas
especialmente de
aquellas
aplicaciones que no se utilicen

en la empresa.
6.
Falta de proteccin de virus a

causa de una antivirus que no
cumpla con la demanda de la
empresa.
Llamar a licitacin con el fin de

encontrar un nuevo producto
TE
0,75
1,5
que
pueda
abastecer
las
necesidades de proteccin de
la empresa en relacin con el
221
manejo de antivirus.
7.
Falta de control de seguridades
Utilizar el Internet como medio
a causa del conocimiento de
de
nuevas amenazas relacionadas
conocimientos en cuanto a los
con la tecnologa.
nuevos virus.
TE
0,6
1,2
actualizacin
Establecer
medidas
prevencin
acuerdo
de
por
a
de
escrito
estos
de
nuevos
conocimientos.
Suscribirse a sitios o revistas

que proporciones informacin
actual sobre amenazas.
8.
Costos
elevados
para
el
mantenimiento de la seguridad.
Realizar
un
estudio
costo-
beneficio con respecto a la

BG
0,5
1,0
implementacin
de
medidas
seguridad
de
necesarias
consideracin
ponerla
de
la
las
a
Alta
Administracin.
9.
Falta de compromiso por parte
BU
0,2
0,6
222
de la Alta Administracin.
Administracin
cmo
este
puntualizando
proceso
puede
ayudar a la proteccin de la
informacin de empresa.
Definir
cmo
sera
la

invertidos en el proceso.

cierto
tiempo
para
hacer

est
funcionando
correctamente.
TABLA 2.37. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN DE LA SEGURIDAD.
223
2.2
ELABORACIN DEL INFORME EJECUTIVO
El informe ejecutivo ser dirigido a la Direccin de Sistemas de la Empresa

Elctrica Quito S.A., cuyo Jefe es el Ing. Francisco Larrea.
Dicho informe se muestra a continuacin:
2.2.1
ANTECEDENTES
La Facultad de Ingeniera en Sistemas Informticos y de Computacin de la

ESCUELA POLITCNICA NACIONAL propone a la Divisin de Sistemas de la
EMPRESA ELCTRICA QUITO S.A. la realizacin del Anlisis de la prestacin de
Servicios apoyados por TI utilizando ITIL,
por parte de su estudiante, como
realizacin de su proyecto de titulacin, necesario para poder obtener el ttulo de

Ingeniero en Sistemas Informticos y de Computacin.
Dicha propuesta es aceptada y para dejar constancia de esto firma un convenio

entre las partes implicadas teniendo como una de las clusulas la entrega de una
copia de la tesis elaborada a la empresa.
Una vez realizados los trmites respectivos, se procede al desarrollo del trabajo,
el mismo que ser orientado por el Ing. Carlos Benavides, Jefe del Grupo de
Planificacin Informtica.
2.2.2
INTRODUCCIN
El anlisis de la prestacin de Servicios apoyados por TI utilizando ITIL se efectu

durante el periodo comprendido entre los meses de octubre de 2007 y febrero del
presente.
224
Se procedi a caracterizar la empresa, la Divisin de Sistemas y los procesos TI

que actualmente se encuentran en funcionamiento bajo su custodia.
Seguidamente se realiz la evaluacin de estos en base a los procesos de

soporte, entrega y seguridad de servicios propuestos por ITIL. Estas tareas se
detallan en el Informe Tcnico que se encuentra en la seccin 2.1 de este
proyecto de titulacin.
Posteriormente fueron interpretados los resultados para obtener conclusiones y

proponer recomendaciones prcticas y viables para mejorar el desempeo de la
organizacin dentro del alcance planteado.
2.2.3
SNTESIS EJECUTIVA
A continuacin se presenta una sntesis ejecutiva del trabajo, que contiene los
objetivos propuestos y los resultados alcanzados:
OBJETIVOS
Conocer la situacin actual de los procesos TI manejados por la

Divisin de Sistemas
a travs de la recoleccin de informacin
especializada mediante el uso de encuestas y entrevistas enfocadas a

las mejores prcticas de ITIL.
Evaluar procesos y roles segn el criterio de ITIL, tomando como

referencia el soporte, entrega y seguridad de estos.
Interpretar los resultados obtenidos del anlisis de datos.
Identificar factores crticos de cumplimiento.
Definir actividades de mejora para los factores crticos de cumplimiento

detectados.
225
Plantear posibles riesgos de acuerdo al manejo actual de los procesos

TI en la empresa.
Definir acciones de salvaguarda de acuerdo a riesgos identificados.
Elaborar
un
conclusiones
informe
y
tcnico
de
recomendaciones
la
evaluacin
prcticas,
realizada
con
sugerencias
de
soluciones posibles de implantar con el menor costo.

Elaborar un informe ejecutivo de la evaluacin realizada para

conocimiento de la Divisin.
ALCANCE
Se realizar un anlisis de los servicios apoyados por TI que actualmente se

tiene en la empresa con el fin de tener un punto de referencia al cual mas
adelante aplicar ITIL, teniendo como meta el entregar un documento tcnico y
uno ejecutivo con los resultados del anlisis para que sirva de ayuda a la
empresa para la toma de decisiones en cuanto al manejo de las tecnologas de
la informacin.
Para dicha evaluacin se emplearn encuestas y entrevistas enfocadas a la

obtencin de informacin necesaria para su respectivo anlisis, quedando
establecido que la aplicacin de estas no interrumpir la operacin normal de las
actividades de las personas de la Divisin de Sistemas.
2.2.4
RESULTADOS DEL ANLISIS
Los resultados obtenidos de acuerdo a los anlisis realizados son los siguientes:
226
EVALUACIN DE PROCESOS
PROCESO
Finanzas
Problemas
Niveles de Servicio
Disponibilidad
Configuracin
Continuidad
Capacidad
Cambios
Seguridad
Versiones
Service Desk
Incidentes
CUMPLIMIENTO DEL
PROCESO
14,7%
16,6%
20,2%
29,2%
29,5%
30,4%
36,0%
37,0%
43,4%
45,3%
49,2%
72,0%
REPRESENTACIN GRFICA DE RESULTADOS

CUMPLIMIENTO DE LA ADMINISTRACIN DE PROCESOS EVALUADOS
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
Fi
na
nz
as
Pr
N
ob
iv
le
el
m
es
as
de
S
er
vi
cio
D
is
po
ni
bi
lid
C
ad
on
fi g
ur
ac
i
n
C
on
ti n
ui
da
d
C
ap
ac
id
ad
C
am
bi
os
Se
gu
rid
ad
Ve
rs
io
ne
Se
s
rv
ic
e
D
es
k
In
ci
de
nt
es
0%
Procesos
MEDIA DE CUMPLIMIENTO
FACTORES CRTICOS MAS IMPORTANTES DETECTADOS POR PROCESO
Administracin
Financiera de
los Servicios TI
No se ha definido una fijacin de polticas financieras para el rea

de TI.
La organizacin no dispone de la informacin financiera precisa
para la toma de decisiones.
227
No se tiene definido cunto de los gastos de los servicios TI

ofrecidos son para el rea de TI.
No se tiene definido cules son los elementos de coste de los

servicios TI.
No se asegura que los servicios TI estn suficientemente

financiados.
No se han definido parmetros para el registro de problemas, ya

que se trata a estos como incidentes y viceversa.
Administracin
de Problemas
El porcentaje de investigacin de la causa de un problema es

mnima.
No siempre se informa al cliente que solicit ayuda en cuanto a

un problema, cul fue la solucin efectuada para resolver el
mismo.
No se tiene correctamente definidos los servicios ofrecidos tanto

interna como externamente, as como tambin quines son sus
responsables.
Administracin
de los Niveles
de Servicio
No se manejan documentos formales para los acuerdos de nivel
Solo ciertos servicios ofrecidos se centran en el cliente y su
de servicio.
negocio y no en la tecnologa.
No se ha definido un proceso a seguir para administrar la

disponibilidad de servicios.
Administracin
de la
Disponibilidad
No se ha definido cul es la resistencia de la infraestructura TI.

No se tienen definidos mtodos ni
tcnicas para evaluar la
disponibilidad.
No se han determinado franjas horarias de disponibilidad de los
servicios TI.
No se han determinado los objetivos, estrategias y polticas de la

Administracin
de la
Configuracin
No se ha determinado el alcance y nivel de detalle del proceso de

configuracin.
No se conoce el estado actual de los componentes de la
infraestructura.
No se ha invertido en ninguna herramienta de software para el

control
de
la
administracin
de
los
elementos
de
la
228
infraestructura.
No se tiene un manual de usuario de todas las aplicaciones que

corren en la empresa.
No se maneja un Plan de Gestin de Emergencias.
No se ha realizado una comunicacin adecuada del plan de

recuperacin y prevencin.
Administracin
de la
Continuidad
No se realizan simulacros para diferentes tipos de desastres.

Los
planes
de
prevencin
recuperacin
no
estn
adecuadamente actualizados.
No
se
realiza
una
evaluacin
constante
de
riesgos,
vulnerabilidades y amenazas a los que est expuesta la

infraestructura TI.
No se realizan pruebas y auditoras constantes para ver si las

vulnerabilidades realmente fueron controladas tras una crisis.
No se traduce las necesidades del negocio en capacidad

requerida.
Administracin
de la
Capacidad
No se realizan modelos ni simulaciones sobre diferentes

escenarios, para llevar a cabo previsiones de carga y respuesta
de la infraestructura informtica.
No se realizan benchmarks con prototipos reales para asegurar la
capacidad y el rendimiento de la futura infraestructura.
No se conoce bien el estado actual de la tecnologa en la

organizacin.
No se manejan documentos formales para la solicitud de un

cambio, as como tambin los costos y recursos relacionados a
este, al igual de que la causa de peticin del cambio.
Administracin
de Cambios
No se tienen criterios de aceptacin de una peticin de cambio.

No siempre se tiene el acceso a usuarios al entorno de pruebas
de un cambio para hacer una valoracin antes de enviarlo a
produccin.
Las pruebas post implementacin de un cambio no se las realiza

siempre.
Administracin
de la Seguridad
No se tienen programas de formacin en cuanto al manejo de la

seguridad.
Existe despreocupacin por la seguridad del personal por lo que
229
sabe del negocio.
No se ha implementado el Plan de Seguridad.
Se
realizan
autoevaluaciones
para
ver
si
se
manejen
correctamente las polticas de seguridad con escasa frecuencia.
Se tiene a los equipos y procedimientos de seguridad

actualizados slo en un 33%.
No todo el personal conoce y acepta las medidas de seguridad

establecidas, as como sus responsabilidades al respecto.
No se tienen criterios de unidad de versin, especialmente en lo

que se refiere a hardware y documentacin.
Nunca se compra una versin de software, an cuando en ciertas

ocasiones sea necesario.
No se desarrollan planes de back-out.
Los procedimientos de rollout no son documentados.
Administracin
de Versiones
No se realizan pruebas de aceptacin de versiones antes de

llevarlas al ambiente de operacin.
No siempre se definen qu elementos de la configuracin se

vern directa o indirectamente implicados durante y tras el
lanzamiento de una nueva versin.
No se realizan auditoras a las estaciones de los usuarios con la

persistencia que deberan.
No se evala la calidad de prestacin de servicios por parte de la

persona que dio el soporte.
Funcin
Service Desk
La evaluacin de la satisfaccin de los clientes es casi nula.
No se dispone de toda la informacin de servicios de la empresa.
No se da un sondeo apropiado a los clientes para conocer sus

expectativas y necesidades.
La comunicacin con los clientes y usuarios con respecto
cambios planeados y de corto plazo es ineficiente.
Administracin
de Incidentes
No existe alguna persona que administre la escalacin de

incidentes.
No se realiza una evaluacin exhaustiva de los detalles de un
incidente.
TABLA 2.38. RESULTADO DEL CUMPLIMIENTO DE LOS PROCESOS EVALUADOS

230
EVALUACIN DE ROLES
PROCESO
Finanzas
Configuracin
Disponibilidad
Seguridad
Problemas
Niveles de Servicio
Cambios
Continuidad
Service Desk
Incidentes
Capacidad
Versiones
CUMPLIMIENTO DE
ROLES POR PROCESO
0,0%
15,3%
25,0%
25,0%
27,1%
30,0%
42,9%
49,1%
58,5%
61,1%
63,9%
87,5%
REPRESENTACIN GRFICA DE RESULTADOS

CUMPLIMIENTO DE ROLES PARA CADA PROCESO EVALUADO
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
Fi
na
nz
as
on
fi g
ur
ac
i
D
isp
n
on
ib
il id
ad
Se
gu
ri d
ad
Pr
N
ob
ive
le
m
le
s
as
de
S
er
vi
cio
C
am
bi
os
C
on
ti n
ui
da
Se
d
rv
ic
e
D
es
k
In
ci
de
nt
es
C
ap
ac
id
ad
Ve
rs
io
ne
s
0%
Procesos
MEDIA DE CUMPLIMIENTO
FACTORES CRTICOS MAS IMPORTANTES DETECTADOS POR PROCESO
Administracin
Financiera de
los Servicios TI
No existe una persona que trabaje con los administradores y

financieros en el desarrollo de las polticas de presupuestos,
contabilidad y cargos para los servicios TI.
No existen responsables en cuanto al presupuesto, contabilidad
231
y cargos de los servicios TI.
Ninguna persona ha implementado el proceso de Administracin

Financiera de los servicios TI.
No existe ninguna persona que se haga cargo de la

administracin de la configuracin, por lo tanto no se ha
determinado el alcance y nivel de detalle de este proceso.
No se ha desarrollado algn sistema de identificacin de

elementos de configuracin y polticas para su nombramiento.
Administracin
de la
Configuracin
No se ha planeado, ni implementado una base de datos que

ayude en la administracin de la configuracin.
Existe una persona que se dedique a la custodia de todas las
copias de software, sin embargo no del resto de elementos de la
configuracin (hardware y documentacin).
No se tiene informacin del estatus de los elementos de

configuracin.
No existe una persona que defina y desarrolle el proceso de la

Disponibilidad.
Administracin
de la
Disponibilidad
No se ha asignado alguna persona que se encargue de la

optimizacin de la infraestructura de TI.
No hay alguien que se encargue de que los servicios de TI estn
diseados de tal manera que los niveles de servicio sean
cumplidos.
Ningn individuo que trabaje con los servicios TI, genera reportes
de disponibilidad.
No existe un responsable formal de la operacin efectiva del

proceso de la seguridad.
Administracin
de la Seguridad
No se realiza una correcta integracin de las estrategias oficiales

de seguridad de la informacin por parte del cliente.
No siempre se realizan auditoras de seguridad internas y

externas.
No realizan informes de seguridad.
No existe una persona que desarrolle y de mantenimiento al
Administracin
de Problemas
control de errores y problemas de una manera formal.

No se ha realizado la obtencin de recursos necesarios para la
administracin de problemas.
232
No existe una persona o grupo de personas destinado a la

investigacin
de
problemas
para
convertirlos
en
errores
conocidos.
No existe una persona que constantemente negocie con los

clientes en nombre de TI y con las reas de TI en nombre del
negocio.
Administracin
de los Niveles
de Servicio
No se ha definido correctamente la estructura de acuerdos de
No siempre se realiza una revisin del desempeo de la
nivel de servicios en la organizacin.

No se ha elaborado un Programa de Mejora del Servicio.
organizacin con respecto a la infraestructura TI.
No existe alguna persona que decida qu gente asistir a qu

reuniones para aprobar un cambio.
No existe una persona que autorice los cambios aceptados en las

reuniones de aprobacin.
Administracin
de Cambios
No existe una persona que retire cambios implementados que

hayan fallado.
No existe una persona que participe formalmente en la
programacin de cambios.
No existe una persona o grupo de personas que evalen y

aprueben peticiones de cambio urgentes.
No hay un grupo destinado a la implementacin de cambios

urgentes.
No se ha realizado una correcta asignacin de personal y

recursos para la administracin de la continuidad con respecto a
los servicios TI entregados.
Administracin
de la
Continuidad
No se ha asignado una persona que dirija y autorice actividades

para el control de la continuidad de los servicios.
No existe una persona que tome bajo su responsabilidad el
proceso de continuidad y lidere a los equipos destinados a
mantener el funcionamiento de servicios.
Administracin
de Service
Desk
No se implementan Planes de Recuperacin.

No siempre
se tiene la habilidad de comprender que los
problemas del cliente afectan al negocio.
233
La conduccin del Proceso de Gestin de Incidentes no es muy

adecuada para lograr la efectividad y eficiencia esperada.
No se usan mtodos para dirigir al Equipo de Service Desk con el

fin de brindar un servicio de calidad.
No se realiza seguimiento a incidentes y quejas cuando ya son

asignados a soporte de segundo o tercer nivel.
No se mantiene informado al usuario sobre estatus y progresos

con respecto a algn incidente reportado.
No siempre se monitorea la efectividad y eficiencia del proceso

de administracin de incidentes.
Administracin
de Incidentes
No se genera informacin muy detallada para la administracin

de incidentes.
No se realiza monitoreo del estatus y progreso de un incidente.
No se realiza monitoreo de incidentes ni de los elementos de

configuracin afectados.
No existe una persona especfica que administre el proceso de la

capacidad.
No existe una persona que se encargue de establecer los niveles

adecuados de monitoreo de recursos y desempeo de sistemas.
Administracin
de la
Capacidad
No se ha asignado a nadie el desarrollo de un Plan de Capacidad

de acuerdo al ciclo de planeacin del negocio.
Ningn individuo se encarga de documentar las necesidades de
cualquier incremento o reduccin en el hardware basado en los
requisitos de servicio por parte de los clientes.
De vez en cuando se realizan reportes del uso actual de los

recursos, sin embargo no existe una persona que se encargue de
forma peridica de esta labor.
Administracin
de Versiones
Se ha establecido y se mantiene polticas de liberacin slo de

versiones de software.
No siempre se controla las actividades dentro del proceso de
versiones.
TABLA 2.39. RESULTADO DEL CUMPLIMIENTO DE ROLES EVALUADOS

234
2.2.5
CONCLUSIONES Y RECOMENDACIONES
Las conclusiones y recomendaciones sern las mismas que constan para cada
proceso en el Informe Tcnico presentado en la seccin 2.1.
235
CAPITULO 3.
CONCLUSIONES Y RECOMENDACIONES
3.1.
CONCLUSIONES
Con respecto a la realizacin de este trabajo, la principal dificultad encontrada

una vez establecido el lugar donde se llevara a cabo la evaluacin, fue la
obtencin de informacin, ya que la mayora de las personas de la Divisin de
Sistemas (lugar al cual fue dirigido la evaluacin) no disponan del tiempo
necesario para contestar las encuestas proporcionadas, as como tampoco se
poda dar lugar a las entrevistas, debido a que se mantenan en cursos
relacionados al rea de trabajo.
En muchos casos, esto dio lugar al
incumplimiento de ciertas actividades establecidas en el cronograma de

trabajo entregado a la organizacin al inicio del proyecto.
El mtodo de evaluacin utilizado funcion con limitaciones debido a que no

se pudo establecer en ciertas ocasiones si un proceso cumpla o no con
alguna actividad, debido a la dependencia de ste con otros procesos no
implementados o en su defecto la falta de implementacin del mismo en la
organizacin.
En relacin al manejo del proceso Administracin de Incidentes, al igual que la

funcin Service Desk ya implementados en la organizacin, se puede decir
que su principal problema es la falta de procedimientos establecidos
formalmente bajo un esquema de documentacin que permita darlos a
conocer, as como tambin la ausencia de reportes relacionados al manejo de
cada uno de estos.
Si bien es cierto, ITIL propone una gua de actividades que se deberan tomar
en cuenta para mantener la correcta administracin de los servicios TI, sta no
propone una metodologa a seguir para su establecimiento, es por esta razn
236
que una vez realizado el anlisis respectivo se han definido recomendaciones

que de cierta forma van a poder corregir algunas acciones mal desempeadas
en los procesos ya implementados, o en su defecto cmo podran llevar a
cabo las funciones relacionadas con los que no lo estn.
Con respecto a los resultados obtenidos del anlisis realizado, se puede

concluir que debido al incumplimiento de las actividades relacionadas a cada
proceso o funcin por cualquiera de las causas relacionadas a estos, existen
muchos riesgos para que no se lleve correctamente su administracin como
puede verse en la seccin de Anlisis de Riesgos expuesto en el Captulo 2.
Con respecto al tema de la adopcin de ITIL en la organizacin, es necesario

tener muy presente que esta exige un compromiso con un proyecto a varios
aos, as como dar voz y voto sobre el negocio a las personas que se
encontraran a cargo del manejo de los procesos relacionados. Por otro lado,
dicha adopcin no requiere implementar todos los grupos de procesos
simultneamente.
Adicionalmente, el enfoque de gestin de servicios TI en base a ITIL debe ser

dirigido a la entrega de valor aadido y valor real al usuario y no a la
implementacin de ste porque est de moda.
3.2.
RECOMENDACIONES
Se aconseja que la Alta Administracin participe directamente en la

implementacin de los procesos, especialmente con la motivacin y el
liderazgo, ya que si esta no respalda amplia y demostrablemente el uso de las
mejores prcticas, o si no se est completamente comprometida con el cambio
y la innovacin, no se puede esperar que la entrega de servicios TI mejore y
peor an que sea aceptado por los usuarios.
237
Es aconsejable que como fundamento bsico de un programa de

implementacin o mejora en los procesos de ITIL se realice la capacitacin de
toda la organizacin orientado a que todo el personal hable un idioma comn
con el fin de obtener el xito deseado con respecto a la administracin de
estos.
Es recomendable que en el proceso y funcin implementados hasta el

momento se realicen los cambios pertinentes para el mejoramiento de su
gestin, ya que son el eje primordial de contacto con los usuarios. Para poder
hacerlo se pueden tomar en cuenta las recomendaciones expuestas en el
Captulo 2.
En cuanto se refiere a los procesos todava no implantados, es aconsejable

que se tome a cada uno de estos como un proyecto en donde se marquen
objetivos, se designe un
equipo debidamente formado en sus tareas y
responsabilidades, tomando en cuenta que si dicho proceso es demasiado

complejo, la gente se resistir o intentar saltrselo.
Para continuar la implementacin de los procesos de ITIL se tienen varios

caminos, sin embargo se recomienda tomar en cuenta los siguientes:
1. Implementar la Administracin de Problemas con el fin de poder identificar

las causas de los incidentes reportados valindose del proceso y funcin
ya establecidos en la institucin.
2. Implementar la Administracin de Cambios para luego continuar con la
implementacin de la Administracin de la Configuracin.
3. Implementar la Administracin de los Niveles de Servicio definiendo los
requerimientos de los clientes de la Divisin de Sistemas y realizando una
negociacin simple para la entrega de servicios TI relacionados. Al mismo
tiempo se podra empezar con un programa de mejora continua.
238
Se aconseja tener paciencia en cuanto a la obtencin de beneficios al

implementar los
procesos, ya que el transcurso para llevar a cabo dicha
implantacin depende del alcance definido para estos.
Se recomienda que para contrarrestar los riesgos identificados a lo largo de

este proyecto, se lleven a cabo las medidas de salvaguarda definidas en el
Anlisis de Riesgos mostrado en el Captulo 2.
Aunque no es requisito la implantacin de ITIL, se recomienda su adopcin

para trabajar en conformidad con ISO 20000, ya que sta aportar una base
importantsima sobre la cual operar haciendo mucho ms fcil el proceso.
Se recomienda usar en otras empresas de servicios pblicos los procesos de

evaluacin usados en este proyecto, para validar los mismos.
239
BIBLIOGRAFA
LIBROS
[1] OGC, Planning to Implement ITSM, V. 2.0, Copyright 2002, Editorial TSO.
[2] OGC, Service Delivery, Copyright 2001, Version 2.1, Editorial TSO.
[3] OGC, Service Support, Copyright 2000, Version 1.3, Editorial TSO.
[4] OGC, Security Management, Copyright 1998, Version Beta, Editorial TSO.
[5] Pressman R., Ingeniera del Software, 4ta Edicin.
PGINA WEB
[1] OSIATIS S.A., Gestin de Servicios TI,
www.itil.osiatis.es,
ltimo Acceso: 18/02/2008

Escuela Politécnica Nacional: Facultad de Ingeniería en Sistemas

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Escuela Politécnica Nacional: Facultad de Ingeniería en Sistemas

Загружено:

Авторское право:

Доступные форматы

ESCUELA POLITCNICA NACIONAL

FACULTAD DE INGENIERA EN SISTEMAS

ANLISIS DE LA PRESTACIN DE SERVICIOS APOYADOS

PROYECTO PREVIO A LA OBTENCIN DEL TTULO DE INGENIERO EN

ALMEIDA TOAPANTA JENNY ALEXANDRA

DIRECTOR: Msc. Ing. JAIME NARANJO

Quito, Febrero 2008

A travs de la presente declaro ceder mis derechos de propiedad intelectual

Jenny Alexandra Almeida Toapanta

Ing. Jaime Naranjo

Al personal de Sistemas de la EEQ S.A., especialmente al Ing. Carlos Benavides, quien me

Mi Scrapy precioso, que siempre llena de alegra mi vida.

A todos ustedes que Dios les bendiga y a mi me de la oportunidad de demostrarles cuanto

ENFOQUE PROCESAL DE ITIL............................................................................................ 14

SELECCIN DE LOS PROCESOS A SER EVALUADOS EN LA EMPRESA ........................ 16

Actividades/Subprocesos a evaluarse por cada proceso seleccionado........................................... 18

REALIDAD DE LA ORGANIZACIN .................................................................................... 21

MAPEO DE LOS PROCESOS MANEJADOS POR ITIL VS. LOS SUBPROCESOS DE LA

APLICACIN DE ITIL PARA EL ANLISIS DE LOS PROCESOS SELECCIONADOS..... 28

Mtodo de Interpretacin de Resultados........................................................ 31

Evaluacin de Resultados. ..................................................... 31

ANLISIS DE ROLES ............................................................................................... 33

MAPEO DE ROLES DE LOS PROCESOS SELECCIONADOS DE ITIL VS. LOS ROLES

MANEJADOS EN LA DIVISIN DE SISTEMAS .................................................................................. 33

APLICACIN DE ITIL PARA EL ANLISIS DE LOS ROLES SELECCIONADOS............... 35

Clculos aplicados para la obtencin del porcentaje de cumplimiento de roles ............................ 36

Mtodo de Interpretacin de Resultados................................................ 37

Evaluacin de Resultados.. .................................................... 38

ANLISIS DE RIESGOS ............................................................................................ 39

ANLISIS DE ESTIMACIN DE RIESGOS ........................................................................... 39

Identificacin de Riesgos. ...................................................... 39

Categorizacin de Riesgos.. ....................................................... 39

Mtodo de Interpretacin del Impacto de Riesgos............................................. 39

Clculos aplicados para la obtencin del Porcentaje de Riesgo .................................................... 40

Mtodo de interpretacin de la Probabilidad de Riesgo. .................................................. 41

Mtodo de Interpretacin de Riesgos..................................................... 41

Evaluacin de Resultados ...................................................... 42

ELABORACIN DEL INFORME TCNICO ............................................................................ 43

ACTIVIDADES REALIZADAS PARA EL DESARROLLO DEL INFORME....................... 43

Establecimiento de Herramientas para la obtencin de Informacin.....43

Sesiones para la obtencin de Informacin....44

Resultados de la Evaluacin de Procesos...45

Resultados del Anlisis de Roles ..125

Resultados de la Anlisis de Riesgos.....162

ELABORACIN DEL INFORME EJECUTIVO...................................................................... 223

CAPITULO 3.................................................................................................. 235

CONCLUSIONES .................................................................................................... 235

RECOMENDACIONES ............................................................................................. 236

TABLA 2.8. RESULTADO OBTENIDO DE LA APLICACIN DE LA ENCUESTA Y ENTREVISTA

TABLA 2.27. RESULTADO OBTENIDO DEL ANISIS DE RIESGOS PARA LA ADMINISTRACIN

La evaluacin de la prestacin de servicios apoyados por TI1 en la Empresa

Por otro lado, se realiza la identificacin de roles de acuerdo a los procesos

Estos sern comparados con las

los miembros de la Divisin de Sistemas en la

organizacin para su evaluacin.

La obtencin de informacin para el presente estudio es mediante el uso de

Adicionalmente, se da lugar al anlisis de riesgos para cada proceso, basado en

Para la presentacin de resultados, se genera un informe tcnico y uno ejecutivo

Por ltimo se establecen las respectivas conclusiones y se plantean las

Este proyecto consiste en el anlisis de la gestin de servicios apoyados por TI

Este documento est dividido en 3 captulos:

Captulo 1. Corresponde a la evaluacin de la organizacin enfocada al anlisis

Aqu se dio paso a la aplicacin de encuestas, entrevistas y guas