Tecnologia de Informacion Gerencia de Servicios Basado en ITIL PDF

A mis hijos Miguel y Manuel
Gracias por su soporte e inspiración

en los momentos difíciles.
J. Lloréns Fábregas
i
ii
Prefacio
Informática no es un problema
técnico…. Es un problema de gerencia.
Hasta hace pocos años en los departamentos IBM o de “procesamiento

de datos”, como se les solía llamar, la administración de los servicios era
bastante simple, sólo teníamos que preocuparnos de guardar
ordenadamente unos “decks" de tarjetas perforadas en los que residían los
programas o algunos archivos de datos y, en las organizaciones más
sofisticadas, guardar ordenadamente unos cuantos carretes de cinta
magnética, donde residían los archivos de datos más importantes. Junto
con esos elementos, unos instructivos que le indicaban al personal de
operación los pasos que debían ejecutarse, completaban el conjunto de
componentes necesarios para prestar el servicio requerido por los
usuarios, que normalmente se concretaba en un listado o reporte.
La tecnología de información, como se le denomina hoy día, ha
evolucionado dramáticamente, las facilidades y posibilidades que
disponemos en la actualidad eran inimaginables en aquellas épocas; a
veces, hasta nosotros mismos nos sorprendemos de las capacidades que
nos traen las nuevas tecnologías. A pesar de ello, no es poco frecuente oír
a los ejecutivos y usuarios de las empresas quejarse continuamente de los
servicios de informática. Siempre se habla de que el departamento de
tecnología de información es una especie de caja negra capaz de absorber
más y más recursos, sin que la empresa reciba una contraprestación
razonable.
Del lado de informática también es frecuente oír quejas sobre la
cantidad de recursos que se les otorga y del bajo reconocimiento que
reciben los denodados esfuerzos que se invierten para brindar un servicio
de calidad.
Obviamente, los técnicos de tecnología de información no somos ni
unos buenos comunicadores, ni unos buenos administradores.
Evidentemente, hay que acercar esos dos extremos, especialmente
porque la tecnología de información es un arma fundamental para que
cualquier empresa pueda competir con éxito en su mercado. Como de
iii
costumbre, es más fácil decirlo que hacerlo; sin embargo, al igual que la
tecnología, las disciplinas de gerencia de los servicios de tecnología de
información han venido evolucionando y madurando significativamente y
su inserción metódica en cualquier organización de informática puede
significar una contribución importante para que pueda entregarse un
servicio de alta calidad, con un costo razonable.
En el presente libro nos proponemos discutir sobre ese conjunto de
disciplinas de administración de servicios de tecnología de información,
no sin antes enfatizar que estas no constituyen una panacea y que su
aplicación debe ser realizada desde una comprensión profunda de las
verdaderas necesidades de la empresa y de sus objetivos estratégicos y
desde un compromiso activo con el logro de dichos objetivos.
Como es costumbre, hemos tratado de producir un texto que pueda
acompañar a gerentes y administradores de TI en su empeño por ordenar
y disciplinar la gestión de servicios, para ello hemos puesto nuestros
mejores esfuerzos, esperamos no defraudarlos.
iv
Tecnología de Información
Administración de Servicios
Índice general
Capítulo I
Disciplinas de administración de servicios de TI
1. ¿Qué es Gobernanza de TI? ........................................................... 3
2. La administración de servicios de TI ............................................. 6
3. ¿Qué es COBIT?............................................................................ 7
4. ¿Qué es ITIL? ................................................................................ 9
5. ¿Qué es ISO 20000? .................................................................... 13
6. ¿Qué es CMM? ............................................................................ 16
7. ¿Qué es MOF? ............................................................................. 20
8. Principales disciplinas de administración de TI........................... 21
Capítulo II
Centro de atención
1. ¿Qué es un centro de atención a usuarios?................................... 31
1.1. Ventajas................................................................................ 32
1.2. Barreras ................................................................................ 32
2. Modalidades................................................................................. 32
3. Planificación ................................................................................ 33
4. Facilidades ................................................................................... 34
5. Estructura ..................................................................................... 35
6. Actividades .................................................................................. 36
6.1. Atención de llamadas ........................................................... 36
6.2. Cierre del reporte ................................................................. 37
6.3. Manejo desde inicio hasta cierre .......................................... 40
6.4. Centro de información ......................................................... 40
6.5. Actividades adicionales........................................................ 41
7. Evaluación de la disciplina .......................................................... 41
v
Capítulo III
Manejo de Incidentes
1. ¿En qué consiste el manejo de incidentes?................................... 45
1.1. Ventajas................................................................................ 47
1.2. Barreras ................................................................................ 47
2. Requerimientos ............................................................................ 48
3. Clasificación de los incidentes ..................................................... 48
4. Escalamiento y soporte ................................................................ 50
5. Actividades................................................................................... 50
5.1. Registro de incidentes .......................................................... 51
5.2. Clasificación de los incidentes ............................................. 47
5.3. Análisis, Resolución y Cierre de Incidentes......................... 52
6. Evaluación de la disciplina........................................................... 53
Capítulo IV
Manejo de problemas
1. ¿En qué consiste el manejo de problemas? ................................. 57
1.1. 1Ventajas.............................................................................. 58
1.2. Barreras ................................................................................ 59
2. Actividades................................................................................... 59
2.1. Control de problemas ........................................................... 60
2.2. Control de errores................................................................. 63
2.3. Revisión de post implementación y cierre ........................... 64
3. Evaluación de la disciplina........................................................... 64
4. Ejemplo ........................................................................................ 65
Capítulo V
Administración de Configuraciones
1. ¿En qué consiste la administración de configuraciones? ............. 69
1.1. Ventajas................................................................................ 70
1.2. Barreras ................................................................................ 70
2. Terminología................................................................................ 71
2.1. Ítems de configuración ......................................................... 71
2.2. Base de datos de configuraciones......................................... 72
2.3. Línea base de configuración................................................. 72
2.4. Sistema de administración de configuraciones. ................... 72
vi
2.5. Ambientes operacionales ..................................................... 73
3. Proceso......................................................................................... 75
3.1. Planificación ........................................................................ 76
3.2. Clasificación y Registro ....................................................... 77
3.3. Alcance ................................................................................ 77
3.4. Nivel de detalle y Profundidad............................................. 78
3.5. Nomenclatura....................................................................... 78
3.6. Control ................................................................................. 79
3.7. Auditorías............................................................................. 79
Capítulo VI
Administración de versiones
1. ¿En qué consiste la administración de versiones? ....................... 83
1.1. Ventajas................................................................................ 85
1.2. Barreras ................................................................................ 85
2. Consideraciones de tipo práctico ................................................. 86
2.1. Tipos de versiones................................................................ 86
2.2. Actualización y custodia de componentes ........................... 87
2.3. Versiones anteriores............................................................. 88
2.4. Nomenclatura de versiones .................................................. 88
2.5. Estatus de una versión.......................................................... 89
3. Actividades de administración de versiones ................................ 89
3.1. Planificación ........................................................................ 90
3.2. Verificación de cumplimiento de estándares ....................... 91
3.3. Verificación de cumplimiento de pruebas............................ 91
4. Implementación ........................................................................... 93
5. Soporte inicial .............................................................................. 94
Capítulo VII
Administración de cambios
1. ¿En qué consiste la administración de cambios? ......................... 97
1.1. Ventajas................................................................................ 98
1.2. Barreras ................................................................................ 98
2. Elementos .................................................................................... 99
3. Roles ............................................................................................ 99
vii
4. Actividades................................................................................. 100
4.1. Registrar ............................................................................. 101
4.2. Aceptación de la solicitud .................................................. 102
4.3. Clasificación....................................................................... 102
5. Aprobación y Planificación........................................................ 104
6. Implementación.......................................................................... 105
7. Evaluación.................................................................................. 106
8. Evaluación de la disciplina......................................................... 106
Capítulo VIII
Monitorización y control
1. ¿En qué consiste monitorización y control?............................... 111
1.1. Ventajas.............................................................................. 113
1.2. Barreras .............................................................................. 114
2. Ciclo de monitorización ............................................................. 114
3. Terminología.............................................................................. 115
4. Herramientas .............................................................................. 116
5. Niveles de monitorización.......................................................... 117
6. Formas de monitorización.......................................................... 118
7. Implementación de la disciplina................................................. 119
Capítulo IX
Administración de niveles de servicio
1. ¿En qué consiste la administración de niveles de servicio? ....... 123
1.1. Ventajas.............................................................................. 124
1.2. Barreras .............................................................................. 125
2. Terminología.............................................................................. 125
2.1. Proveedores, clientes y usuarios......................................... 125
2.2. Catálogo de servicios ......................................................... 126
2.3. Acuerdo de nivel de servicio .............................................. 127
2.4. Acuerdo de nivel operacional ............................................ 127
2.5. Programa de calidad de servicio......................................... 127
3. Creación del catálogo de servicios ............................................. 128
4. Proceso ....................................................................................... 130
4.1. Preparación......................................................................... 130
4.2. Seguimiento........................................................................ 131
viii
4.3. Revisión continua............................................................... 132
5. Evaluación de la disciplina ........................................................ 132
Capítulo X
Administración Financiera de TI
1. ¿En qué consiste la administración financiera de TI?................ 137
1.1. Ventajas.............................................................................. 138
1.2. Barreras .............................................................................. 138
2. Terminología.............................................................................. 138
2.1. Costos y gastos................................................................... 139
2.2. Depreciación y amortización ............................................. 141
3. Planificación .............................................................................. 142
3.1. Catálogo de servicios ......................................................... 143
3.2. Costeo de servicios ............................................................ 144
3.3. Proyectos............................................................................ 145
3.4. Costeo de proyectos ........................................................... 145
4. Elaboración del presupuesto ...................................................... 146
5. Contabilidad............................................................................... 147
6. Actividades de la administración financiera de TI .................... 148
Capítulo XI
Administración de la capacidad
1. ¿Qué es administración de la capacidad?................................... 155
1.1. Ventajas.............................................................................. 157
1.2. Barreras .............................................................................. 157
2. Actividades ................................................................................ 158
2.1. Plan de Capacidad.............................................................. 159
2.2. Estimación.......................................................................... 160
2.3. Asignación de recursos ...................................................... 160
2.4. Monitorización................................................................... 161
3. Administración de la demanda .................................................. 161
ix
Capítulo XII
Continuidad de los servicios de TI
1. ¿Qué es administración de la continuidad? ................................ 167
1.1. Ventajas.............................................................................. 169
1.2. Barreras .............................................................................. 169
2. El plan de continuidad del negocio - (BCP)............................... 170
3. Terminología.............................................................................. 172
4. Preparación................................................................................. 173
4.1. Evaluación de riesgos......................................................... 173
4.2. Identificar procesos críticos ............................................... 173
4.3. Selección de estrategias de recuperación ........................... 174
5. Alcance de la continuidad de servicios ...................................... 175
6. Organización y planificación ..................................................... 177
6.1. Plan de mitigación de riesgos............................................. 177
6.2. Plan de manejo de emergencias ......................................... 177
6.3. Plan de recuperación .......................................................... 178
7. Continuidad de servicios en el día a día..................................... 178
7.1. Adiestramiento ................................................................... 179
7.2. Actualización...................................................................... 179
Capítulo XIII
Administración de la disponibilidad
1. ¿Qué es administración de la disponibilidad? ............................ 183
1.1. Cálculo de la disponibilidad ............................................... 185
1.2. Ventajas.............................................................................. 185
1.3. Barreras .............................................................................. 186
2. Requerimientos de disponibilidad.............................................. 186
3. Plan de disponibilidad ................................................................ 187
4. Monitorización de la disponibilidad........................................... 187
5. Mediciones ................................................................................. 189
x
Capítulo XIV
Seguridad de la información
1. ¿En qué consiste la administración de seguridad? ..................... 193
1.1. Ventajas.............................................................................. 194
1.2. Barreras .............................................................................. 195
2. La seguridad en el nivel de la empresa ...................................... 195
3. Actividades ................................................................................ 197
4. Políticas de seguridad ............................................................... 198
5. El plan de seguridad................................................................... 198
6. Cumplimiento de la normativa de seguridad ............................. 199
7. Evaluación y mantenimiento ..................................................... 200
Capítulo XV
Medición
1. ¿En qué consiste la medición de los servicios de TI? ................ 205
1.1. ¿Por qué medir? ................................................................. 206
1.2. ¿Qué debemos medir?........................................................ 206
1.3. ¿Quiénes participan en la medición? ................................. 207
1.4. Criterios para definir indicadores....................................... 207
1.5. Interpretación de indicadores ............................................. 208
2. Uso de los indicadores ............................................................... 208
3. Algunos indicadores o mediciones ............................................ 209
Anexo I - Implantación de las Disciplinas de Administración de

Servicios de TI............................................................ 213
Anexo II - COBIT - Procesos de TI ............................................. 217
Anexo III - COBIT - Relaciones de los Objetivos de Control ...... 219
Bibliografía ..................................................................................... 235
xi
xii
Capítulo I
Disc iplina s de
Adm inist ra c ión de
Se rvic ios de T I
Capítulo I

Tabla de contenido
1.- ¿Qué es Gobernanza de TI? .......................................................... 3

2.- La administración de servicios de TI ............................................ 6
3.- ¿Qué es COBIT?........................................................................... 7
4.- ¿Qué es ITIL? ............................................................................... 9
5.- ¿Qué es ISO 20000? ................................................................... 13
6.- ¿Qué es CMM? ........................................................................... 17
7.- ¿Qué es MOF? ............................................................................ 20
8.- Principales disciplinas de administración de TI ......................... 21
2
1.- ¿Qué es Gobernanza de TI?

1.1.- Gobernanza Empresarial
El diccionario de la real academia española define el término
gobernanza como:
1. Arte o manera de gobernar que se propone como objetivo el logro
de un desarrollo económico, social e institucional duradero,
promoviendo un sano equilibrio entre el Estado, la sociedad civil
y el mercado de la economía.
2. Acción y efecto de gobernar o gobernarse.
En el año 2002, los temas de gobernanza corporativa y control
tomaron un fuerte impulso como producto de los escándalos financieros
que llevaron al colapso a importantes corporaciones –como la petrolera
ENRON- y que demostraron la necesidad de nuevas regulaciones para
fortalecer la gobernanza corporativa en Europa y Estados Unidos.
El Banco Internacional de Pagos (Bank of Internacional Settlements)
de Basilea – Suiza, creado en 1930, es actualmente el principal centro
para la cooperación internacional de bancos centrales y supervisores
bancarios. En el año 1974, estableció un comité de supervisión bancaria
encargado de generar los estándares mínimos para los países miembros
del grupo de los diez –el G10-. Este comité, si bien no posee ninguna
autoridad de supervisión sobre los países miembros y sus conclusiones no
tienen ninguna fuerza legal, ha formulado una serie principios y
estándares de supervisión bancaria, que han sido acogidos no sólo por los
países miembros del G10, sino por la mayoría de los países del mundo.
En Junio de 2004, el comité de supervisión bancaria de Basilea
publicó el documento conocido como Basilea II, que es el segundo de los
acuerdos de Basilea, que pasó a constituirse como un estándar
internacional y es una referencia para todos los reguladores bancarios. En
sus documentos, el Banco Internacional de Pagos de Basilea establece la
siguiente definición para gobernanza:
3
Capítulo I
“Gobernanza corporativa es un conjunto de relaciones entre

la gerencia de la organización, la junta directiva, los
accionistas y otros grupos de interés. La gobernanza
corporativa provee la estructura a través de la cual se fijan
los objetivos de la organización y los medios para
alcanzarlos, así como también, se determinan los
mecanismos de medición del desempeño. Una buena
gobernanza corporativa debe incentivar apropiadamente a la
junta directiva y a la gerencia a perseguir objetivos que estén
en el interés de la empresa y sus accionistas y debe facilitar
el monitoreo efectivo, estimulando, de esta forma, a las
empresas a utilizar los recursos más eficientemente.”
Vemos pues, que la gobernanza corporativa incluye la distribución de
derechos y responsabilidades de los participantes en una corporación,
tales como directores, gerentes, accionistas y otras partes involucradas o
interesadas –stakeholders-, estableciendo claramente las reglas y
procedimientos para la toma de decisiones en los asuntos corporativos.
Si bien el foco de la gobernanza corporativa está en las finanzas y las
auditorías, también incluye otras funciones corporativas como tecnología
de información, recursos humanos y cumplimiento de requerimientos
ambientales.
Resumiendo, podemos definir la gobernanza empresarial o corporativa
como el conjunto de prácticas y responsabilidades cumplidas por la
dirección ejecutiva de una empresa, con el fin de:
• Proporcionar dirección estratégica
• Asegurar de que los objetivos se cumplen
• Comprobar que los riesgos se administran adecuadamente
• Verificar que los recursos de la organización se utilizan
adecuadamente
Es importante visualizar la diferencia entre gobernanza empresarial y
gestión o administración; podemos decir que la gobernanza empresarial
establece el ambiente donde los gerentes pueden actuar.
Mientras que la administración incluye las actividades de
• Definir normas y formas de comportamiento
• Rendir cuentas
• Velar por una utilización adecuada de los recursos
• Definir de un ciclo de regulación en sus procesos
4
• Establecer una cartera de proyectos

• Responder a las exigencias tanto del gobierno, como de los
usuarios.
La gobernanza, por el contrario, incluye las actividades de:
• Establecer orientación y direccionamiento
• Establecer un marco general para decidir
• Establecer una definición de valores y principios
• Promover ciclos de regulación y adaptación
• Dictar lineamientos estratégicos y tácticos
• Responder a las exigencias de la sociedad y de los accionistas.
• Mirar al futuro y visualizar nuevas oportunidades
1.2.- Gobernanza de TI
Dentro del nuevo concepto de gobernanza corporativa o gobernanza
empresarial, se hizo lógico plantearse que los controles establecidos sobre
la función de tecnología de información deben estar en un nivel
adecuado, puesto que TI es fundamental para el cumplimiento de los
procesos del negocio.
La gobernanza de TI no es una disciplina aislada, sino que es una
parte integral de la gobernanza empresarial o corporativa y tiene como
propósito: establecer el liderazgo, las estructuras organizativas y los
procesos necesarios para asegurar que la TI apoye el logro de los
objetivos y las estrategias de la empresa.
La gobernanza de las tecnologías de información y comunicaciones
constituye una responsabilidad tanto de la gerencia técnica, como de la
directiva de la empresa y puede decirse que:
• Establece la estructura que vincula procesos, recursos e
información de TI con las estrategias y objetivos de la compañía.
• Integra e institucionaliza las mejores prácticas de planificación y
organización, de adquisición e implementación, de entrega y
soporte y de monitorización del desempeño de la función de TI.
Obviamente, este nuevo concepto de gobernanza de TI requiere la
existencia de normas y estándares de uso, por lo que, en el tiempo, han
ido apareciendo varios, entre los cuales debemos mencionar:
• ITIL (Information Technology Infrastructure Library- Biblioteca
de infraestructura de tecnología de información)
5
Capítulo I
• COBIT (Control Objectives for Information and related

Technology – Objetivos de control para la información y la
tecnología relacionada)
• CMM(Capability Maturity Model – Modelo de madurez de la
capacidad)
• ITSEC(Information Technology Security Evaluation Criteria-
Criterios de evaluación de seguridad de la tecnologñia de
información)
• Microsoft Operations Framework -basado en ITIL-.
Cada uno de esos estándares, han hecho enormes contribuciones a la
gobernanza de TI, dentro de su nivel de especialización, haciendo que,
hoy día, el desafío de la gerencia de TI sea hallar la mejor forma de
utilizarlos, combinándolos inteligentemente y aprovechándolos al
máximo.
2.- La administración de servicios de TI
Observamos en el punto anterior que la gobernanza de TI enfatiza la
importancia de la gestión de servicios de TI, en términos de alinear el
soporte a los procesos del negocio, mejorar la calidad de los servicios,
reducir los costos de los servicios, reducir el tiempo de entrega y reducir
los riesgos de TI.
En efecto, la tecnología de información constituye un elemento de
apoyo fundamental de cualquier empresa, para lograr su funcionamiento
eficiente y para materializar y cumplir sus objetivos estratégicos, por lo
que, dada esta dependencia, se hace imprescindible que los servicios de
tecnología de información operen en forma eficaz y eficiente y para ello
es necesario incorporar y aplicar los conocimientos que conforman las
mejores prácticas en el área de gestión de servicios de TI.
El gran desafío que enfrentan los profesionales de la informática es
alinear los servicios de TI con las necesidades del negocio, con eficiencia
y dentro de una relación costo / beneficio razonable.
Todos los esquemas que se han desarrollado y que citamos en el punto
anterior -ITIL, COBIT, CMM, ITSEC, MOF- constituyen un marco de
referencia para organizar el funcionamiento de los procesos de
administración de servicios de TI, todos ellos adoptan un conjunto de
mejores prácticas recogidas por diferentes organizaciones, que se
complementan para describir las disciplinas que permiten administrar
eficaz y eficientemente los servicios de TI, optimizando sus beneficios y
6
garantizando la integración de éstos a la cadena de valor de las unidades

de negocio.
Centenares de organizaciones en el mundo aplican esos marcos de
trabajo, puesto que han sido desarrollados tomando en cuenta la
dependencia creciente que tienen las empresas modernas en la tecnología,
para alcanzar sus objetivos y, porque, además, permiten definir
procedimientos que hagan más eficiente la administración de los servicios
de TI, estableciendo orden y un esquema de trabajo comunes.
Es oportuno señalar, sin embargo, que ninguno de estos marcos de
trabajo constituye una solución por si mismo, pues para lograr sus
objetivos, es necesario adaptarlos a cada empresa en particular e
insertarlos en las operaciones diarias de TI, desarrollando los
procedimientos y el personal de soporte capaz de aplicarlos y ponerlos en
práctica.
3.- ¿Qué es COBIT?
La Asociación para el Control y Auditoría de los Sistemas de
Información (Information Systems Audit and Control Association1) y el
Instituto de Gobernanza de TI (IT Governance Institute2) son las
principales organizaciones que han desarrollado COBIT (Control
Objectives for Information and related Technology - Objetivos de control
para la información y la tecnología relacionada), con el fin de ser
empleado no solamente por los auditores de una empresa, sino también
como una guía integral para lo que se denomina los “dueños de proceso”
y para la gerencia de las empresas.
La dinámica de los negocios requiere, cada vez más, la autonomía de
los dueños de proceso, de tal forma que puedan asumir la responsabilidad
total de todos aspectos del proceso que les corresponde y, a su vez, ello
requiere que se establezcan controles adecuados. Con esa finalidad,
COBIT se ha desarrollado como una herramienta para el dueño de
proceso del negocio, facilitándole el cumplimiento de esas
responsabilidades.
1
Inicialmente fundada como una asociación de auditores -EDP Auditors Association- en
1967, hoy día ISACA tiene más de 65 mil miembros en unos 140 países, incluyendo una
variedad de profesionales relacionados con TI, como auditores de sistemas, consultores,
profesionales de seguridad de TI, reguladores, gerentes de TI, etc. Actualmente existen
alrededor de 170 capítulos de ISACA alrededor del mundo.
2
El ITGI, instituto afiliado a ISACA, fue creado en los Estados Unidos, el año 1998,
reconociendo la importancia que, para las empresas, tiene la función de TI.
7
Capítulo I
COBIT establece un marco de trabajo que parte de una premisa muy

simple y práctica: “el dueño de un proceso y la organización requieren
información para alcanzar sus objetivos, por ello los recursos de TI deben
ser manejados por un conjunto de procesos estructurados
adecuadamente”.
El marco de COBIT establece un sistema que incluye 34 objetivos de
control de alto nivel, uno para cada uno de los procesos de TI, agrupados
en cuatro dominios:
planificación y organización
adquisición e implantación
entrega y soporte
seguimiento o monitorización.
Esta estructura cubre todos los aspectos de la información de una
empresa y de la tecnología que la soporta y estos 34 objetivos de control
permiten que el dueño de un proceso de negocio pueda asegurarse que se
esté ejerciendo un control adecuado sobre la función de TI.
Además, correspondiendo a cada uno de los 34 controles de alto nivel,
COBIT incluye una guía para auditar, que permite revisar la función
de TI contra unos 318 objetivos detallados de control, lo cual, a su vez,
permite ayudar a la gerencia a verificar su cumplimiento o determinar las
mejoras que requieren los procesos para lograrlo.
De más reciente desarrollo son las pautas para la gerencia de
COBIT, que permiten que la gerencia de la empresa pueda manejar con
mayor eficacia las necesidades y los requerimientos de la gobernanza de
TI. Tales pautas para la gerencia de COBIT son genéricas y orientadas a
la acción, con el fin de dar respuesta a preguntas como las siguientes:
• ¿Qué tan lejos debemos ir?
• ¿Está justificado el costo por los beneficios?
• ¿Cuáles son los indicadores de buen funcionamiento?
• ¿Cuáles son los factores críticos del éxito?
• ¿Cuáles son los riesgos de no alcanzar nuestros objetivos?
• ¿Qué hacen otras empresas?
• ¿Cómo medirnos y compararnos?
COBIT también incluye:
8
• Modelos de madurez, para que la gerencia de una organización

pueda tener control sobre los procesos de TI, estableciendo las
brechas entre lo que se tiene en el presente y lo que debiera ser.
• Un conjunto de indicadores que permitan establecer si los
procesos de TI alcanzan sus objetivos de soporte al negocio y si se
están cumpliendo con eficiencia.
• Un sistema de herramientas para llevar COBIT a la práctica,
basadas en las lecciones aprendidas por las organizaciones que lo
han hecho en el pasado.
Para resumir, podemos decir que COBIT ha sido diseñado como una
herramienta que permite que los directivos de una empresa cumplan una
eficaz y eficiente gobernanza de TI y que comprendan los riesgos y
beneficios asociados a la tecnología de información.
4.- ¿Qué es ITIL?
La Biblioteca de Infraestructura de Tecnología de Información
(Information Technology Infrastructure Library - ITIL) fue desarrollada
por la dependencia gubernamental del Reino Unido, denominada Office
of Goverment Comerce (OGC) -Oficina Gubernamental de Comercio-,
hacia finales de 1980. En esta librería se recogieron las mejores
experiencias en el manejo de los servicios de tecnología de información,
para uso del gobierno del Reino Unido. Hoy día, ITIL se ha convertido en
un estándar de facto para la gestión de los servicios de informática, pues
ha demostrado ser de gran utilidad en muchas organizaciones, como base
para organizar y desarrollar los servicios de TI.
ITIL ofrece un enfoque sistemático para la prestación de servicios de
tecnología de información con alta calidad, por lo que las empresas
modernas, que dependen cada vez más de esa tecnología, adoptan con
gran interés el conjunto de disciplinas de servicio que presenta ITIL, con
el fin de que sus servicios de TI realmente apoyen el logro de sus
objetivos y constituyan el respaldo que requiere la eficiencia de sus
operaciones.
Si observamos que la fase de desarrollo e implantación, dentro del
ciclo de vida de los productos y servicios de tecnología de información,
constituye sólo el 30% de los costos y el tiempo, mientras que la fase de
operación de esos servicios ocupa el 70 %, es fácil explicarse la
importancia que tiene la administración eficiente de esos servicios.
9
Capítulo I
4.1.- Los procesos de ITIL

ITIL fue publicado originalmente a fines de 1980, constaba de 10
libros y cubría las áreas de Soporte de Servicios y Prestación de
Servicios. Con los años, ITIL se ha ido convirtiendo en algo más que una
serie de libros sobre los servicios de tecnología de información. Los
libros originales se fueron expandiendo y se le fueron añadiendo libros
complementarios que cubrían una numerosa variedad de temas, desde el
cableado hasta la gestión de la continuidad del negocio.
A partir del año 2000, la OCG acometió una revisión de la biblioteca,
con la participación de consultores, especialistas y proveedores de
tecnología de información, creándose una nueva versión que facilitó el
acceso a la información necesaria para administrar los servicios. En esa
nueva versión, los libros se agruparon en dos áreas: soporte de servicios y
prestación de servicios. En esas dos grandes áreas, se agruparon diversos
procesos íntimamente interrelacionados:
• Procesos de soporte
Escritorio de servicios (Service Desk).
Administración de la Configuración (Configuration
Management).
Administración de Incidentes (Incident Management).
Administración de Problemas (Problem Management).
Administración de Cambios (Change Management).
Administración de la Distribución (Release
Management).
• Procesos de entrega de servicios
Administración de la Capacidad (Capacity
Management).
Administración de la Disponibilidad (Availability
Management).
Administración de la Continuidad (Continuity
Management).
Administración Financiera (Financial Management).
Administración del Nivel de Servicio (Service Level
Management).
10
4.2.- ITIL versión 3

La más reciente versión de ITIL –versión 3- desarrollada el año 2006,
ha ampliado significativamente el alcance de ITIL, presentando una
organización diferente e introduciendo el concepto del ciclo de vida
de los servicios.
La versión 3 de ITIL incluye los siguientes 5 libros, para cada fase del
ciclo de vida:
1. Estrategias de Servicios (Service Strategies)
En esta fase se analizan y comprenden los planes del negocio, para
traducirlos en estrategias de TI que permiten planificar la gestión de
servicios de TI.
2. Diseño de Servicios (Service Design)
En esta fase se diseñan nuevos servicios o se modifican para ser
introducidos en un ambiente de producción. Esto es, incluye el
desarrollo de nuevos servicios y sus procesos relacionados, así como
la modificación de servicios existentes.
3. Transición de Servicios (Service Transition)
En esta fase se crean las estrategias de transición y puesta en
producción de los servicios nuevos o modificados.
4. Operación de Servicios (Service Operations)
En esta fase se cumplen las actividades y procesos requeridos para
que los usuarios del negocio reciban los servicios con el nivel de
calidad requerido.
5. Mejora Continua de Servicios (Continuous Service Improvement -
CSI)
Esta fase centra su atención en la medición y el análisis de los
procesos, con el fin de establecer un adecuado ciclo de mejora
permanente sobre los servicios existentes.
En estas fases del ciclo de vida de los servicios se agrupan las
funciones y procesos de la siguiente forma:
1. Funciones y procesos en la fase de estrategia de servicios
1.1. Administración financiera (Financial Management)
1.2. Administración de la cartera de servicios (Service Portafolio
Management -SPM)
1.3. Administración de la demanda (Demand Management)
11
Capítulo I
2. Funciones y procesos en la fase de diseño de servicios

2.1. Administración del catálogo de servicios (Service Catalogue
Management)
2.2. Administración de niveles de servicio (Service Level
Management)
2.3. Administración de la capacidad (Capacity Management)
2.4. Administración de la disponibilidad (Availability Management)
2.5. Administración de la continuidad de servicios de TI (IT Service
Continuity Management)
2.6. Administración de la seguridad de información (Information
Security Management )
2.7. Administración de proveedores (Supplier Management )
3. Funciones y procesos en la fase de transición de servicios
3.1. Planificación de la transición y soporte (Transition Planning
and Support )
3.2. Administración de cambios (Change Management)
3.3. Administración de la configuración (Service Asset and
Configuration Management)
3.4. Administración de versiones y su implantación (Release and
Deployment Management)
3.5. Validación y prueba de servicios (Service Validation and
Testing)
3.6. Evaluación (Evaluation)
3.7. Administración del conocimiento (Knowledge Management)
4. Funciones y procesos en la fase de operación de servicios
4.1. Administración de eventos (Event Management)
4.2. Administración de Incidentes (Incident Management)
4.3. Atención de requerimietos (Request Fulfillment)
4.4. Administración de problemas (Problem Management)
4.5. Administración de acceso (Access Management)
4.6. Monitorización y control (Monitoring and Control)
4.7. Operaciones de TI (IT Operations)
4.8. Escritorio de servicios (Service Desk)
12
5. Funciones y procesos en la fase de mejora continua de servicios

5.1. Mejora continua de procesos (CS improvement Process)
5.2. Reporte de servicios (Service Reporting)
5.- ¿Qué es ISO 20000?
Con el éxito de ITIL, en año 1991 la organización BSI -British
Standards- promovió la creación de estándares y normas específicas para
tecnología de información y publicó la BS-15000, que con el tiempo ha
dado lugar a las normas ISO 20000, que se han establecido como estándar
internacional para la gestión de servicios de tecnología de información.
ISO 20000, publicado en Marzo de 2006, se basa en dos documentos,
BS15000-1 y BS15000-2, publicados en 2002 y 2003 respectivamente, y
que, a su vez, fueron precedidos por una versión inicial de BS15000-1,
publicada en el año 2000.
Hoy día, el estándar contiene dos partes: ISO/IEC 20000-1 e ISO/IEC
20000-2. La primera parte, ISO 20000-1, es la especificación de la
gestión de servicios y la segunda parte, ISO 20000-2, contiene la
descripción de las “mejores prácticas” en materia de gestión de servicios
de TI.
Los objetivos de la norma ISO 20000 se podrían definir de la siguiente
forma:
• Promover la adopción de procesos integrados para suministrar los
servicios de TI.
• Medir la comprensión y aplicación de las “buenas prácticas”.
• Ayudar a las organizaciones a generar servicios de calidad dentro
de un marco de eficiencia.
Se estima que la norma ISO 20000 será una norma de enorme éxito en
los años venideros, pues:
• Las empresas dependen cada vez más de sus sistemas de TI y
requieren una gestión eficaz y eficiente.
• Las fallas e incidentes cada vez impactan más a las empresas, por
lo que se requiere un sistema de gerencia capaz de manejarlos
adecuadamente.
• Las infraestructuras de TI son cada vez más complejas y se
requiere que sean operadas y administradas eficientemente.
• Poseer la certificación ISO 20000 será una ventaja competitiva y
una referencia positiva muy valorada por los clientes.
13
Capítulo I
El portal de la GSTI, ISO 20000 Central -puede ser visitado en la

dirección internet http://20000.fwtk.org/- ha identificado que la
implementación de las normas ISO 20000 puede derivar beneficios e
introducir mejoras tales como:
• La alineación de los servicios de TI con la estrategia del negocio
• La creación de un marco formal para los proyectos de mejora de
los servicios
• La provisión de un marco de comparación con las mejores
prácticas
• La creación de una ventaja competitiva por medio de la prestación
de servicios consistentes y económicamente eficaces
• La creación de una cultura proactiva, debido a la fijación de
propietarios y responsables de los procesos a todos los niveles
• La reducción de los riesgos y, por lo tanto, reducción de los costos
en términos de la recepción externa de los servicios
• La simplificación en la introducción de cambios organizacionales
importantes por medio de la creación de un enfoque consistente y
normalizado
• La mejora en la reputación y percepción
• El cambio de procesos reactivos a procesos proactivos
• La mejora en las relaciones ínter departamentales por medio de
una mejor definición de responsabilidades y objetivos
A pesar de que entre ITIL e ISO 20000 existe una gran interrelación,
puede observarse que existen importantes diferencias:
• ISO 20000 es certificable; ITIL no, son sólo unas “buenas
prácticas”.
• Para certificar ISO 20000 no es necesario implantar ITIL, pero su
utilización puede hacer el sistema más robusto y más sencillo el
cumplimiento de la normativa ISO 20000.
• La estructuración de la organización no es un requisito de ISO
20000 mientras que la adopción de PDCA (Plan, Do, Check, Act)
es fundamental.
• ISO 20000 incluye relaciones y control de proveedores y
subcontratistas.
• El Plan de Continuidad de Negocio no es obligatorio en ITIL.
14
• ITIL cubre la gestión financiera mientras que ISO 20000 cubre

presupuestos y contabilidad.
• ISO 20000 incluye requerimientos de Seguridad de la Información
(ISO 27001).
Resumiendo, podemos afirmar que uno de los objetivos
fundamentales del modelo ITIL y, por tanto, de las normas ISO 20000 es
estimular la mejora continua de la calidad en la gestión de los servicios de
TI.
Dentro de las normas ISO 20000, se considera la aplicación del
modelo de mejora permanente de la calidad PDCA, conocido como
“Círculo de Deming” o esquema de “Plan-Do-Check-Act”. Este
esquema, originalmente definido por Walter A. Shewhart3 fue
desarrollado y aplicado posteriormente por W. Edward Deming4 en sus
trabajos sobre Calidad Total.
El Ciclo PDCA básico consiste en una serie de cuatro pasos que se
llevan a cabo consecutivamente:
1. P: PLAN (Planear): establecer los planes.
2. D: DO (Hacer): llevar a cabo los planes.
3. C: CHECK (Verificar): verificar si los resultados concuerdan
con lo planeado.
4. A: ACT (Actuar): actuar para corregir los problemas
encontrados.
Un factor importante para lograr esta mejora continua es realizar
comprobaciones periódicas de la calidad de gestión de los servicios de TI.
En tal sentido, la ISO 20000 proporciona una forma de verificar el
comportamiento de una organización en relación con el objetivo de seguir
mejorando la calidad de los servicios.
En ISO 20000, el servicio de TI se divide en 7 subprocesos
integrados:
1. Servicios de entrega y soporte
Incluye los servicios que proporciona la organización TI para
apoyar adecuadamente las funciones del negocio y satisfacer
las necesidades de sus clientes y usuarios: administración de
niveles de servicio, administración de la continuidad y
3
W. A. Shewhart es conocido como el padre del control estadístico de calidad
4
W. Edward Deming, profesor de estadística, fundador de la Calidad Total
15
Capítulo I
disponibilidad, administración de la capacidad,

administración del presupuesto, manejo de incidentes y de
problemas.
2. Servicios de planificación para implementación
Incluye los servicios que la organización de TI planifica para
implementar o actualizar los servicios: administración de
cambios, administración de la entrega de servicio y
administración de implantación.
3. Administración de Seguridad
Incluye los controles de seguridad que se implementan y
mantienen para mitigar el impacto y reducir la posibilidad de
incidentes en relación con el almacenamiento, transmisión y
proceso de la información.
4. Perspectiva de negocio
Se centra en los principios y requerimientos clave de la
organización y operación del negocio: administración de
relaciones de negocio, administración de proveedores y
administración de niveles de servicio.
5. Administración de resolución
Incluye los servicios que se prestan para minimizar los
trastornos al negocio, mediante la detección y análisis
proactivo de causas y definición de acciones para mejorar:
manejo de incidentes, manejo de problemas, administración
de cambios, administración de configuración e informes de
servicio.
6. Administración de proceso de control
Se centra en la administración de cambios y configuración de
servicios para dar soporte al negocio: administración de la
configuración, administración de cambios, manejo de
incidentes y manejo de problemas.
7. Administración de implantación
Se centra en la puesta en marcha de servicios, sistemas,
programas y equipos nuevos o modificados.
16
6.- ¿Qué es CMM?

El Modelo de Madurez de la Capacidad (CMM - Capacity Maturity
Model) fue desarrollado en 1986 por el Instituto de Ingeniería de
Sistemas (SEI) de la universidad Carnegie Mellon. Este modelo describe
un marco de referencia para el desarrollo y mantenimiento de software en
las organizaciones, así como para la adquisición de software.
CMM constituye un modelo en el que el mejoramiento de los procesos
de software se implementa incrementalmente. El modelo CMM puede ser
adaptado y moldeado a cualquier organización en particular, dentro del
marco de los procedimientos que establece.
El modelo CMM se centra en el concepto de madurez de los procesos,
concepto que define como el grado de definición de los procesos y el
grado de cumplimiento de los mismos en el manejo de los proyectos de
software.
En nuestro medio, esos procesos se suelen englobar dentro del término
de metodología de desarrollo y mantenimiento de sistemas; por lo que
podríamos afirmar que la madurez está determinada por el nivel de
claridad y precisión en la definición de la metodología y en el grado de
compromiso que existe dentro de la organización para cumplirla,
utilizarla para establecer los productos o entregables y ajustar los planes,
de tal manera que los proyecto sea controlables.
En el año 2002, el CMM fue reemplazado por una nueva versión,
Integración de Modelos de la Madurez de las Capacidades (Capacity
Maturity Model Integration).
Al igual que para CMM, la principal premisa de CMMI es que “La
calidad de un producto la determina de manera importante la calidad del
proceso que se sigue para desarrollarlo y mantenerlo”
Hoy día, CMMI es un modelo de referencia sobre buenas prácticas
maduras, consolidadas, y probadas para el desarrollo y mantenimiento de
productos y servicios, cubriendo todo el ciclo de vida, desde la
concepción hasta la instalación y mantenimiento. Integra la Ingeniería de
Software, la Ingeniería de Sistemas y la Adquisición de Productos y
Servicios.
CMMI es:
• Un guía para mejorar los procesos y comprobar la capacidad de un
grupo al ejecutarlos
• Un modelo de madurez, esto es, de directrices, prácticas y
disciplinas basadas en las mejores prácticas de la industria.
17
Capítulo I
•Un marco de referencia para calificar y diagnosticar el progreso de

una organización.
• Indica qué deben hacer los procesos, no cómo deben hacerlo.
CMMI no es:
• Una metodología de desarrollo o dirección de proyectos.
• NO compite con metodologías de desarrollo como RUP, TOGAF,
etc.
• NO compite con PMBOK del PMI ni con PRINCE 2 u otras
disciplinas de administración de proyectos
• No es un estándar de procesos.
CMMI, en muchas empresas se complementa con otros modelos,
como los que arriba hemos citado.
6.1.- Niveles en CMMI
El modelo CMMI establece varias etapas dentro de la evolución de los
procesos de desarrollo y mantenimiento de software:
1. Inicial:
Las organizaciones que están en esta etapa, se caracterizan por
tener procesos desorganizados, poco predecibles y que no pueden
ser controlados adecuadamente.
Los procedimientos, cuando existen, se abandonan en momentos
de crisis y no hay la capacidad para derivar experiencias y repetir
los procesos que hayan resultado exitosos.
El éxito de los proyectos depende casi exclusivamente de las
capacidades individuales
2. Gestionado:
En esta etapa, las organizaciones utilizan la ingeniería de
software para establecer los procesos básicos de dirección de
proyectos, para planificar, para controlar los costos y asegurar la
calidad de los productos.
Entre las disciplinas que se aplican en esta etapa están:
Administración de requerimientos
Planificación de proyectos
Seguimiento y control de proyectos
Administración de acuerdos con proveedores
Aseguramiento de la calidad de procesos y productos
18
Administración de la configuración
3. Definido:
En esta etapa las organizaciones han definido y documentado los
estándares y procedimientos de desarrollo y mantenimiento y,
adicionalmente, todos los proyectos siguen un proceso estándar
para desarrollar y mantener software.
En esta etapa se añaden diferentes disciplinas como:
Desarrollo de requerimientos
Integración de productos
Verificación
Validación
Administración integrada de proyectos
Administración de riesgos
Administración integrada de proveedores
4. Cuantitativamente Gestionado:
En esta etapa, adicionalmente a las definiciones realizadas en la
etapa anterior, los productos y las actividades se miden y evalúan
cuantitativamente. Se mide la calidad y la efectividad del
proceso, a través de criterios cuantitativos, y se verifica el
cumplimiento de los objetivos de negocio
Medición del desempeño de los procesos en la
organización
Administración cuantitativa de proyectos
5. En Optimización:
Esta etapa se caracteriza por la mejoría cuantificable y continua
de las prácticas de desarrollo y mantenimiento, mediante la
retroalimentación de las mediciones y la realización de proyectos
piloto destinados a evaluar nuevas ideas y tecnologías.
Innovación y despliegue organizativo
Análisis causal
Las claves para implementar exitosamente CMMI son:
Involucrar a los ejecutivos de la empresa
19
Capítulo I
No perder de vista los objetivos de negocio y

revisarlos periódicamente
Aprovechar estas iniciativas para mejorar
realmente los procesos
Involucrar a los afectados por el proceso
Hacerlos partícipes de las decisiones
Crear una cultura de mejora
Definir procedimientos simples y útiles, que
aporten verdadero valor a la gente que los usa
Aprovechar prácticas que sabemos que funcionan
para nosotros
Educación y formación
Sesiones de formación, tanto formales como
informales
Considerar las nuevas capacidades y los
conocimientos que serán requeridos.
Comunicación interna y externa
Buscar el apoyo de consultores y otros grupos de la
organización
Cumplir un plan de comunicación
7.- ¿Qué es MOF?
El marco de operaciones de Microsoft (Microsoft Operations
Framework - MOF) es un conjunto de prácticas recomendadas por
Microsoft, a partir de las cuales se pueden diseñar los procedimientos,
controles y funciones necesarios para que la infraestructura de TI pueda
ser administrada con eficacia.
MOF está basado en la Biblioteca de infraestructuras de TI (ITIL) y
está orientada a la plataforma de Microsoft.
MOF ofrece directrices sobre la forma de planificar, implementar y
mantener los procesos operativos de TI que respaldan las soluciones de
servicio críticas. MOF es un modelo genérico y, por este motivo, debe
adaptar muchas de las recomendaciones para usarlas en una empresa en
particular.
20
MOF es un modelo estructurado y flexible que está basado en lo

siguiente:
• Los equipos de consultoría y soporte técnico de Microsoft y sus
experiencias de trabajo con clientes empresariales y socios,
además de grupos internos de operaciones de TI en Microsoft.
• La Biblioteca de infraestructuras de TI (ITIL), que describe los
procesos y las prácticas recomendadas necesarios para el
suministro de soluciones de servicio críticas.
• ISO/IEC 15504, de la Organización Internacional de
Normalización (ISO), que proporciona un enfoque normalizado
para evaluar la madurez del proceso de software.
Los detalles que integran el marco MOF pueden obtenerse en forma
gratuita en la siguiente dirección de internet:
https://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx
8.- Principales disciplinas de administración de TI

La administración de servicios de TI consiste en la administración de
todos los componentes de la infraestructura de una organización e incluye
las tareas administrativas diarias, planificadas y a solicitud, necesarias
para que el sistema de TI funcione correctamente.
Todas las tareas de administración de operaciones se deben describir

mediante procedimientos escritos, con el fin de que todos los empleados
21
Capítulo I
de soporte sigan los mismos métodos, utilicen las herramientas

convenientemente y cumplan con los estándares.
Independientemente del marco de referencia que se utilice, puede
decirse que el conjunto de disciplinas de administración de servicios de
tecnología de información está conformado por las siguientes:
1. Centro de atención
2. Manejo de incidentes
3. Manejo de problemas
4. Administración de la configuración
5. Administración de versiones
6. Administración de cambios
7. Monitorización y control
8. Administración de niveles de servicio
9. Administración financiera de los servicios TI
10. Administración de la capacidad
11. Administración de la continuidad de los servicios TI
12. Administración de la disponibilidad
13. Administración de la seguridad de información
Es muy importante destacar que la mayoría de las disciplinas
mencionadas no podrá ser implementada correctamente si no se cuenta
con el apoyo de las herramientas adecuadas, especialmente las disciplinas
de centro de atención, administración de configuraciones y
monitorización y control.
Afortunadamente en el mercado existe una amplia oferta de paquetes
de software de gran calidad, que ofrecen diferentes capacidades y
facilidades. Entre ellos, podemos citar los siguientes:
• Tívoli de la empresa IBM
• Unicenter y otros productos de la empresa Computer Associates
• Vantage y otros productos de la empresa Compuware
• HP Service Management Center
• HP OpenView
• Patrol y otros productos de la empresa BMC
• LANDesk Software
• Axios Systems
22
• OpTier's CoreFirst
8.1.- Centro de atención
El centro de atención a los usuarios constituye el centro de las
comunicaciones de los usuarios con la función de TI, por lo que es el
punto más crítico en la construcción de una buena relación con el cliente.
El objetivo principal de un centro de atención es servir como punto de
contacto entre los usuarios y la gerencia de servicios TI. En su
concepción más moderna, también debe funcionar como punto de enlace
de todos los procesos destinados a dar soporte al usuario:
• Registrando y haciendo seguimiento de todas las llamadas
recibidas de los usuarios.
• Aplicando soluciones temporales a los errores conocidos,
integrándose, de esta forma, con la disciplina de manejo de
incidentes.
• Tramitando los cambios solicitados por los usuarios,
mediante peticiones de servicio, integrándose, de esta forma,
con las disciplinas de administración de cambios y de
versiones.
8.2.- Manejo de incidentes
Es la disciplina orientada a la restauración rápida del servicio,
clasificando los incidentes y haciendo seguimiento de la solución de los
incidentes. El manejo de incidentes guarda una estrecha relación con la
disciplina de manejo de problemas, pero a diferencia de ésta, no se ocupa
de analizar e identificar las causas que puedan haber causado un
determinado incidente, sino que, como ya apuntáramos, centra su
atención exclusivamente en restaurar el servicio.
Establece la forma de:
• Identificar
• Analizar
• Corregir
• Hacer seguimiento
• Recuperar la operación normal
23
Capítulo I
8.3.- Manejo de problemas

Es la disciplina orientada a la prevención y solución de los problemas
que presenten los servicios de TI, controlando los problemas y errores, y
actuando proactivamente ante los estos.
Incluye Políticas y Procedimientos de:
• Detección
• Registro
• Seguimiento
8.4.- Administración de la configuración
Esta disciplina tiene como objetivo controlar los activos de TI:
• Manteniendo un control detallado de todos los componentes
de la infraestructura TI, tanto hardware como software,
almacenando esa información en una base de datos de
configuración – inventario de hardware y software-.
• Suministrando información actualizada sobre la
configuración de la infraestructura de TI, para el
cumplimiento de los diferentes procesos de administración de
servicios.
8.5.- Administración de versiones
La administración de versiones es la disciplina que centra su atención
en la implementación y en el control de calidad de todo el software y
hardware instalado o a ser instalado en el ambiente de producción.
La administración de versiones se integra con las disciplinas de
administración de cambios y de configuraciones, para asegurar que toda
la información relativa a las nuevas versiones se integra adecuadamente
en la base de datos de administración de configuraciones, de forma que
ésta se halle correctamente actualizada y ofrezca una imagen real de la
configuración de la infraestructura TI.
8.6.- Administración de cambios
Dentro del ámbito de TI el cambio es constante: nuevas aplicaciones,
cambios en las aplicaciones, entonación de sistemas, crecimiento,
actualización tecnológica, corrección de problemas, prevención de
problemas, cambios por requerimientos legales, cambios por
requerimientos del negocio.
24
Esta disciplina tiene como objetivos:

• Evaluar el impacto (consecuencias) de un cambio
• Asegurar la participación coordinada de todas las unidades
afectadas por un cambio
• Evitar cualquier posible falla en la implantación
• Prevenir interrupciones en el servicio como consecuencia de un
cambio
Establece los procedimientos para:
• Solicitar e informar un cambio
• Evaluar el impacto y categorizar los cambios (urgentes, de menor
impacto, severos, etc.)
• Justificar y aprobar
• Coordinar
• Implantar
• Controlar la calidad
8.7.- Monitorización y control
Se entiende como monitorización a la observación continua del
comportamiento de los elementos que integran la infraestructura
tecnológica, a los fines de detectar cualquier cambio en ese
comportamiento.
• Mantener un seguimiento del funcionamiento de los diferentes
componentes de la infraestructura tecnológica.
• Reportar los cambios que se identifiquen en ese funcionamiento,
con el fin de que puedan iniciarse las acciones correctivas que
pudiesen ser necesarias.
8.8.- Administración de niveles de servicio
• Definir el nivel de calidad del servicio que requiere cada usuario
• Crear compromisos formales o acuerdos de servicio suscritos
conjuntamente con los usuarios.
• Controlar el cumplimiento de los compromisos
• Incluye procedimientos para:
25
Capítulo I
• Negociar y establecer el nivel de calidad para los servicios

que requiere cada usuario, dentro del marco de las prioridades
del negocio y de las capacidades del centro de computación.
• Desglosar dichos servicios en niveles mesurables y
cuantificables (oportunidad de los resultados, disponibilidad
de la aplicación, tiempos de respuesta, período de proceso,
horario de proceso, etc.).
• Determinar los factores que favorecen o desfavorecen los
niveles de servicio.
• Hacer seguimiento al cumplimiento de los niveles de servicio
prestados.
8.9.- Administración financiera de los servicios TI
Esta disciplina permite tener una correcta comprensión de los costos
de los servicios de TI y facilita la:
• Elaboración de presupuestos
• Identificación de elementos de costo y sus categorías
• Estimación y seguimiento de los costos
8.10.- Administración de la capacidad
Esta disciplina permite asegurar el crecimiento ordenado de la
instalación y evitar los problemas que podrían ocasionarse por carencia
de los equipos necesarios
Incluye procedimientos para:
• Definir y cuantificar la carga de trabajo
• Evaluar el consumo actual de recursos
• Pronosticar el crecimiento
• Justificar la adquisición de nuevos equipos
8.11.- Administración de la continuidad de los servicios TI
Esta disciplina permite preparar al centro de computación para
garantizar la continuidad de sus operaciones aún cuando alguna catástrofe
(como incendio, inundación o terremoto, etc.) haya destruido parcial o
totalmente sus instalaciones.
La disciplina incluye procedimientos para:
• Identificar riesgos
26
• Identificar aplicaciones críticas

• Identificar archivos críticos
• Identificar componentes críticos de hardware, software y
telecomunicaciones
• Determinar formas alternas de proceso para aplicaciones críticas
• Definir equipos de contingencia
• Asegurar los respaldos correctos a las bibliotecas y los archivos
críticos
• Almacenar los respaldos fuera de la instalación
• Trazar los planes de contingencia
• Probar periódicamente los planes de contingencia (simulacros)
8.12.- Administración de la disponibilidad
La administración de la disponibilidad es la disciplina responsable de
optimizar y monitorizar los servicios TI, con el fin de que estos funcionen
ininterrumpidamente, en forma confiable, cumpliendo los acuerdos de
servicio, a un costo razonable.
La satisfacción del cliente y la rentabilidad de los servicios TI
dependen en gran medida de la efectividad con que se cumpla esta
disciplina.
Incluye procedimientos para:
• Cálculo y monitorización de la disponibilidad
• Planificación, monitorización e información
8.13.- Administración de la seguridad de información
La administración de la seguridad es la disciplina que vela por la
integridad de la información; para que esta sea correcta y completa, esté
siempre a disposición de los procesos del negocio y sea utilizada sólo por
aquellos funcionarios que tengan autorización para hacerlo.
27
Capítulo I
28
Capítulo II
Ce nt ro de At e nc ión
Capítulo II
Centro de atención
Tabla de contenido
1.- ¿Qué es un centro de atención a usuarios? .................................31

1.1.- Ventajas .............................................................................32
1.2.- Barreras..............................................................................32
2.- Modalidades ...............................................................................32
3.- Planificación ...............................................................................33
4.- Facilidades ..................................................................................34
5.- Estructura....................................................................................35
6.- Actividades .................................................................................36
6.1.- Atención de llamadas.........................................................36
6.2.- Cierre del reporte ...............................................................37
6.3.- Manejo desde inicio hasta cierre........................................40
6.4.- Centro de información .......................................................40
6.5.- Actividades adicionales .....................................................41
7.- Evaluación de la disciplina .........................................................41
30
Centro de atención
Centro de atención
1.- ¿Qué es un centro de atención a usuarios?

El objetivo principal de un centro de atención es servir como punto de
contacto entre los usuarios y la gerencia de servicios TI. En su
concepción más moderna, también debe funcionar como punto de enlace
de todos los procesos destinados a dar soporte al usuario:
• Registrando y haciendo seguimiento de todas las llamadas
recibidas de los usuarios.
• Aplicando soluciones temporales a los errores conocidos,
integrándose, de esta forma, con la disciplina de manejo de
incidentes.
• Tramitando los cambios solicitados por los usuarios, mediante
peticiones de servicio, integrándose, de esta forma, con las
disciplinas de administración de cambios y de versiones.
31
Capítulo II
Para el buen desenvolvimiento de las operaciones del negocio, es

importante que los usuarios perciban que están recibiendo una atención
personalizada y ágil:
Al solicitar soporte técnico en el uso de los recursos
informáticos.
En la solución rápida de las fallas y las interrupciones
del servicio.
Es importante observar que la disciplina de centro de atención también
juega un papel importante en el soporte al negocio, pues permite
identificar nuevas oportunidades para la gerencia de TI, a través de su
contacto con los usuarios.
1.1.- Ventajas
Los principales beneficios de la correcta implementación de un centro
de atención pueden resumirse en:
• Mejor atención al usuario que repercute en un mayor grado de
satisfacción.
• Identificación de nuevas oportunidades para apoyar al negocio.
• Centralización de procesos que mejoran la gestión de la
información y la comunicación.
• Soporte diligente al servicio
1.2.- Barreras
La implantación de un centro de atención puede tropezar con una serie
de barreras como las que a continuación enumeramos:
• No se adoptan facilidades adecuadas de comunicación, en
calidad y cantidad.
• No se adecuan las facilidades de oficina para que el personal
técnico pueda atender con comodidad las llamadas de los
usuarios.
• No se adiestra adecuadamente al personal.
• No se establecen protocolos de comunicación con los
usuarios o no se instruyen adecuadamente al personal.
2.- Modalidades
El contacto con el usuario puede adquirir diversas modalidades,
dependiendo de la amplitud de los servicios que se piensen ofrecer:
• Call center:
32
Centro de atención
Su objetivo es gestionar un alto volumen de llamadas y

dirigir los requerimientos de los usuarios a las unidades de
soporte que correspondan, de acuerdo con la naturaleza de la
llamada, con la excepción de los casos más triviales.
• Centro de ayuda (Help Desk):
Su principal objetivo es similar al del call center (recibir
todas las llamadas e los usuarios), pero adicionalmente, busca
ofrecer una primera línea de soporte técnico que permita
resolver en el menor tiempo posible las interrupciones del
servicio y canalizar aquellos requerimientos más complejos
hacia las unidades de soporte que correspondan
• Centro de servicios (Service Desk):
Es el centro de comunicación entre usuario y todos los
servicios de TI ofrecidos por la organización, pues además de
ofrecer los servicios que ofrecen las dos modalidades
anteriores, ofrece servicios adicionales a los usuarios y la
organización TI, tales como:
Supervisar los contratos de mantenimiento.
Administrar las licencias de software.
Supervisar los acuerdos de servicio con los
usuarios.
• Línea caliente para clientes (Customer Hot Line):
Una línea caliente normalmente está dedicada a atender las
llamadas de los clientes de la empresa (externos a la
organización), para solicitar asistencia o presentar quejas o
problemas en relación con los productos o servicios que la
empresa mercadea.
3.- Planificación
La implementación de un centro de atención requiere una meticulosa
planificación. Como primer paso debe establecerse:
• ¿Cuáles son las necesidades?
• ¿Qué tipo de centro se desea? call center, centro de ayuda o centro
de servicios.
• ¿Cuáles serán sus funciones?
• ¿Quiénes serán los responsables del mismo?
33
Capítulo II
• ¿Qué calificaciones profesionales deberán tener sus integrantes?

• ¿Cómo se prestará el servicio técnico? ¿con personal y recursos
propios o utilizando un proveedor de este tipo de servicios?
• ¿Qué estructura queremos darle al centro de atención?
¿centralizado o descentralizado?
• ¿En qué horarios deberá funcionar el centro de servicios?
• ¿Qué herramientas tecnológicas de apoyo se requieren?
• ¿Qué métricas serán utilizadas para evaluar el desempeño del
centro de atención?
Adicionalmente, será muy importante preparar charlas, cursos y guías
de trabajo para el personal, de tal forma que en todo momento se
establezca una interacción respetuosa y amable con el cliente (usuario).
Recíprocamente, será siempre importante desarrollar material de
divulgación para los usuarios, de tal forma que estos conozcan cómo
operará el centro y qué deben esperar de este servicio.
Un activo muy importante para un centro de atención serán los
protocolos de comunicación con los usuarios, que facilite la
identificación de los problemas, su posible solución y la ruta que debe
seguir si el problema requiere ser escalado hacia otros grupos de soporte.
Será también fundamental establecer los procedimientos de
seguimiento a las llamadas que se transfieran a otras instancias de
soporte, con el fin de asegurar que cualquier llamada que haya recibido el
centro sea atendida adecuada y rápidamente.
4.- Facilidades
Hoy día existen innumerables facilidades para que un centro de
atención pueda funcionar eficientemente:
1. Dispositivos de comunicación, como los ACD (automatic call
distribution), que permiten administrar eficientemente el flujo de las
llamadas y su atención ordenada, o como las facilidades de correo de
voz.
2. Paquetes de software que permiten apoyar la operación de un centro
de atención. Estos paquetes ofrecen facilidades para registrar cada
llamada recibida y dejar la huella de todas las acciones tomadas,
hasta el momento de su cierre, en que el usuario exprese su
aceptación de la solución recibida, lo cual permite que los
supervisores del centro de atención puedan hacer seguimiento de los
34
Centro de atención
problemas reportados que aun no hayan recibido una solución

definitiva.
Estos paquetes de software, normalmente asociados al tipo de
sistemas que se denominan de CRM (Customer Records
Management), también incluyen facilidades para que, a través de la
disciplina de administración de la configuración, se actualice el
inventario de hardware y software, para que, de esta forma, el técnico
del centro de atención, al atender una llamada de un usuario, puede
consultar al sistema y conocer todo el software y los dispositivos que
ese usuario pueda tener instalados en su estación de trabajo.
3. Facilidades para prestar soporte de forma remota. Aunque el usuario
esté en una localidad lejana, el técnico de soporte, con la autorización
del usuario, puede tomar control de la estación de trabajo del usuario
y aplicar los correctivos que pudieran ser necesarios.
En general, la meta debe ser implantar un centro de servicios dotado
de herramientas y gobernados con procedimientos que le permitan
alinearse con los procesos de negocio, mejoren la satisfacción de los
clientes (usuarios), optimicen la imagen externa de la organización de TI
y se constituyan en una fuente de información para identificar nuevas
oportunidades de servicio y formas de mejorarlo.
5.- Estructura
Como arriba señaláramos, el centro de atención es el punto de
contacto central de toda la organización TI con sus clientes y usuarios.
Por tal razón es imprescindible que:
• Sea fácilmente accesible.
• Ofrezca un servicio de calidad, consistente y homogéneo.
• Informe a los usuarios (dar un “feed back” adecuado) y lleve un
registro de toda la interacción con los mismos.
• Acumule experiencias, para atender con mayor eficacia los casos
similares que puedan presentarse en el futuro
Para cumplir estos objetivos es necesario implementar una adecuada
estructura organizativa y de procedimientos; así mismo, los integrantes
del centro de servicios deben:
• Conocer todos los protocolos de interacción con el cliente:
guiones, listas de chequeo, etc.
• Disponer de herramientas de software que les permitan llevar un
registro de la interacción con los usuarios.
35
Capítulo II
• Estar informados acerca de los criterios para escalar a instancias

superiores.
• Tener acceso rápido a las bases de datos de inventario de
hardware y software, así como a las bases de conocimiento
(lecciones aprendidas), para ofrecer un mejor servicio a los
usuarios.
• Recibir entrenamiento continuo sobre los productos y las
facilidades instalados en la empresa.
Dependiendo de las características de la empresa y del servicio que se
desee brindar, el centro de atención puede tener un perfil organizativo
diferente: centralizado, descentralizado o mixto. Todo ello dependerá de:
• Si los usuarios se encuentran en diversas localidades geográficos
• Si están involucrados diferentes idiomas, productos y servicios.
• Si los usuarios trabajan en diferentes horarios.
• Si se necesita dar algunos de los servicios de mantenimiento o
atención en el lugar donde esté el usuario.
La estructura centralizada es la estructura más común, aun para
empresas que, como los bancos, tienen usuarios dispersos en diferentes
localidades. Las ventajas son obvias, pues pueden aprovecharse mejor los
recursos humanos y resulta mucho más fácil mantenerlo actualizado.
Hoy día, dadas las grandes capacidades de los canales de
comunicación, existe una tendencia creciente a tercerizar (outsorcing)
parte de los servicios de soporte, dejando principalmente en la empresa
las funciones de monitorización y medición de los servicios prestados por
el proveedor, así como la supervisión de los contratos de mantenimiento
y niveles de servicio y la administración de las licencias de software.
6.- Actividades
6.1.- Atención de llamadas
Como puede verse en las gráficas que se muestran en las páginas
siguientes, las principales actividades que cumple un centro de atención
son:
1. Recibir las llamadas de los usuarios y registrarlas en la base de datos.
2. Asignar un código identificador a cada llamada registrada. Este
código se acostumbra a informárselo al usuario, con el fin de que, en
caso de cualquier reclamo u observación, se haga referencia al
mismo.
36
Centro de atención
3. Revisar la base de datos de configuraciones, con el fin de conocer en

detalle los componentes que el usuario tiene instalados en su estación
de trabajo.
4. Siguiendo los protocolos establecidos para ello, solicitar al usuario
toda la información posible sobre el problema o la falla que reporta,
con el fin de poder encontrar la solución adecuada.
5. Si se estima que el problema puede estar en la estación de trabajo,
tratar de guiar al usuario telefónicamente, para que el mismo
resuelva la falla.
6. En caso de que no sea posible, tomar el control de la estación de
trabajo del usuario y aplicar los correctivos que puedan ser
necesarios. Existen instalaciones en las que no se utilizan estas
facilidades y en su lugar la acción alternativa es enviar a un técnico
de soporte, para que aplique directamente en la estación de trabajo,
los correctivos que puedan ser necesarios.
7. En caso de fallas que no son de la estación de trabajo o que no
pueden ser corregidas por el técnico del centro de atención, se
procede a escalar el reporte a otras instancias, como técnicos de
soporte o analistas de sistemas, dejando registrado el problema en la
base de datos, con el estatus de pendiente.
6.2.- Cierre del reporte
Una de las tareas centrales de la disciplina es hacer el seguimiento de
los reportes que están pendientes, de tal forma que ninguno pueda quedar
desatendido.
Una vez que una falla reportada ha sido resuelta, se deberá cambiar el
estatus del reporte en la base de datos, de pendiente a resuelta.
El supervisor del centro de atención se encargará de verificar con el
usuario que los problemas que se han reportado como resueltos, lo haya
sido a su entera satisfacción. En caso afirmativo, el supervisor cambiará
el estatus en la base de datos, de resuelto a cerrado. En caso negativo, el
supervisor acordará con los técnicos correspondientes las acciones que
deben ser tomadas y reversará el estatus del reporte, de resuelta a
pendiente con alta prioridad.
37
Capítulo II
38
Centro de atención
39
Capítulo II
6.3.- Manejo desde inicio hasta cierre

Independientemente de que la solución de los problemas que le hayan
sido reportados requiera la atención de otros departamentos y personal, el
centro de atención debe ofrecer una primera línea de soporte para la
solución de las fallas, interrupciones de servicio o solicitudes de servicio
que puedan presentar los clientes y usuarios.
Entre sus tareas específicas se incluyen:
• Registrar cada incidente o requerimiento y hacer seguimiento al
progreso de su solución.
• Seguimiento de los requerimientos escalados.
• Cierre del incidente y confirmación con el cliente.
6.4.- Centro de información
El centro de atención debe ser la principal fuente de información de
los clientes y usuarios, informando sobre nuevos servicios y el
lanzamiento de nuevas versiones para la corrección de errores. Este
contacto directo con los clientes debe servir también para identificar
nuevas oportunidades de servicio, evaluar las necesidades de los clientes
y su grado de satisfacción con el servicio prestado.
El centro de atención se encuentra en una situación inmejorable para
ofrecer también información privilegiada a todos los procesos de gestión
40
Centro de atención
de los servicios TI. Para ello es imprescindible que se lleve un registro

minucioso de toda la interacción con los usuarios y clientes.
6.5.- Actividades adicionales
En algunas empresas, el centro de atención también es responsable de
la relación con algunos proveedores de servicios y de productos de
hardware y software, por lo que es fundamental que mantenga una
estrecha relación con los representantes y responsables externos de su
mantenimiento.
7.- Evaluación de la disciplina
La mejor medida del éxito de un centro de atención es la satisfacción
del cliente, aunque ésta, obviamente, no sea responsabilidad exclusiva del
centro. Es importante establecer métricas simples y bien definidas que
permitan medir y calificar el desempeño del centro de atención, tales
como:
• Tiempo promedio de respuesta a las solicitudes recibidas a través
de los diferentes medios de comunicación (teléfono, correo
electrónico, correo de voz, fax, etc.)
• Porcentaje de incidentes que se cierran en primera línea de
soporte.
• Porcentaje de consultas respondidas en primera instancia.
• Análisis estadísticos de los tiempos de resolución de incidentes
organizados según su urgencia e impacto.
• Número y porcentaje de llamadas escaladas a otras instancias de
soporte.
• Grado de satisfacción de usuarios y/o clientes, que puede
determinarse mediante encuestas periódicas, que permitan
cuantificar la percepción del usuario con respecto a los servicios
recibidos.
41
Capítulo II
42
Capítulo III
Capítulo III
Tabla de contenido
1.- ¿En qué consiste el manejo de incidentes? .................................45

1.1.- Ventajas .............................................................................47
1.2.- Barreras..............................................................................47
2.- Requerimientos...........................................................................48
3.- Clasificación de los incidentes ...................................................48
4.- Escalamiento y soporte...............................................................49
5.- Actividades .................................................................................50
5.1.- Registro de incidentes ........................................................50
5.2.- Clasificación de los incidentes...........................................51
5.3.- Análisis, Resolución y Cierre de Incidentes ......................52
44
1.- ¿En qué consiste el manejo de incidentes?

Un incidente es cualquier interrupción no planeada de cualquier
servicio de TI y la disciplina de manejo de incidentes busca restaurar ese
servicio de la manera más rápida y eficaz posible.
El manejo de incidentes guarda una estrecha relación con la disciplina
de manejo de problemas, pero a diferencia de ésta, no se ocupa de
analizar e identificar las causas que puedan haber causado un
determinado incidente, sino que, como ya apuntáramos, centra su
atención exclusivamente en restaurar el servicio. Es claro, sin embargo,
que si bien son diferentes, guardan una estrecha interrelación.
45
Capítulo III
En líneas generales, los objetivos del manejo de incidentes son:

• Detectar cualquiera alteración en los servicios TI.
• Registrar y clasificar esas alteraciones.
• Asignar el personal encargado de restaurar el servicio.
Es importante destacar que el cumplimiento de las actividades de esta
disciplina requiere un estrecho contacto con los usuarios, por lo que la
coordinación con el centro de atención juega un papel esencial en su
desarrollo.
Normalmente, el concepto de incidente se asocia con algún

funcionamiento inadecuado de los componentes de hardware o software;
sin embargo, en ITIL se define como un incidente a “Cualquier evento
que no forma parte de la operación estándar de un servicio y que causa,
o puede causar, una interrupción o una reducción de calidad del mismo”.
Casi cualquier llamada que recibe el centro de atención puede
clasificarse como un incidente, incluyendo las solicitudes de servicio
tales como mudanza de equipos, solicitud de nuevas licencias, etc.
46
siempre que la solicitud corresponda a uno de los servicios que se

consideren estándar de la organización.
Cualquier cambio que deba ser aplicado en cualquier elemento de de
la infraestructura de TI requiere la elaboración de una solicitud de cambio
que deberá ser tratada según los procedimientos de la administración de
cambios.
1.1.- Ventajas
Las principales ventajas de una adecuada implementación de la
disciplina de manejo de incidentes son:
• Se mejora la productividad de los usuarios.
• Se vela por el cumplimiento de los niveles de servicio acordados
con los usuarios.
• Se optimiza la utilización de los recursos disponibles.
• Se dispone de una base de datos de incidentes precisa, con los
incidentes relacionados a cada uno de los componentes de la
infraestructura.
• Se puede lograr una mayor satisfacción de los usuarios y clientes.
Por el contrario, la carencia de un adecuado manejo de incidentes
puede significar:
• Un deterioro de los niveles de servicio.
• Utilización ineficiente de los recursos.
• Pérdida de información valiosa información sobre las causas y
efectos de los incidentes para poder mejorar la infraestructura de
TI.
• Proliferación de clientes y usuarios insatisfechos por la mala y/o
lenta atención de sus incidentes.
1.2.- Barreras
Entre las principales barreras con que tropieza la implantación de una
disciplina manejo de incidentes pueden citarse las siguientes:
• No se siguen los procedimientos previstos.
• Se resuelven los incidentes sin registrarlos adecuadamente.
• Los incidentes se escalan innecesariamente.
• No están bien definidos los niveles de calidad de servicio ni los
productos soportados, lo que puede provocar que se atiendan
47
Capítulo III
incidentes que no corresponden a los servicios estándar o que no

han sido acordados previamente con el cliente.
2.- Requerimientos
El manejo de incidentes requiere de una infraestructura que facilite su
correcta implementación. Entre los elementos necesarios cabe destacar
los siguientes:
• El sistema de registro de incidentes, para ser compartido con la
disciplina de centro de atención.
• Una base de conocimiento, que permita comparar los nuevos
incidentes que se reportan, con incidentes ya resueltos en el
pasado, con el fin de:
Evitar transferir innecesariamente los incidentes que se
reciban.
Convertir el conocimiento –know how- de los técnicos
en un activo duradero para la empresa.
Poner directamente a disposición del cliente parte o la
totalidad de estos conocimientos en forma de “preguntas
frecuentes” –FAQs- en la intranet para los usuarios
internos de la empresa o en la extranet para los clientes,
con el fin de que en algunas oportunidades sea el propio
usuario quien aplique el correctivo, sin necesidad de
notificar el incidente.
• Una base de datos del hardware y software instalado, que permita
conocer todas las configuraciones actuales y el impacto que éstas
puedan tener en la resolución del incidente.
3.- Clasificación de los incidentes
Es frecuente que se presenten múltiples incidentes concurrentemente,
por lo que es necesario determinar la prioridad para atender la resolución
de los mismos y asignar los recursos para atender los incidentes de mayor
prioridad. El nivel de prioridad debe basarse en dos parámetros
esenciales:
• Impacto
El impacto de un incidente está determinado por la forma
cómo éste afecta los procesos de negocio o por la cantidad de
usuarios afectados.
• Urgencia
48
La urgencia de un incidente depende del tiempo máximo de

que el usuario o el cliente puede esperar para la resolución
del incidente, sin que la operación de su área del negocio
sufra consecuencias importantes. La urgencia también
depende de los niveles de servicio que hayan sido acordados
con el usuario o cliente.
Para la clasificación de un incidente, además de los parámetros arriba
citados, también se hace necesario tomar en cuenta factores como el
tiempo de resolución esperado y los recursos necesarios para atender el
incidente. Así pues, aunque en algunos casos no sean de mayor prioridad,
los incidentes “sencillos” se tramitarán cuanto antes.
Es conveniente establecer criterios claros para establecer, en primera
instancia, la prioridad del incidente; el “diagrama de prioridades” que se
muestra en la gráfica es un ejemplo de cómo pueden establecerse esos
criterios.
4.- Escalamiento y soporte

Es frecuente que el centro de atención no tenga la capacidad de
resolver en primera instancia un incidente, por lo que debe recurrir a un
especialista o a algún superior que pueda tomar decisiones que escapan
de su responsabilidad. A este proceso se le denomina escalar un
incidente.
49
Capítulo III
Básicamente hay dos formas de escalar incidentes:

• Funcional: Se requiere el apoyo de un especialista de más alto
nivel para atender el incidente.
• Jerárquico: Se acude a un superior, de mayor autoridad, para
tomar decisiones que escapan de las atribuciones del primer nivel,
como por ejemplo, asignar más recursos para la atención de un
incidente específico.
5.- Actividades
Las actividades que se cumplen en el proceso de atención de
incidentes son:
1. Registro de incidentes
2. Clasificación de los incidentes
3. Análisis, Resolución y Cierre de Incidentes
5.1.- Registro de incidentes
La admisión y registro del incidente es el primer paso para una
correcta gestión del mismo.
Los incidentes pueden provenir de diversas fuentes tales como
usuarios, de la gestión de aplicaciones, del mismo centro atención o de
soporte técnico, entre otros. Inmediatamente debe realizarse el proceso de
registro, pues resulta mucho más costoso hacerlo posteriormente y se
corre el riesgo de que la aparición de nuevos incidentes demore
indefinidamente el proceso de registro.
En el proceso de registrar un incidente, se cumplen las siguientes
tareas:
• Al realizarse la admisión del incidente en el centro de atención
debe evaluarse en primera instancia si el servicio está incluido en
los acuerdos de servicio establecidos con el usuario o el cliente.
En caso de que no fuese así, el requerimiento deberá referirse a
una autoridad competente.
• Debe comprobarse que el incidente no haya sido registrado, pues
es común que varios usuarios notifiquen un mismo incidente.
• Debe asignarse un número de referencia al incidente, que lo
identificará tanto para los procesos internos, como para las
comunicaciones con el usuario o cliente.
50
• Se completará el registro inicial, introduciendo en la base de datos

la información básica necesaria para la atención del incidente
(hora, descripción del incidente, sistemas afectados...).
• Deberá incluirse cualquier información de apoyo que sea relevante
para la resolución del incidente, que puede ser solicitada al cliente
a través de un formulario específico, o que pueda ser obtenida de
la propia base de datos de hardware y software.
• Se notificará el incidente a todos los usuarios que puedan resultar
afectados por el incidente, con el fin de que conozcan cómo esta
incidencia puede afectar su flujo normal de trabajo.
5.2.- Clasificación de los incidentes
La clasificación de un incidente tiene como objetivo principal
recopilar toda la información que pueda ser de utilidad para la resolución
del mismo, para ello debe incluir las siguientes tareas:
• Categorización:
La categorización de un incidente, como su nombre lo indica,
consiste en la asignación de una categoría, dependiendo de
los servicios afectados o del grupo de trabajo responsable de
su resolución. La categoría de un incidente permite
identificar los servicios afectados por el incidente.
• Asignación de prioridad:
La asignación del nivel de prioridad, de acuerdo con el
impacto y la urgencia y según los criterios que hayan sido
preestablecidos.
• Asignación de recursos:
En los casos en que el centro de atención no puede resolver el
incidente en primera instancia, se deberá transferir al grupo
de soporte técnico que corresponda y deberá designarse el
personal que deberá atenderlo -segundo nivel-.
• Seguimiento:
El supervisor del centro de atención hará seguimiento del
progreso o estatus del incidente, así como del tiempo de
respuesta esperado. Normalmente los estatus de un incidente
pueden ser: registrado, en progreso, suspendido, escalado a
nivel siguiente, resuelto y cerrado.
51
Capítulo III
El tiempo de resolución del incidente corresponderá a los

acuerdos de servicio que se hayan establecidos con los
usuarios o clientes y a la prioridad que se haya asignado.
5.3.- Análisis, Resolución y Cierre de Incidentes
En primera instancia se examina el incidente con ayuda de la base de
datos donde se acumulan y organizan las lecciones aprendidas –base de
conocimiento-, para determinar si se puede identificar algún incidente ya
resuelto y aplicar la solución ya conocida.
Si la resolución del incidente escapa a las posibilidades del centro de

atención, éste lo transferirá a un segundo nivel, para su investigación por
los expertos que se asignen. Si estos expertos logran atender el incidente
se seguirán los procedimientos para escalar incidentes que se hayan
preestablecido.
Durante todo el ciclo de vida del incidente se debe actualizar la
información almacenada en las correspondientes bases de datos para que
el personal involucrado en un incidente y su solución dispongan de
información actualizada sobre el estatus del mismo -registrado, en
progreso, suspendido, escalado a nivel siguiente, resuelto o cerrado-.
52
Existen casos en que para aplicar las medidas que permitan reanudar
el servicio será necesario producir una solicitud de cambio, que
normalmente corresponderá a un cambio urgente.
Cuando se haya solucionado un incidente se deberá:
• Cotejar con los usuarios que la solución ha sido satisfactoria.
• Incorporar las lecciones aprendidas en la base de conocimientos.
• Cerrar el incidente -colocarlo en estatus cerrado-.
Para evaluar el desempeño de la disciplina de manejo de incidentes,
será importante generar periódicamente diferentes reportes y generar
información para otras disciplinas como:
• Administración de Niveles de Servicio
Será fundamental que usuarios y los clientes dispongan de
información puntual sobre el cumplimiento de los niveles
servicio acordados y de las medidas correctivas que deberán
tomarse, en caso de incumplimiento.
• Seguimiento del desempeño del centro de servicio
Para conocer el grado de satisfacción de los usuarios y
clientes por el servicio prestado y supervisar el correcto
funcionamiento de la primera línea de soporte.
• Optimización de la asignación de recursos
Todos los administradores de servicios deben saber si los
procedimientos para escalar incidentes se han cumplido
adecuadamente y si se han evitado duplicidades en el proceso
de atención de incidentes.
• Identificación de deficiencias en los procedimientos
Sobre todo en sus etapas iniciales, los procedimientos
podrían tener deficiencias que no les permitan adecuarse a la
estructura de la organización o las necesidades de los
usuarios o clientes, por lo que se deban tomar medidas
corregirlos.
• Acumulación de Información Estadística
La información que se acumula en el proceso de manejo de
incidentes puede ser utilizada para que la gerencia de
53
Capítulo III
servicios de TI haga proyecciones sobre requerimientos de

recursos, costos asociados al servicio, etc.
Para la evaluación del desempeño de la disciplina será necesario
establecer diferentes métricas, tomando en cuenta variables como las
siguientes:
• Número de incidentes por categorías y prioridades.
• Tiempos de resolución clasificados de acuerdo al impacto y a la
urgencia de los incidentes.
• Porcentaje de incidentes, clasificados por impacto y prioridad, que
han sido resueltos en primera instancia por el centro de atención.
• Costos asociados a la disciplina.
• Uso de los recursos disponibles en el centro de atención.
• Grado de satisfacción de usuarios y/o clientes, que puede
determinarse mediante encuestas periódicas, que permitan
cuantificar la percepción del usuario con respecto a los servicios
recibidos.
54
Capítulo IV
M a ne jo de
Proble m a s
Capítulo IV
Manejo de problemas
Tabla de contenido
1.- ¿En qué consiste el manejo de problemas? ...........................57

1.1.- Ventajas .............................................................................58
1.2.- Barreras..............................................................................59
2.- Actividades.............................................................................59
2.1.- Control de problemas.........................................................60
2.2.- Control de errores ..............................................................63
2.3.- Revisión de post implementación y cierre .........................64
3.- Evaluación de la disciplina.....................................................64
4.- Ejemplo ..................................................................................65
56
Manejo de problemas
Manejo de problemas
1.- ¿En qué consiste el manejo de problemas?

Las funciones principales del manejo de problemas son:
• Investigar las causas de cualquier alteración, real o potencial,
del servicio de TI.
• Determinar posibles soluciones a tales alteraciones.
• Proponer las solicitudes de cambio (RFC) necesarias para
asegurar la calidad de la implantación de las soluciones.
• Realizar revisiones post implementación (PIR) para asegurar
que los cambios han surtido los efectos buscados, sin crear
problemas secundarios.
El manejo de problemas puede ser:
• Reactivo: Analiza los incidentes ocurridos para descubrir su
causa y propone soluciones a los mismos.
• Proactivo: Evalúa y hace seguimiento a la calidad de la
infraestructura TI y analiza su configuración, con el objetivo
de prevenir incidentes antes de que estos puedan ocurrir.
Tal como se discutía en el capítulo de administración de incidentes,
esa disciplina tiene como objetivo restablecer lo más rápidamente los
servicios, sin contemplar las acciones que puedan ser necesarias para
determinar las causas que hayan generado el incidente.
Cuando algún tipo de incidente se convierte en recurrente o tiene un
fuerte impacto en la infraestructura TI, la disciplina de manejo de
problemas incluye las actividades necesarias para determinar las causas y
encontrar las posibles soluciones.
Para los efectos de la disciplina de manejo de problemas, es necesario
diferenciar entre:
• Problema:
Causa aun no identificada de una serie de incidentes o de un
incidente aislado pero de importancia significativa.
57
Capítulo IV
• Error conocido:
Un problema pasa a ser un error conocido cuando se han
determinado sus causas.
1.1.- Ventajas
Los principales beneficios de un adecuado manejo de problemas son:
• Cumplimiento de los niveles de servicio acordados con los
usuarios.
• Optimización de los recursos disponibles.
• Mayor satisfacción general de usuarios y clientes.
Recíprocamente, la carencia de un adecuado manejo de problemas
puede significar:
• Un deterioro de los niveles de servicio.
• Utilización ineficiente de los recursos.
• Repetición continua de fallas similares
• Proliferación de clientes y usuarios insatisfechos por la
repetición de fallas similares.
58
Manejo de problemas
1.2.- Barreras
Entre las principales barreras con que tropieza la implantación de una
disciplina manejo de problemas pueden citarse las siguientes:
• No se siguen los procedimientos previstos.
• Se posterga la adopción de soluciones.
• Se resuelven los problemas sin registrarlos adecuadamente.
• Personal técnico insuficiente.
2.- Actividades
Las principales actividades del manejo de problemas son:

1. Control de Problemas:
En esta actividad se registran y clasifican los problemas, para
determinar sus causas y convertirlos en errores conocidos.
2. Control de Errores:
En esta actividad se registran los errores conocidos y se
proponen soluciones a los mismos mediante solicitudes de
cambio que son procesadas de acuerdo con los
procedimientos establecidos para la administración de
cambios.
3. Revisión de postimplantación:
En esta actividad se efectúa la revisión de los cambios
implementados para corregir los errores conocidos, en
conjunción con la disciplina de administración de cambios.
59
Capítulo IV
4. Detección de problemas
Opcionalmente, si la estructura de la organización lo ha
establecido, en esta actividad se desarrolla un manejo de
problemas proactivo, en conjunción con la disciplina de
monitorización y control, que permita a detectar problemas
antes de que estos se manifiesten y puedan causar un
deterioro en la calidad del servicio.
2.1.- Control de problemas

Tal como señalamos en el párrafo precedente, el principal objetivo de
la actividad de control de problemas es lograr que estos se conviertan en
errores conocidos para que en la actividad de control de errores puedan
proponerse las soluciones correspondientes.
El control de problemas, a su vez, se cumple en tres actividades:
1. Identificación y registro
2. Clasificación y asignación de recursos
3. Análisis y diagnóstico: error conocido
60
Manejo de problemas
2.1.1.- Identificación y registro

Una de las tareas principales del manejo de problemas es identificar
los mismos, para lo cual las principales fuentes de información son:
• La base de datos de Incidentes: en principio cualquier
incidente del que no se conocen sus causas y que se ha
cerrado mediante algún tipo de solución temporal constituye
potencialmente un problema. Sin embargo, antes de llevarlo a
la categoría de problema se deberá de analizar si se trata de
un incidente aislado y su impacto en la infraestructura de TI.
• Análisis de la infraestructura TI: en conjunción con las
disciplinas de administración de disponibilidad, de capacidad
y de monitorización y control, el manejo de problemas
analiza los diferentes procesos y determina en qué áreas se
deben robustecer los sistemas y la infraestructura de TI, para
evitar futuros problemas.
• Deterioro de los Niveles de Servicio: un desempeño que se
deteriora es una indicación de que existe algún problema, que
aun no se ha manifestado en forma de incidente.
Todas las áreas de organización de TI deben colaborar en el manejo de
problemas, identificando problemas reales o potenciales e informando
sobre cualquier síntoma que pueda indicar un deterioro en el servicio TI.
El registro de problemas es bastante similar al registro de los
incidentes; sin embargo, el énfasis no debe colocarse en los detalles
específicos de los incidentes asociados, sino en su naturaleza y posible
impacto.
El registro de problemas debe incorporar información como:
Causas del problema.
Síntomas asociados.
Soluciones temporales.
Servicios involucrados.
Niveles de urgencia, prioridad e impacto.
Estado: activo, error conocido, cerrado.
2.1.2.- Clasificación y asignación de recursos
La clasificación del problema debe tomar en cuenta desde las
características generales de éste, tales como si se trata de un problema de
hardware o de software, que áreas del negocio se ven afectadas y detalles
61
Capítulo IV
sobre los diferentes elementos de configuración involucrados en el

mismo.
Un factor esencial es la determinación de la prioridad del problema,
que al igual que en el caso de los incidentes, se determina tanto a partir de
la urgencia (demora aceptable para la solución del problema) como de su
impacto (grado de deterioro de la calidad del servicio).
Al igual que en la administración de incidentes la prioridad puede
cambiar en el transcurso del proceso del problema, por ejemplo, cuando
se encuentra alguna solución temporal al mismo, que reduce
considerablemente su impacto, puede reducirse su prioridad.
Una vez clasificado y de acuerdo con la prioridad de un problema, se
deben de asignar los recursos necesarios para su solución. Estos recursos
deben ser suficientes para asegurar que los problemas asociados sean
tratados eficazmente y, de esa forma, minimizar el impacto en la
infraestructura de TI.
2.1.3.- Análisis y diagnóstico: error conocido
Los objetivos principales del proceso de análisis son:
• Determinar las causas del problema.
• Definir soluciones temporales a la administración de
incidentes para minimizar el impacto del problema, hasta que
se implementen los cambios necesarios que lo resolverán
definitivamente.
Es esencial tener en cuenta que no siempre el origen del problema es
un error de hardware o software. Es frecuente que un problema pueda ser
causado por:
• Errores de procedimiento.
• Documentación incorrecta.
• Falta de coordinación entre diferentes áreas.
Es también posible que la causa del problema sea un error o "bug"
bien conocido en alguna de las aplicaciones instaladas, por lo que se hace
necesario entrar en contacto con los equipos de desarrollo y
mantenimiento de sistemas, en caso de aplicaciones desarrolladas "en la
casa", o tramitar ante el grupo de soporte del proveedor o, en algunos
casos, investigar en internet la información sobre errores conocidos que
pueda ser utilizada para resolver el problema en cuestión.
Como ya indicáramos, una vez determinadas las causas de un
problema, éste se convierte en un error conocido y comienza a ser
62
Manejo de problemas
manejado por los procedimientos de control de errores, para su posterior

procesamiento.
2.2.- Control de errores
El proceso de control de errores incluye dos actividades:
1. Análisis de la solución
2. Aplicación de la solución
El registro de los errores conocidos es de vital importancia para el
inicio de estas actividades del manejo de problemas, con el fin de poder
asociarle, siempre que sea posible, algún tipo de solución temporal que
pueda mitigar el impacto de los incidentes asociados.
2.2.1.- Análisis de la solución
Con el fin de evitar inconvenientes, el análisis de las soluciones debe
incluir una evaluación de:
• Posible impacto que la solución de un problema pueda tener
sobre la infraestructura de TI.
• Los costes asociados.
• Sus consecuencias sobre los niveles de servicio.
2.2.2.- Aplicación de la solución
Existen algunos casos, en los que dado el impacto que el problema
tiene sobre la calidad del servicio, se deben emitir solicitudes de cambio
de emergencia para su proceso urgente por parte de los responsables de la
administración de cambios. En estos casos es importante que se evalúe si
la solución temporal que se ha diseñado es lo suficientemente buena
como para mantener unos niveles de calidad de servicio aceptables.
Una vez determinada la solución óptima a un problema y antes de
elevar una solicitud de cambio a la administración de cambios deben
hacerse varias consideraciones:
• ¿Es conveniente demorar la solución? Bien sea porque en el
corto plazo se prevén cambios significativos en la
infraestructura de TI o por el escaso impacto del problema en
cuestión.
• ¿Se justifica el costo de implantar la solución?
En cualquier caso, se implemente o no la solución, toda la
información sobre el error y su solución se deberá registrar en las bases
de datos asociadas.
63
Capítulo IV
En caso de que se proceda con la implantación de la solución, se

emitirá una solicitud de cambio y la implantación de la solución pasa a
ser coordinada por la disciplina de administración de cambios.
2.3.- Revisión de post implementación y cierre
Antes de dar el problema por resuelto y cambiar su estado a “cerrado”
se debe analizar el resultado de la implementación de la solicitud de
cambio procesada por administración de cambios. Si los resultados de
este cambio son los deseados, se pueden cerrar todos los incidentes
relacionados con este problema y se considera concluido el proceso.
Hemos podido observar que el objetivo central de la disciplina de
manejo de problemas es mejorar el funcionamiento de la infraestructura
TI; así pues, para evaluar su eficacia será imprescindible realizar un
seguimiento continuo de los procesos relacionados y evaluar su
desempeño.
Un buen manejo de problemas debe traducirse en una:
• Disminución en el número de incidentes
• Mayor eficacia en la resolución de problemas.
• Una administración proactiva que permita identificar
problemas potenciales antes de que estos se manifiesten o
provoquen una degradación de la calidad del servicio de TI
Un eficaz manejo de problemas requiere que las responsabilidades
sobre cada disciplina y cada área de servicios estén claramente definidas.
La elaboración de informes y resúmenes sobre las actividades de
manejo de problemas cumplidas, permitirá que la gerencia de TI evalúe el
rendimiento de la disciplina, así como también aportará información
valiosa para otras áreas de servicio de TI. Entre los informes que pueden
ser producidos periódicamente están:
• Informes de rendimiento del manejo de problemas, que
detallen la cantidad de errores resueltos, la eficacia de las
soluciones propuestas y los tiempos de respuesta.
• Informes de acciones de prevención, en los que se
especifiquen las acciones ejercidas para la prevención de
nuevos problemas
64
Manejo de problemas
• Resultados de los análisis que se hayan realizado sobre la

adecuación de la infraestructura de TI en relación con las
necesidades de la empresa.
• Informes de calidad de los productos y servicios contratados,
que puedan facilitar la evaluación de los proveedores.
4.- Ejemplo
65
Capítulo IV
66
Capítulo V

Configura c ione s
Capítulo V
Administración de Configuraciones
Tabla de contenido
1.- ¿En qué consiste la administración de configuraciones?............69

1.1.- Ventajas .............................................................................70
1.2.- Barreras..............................................................................70
2.- Terminología ..............................................................................71
2.1.- Ítems de configuración (configuration item - CI) ..............71
2.2.- Base de datos de configuraciones. .....................................72
2.3.- Línea base de configuración (configuration baseline) .......72
2.4.- Sistema de administración de configuraciones. .................72
2.5.- Ambientes operacionales ...................................................73
3.- Proceso .......................................................................................75
3.1.- Planificación ......................................................................76
3.2.- Clasificación y Registro.....................................................77
3.3.- Alcance ..............................................................................77
3.4.- Nivel de detalle y Profundidad ..........................................78
3.5.- Nomenclatura.....................................................................78
3.6.- Control ...............................................................................79
3.7.- Auditorías...........................................................................79
68
Administración de configuraciones
1.- ¿En qué consiste la administración de

configuraciones?
Las funciones principales que cumple la administración de
configuraciones son:
• Mantener el control detallado de todos los componentes de la
infraestructura TI, tanto de hardware como de software,
almacenando esa información en una base de datos de
configuración – inventario de hardware y software-.
• Suministrar información actualizada sobre la configuración
de la infraestructura de TI, para el cumplimiento de los
diferentes procesos de administración de servicios que así lo
requieren.
Para poder administrar eficientemente la infraestructura informática,
es fundamental conocer en detalle cuáles son sus componentes y sus
interrelaciones; esa es la tarea central de la administración de
configuraciones.
69
Capítulo V
La administración de configuraciones no es una labor sencilla, pues

requiere una colaboración muy activa de todos los administradores de
servicios de TI y en particular de los procesos de administración de
cambios y versiones. Por tal razón, en muchas organizaciones medianas y
pequeñas se prefiere combinar esas disciplinas, simplificando el proceso
de control.
1.1.- Ventajas
Los beneficios de una adecuada administración de configuraciones
son múltiples, entre ellos:
• Resolución más rápida de los problemas, que redunda en una
mayor calidad de servicio.
• Una administración de cambios más eficiente.
• Control de licencias. Se pueden identificar copias ilegales de
software que pueden suponer un peligro para la
infraestructura TI y el incumplimiento de las normas legales
que podría repercutir negativamente en la organización.
• Mejor nivel de seguridad, pues una base de datos de
componentes actualizada ayuda a realizar un análisis de las
vulnerabilidades en la infraestructura.
• Mayor rapidez en la restauración de servicios. Cuando se
conocen todos los ítems de configuración y sus
interrelaciones es mucho más sencillo recuperar la
configuración de la infraestructura de producción en un
menor tiempo.
1.2.- Barreras
Las principales barreras que encuentra la implantación de la disciplina
de administración de configuraciones son:
• Desactualización de la base de datos de configuración,
debido a que mantenerla actualizada requiere dedicación y
prolijidad que no siempre el personal está motivado a
cumplir.
• Herramientas inadecuadas, es necesario disponer del software
adecuado que facilite los procesos de manejo y actualización
de la base de datos.
• Falta de coordinación con las disciplinas de administración
de cambios y de versiones, que impide una correcta
actualización de la base de datos.
70
• Asignación de responsabilidades, debe haber una clara

definición y asignación de responsabilidades, con el fin de
garantizar que la base de datos de configuración se actualiza
adecuadamente.
2.- Terminología
A lo largo de este capítulo hemos utilizado diferentes conceptos con
diferentes denominaciones, sin embargo, especialmente en
administración de configuraciones, para poder desarrollar unos
procedimientos consistentes y sin ambigüedades es imprescindible
manejar una terminología clara y precisa, por lo que a continuación
discutiremos los más importantes.
2.1.- Ítems de configuración (configuration item - CI)
Es la denominación genérica que se le da a todos los componentes de
los servicios de TI, como pudieran ser:
• Dispositivos de hardware como: PCs, impresoras, puntos de
red, enrutadores, concentradores, etc. así como cada uno de
sus componentes de hardware como tarjetas, teclados,
lectores de CDs, etc.
• Componentes de software como: los sistemas operativos, las
aplicaciones, los programas que integran una aplicación, los
drivers, los protocolos de red, etc.
• Documentación como: componentes escritos, planes, diseños,
manuales, instructivos, acuerdos de niveles de servicio,
contratos, etc.
71
Capítulo V
ITIL define ítem de configuración como:

Cualquier activo, servicio, componente u otro
elemento que se controla (o que será
controlado) por la administración de
configuraciones.
2.2.- Base de datos de configuraciones (configuration
management data base - CMDB).
La base de datos de configuraciones debe incluir:
• Información detallada sobre cada ítem de configuración.
• Interrelaciones entre los diferentes ítems de configuración,
como, por ejemplo, relaciones "padre-hijo" o
interdependencias tanto lógicas como físicas (Ej.: la estación
de trabajo está conectada al punto de red X que se conecta al
concentrador Y)
La base de datos de la administración de configuraciones no puede
limitarse a una mera enumeración del inventario de componentes, sino
que debe tener la capacidad de presentar una imagen global de la
infraestructura TI.
2.3.- Línea base de configuración (configuration baseline)
Una línea base de configuración es la definición de la estructura que
debe tener un ítem, la cual ha sido formalmente acordada y establecida.
Este concepto lo podemos asociar a la definición de los estándares que
deben cumplir algunos ítems de configuración, como ocurre con los
programas, los instructivos, los modelos de datos, etc. La línea base de
configuración se utiliza en la disciplina de administración de cambios,
para verificar que los nuevos ítems que pasan al ambiente de producción
cumplan con los estándares.
2.4.- Sistema de administración de configuraciones
(Configuration Management System).
Es claro que la administración de configuraciones requiere el apoyo de
un sistema de información que debe contar con facilidades para dar
entrada a los ítem de configuración, mantener y actualizar la base de
datos de configuración y para extraer la información que requieren los
diferentes procesos de administración de servicios de TI.
Uno de los grandes retos, al iniciar el desarrollo de las disciplinas de
administración de servicios es el levantamiento del inventario de
hardware y software. Afortunadamente, en el mercado pueden
72
encontrarse una gran cantidad de paquetes que automatizan gran parte de

las funciones de recolección de datos y mantenimiento de la base de datos
de configuraciones, algunos de estos paquetes disponen de facilidades
para explorar algunos equipos conectados a la red -como las estaciones de
trabajo, impresoras y servidores-, con el fin de identificar todos los
dispositivos y componentes de software instalados y actualizar
automáticamente el inventario. Algunos de estos paquetes también
permiten identificar software ilegalmente instalado. Entre estos paquetes
podemos citar:
Discovery
LOGINventory
Everest Corporate Edition
NetSupport DNA
Users Ghost
Alloy Network Inventory
EMCO Network Inventory
WinAudit
Asset Tracker for Networks
Steel Inventory
Alchemy Network Inventory
Computer Admin Lite
Admin Express
2.5.- Ambientes operacionales
Un ambiente operacional es un conjunto de componentes y recursos
que se organizan separadamente para cumplir un propósito específico,
como:
• Ambiente de producción
El ambiente de producción está conformado con todos los
recursos y componentes destinados a procesar las
operaciones y la información de la empresa. Es un ambiente
que maneja los “datos reales” del negocio, al que sólo tienen
acceso los usuarios, con las limitaciones que les imponen los
perfiles de seguridad que les hayan sido asignados, de
acuerdo con sus atribuciones y responsabilidades.
73
Capítulo V
Es norma general que el personal de desarrollo de sistemas

no tenga acceso a este ambiente, con el fin de mantener una
sana segregación de funciones.
• Ambiente de desarrollo
El ambiente de desarrollo está conformado con todos los
recursos y componentes destinados a desarrollar o modificar
las diferentes aplicaciones para uso de la empresa. Es un
ambiente que maneja datos ficticios que utiliza el personal de
desarrollo y mantenimiento.
El acceso a este ambiente tiene menos restricciones que el
ambiente de producción.
• Ambiente de prueba
El ambiente de prueba está conformado con todos los
recursos y componentes destinados a realizar pruebas de
sistema y de desempeño de las diferentes aplicaciones –
nuevas o modificadas- para uso de la empresa. Es un
ambiente con una estructura muy similar a la del ambiente de
producción, pero en el que se manejan datos ficticios –datos
de prueba-.
El acceso a este ambiente tiene más restricciones que el
ambiente de desarrollo, pero menos que el ambiente de
producción. Solamente lo utilizan usuarios y personal de
desarrollo, debidamente autorizados para cumplir procesos
prueba específicamente planificados.
74
• Ambiente de adiestramiento.
En algunas empresas se utiliza un ambiente de
adiestramiento, este ambiente está conformado con todos los
recursos y componentes destinados necesarios para que los
usuarios de un nuevo sistema puedan aprender a utilizar sus
funciones en forma muy similar a como lo harán cuando el
sistema pase a producción.
Normalmente se utiliza para adiestrar a los usuarios para un
nuevo sistema de largo alcance. Es un ambiente con una
estructura muy similar a la del ambiente de producción, pero
en el que también se manejan datos ficticios –datos de
prueba-.
El acceso a este ambiente tiene más restricciones que el
ambiente de desarrollo, pero menos que el ambiente de
producción. Solamente lo utilizan usuarios y personal de
desarrollo, debidamente autorizados para cumplir los
procesos de adiestramiento específicamente planificados.
La separación de ambientes es un elemento fundamental de control
interno, pues permite establecer controles estrictos sobre el uso de los
componentes destinados a producción y el acceso a la información del
negocio. En algunas empresas, en las que no se dispone de suficientes
recursos, será imprescindible que, como mínimo, se establezca una
separación estricta entre el ambiente de producción y todas las
actividades de desarrollo y prueba.
Es importante observar que los procesos de migración de
componentes desde el ambiente de prueba al ambiente de producción, una
vez que han pasado satisfactoriamente los procesos de prueba, se realizan
bajo la supervisión de las disciplinas de administración de versiones y de
cambios.
3.- Proceso
Las principales actividades que se cumplen dentro del proceso de
administración de configuraciones son:
1. Planificación:
Determinar los objetivos y estrategias de la administración de
configuraciones.
75
Capítulo V
2. Clasificación y registro:
Los ítems de configuración (CI´s) deben registrarse de acuerdo a su
línea base y nomenclatura que se hayan predefinido.
3. Seguimiento y control:
Es necesario asegurar que la base de datos de la administración de
configuración (CMDB) esté correctamente actualizada, por lo que es
fundamental hacer un seguimiento que permita asegurar que cada una
de las disciplinas relacionadas –administración de cambios y de
versiones- registren y actualicen correcta y oportunamente la
información de su competencia.
4. Realización de auditorías:
Como es práctica normal en cualquier proceso de inventario, la
administración de la configuración incluye la realización de
auditorías que permitan cotejar la información registrada en la base
de datos contra la configuración física real de la infraestructura TI de
la organización.
5. Elaboración de informes:
La Administración de configuraciones tiene como función primordial
aportar información a otras disciplinas y para las diferentes áreas de
la infraestructura de TI.
3.1.- Planificación
Sin una base de datos de configuraciones es muy difícil que puedan
administrarse satisfactoriamente los servicios de TI, por la sencilla razón
de que no existiría un conocimiento detallado de lo que se está
administrando. Por esta razón, puede decirse que la disciplina de
administración de configuraciones es el corazón de la administración de
servicios de TI.
Las principales tareas que se cumplen dentro de la actividad de
planificación son las siguientes:
• Designar una persona responsable: una descentralización
excesiva o dispersión de esta responsabilidad entre las
diferentes unidades técnicas, puede generar descoordinación,
con el riesgo de que la actualización de la base de datos se
actualice en forma desigual.
• Invertir en alguna herramienta de software adecuada a las
actividades requeridas, pues no es posible cumplir con esta
disciplina con métodos manuales.
76
• Establecer claramente:
El alcance y objetivos.
El nivel de detalle.
El proceso de implementación en orden de importancia o
de acuerdo con los lineamientos dictados por la gerencia
de TI.
• Coordinar el proceso estrechamente con la administración de
cambios, y la administración de versiones.
Una planificación adecuada permitirá que la administración de
configuraciones se desarrolle sin dificultades y permitirá desarrollar una
base de datos robusta para apoyar el resto de los procesos.
3.2.- Clasificación y Registro
Es claro que la principal tarea de la administración de configuraciones
es mantener la base de datos de configuraciones, por ello es importante
un trabajo de diseño que establezca criterios de clasificación y registro de
los componentes, para llevar a cabo esta labor con éxito será importante
que:
• Los objetivos sean realistas: una excesiva profundidad o
detalle puede sobrecargar de trabajo a la organización y
causar, a la larga, que se abandonen estas responsabilidades.
• La información sea suficiente: debe existir, por lo menos un
registro de todos los sistemas y componentes críticos de la
infraestructura TI.
3.3.- Alcance
Al poner en marcha la disciplina de administración de configuraciones
será importante establecer prioridades, determinando qué sistemas y
componentes TI van a ser incluidos gradualmente en la base de datos de
componentes. Debe tomarse en cuenta que al establecer el alcance:
• Será esencial incluir todos los sistemas de hardware y
software relacionados con los servicios críticos.
• Será recomendable incorporar la documentación asociada a
niveles de servicio y licencias.
En general cualquier servicio o proceso debe ser incluido en la base de
datos, pero debe hacerse en forma gradual; si se fijan unos objetivos
demasiado ambiciosos podrían llevar a la frustración y al fracaso.
77
Capítulo V
3.4.- Nivel de detalle y Profundidad

Una vez determinado el alcance de la base de datos de
configuraciones es fundamental establecer el nivel de detalle necesario,
para ello se deberá:
• Determinar los atributos que describen cada tipo de ítem.
• Determinar las relaciones lógicas y físicas que se registrarán
para los diferentes ítems.
• Ítems y subcomponentes que deberán ser registrados
independientemente.
Por ejemplo, si se decide incluir las estaciones de trabajo en la base de
datos, debe considerarse incluir:
• Atributos: fabricante, tipo, modelo, fecha de compra,
procesador, memoria, sistema operativo, costo, etc.
• Relaciones: punto de red al cual está conectado, a qué usuario
está asignada, dispositivos que tenga conectados como,
teclado, monitor, impresoras, scanners, etc.
• Subcomponentes: tarjetas de red, discos duros, tarjetas
gráficas, herramientas, paquetes de software y programas
instalados.
3.5.- Nomenclatura
Será de vital importancia establecer un sistema de codificación y
clasificación para los diferentes ítems de configuración, con el fin de que
el sistema pueda ser utilizado con facilidad:
• La identificación de cada tipo de ítem debe ser única y fácil
de interpretar:
• El código debe ser utilizado consistentemente en todas las
comunicaciones referidas a los ítems de configuración.
• Los códigos deben ser establecidos tanto para componentes
de hardware, como también para documentación y
componentes de software.
• Normalmente los ítems de hardware tienen un serial asignado
por el proveedor, que deberá ser incluido en la base de datos,
para ello no debe descartarse el uso de códigos de barra, con
el fin de simplificar los procesos de registro en la base de
datos de configuración.
78
3.6.- Control
La administración de configuraciones debe estar puntualmente
informada de todos los cambios y adquisiciones de componentes para
mantener actualizada la base de datos.
El registro de todos los componentes de hardware debe iniciarse desde
la aprobación de su compra y debe mantenerse actualizado su estado en
todo momento de su ciclo de vida. Asimismo, debe estar correctamente
registrado todo el software "en producción".
Las tareas de control deben centrarse en:
• Asegurar que todos los componentes están registrados en la
base de datos.
• Monitorizar el estado de todos los componentes.
• Actualizar las interrelaciones entre los ítems de
configuración.
• Informar sobre el estado de las licencias.
3.7.- Auditorías
El objetivo de las auditorías es asegurar que la información registrada
en la base de datos de configuraciones coincide con la estructura real de
la infraestructura de TI. Normalmente, las auditorías deberán realizarse
en forma rotativa, pues resultará demasiado engorroso auditar toda la
infraestructura de una sola vez. Adicionalmente, el proceso de auditorías
debe mantenerse con cierta constancia, a los fines de cubrir toda la
infraestructura en un período razonable –un semestre o un año-.
Dentro de lo posible, deberá dotarse el proceso de auditoría de
herramientas automatizadas, como lectores de código de barras y
programas que comparen la base de datos con los datos obtenidos en las
revisiones físicas, con el fin de determinar faltantes, sobrantes e
inexactitudes.
También será importante que se realicen auditorías después de haberse
procesado algún cambio significativo –reemplazo de aplicaciones o de
equipos- y si existe la sospecha de que alguna parte de la información
almacenada en la base de datos está o incompleta o es incorrecta.
Las auditorías deben dedicar especial atención a aspectos tales como:
• Uso adecuado de la nomenclatura en los registros de los
ítems.
79
Capítulo V
• Estatus de los ítems de configuración –instalado,

almacenado, en mantenimiento, descontinuado, etc.-
correctamente registrado.
• Cumplimiento de los niveles de detalle establecidos para el
registro de información sobre los ítems de configuración.
Para el funcionamiento correcto de la administración de
configuraciones se requiere la colaboración de toda la organización TI,
para mantener actualizada la información almacenada en la base de datos
de configuración.
Es importante producir informes periódicos que permitan evaluar el
desempeño de la administración de configuraciones, conocer la
consistencia de la base de datos de configuraciones y para aportar
información para otras áreas de la administración de servicios de TI.
Entre los reportes que podrían producirse, pueden estar:
• Resultados de las auditorías realizadas, mostrando
discrepancias entre la información almacenada en la base de
datos y la configuración real.
• Información sobre ítems que han estado involucrados en
diferentes fallas.
• Costos del proceso.
• Sistemas de clasificación y nomenclatura utilizados.
• Informes sobre ítems no autorizados y/o sin licencias.
• Información estadística y composición de la estructura TI.
80
Capítulo VI

V e rsione s
Capítulo VI
Tabla de contenido
1.- ¿En qué consiste la administración de versiones?..................83

1.1.- Ventajas .............................................................................85
1.2.- Barreras..............................................................................85
2.- Consideraciones de tipo práctico............................................86
2.1.- Tipos de versiones .............................................................86
2.2.- Actualización y custodia de componentes .........................87
2.3.- Versiones anteriores...........................................................88
2.4.- Nomenclatura de versiones ................................................88
2.5.- Estatus de una versión........................................................89
3.- Actividades de administración de versiones ..........................89
3.1.- Planificación ......................................................................90
3.2.- Verificación de cumplimiento de estándares .....................91
3.3.- Verificación de cumplimiento de pruebas .........................91
4.- Implementación......................................................................93
5.- Soporte inicial ........................................................................94
6.- Evaluación de la disciplina.....................................................94
82
1.- ¿En qué consiste la administración de versiones?

La administración de versiones es la disciplina que incluye las tareas
de coordinación y control sobre el proceso de implementación de todo el
software instalado en el ambiente de producción.
Algunos autores prefieren incluir también el control del hardware
instalado dentro de esta disciplina; sin embargo, dado que hardware y
software son elementos tan diferentes no consideramos práctico que la
administración de versiones se ocupe de los ítems de hardware. Por
ejemplo, el software definitivo –instalado en producción- requiere que
una copia de los programas ejecutables y sus correspondientes módulos
fuente, sean custodiados bajo estrictos controles; sin embargo, no tiene
ningún sentido plantear algo similar para el hardware instalado.
Consideramos además, que la administración de cambios y de
configuraciones ofrecen unos marcos procedimentales suficientemente
amplios para el control y la administración de los ítems de hardware.
Una versión –o release- es un conjunto de ítems de configuración que
han sido probados y están listos para ser migrados al ambiente de
producción.
La administración de versiones es una disciplina que debe coordinarse
e integrarse perfectamente con las disciplinas de administración de
cambios y de configuraciones, con el fin de asegurar que toda la
información relacionada con las nuevas versiones se actualice
adecuadamente en la base de datos de configuraciones.
La persona o el equipo responsable de la administración de versiones
tiene como responsabilidad fundamentalísima la custodia de las librerías
o bibliotecas de programas fuentes y ejecutables que han sido aceptados
en el ambiente de producción, así como también, de las bibliotecas de
documentación que deben acompañar dichos componentes.
La disciplina de administración de cambios se encarga de aprobar y
supervisar todo el proceso de cambio y la administración de versiones se
encarga del proceso de migración al ambiente de producción de los ítems
83
Capítulo VI
de configuración nuevos o modificados; obviamente, ambas disciplinas

tienen áreas comunes que deben ser tomadas en cuenta al desarrollar los
procedimientos, para evitar duplicidad de funciones o choque de
responsabilidades. Por esta razón, en algunas organizaciones las
actividades de administración de versiones se incluyen dentro de la
administración de cambios.
Entre los principales objetivos de la administración de versiones

podemos señalar los siguientes:
• Implementar las nuevas versiones de software en el ambiente de
producción, una vez que se hayan realizado pruebas
suficientemente rigurosas.
• Asegurar que el proceso de cambio cumpla las especificaciones de
la solicitud de cambio que lo originó.
• Asegurar, en coordinación con la administración de cambios y de
configuraciones, que todos los cambios se actualicen
correctamente en la base de datos de configuraciones.
• Archivar y custodiar tanto los programas fuente, como copias de
los ejecutables en producción, así como de toda su documentación
asociada, en la biblioteca de componentes en producción.
84
• Mantener la custodia, dentro de los plazos que establezcan las

políticas de la organización, de los ítems reemplazados –versiones
anteriores-.
1.1.- Ventajas
Entre las ventajas que pueden derivarse de una disciplina de
administración de versiones implementada correctamente pueden
señalarse:
• Las nuevas versiones cumplen los objetivos que originaron su
desarrollo.
• Se reduce el número de incidentes que puedan ocasionarse por
incompatibilidades con otro software o hardware instalados.
• El proceso de pruebas que debe preceder la implantación, permite
asegurar la calidad del software y hardware que se instala.
• El correcto mantenimiento de la bibliotecas de componentes
originales -fuentes, ejecutables, documentación, etc.- evita que se
pierdan valiosos elementos de la infraestructura.
• Se mantiene un control centralizado del software que pasa al
ambiente de producción.
1.2.- Barreras
Entre las principales barreras que encuentra la implantación de la
disciplina de administración de versiones pueden señalarse las siguientes:
• Resistencia a la centralización del proceso de cambio.
• El personal y, en general, la organización TI no reconocen la
autoridad del administrador de versiones, especialmente en lo
relacionado a la custodia de los ítems instalados en el ambiente de
producción.
• No se realizan pruebas lo suficientemente rigurosas de las nuevas
versiones, lo cual genera emergencias en el ambiente de
producción y la permanente necesidad de hacer excepciones en el
cumplimiento de los procedimientos, con el fin de poder
modificar los componentes directamente en ese ambiente.
• Hay resistencia a desarrollar planes de retorno o “backout", para
deshacer cualquier cambio que se haya implementado en
producción, pero que, por cualquier razón, no esté funcionando
adecuadamente.
85
Capítulo VI
• Carencia de herramientas de distribución de software, para la

instalación de nuevas versiones que puedan requerir la instalación
de uno o más componentes en diferentes servidores o en las
estaciones de trabajo de los diferentes usuarios de una nueva
versión.
2.- Consideraciones de tipo práctico
Señalábamos al inicio, que una versión es un conjunto de ítems de
configuración nuevos o modificados, que han sido probados y están listos
para ser puestos en producción, indicábamos también, que las
especificaciones funcionales y técnicas de una versión deben estar
establecidas en la solicitud de cambio que la originó.
En cierta forma, se puede afirmar que la administración de versiones
es el último paso de los diferentes procesos de adquisición, desarrollo,
mantenimiento e implantación de software, tanto software de aplicaciones
para el apoyo del negocio, como software base, entendiendo como
software base: los sistemas operativos, manejadores de bases de datos,
compiladores, programas de utilidad, programas de automatización de
oficinas, etc. Por ello, será importante establecer el conjunto de normas
que deberán gobernar la implantación de nuevas versiones, con el fin de
establecer unas sólidas metodologías de trabajo.
2.1.- Tipos de versiones

De acuerdo con su magnitud o impacto en la infraestructura de TI, las
versiones pueden clasificarse en:
• Versiones mayores
86
Una versión mayor corresponde a la instalación de grandes

piezas de software. Normalmente corresponde a un nuevo
sistema operativo, aplicación o al reemplazo del software de
apoyo a un número importante de operaciones del negocio.
• Versiones menores
Una versión menor corresponde a un grupo no muy grande
de ítems de configuración, que complementan la capacidad
de un elemento de software mayor o que cambian la
funcionalidad de algún módulo de un sistema o corrigen
varios errores conocidos.
• Versiones de emergencia
Una versión de emergencia corresponde a uno o varios ítems
de configuración que reemplazan ítems en producción, para
reparar un error conocido.
Será muy importante que los procedimientos de administración de
versiones tomen en cuenta los diferentes tipos de versiones, con el fin de
asegurar su agilidad, Evitando que para una versión de emergencia priven
las mismas condiciones que para una versión mayor, sin perder de vista
los controles fundamentales.
2.2.- Actualización y custodia de componentes
La administración de versiones debe establecer la forma cómo se
mantendrán las diferentes librerías o bibliotecas de programas fuentes y
ejecutables que quedan bajo la custodia del administrador de versiones.
En el caso de las aplicaciones los componentes se almacenarán en
bibliotecas propias de la instalación, cuyo acceso quedará restringido a
los administradores de versiones únicamente; sin embargo, en el caso del
software base y algunas aplicaciones adquiridas es preferible almacenar
ordenadamente, en archivos de seguridad los ítems tal como fueron
recibidos del proveedor.
Hoy día, es usual recibir vía internet nuevas versiones y correcciones
de errores conocidos o, simplemente, actualizaciones; por lo que es muy
importante establecer procedimientos que aprovechen la gran flexibilidad
que esta forma de trabajo ofrece, pero que, además, establezcan
suficientes controles sobre su aplicación.
Existen casos, como los antivirus, que se actualizan automáticamente,
de forma continua. Si para estos componentes se puede tener la confianza
de que el proveedor realiza una buena administración de versiones, no
valdrá la pena invertir tiempo y energía para ponerlos bajo nuestra
87
Capítulo VI
administración de versiones. En estos casos, bastará con registrar el

software en la base de datos de configuraciones y auditar periódicamente
su proceso de actualización, para verificar que se está cumpliendo
satisfactoriamente.
También es frecuente que se autorice a un proveedor a que tenga
acceso a nuestra infraestructura, con el fin de que directamente, desde sus
oficinas, pueda instalar ítems nuevos o modificados. En estos casos
tampoco valdrá la pena invertir tiempo y energía para ponerlos bajo
nuestra administración de versiones, bastará con llevar un registro
detallado de estos eventos de actualización y auditar periódicamente el
proceso de actualización, para verificar que se está cumpliendo
satisfactoriamente.
2.3.- Versiones anteriores
En la administración de versiones es muy importante mantener una
práctica ordenada para almacenar y custodiar las versiones que preceden
a los componentes en producción –versiones anteriores-, con el fin de
poder recuperar cualquier ítem, aunque haya transcurrido algún tiempo
desde su reemplazo. Esta práctica resulta especialmente valiosa para los
ítems de software, que a veces tienen alguna falla que ha pasado
inadvertida en los procesos de prueba y que, tiempo después de haber
sido instalados, causan una interrupción en el servicio o presentan un
funcionamiento inadecuado.
2.4.- Nomenclatura de versiones
Una práctica común es la de establecer una codificación que
identifique unívocamente cada versión. Normalmente, se utiliza un
sistema de aceptación muy generalizada, que consiste en denominar:
• Versiones mayores: 1.0, 2.0, etc.
• Versiones menores: 1.1, 1.2, 1.3, etc.
• Versiones de emergencia: 1.1.1, 1.1.2, etc.
Igualmente, los ítems de configuración que integran una versión,
deberán asociar su nombre o código de identificación con la versión a la
cual pertenecen.
Cabe señalar que este esquema de denominación de versiones es
apropiado para empresas productoras de software, en el caso de cualquier
otra empresa, sólo será necesario identificar los ítems que conforman un
sistema o una pieza grande de software e identificar las diferentes
versiones a nivel componente.
88
2.5.- Estatus de una versión

Las diferentes versiones cumplen un ciclo de vida, desde que se
formula la solicitud de cambio que la origina, hasta que es reemplazada
del ambiente de producción, por lo que hablamos de que una versión
puede pasar por diferentes estatus:
• Solicitada
• En desarrollo
• En prueba
• En producción
• Descontinuada
Junto con la información pertinente de cada ítem de configuración, en
la base de datos de configuraciones, será importante que se registre su
estatus.
3.- Actividades de administración de versiones
Para dar inicio a la disciplina de administración de versiones, será
importante establecer el conjunto de normas y políticas que deberán
gobernar los procedimientos de implantación de nuevas versiones, con el
fin de establecer unas sólidas metodologías de trabajo.
89
Capítulo VI
Adicionalmente, deberán establecerse los procedimientos que deberán

seguirse para cumplir las siguientes actividades, que conforman la
disciplina:
• Planificación
• Verificación de cumplimiento de estándares
• Verificación de cumplimiento de pruebas
• Implementación
• Soporte inicial
3.1.- Planificación
Antes de instalar una nueva versión en producción se requiere
formular varios planes, dependiendo del tipo de versión -mayor, menor o
de emergencia-. Estos planes formarán parte del material que será
revisará por la administración de cambios y deberán tomar en cuenta los
siguientes aspectos:
• Alcance, contenido, riesgos, responsabilidades y usuarios
involucrados en la versión.
• Estrategia para obtener la participación de todas las partes
involucradas –unidades de soporte, analistas de sistemas, técnicos
de bases de datos, usuarios, etc.-
• Planes de retorno –backout- para las situaciones de falla. Verificar
que los planes de retorno o respaldo y de retorno o backout han
sido convenientemente preparados y que son totalmente viables.
• Establecer quién, cómo y cuándo tomará la decisión de aplicar los
planes de retorno –en caso de ser necesario-, para minimizar el
impacto negativo sobre el servicio.
• ¿Qué se va a instalar? Establecer qué ítems de configuración están
involucrados en la nueva versión.
• ¿Quiénes son los usuarios?
• ¿Dónde están de los usuarios? En el caso de distribuciones
internacionales, ¿cuales consideraciones deben ser hechas?
• ¿Cuáles son las principales dificultades que se prevén?
• ¿Cómo serán entregados los componentes de la nueva versión?
• ¿Cuál es el impacto que puede tener la instalación de la nueva
versión en la continuidad y calidad de los servicios?
90
• Definir cuáles son los recursos humanos y técnicos necesarios

para llevar a cabo la implementación de la nueva versión con
éxito.
• Establecer quiénes serán los responsables directos en las
diferentes etapas del proceso de migración.
• Verificar que se hayan desarrollado planes de comunicación y
adiestramiento para que los usuarios participen y estén
debidamente informados, con el fin de evitar que una nueva
versión llegue como una sorpresa.
3.2.- Verificación de cumplimiento de estándares
La administración de versiones constituye la “recta final” de los
procesos de desarrollo y mantenimiento. En algunas oportunidades estos
desarrollos se realizan "en casa" y en otras se realizan con la participación
de proveedores externos. En ambos casos, la primera tarea de la
administración de versiones será la de asegurar que el paquete o paquetes
de software cumplan con las definiciones de línea base y estándares. En
algunas empresas existe una unidad que cumple las funciones de
aseguramiento de calidad, encargada de vigilar que durante todo el
proceso de desarrollo se cumplan los estándares. Si ese fuera el caso,
estas funciones estarán fuera del proceso de administración de versiones
y únicamente se mantendrá la tarea de verificar que las sesiones de
revisión de calidad se hayan cumplido satisfactoriamente.
La disciplina de administración de versiones también incluirá las
tareas correspondientes a la actualización de la base de datos de
configuraciones.
3.3.- Verificación de cumplimiento de pruebas
Una nueva versión, antes de pasar a producción, debe cumplir una
serie de procesos de prueba, como los que se describen en los siguientes
párrafos
Normalmente, los procesos de prueba corresponden a las
metodologías de desarrollo y mantenimiento que utiliza la empresa, por
lo que no corresponden a las actividades de administración de versiones;
sin embargo, dentro de esta disciplina debe incluirse la tarea de verificar
que dichas pruebas se hayan cumplido satisfactoriamente.
3.3.1.- Prueba unitaria
Una prueba unitaria es una prueba que se hace de un solo programa o
de un módulo. El programador del módulo es responsable de realizar la
prueba unitaria en el ambiente de desarrollo.
91
Capítulo VI
3.3.2.- Prueba de integración

Una prueba de integración es la prueba que se hace de las interfaces
que existen entre diversos componentes dentro de un módulo, con el fin
de detectar cualquier problema de intercambio de datos, archivos o
parámetros y asegurar que pueden ser ejecutados en el orden o secuencia
requeridos.
El analista del proyecto con ayuda de los restantes miembros del
equipo de desarrollo o mantenimiento, realiza estas pruebas en el
ambiente de prueba.
3.3.3.- Prueba Funcional
El propósito de una Prueba Funcional es identificar las discrepancias
que puedan existir entre un componente o sistema con sus
especificaciones funcionales.
Estas pruebas las realizan el representante funcional en el equipo de
trabajo, junto con el analista del proyecto y la ayuda de los restantes
miembros del equipo de desarrollo o mantenimiento. Una prueba
funcional se lleva a cabo en el ambiente de prueba.
3.3.4.- Prueba de Sistema
La Prueba de Sistema es el complemento de la prueba funcional, está
dirigida a probar los aspectos técnicos del sistema para detectar
discrepancias con respecto a sus objetivos de desempeño como tiempo de
respuesta, cumplimiento de estándares. Estas pruebas las ejecuta el
analista responsable del proyecto con la ayuda de los restantes miembros
del equipo y la supervisión de personal de soporte técnico.
Una prueba de sistema se lleva a cabo en el ambiente de prueba.
3.3.5.- Prueba de Aceptación Técnica
Una Prueba de Aceptación Técnica es un proceso de prueba llevado a
cabo por el personal técnico distinto del personal que desarrolló el
sistema; en algunas empresas se cuenta con grupos dedicados realizar
esta clase de pruebas para todos los sistemas que se desarrollan o
modifican, antes de que los mismos pasen a producción. Sin embargo,
para cumplir con esas tareas, la mayoría de las empresas prefiere
organizar grupos de prueba ad-hoc con personal de operaciones y de
soporte técnico. Normalmente, en una prueba de aceptación técnica se
someten los sistemas a condiciones extremas, con el fin de asegurar que
el sistema funcionará satisfactoriamente en cualquier caso.
92
4.- Implementación
Una vez que se ha establecido la coordinación con el proceso de
administración de cambios, se procede con la implantación en
producción. Este proceso puede ser:
• Completa
• Parcial
A su vez, una vez cumplidos los procesos de implantación, la
administración de versiones debe asegurarse de que:
• Se incluyan los programas fuente, la documentación y las copias
de los programas ejecutables, en las bibliotecas correspondientes-
• La base de datos de configuración quede correctamente
actualizada.
• Se informe debidamente a la unidad de atención a los usuarios.
4.1.1.- Implementación completa
Cuando se realiza instala una implantación completa, se instalan todos
los ítems que componen la versión simultáneamente para todos los
usuarios, en todas las localidades.
Normalmente, para este tipo de implementaciones se establece un
período de prueba final, denominado de aceptación funcional. Este
período de prueba lo cumplen los usuarios, con el personal de soporte y el
personal de operaciones, para evaluar que el sistema se desempeña
adecuadamente trabajando bajo condiciones reales.
Algunas veces estas pruebas pueden incluir el cumplimiento de
paralelos. Probar un sistema nuevo en paralelo con el sistema vigente,
implica la instalación total del sistema en el ambiente de producción, su
ejecución con datos reales y la comparación de sus resultados con los que
produce el sistema vigente.
Una vez que estos procesos de aceptación se cumplen, el nuevo
sistema pasa a ser el sistema oficial y se desinstalan todos los
componentes que correspondan al sistema que se reemplaza.
4.1.2.- Implementación parcial
Muchas veces se realiza lo que se denomina instalación piloto, para
asegurar que el sistema se comporta adecuadamente en el ambiente de
producción. También, si los usuarios se encuentran dispersos en
localidades muy distantes y existen diferencias importantes de horario, se
prefiere ir cubriendo grupos de usuarios separadamente. En estos casos,
93
Capítulo VI
los usuarios finales deben estar informados del calendario de instalación

y la forma cómo podrían afectarse sus actividades diarias.
5.- Soporte inicial
Normalmente, en el inicio de un nuevo servicio pueden haber errores
que hayan pasado desapercibidos por los diferentes procesos de prueba,
por lo que debe considerarse que las versiones que están cumpliendo el
período de aceptación pudieran requerir la intervención de algún
miembro del personal de desarrollo o del personal de soporte, para ello
los procedimientos deben contemplar la posibilidad de otorgar
autorizaciones temporales, para que estos técnicos puedan cumplir su
cometido, con agilidad.
Será muy importante para evaluar el desempeño de los equipos de
desarrollo que, aunque estas tareas de soporte inicial se cumplan
flexiblemente, queden bien registradas bajo las disciplinas de manejo de
incidentes y de problemas.
Para evaluar el desempeño de la disciplina de administración de
versiones será importante generar informes periódicos que ofrezcan una
información precisa de las acciones cumplidas y presenten una métrica
cubriendo aspectos como:
• Número de nuevas versiones implantadas, por categoría
• Número de procesos de retorno que se han tenido que realizar y
razones que privaron para realizarlos.
• Incidentes asociadas a nuevas versiones.
• Uso de recursos en cada caso.
• Existencia de versiones ilegales de software.
• Adecuado registro de las nuevas versiones en la base de datos de
configuración.
• Incidentes provocados por un uso incorrecto de la nueva versión
por parte de los usuarios.
• Disponibilidad del servicio durante y después del proceso de
implantación de la nueva versión.
94
Capítulo VII

Ca m bios
Capítulo VII
Tabla de contenido
1.- ¿En qué consiste la administración de cambios? ........................97

1.1.- Ventajas .............................................................................98
1.2.- Barreras..............................................................................98
2.- Elementos ...................................................................................99
3.- Roles ...........................................................................................99
4.- Actividades ...............................................................................100
4.1.- Registrar...........................................................................101
4.2.- Aceptación de la solicitud................................................102
4.3.- Clasificación ....................................................................102
5.- Aprobación y Planificación ......................................................104
6.- Implementación ........................................................................105
7.- Evaluación ................................................................................106
8.- Evaluación de la disciplina .......................................................106
96
1.- ¿En qué consiste la administración de cambios?

El cambio, dentro de una infraestructura de servicios, es algo
constante; se instalan nuevas aplicaciones, nuevos equipos, nuevos
puntos de red, nuevas estaciones de trabajo, nuevas versiones del
software instalado, etc. Por esta razón es imperativo que todos esos
cambios se realicen ordenadamente, sin que afecten el servicio de la
plataforma TI, y que sean el resultado del trabajo en equipo, con la
participación de todos los responsables, el personal de soporte requerido
y los usuarios afectados por el cambio.
ITIL define un cambio como la adición, modificación o
eliminación de un servicio o componente autorizado,
planificado o de soporte y su documentación relacionada .
El principal objetivo de la Administración de cambios es evaluar y
planificar el proceso de cambio para asegurar que se realice de la forma
más eficiente, siguiendo los procedimientos establecidos y asegurando en
todo momento la calidad y continuidad de los servicios de TI.
La administración de cambios debe trabajar para asegurar que los
cambios:
• Están justificados y debidamente sustentados.
• Están convenientemente registrados, clasificados y
documentados.
• Han sido cuidadosamente probados en un ambiente de
prueba.
• Se llevan a cabo sin perjuicio de la calidad del servicio TI.
• Se reflejen en la base de datos de componentes.
• Están acompañados de un plan para deshacer el cambio –
backout-, en caso de que el cambio pueda generar problemas
en el servicio, por cualquier falla que pueda presentar.
97
Capítulo VII
• Asegurar que en la instalación de un cambio participe todo el

personal de soporte –analistas, técnicos de soporte, técnicos
de red, técnicos de base de datos, etc.- y usuario necesarios
para lograr una implementación exitosa.
1.1.- Ventajas
La administración de cambios, por lo permanente y constante de los
cambios, viene a ser una de las disciplinas medulares para poder asegurar
la continuidad de los servicios. En general, podemos decir que su correcta
aplicación puede brindar las siguientes ventajas:
• Se reduce el número de incidentes y problemas que
potencialmente un cambio puede generar.
• Se puede regresar a la situación anterior sin mayores
dificultades, en caso de que el cambio no resulte exitoso.
• Se estimula el trabajo en equipo, al lograr la participación
ordenada y planificada de técnicos y usuarios.
• Los cambios se asimilan más fácilmente.
• Se pueden evaluar los verdaderos costos asociados a un
cambio.
• La base de datos de configuraciones se actualiza
correctamente.
1.2.- Barreras
La disciplina de administración de cambios tropieza con una serie de
barreras como las que a continuación enumeramos:
• No se acepta la autoridad del administrador de cambios.
• Existe la tendencia a instalar cambios de manera
independiente, sin mayor planificación.
• Existe tendencia a ignorar los procedimientos establecidos y,
en particular, a evitar las tareas de actualización de la base de
datos de configuraciones.
• Los encargados de la administración de cambios no conocen
a fondo las actividades, servicios, necesidades y estructura TI
de la organización, lo cual los incapacita para desarrollar
correctamente su actividad.
• Los administradores de cambios no disponen de las
herramientas adecuadas de software para hacer seguimiento y
documentar adecuadamente el proceso.
98
• Se implementan procedimientos demasiado rígidos, que

dificultan los procesos de cambios medianos y menores, que
constituyen la gran mayoría de los cambios.
2.- Elementos
Los procedimientos de administración de cambios que se adopten
deben definir los siguientes elementos:
• Qué categorías de cambio existen, por ejemplo: mayor,
mediano, menor.
• Cómo se solicita un cambio.
• Cómo se evalúa y categoriza un cambio.
• Cómo se procesa un cambio.
• Cuáles son los niveles de aprobación de un cambio,
dependiendo de su impacto y su categoría.
• Criterios para aceptar, rechazar o posponer un cambio.
Debe tenerse muy presente que el objetivo central de la disciplina de
administración de cambios no es “evitar los cambios”. Tal actitud, sería
absurda, pues la situación normal en cualquier departamento tecnología
es la necesidad constante de implementar cambios. Podemos afirmar que,
por el contrario, el objetivo central del procedimiento de control de
cambios es evitar que los cambios se adopten sin orden ni concierto,
asegurar que solamente se adopten los cambios que realmente requiere el
negocio y estimular el trabajo en equipo.
3.- Roles
En los procedimientos de administración de cambios participan varios
personajes:
1. Proponente:
Es cualquier persona que determina la necesidad de implementar un
cambio y prepara una solicitud de cambio.
2. Administrador de cambios:
Es la persona encargada de motorizar todos los procedimientos que
conforman la administración de cambios, entre ellas:
Procesar todas las solicitudes de cambio.
Asegurar una adecuada evaluación del impacto que cada
cambio pueda tener, antes de que el mismo sea
aprobado.
99
Capítulo VII
Presidir las reuniones del comité de cambios.

3. Técnico evaluador:
Es cualquier persona que, dada su calificación, puede dar una opinión
acerca de la viabilidad de un cambio o pueda determinar el impacto
que dicho cambio tendrá.
4. Comité de cambios –Change Advisory Board (CAB)-:
La función del comité de control de cambios es estudiar cada
solicitud de cambio y recomendar a la gerencia de TI su aprobación o
rechazo. La dirección de este comité estará a cargo del administrador
de cambios y lo integrarán las personas que designe la gerencia de
tecnología de información, como pudieran ser técnicos de soporte,
analistas de sistemas, usuarios, técnicos del centro de atención, etc.
5. Parte afectada:
Es el representante de una función, un departamento, un sistema o un
proyecto sobre el cual un cambio pueda tener impacto, por lo que
tiene particular interés en que el cambio se realice sin ningún trauma.
6. Comité de cambios ampliado:
Es el comité que integran los miembros del comité de control de
cambios y las partes afectadas por un cambio en particular.
7. Grupo implementador:
Es el grupo de técnicos o unidad de la organización que llevará a
cabo la implantación del cambio, con la ayuda de los grupos de
soporte.
8. Grupo de soporte:
Es un grupo de técnicos designados por la jefatura de sus
correspondientes departamentos –soporte técnico, sistemas, centro de
atención, etc.- para apoyar y dar soporte al grupo implementador.
4.- Actividades
La administración de cambios normalmente incluye actividades como
las siguientes:
• Monitorizar y dirigir todo el proceso de cambio.
• Registrar, evaluar y aceptar o rechazar las solicitudes de
cambios recibidas.
• Convocar reuniones del comité de cambios, excepto en el
caso de cambios menores, para la aprobación de las solicitud
de cambios.
100
• Coordinar el desarrollo e implementación del cambio.

• Evaluar los resultados del cambio y proceder a su cierre en
caso de éxito.
4.1.- Registrar
El primer paso del proceso de cambio es registrar las solicitudes de
cambio. Estas solicitudes pueden venir de cualquier parte interesada:
• Administración de problemas, disciplina encargada de
proponer soluciones a errores conocidos, que, normalmente,
requieren la aplicación de un cambio en la infraestructura de
TI.
• Instalación de nuevos servicios, que requieren un cambio en
el hardware o software de la infraestructura de TI.
• Requerimientos de instalación o actualización para
aplicaciones en producción o para el software base,
generados de acuerdo con la disciplina de administración de
versiones.
• Cualquier empleado, cliente o proveedor puede sugerir
mejoras en los servicios que pueden requerir cambios en la
infraestructura.
Una solicitud de cambio, deberá incluir como mínimo la siguiente
información:
• Fecha de preparación.
• Número identificador de la solicitud de cambio.
• Descripción del cambio propuesto:
Propósito -nuevo servicio, actualización, corrección de
error conocido, solución de problema, etc.
Ítems de configuración involucrados.
Estimado de personal y recursos que deben participar en
la implementación del cambio.
Tiempo estimado.
El registro de la solicitud de cambios se irá actualizando a medida que
se vayan cumpliendo las diferentes tareas, con el fin de poder realizar un
seguimiento detallado del proceso, desde su inicio hasta la evaluación
final y su cierre definitivo.
La información de registro debe ser actualizada durante todo el
proceso y debe incluir información como la siguiente:
101
Capítulo VII
• Estatus de la solicitud –registrado, aceptado, rechazado,

discutido en comité, planificado, implementado-
• Fecha de aceptación o rechazo de la solicitud de cambio.
• Evaluación del impacto del cambio en términos de servicios,
aplicaciones, usuarios o componentes afectados.
• Calificación de la magnitud, prioridad y categoría del cambio
• Planes de retorno o back out.
• Recursos asignados.
• Fecha de implementación.
• Plan de implementación.
• Resultados de la revisión post-implementación.
• Evaluación final.
• Fecha de cierre.
4.2.- Aceptación de la solicitud
Una vez que el administrador de cambios recibe una solicitud,
determina quiénes, dentro de la organización, pueden evaluar la solicitud
para determinar si consideran viable el cambio y el impacto que puede
tener en los servicios y sus diferentes componentes.
Una solicitud de cambio puede ser rechazada, si se considera que el
cambio no es viable o no está justificado. La aceptación de una solicitud
de cambio no implica que vaya a ser aprobada por el comité de cambios
ni que vaya a ser implementado.
4.3.- Clasificación
Una vez que el cambio solicitado ha sido evaluado, se evaluarán su
prioridad, su impacto y los factores de riesgo que podrían amenazar el
éxito del cambio.
La prioridad que se asigne expresará la importancia que tiene una
solicitud de cambio en relación con otras solicitud de cambios pendientes
y permitirá establecer el orden en que se irán procesando e implantando
los cambios. La experiencia ha enseñado que una buena forma de
establecer los niveles de prioridad, puede ser la siguiente:
• Baja:
Es frecuente que se prefiera realizar los cambios de prioridad
baja junto con otros cambios que guarden alguna relación.
• Normal:
102
Para los cambios de prioridad normal, debe buscarse el mejor

momento, cuando ofrezca menor riesgo y no entorpezca la
implantación de algún otro cambio de mayor prioridad.
• Alta:
Un cambio de prioridad alta debe realizarse lo más pronto
posible. Normalmente están asociados a solucionar
problemas o errores conocidos, que están afectando el
desempeño de la infraestructura de servicios.
• Urgente:
Los cambios urgentes son aquellos que deben implementarse
para resolver un problema que esté causando serias
dificultades en el servicio; por lo regular, estos cambios no
son de gran magnitud. Es frecuente que los cambios urgentes
se procesen bajo el control de procedimientos especiales, que
aseguren la implantación rápida del mismo.
Muchas veces los procedimientos de administración de cambios

adoptan toda una diversidad de categorías, que poco ayudan a cumplir
con los objetivos que persigue el procedimiento. Será recomendable
adoptar una categorización sencilla de los impactos, como pudiera ser:
cambios simples -que requieren poca participación del personal TI-,
cambios medianos -que casi no tienen efecto sobre la calidad del servicio-
103
Capítulo VII
o complejos -que afectan un área importante del servicio de TI o que

necesitan una gran cantidad de recursos-.
En resumen, diremos que un cambio será categorizado de acuerdo
con:
Su prioridad -baja, normal, alta y urgente-.
Su impacto -simple, mediano o complejo-.
En general, los procedimientos de administración de cambios
establecerán los diferentes caminos que deberán tomarse para llevar a
cabo con éxito la implementación de las diferentes categorías de cambio.
5.- Aprobación y Planificación
Por lo regular, cada cambio será discutido y evaluado por el comité de
cambios; en algunos casos el comité tendrá autoridad para aprobarlo –por
ejemplo, los cambios simples y medianos-, mientras que para los
restantes –cambios complejos- deberá solicitar su aprobación de la
gerencia de TI o del comité de sistema, en las empresas que existe ese
tipo de comité. En el caso de tener que solicitar la autorización de la
gerencia, el comité de cambios deberá presentar su recomendación.
Para darle flexibilidad a los procedimientos, en muchas
organizaciones los cambios simples no se llevan a la discusión del comité
de cambios y son aprobados directamente por el administrador de
cambios, una vez que revisa la evaluación del mismo y los planes de
acción para implementarlo.
El comité de cambios se reúne periódicamente analizar y aprobar o
rechazar las solicitudes de cambios que estén pendientes y evaluar los
planes de acción desarrollados para cada cambio; en particular el comité
evaluará:
• ¿Cuáles son los beneficios esperados del cambio propuesto?
• ¿Está justificado el cambio, e acuerdo con ese costo?
• ¿Cuáles son los riesgos asociados?
• ¿Cuáles son las acciones de mitigación para esos riesgos, que
se han incluido en el plan de acción?
• ¿Se dispone de los recursos necesarios para realizar el
cambio con éxito?
• ¿Cuál será el impacto sobre la infraestructura y la calidad de
los servicios TI?
• ¿Permitirá el cambio mantener los niveles de seguridad?
104
• ¿Puede postergarse el cambio? ¿Hasta cuándo?

Una vez que un cambio se aprueba debe evaluarse la oportunidad en
que el cambio debe ser implementado. Para establecer la mejor
oportunidad, dependiendo de la categoría del cambio, el comité de
cambios preferirá convocar una reunión del comité de cambios ampliado
– integrado por los miembros del comité de control de cambios más las
partes afectadas por un cambio en particular-. En cualquier caso siempre
deberá informarse formalmente tanto a los usuarios involucrados o
afectados por el cambio, como al centro de atención, con el fin de que
conozcan los eventos que podrían eventualmente generar problemas.
La oportunidad del cambio permitirá concretar y detallar los
cronogramas que deberá detallar el grupo implementador -responsable de
llevar a cabo la implantación del cambio- y de comunicarlo a todos los
involucrados.
6.- Implementación
La administración de cambios no incluye las responsabilidades de
implantación de los cambios, ya que dicha implantación será
responsabilidad de alguna unidad técnica -de soporte o sistemas-, que
hemos denominado el grupo implementador, con el apoyo del
personal de diferentes unidades, que hemos denominado grupo de
soporte. Muchos de los cambios serán implementados bajo el control de
los procedimientos de administración de versiones.
Sin embargo, especialmente para los cambios complejos o de alta
prioridad, el administrador de cambios monitorizará el proceso de cambio
para asegurar que se cumplen los cronogramas previstos y la adecuada
asignación de recursos, tanto para el grupo implementador, como para el
grupo de soporte.
Es importante velar por una buena comunicación; al momento de
implantarse el cambio; ningún usuario, proveedor o técnico del centro de
atención debe ignorar que se está realizando un cambio. Será
responsabilidad de la administración de cambios y del centro de atención
mantener informados a los usuarios sobre los cambios y facilitar su
aceptación:
• Escuchando sus sugerencias.
• Comunicando las ventajas asociadas.
• Aclarando dudas y brindando soporte cuando sea necesario.
105
Capítulo VII
• Asegurando que los usuarios y clientes perciban todo cambio

como mejora.
7.- Evaluación
Antes de dar por concluido un proceso de cambio, será necesario
realizar una evaluación que determine el valor y la verdadera
contribución a la calidad del servicio y a la productividad de los usuarios.
Al realizar esa evaluación, deberán considerarse aspectos como:
• ¿Se cumplieron los objetivos previstos?
• ¿En que medida hubo desviaciones con respecto a la
planificación?
• ¿Fue necesario utilizar los planes de retorno o back-out? ¿Por
qué?
• ¿Provocó el cambio algún problema o interrupción no
prevista del servicio?
• ¿Cuál ha sido la percepción de los usuarios en relación al
cambio?
Si la evaluación final determina que el proceso y los resultados han
sido satisfactorios se procederá al cierre de la solicitud de cambio.
Para evaluar el desempeño de la disciplina de administración de
cambios será importante generar informes periódicos que ofrezcan una
información precisa de las acciones cumplidas y presenten una métrica
cubriendo aspectos como:
• Solicitudes de cambio recibidas.
• Proporción de solicitudes aprobadas y rechazadas
• Cantidad de cambios implementados, clasificados por
impacto y prioridad.
• Cantidad de cambios de emergencia realizados.
• Porcentaje de cambios exitosos en primera instancia, segunda
instancia, etc.
• Numero de retornos o backouts detallando las razones de su
aplicación.
• Evaluaciones post-implementación.
• Porcentajes de cambios cerrados sin incidencias posteriores.
106
• Incidencias asociadas a los cambios realizados.

• Número de reuniones del comité de cambios, indicando
cantidad de asistentes, duración, cantidad de cambios
evaluados por reunión, etc.
107
Capítulo VII
Esquema de la administración de cambios
108
Capítulo VIII
M onit oriza c ión y

Cont rol
Capítulo VIII
Tabla de contenido
1.- ¿En qué consiste monitorización y control? .............................111

1.1.- Ventajas ...........................................................................113
1.2.- Barreras............................................................................114
2.- Ciclo de monitorización............................................................114
3.- Terminología ............................................................................115
4.- Herramientas.............................................................................116
5.- Niveles de monitorización ........................................................117
6.- Formas de monitorización ........................................................118
7.- Implementación de la disciplina ...............................................119
110
1.- ¿En qué consiste monitorización y control?

De acuerdo con el diccionario de la Real Academia Española,
monitorizar es la acción de “observar mediante aparatos especiales el
curso de uno o varios parámetros fisiológicos o de otra naturaleza para
detectar posibles anomalías”.
En informática hemos adoptado el término, dándole un sentido
similar, el de observar el comportamiento de los componentes de la
infraestructura tecnológica, con el fin de detectar cualquier anomalía.
Coincidiendo con la definición del DRAE, estas actividades de
observación, normalmente se hacen mediante componentes de hardware y
software especialmente diseñados para ello.
Los problemas de desempeño de la infraestructura de TI pueden
causar dos tipos de dificultades para el negocio:
1. Caídas de sistema (Hard Downtime), cuando los equipos
fallan o se presentan problemas físicos que provocan que los
usuarios no puedan continuar con su trabajo.
2. Bajo desempeño (Soft Downtime) de los sistemas que
integran la red, los servidores las aplicaciones, los dispositivos
de interconexión, los segmentos, enlaces, etc. que puede ser
causado por múltiples factores, pero que afectan el trabajo de
los usuarios, impidiendo que este pueda cumplirse con la
dinámica requerida.
Cuando ocurre una caída del sistema, se detienen las transacciones y
se interrumpen los servicios al cliente, lo cual acarrea pérdidas a la
empresa.
Cuando se degradan los servicios, las consecuencias son menos
catastróficas, sin embargo, la experiencia muestra que estos “Soft
Downtime” son más costosos para las empresas, porque ocurren con
mayor frecuencia.
Las caídas de sistema pueden ser ocasionadas por una enorme
variedad de factores, por lo que la tarea de identificar la raíz de los
111
Capítulo VIII
problemas normalmente es una tarea muy compleja. Como ejemplo

podemos citar fallas que pueden presentar elementos como: servidores,
cableado estructurado, equipos de red, aplicaciones, protocolos de
comunicación, enlaces, PC’s, etc. Como causas de falla pueden citarse:
fallas físicas, errores de configuración, errores de programación, ataques
de virus, etc.
Dado que esta diversidad de fallas causa pérdidas tanto tangibles,
como intangibles –imagen, prestigio, etc.- a la empresa, resulta crucial
poder contar con la capacidad de detectar las fallas desde la raíz, de la
forma más rápida y precisa posible. Es decir, es necesario monitorizar y
analizar el desempeño de los diferentes elementos de TI, para poder
identificar dónde están los problemas y cuáles son sus causas.
La disciplina de monitorización y control es la disciplina encargada de
supervisar y controlar los componentes de la infraestructura, así como
también de observar su funcionamiento para enviar alertas sobre las
condiciones de salud -características que indican éxito o falla- de la
infraestructura y, cuando sea posible, corregir automáticamente las fallas
detectadas.
112
Dentro de la administración de servicios de TI, monitorización y

control, junto con administración de configuraciones son las dos
disciplinas que requieren mayor ayuda de herramientas adecuadas para su
funcionamiento y que sin éstas son prácticamente imposibles de
implementar.
Lo usual para el cumplimiento de la disciplina es que el grupo de
técnicos de monitorización, ubicados en un local acondicionado
especialmente, dispongan de varios monitores que permiten visualizar la
representación gráfica de diferentes nodos o secciones de la
infraestructura. En estos monitores se pueden visualizar las diferentes
situaciones que se van detectando, de acuerdo con los modelos de salud
que se hayan definido.
En un modelo de salud se establece la información que debe ser
recolectada por los diferentes agentes o herramientas de monitoreo y
cómo el sistema o los técnicos deben responder a los diferentes valores.
Normalmente, las herramientas de monitorización ofrecen la facilidad de
presentar gráficamente -utilizando indicadores con color verde o rojo- la
situación de la infraestructura, para que los técnicos puedan determinar de
un vistazo si hay un problema en alguno de los sistemas o de los
componentes.
La disciplina de monitorización y control produce como subproducto
una gran cantidad de información de gran utilidad para ser utilizada por
otras disciplinas, facilitando su cumplimiento, como es el caso de la
administración de niveles de servicio y la administración de
disponibilidad.
1.1.- Ventajas
La implantación de la disciplina de monitorización y control puede
brindar múltiples ventajas, entre las que cabe citar las siguientes:
• Capacidad para anticipar algunos problemas en el servicio.
• Resolución más rápida de los problemas reales y potenciales de
servicio, cuando se utilizan herramientas que permiten tomar
acciones correctivas automatizadas.
• Soporte más dinámico a la ejecución de las operaciones del
negocio.
• Disponibilidad de información sobre el funcionamiento de la
infraestructura tecnológica.
• Mayor disponibilidad de los servicios.
113
Capítulo VIII
• Mejor comprensión de los componentes que, dentro de la

infraestructura, son prioritarios para la entrega de servicios.
• Mayor satisfacción de los usuarios.
• Respuestas más rápidas y más eficaces a los incidentes.
• Reducción de la cantidad de incidentes por la aplicación de
acciones preventivas.
1.2.- Barreras
La disciplina de monitorización y control tropieza con una serie de
barreras como las que a continuación enumeramos:
• No se adoptan herramientas adecuadas.
• No se adiestra debidamente al personal.
• No se crea el ambiente de trabajo adecuado, para que el
personal de monitorización pueda operar con comodidad y
disponga de facilidades de comunicación.
• Si la capacidad de la infraestructura de TI es demasiado
limitada, las exigencias de proceso y tiempo de respuesta de
las herramientas de monitoreo podrían afectar el desempeño
general.
• No se establecen vínculos ágiles con las restantes disciplinas.
• No se aprovecha la información que reúne el proceso de
monitorización, para ser utilizada por las restantes disciplinas
de servicio.
2.- Ciclo de monitorización
114
Tal como podemos observar en la figura, el ciclo de monitorización y

control observa un proceso o una actividad o su resultado, comparando
tales mediciones con una norma preestablecida o estándar, con el fin de
determinar si el proceso se está cumpliendo dentro de los parámetros de
calidad y desempeño.
En caso de que el estándar no se esté cumpliendo, debe
desencadenarse una acción correctiva que, dependiendo de la
sofisticación de las herramientas y de la naturaleza del problema, puede
ser una acción correctiva que se dispare automáticamente o la generación
de un reporte de incidente, para que, de acuerdo con lo establecido por las
disciplinas de manejo de incidentes y de problemas, se tomen las
acciones necesarias.
3.- Terminología
Con el fin de asegurar que los procedimientos se establezcan sin
ambigüedades, es importante tener claras varias definiciones importantes
para esta disciplina:
1. Servicio
Un servicio es una función que se realiza para el negocio y que, por
lo tanto, debe definirse desde ese punto de vista; por ejemplo, los
servicios de correo electrónico y los de impresión pueden ser
considerados como un servicio, independientemente del número de
componentes o ítems de configuración que intervienen en su entrega.
2. Catálogo de servicios
Los servicios que se prestan en una organización de TI, se registran
en el catálogo de servicios, en este catálogo, creado y manejado por
los administradores de monitorización y control, se incluye también
un desglose de los componentes de la infraestructura que soporta la
producción del servicio, denominados componentes del servicio.
3. Instrumental
El instrumental lo integran las herramientas y los mecanismos que se
utilizan para determinar el estado de un componente. No siempre es
posible disponer de instrumentos para monitorizar la salud de algunos
componentes, especialmente para muchos de los componentes de
software.
4. Componentes de servicio
Los componentes de servicio son ítems de configuración, cuya
información se encuentra almacenada en la base de datos de
115
Capítulo VIII
componentes. Aquellos componentes de servicio para los que se

dispone el instrumental necesario para determinar su salud, podrán
ser observados continuamente, para determinar la salud total de un
servicio.
5. Patrón de salud
En un patrón de salud se definen las condiciones que permiten
determinar que un servicio está funcionando en condiciones normales
o presenta fallas. Estos patrones son indispensables para que los
sistemas y el equipo humano de monitorización y control puedan
discernir si un determinado servicio está funcionando
satisfactoriamente.
4.- Herramientas
Si bien todas las disciplinas de administración de servicios requieren
herramientas que, con diversos grados de sofisticación, faciliten su
proceso, en el caso de la disciplina de monitorización y control es de
crucial importancia dotarla de herramientas robustas y de amplio alcance.
Así pues, las herramientas que se seleccionen deberán tener
características como las siguientes:
1- Alta disponibilidad
.Deben operar bajo ambientes de alta disponibilidad, como
“clusters”, etc. y deben haber sido desarrolladas con facilidades que
les permitan ofrecer una alta disponibilidad.
2- Arquitectura compatible.
Obviamente, las herramientas de monitorización y control deben
ser compatibles con la infraestructura instalada.
3- Adaptabilidad
Las herramientas de monitorización y control deben tener la
capacidad de operar en redes donde se combinan diferentes
topologías.
4- Agilidad de notificaciones
Deben tener capacidad para notificar a los técnicos en las consolas
de monitoreo y también para notificar a técnicos responsables de
los servicios que presenten alguna condición, en la forma más
rápida posible.
116
5- Presentación gráfica
Deben tener capacidad para mostrar en forma simple,
preferiblemente en forma gráfica, cualquier anomalía detectada en
cualquiera de los componentes monitorizados.
6- Autodescubrimiento
Deben tener, en lo posible, la capacidad de identificar los cambios
que se hagan en la infraestructura.
7- De bajo impacto.
Deben tener agentes de supervisión livianos, que causen un mínimo
impacto en el desempeño de la infraestructura que se supervisa.
8- Escalabilidad
Deben tener la capacidad de crecer, a medida que crece la cantidad
de objetos manejados y el número de acontecimientos simultáneos
que debe procesar en un momento dado.
9- Interoperabilidad.
Deben satisfacer los requerimientos de interoperabilidad,
integrándose con otras herramientas de administración de servicios
10- Base de datos.
Deben almacenar los datos del funcionamiento de la
infraestructura, para ser utilizados por otras disciplinas de
administración de servicios.
11- Base de conocimiento.
Deben ofrecer facilidades para almacenar los conocimientos que se
vayan derivando de las experiencias, para uso de los técnicos de
monitorización.
12- Seguridad.
Deben cumplir con requerimientos de seguridad, tal como niveles
de acceso y autorizaciones basadas en roles.
5.- Niveles de monitorización
Podemos distinguir dos niveles de monitorización:
1- El nivel interno
El nivel interno de monitorización centra su atención en los
componentes de la infraestructura, evaluando su correcto
funcionamiento.
117
Capítulo VIII
2- El nivel externo
El nivel externo de monitorización centra su atención en los
servicios -como correo, impresión, base de datos, etc.-
independientemente de la multiplicidad de los componentes que
intervienen en su producción.
Un buen servicio de monitorización debe combinar ambos niveles,
con el fin de poder establecer tanto la calidad de los servicios, como la
adecuación de la infraestructura y sus componentes.
6.- Formas de monitorización
Existen varias formas de monitorizar una infraestructura de TI:
1- Activa o pasiva
La monitorización activa consiste en la interrogación que se hace
sobre un dispositivo o un sistema.
La monitorización pasiva es la que se hace utilizando un agente que
envía señales o mensajes que permiten identificar diferentes
situaciones en un dispositivo o sección de la infraestructura.
2- Reactiva o preventiva
En una monitorización reactiva, se diseña una o más acciones que
deberán ser tomadas en caso de que se determine cierta condición.
La monitorización preventiva consiste en analizar un conjunto de
patrones de comportamiento que permiten predecir un problema.
Este tipo de monitorización es más común en organizaciones
maduras, en las que la disciplina de monitorización ha logrado
acumular experiencias significativas.
3- De medición continua o por excepción
La medición continua corresponde a una medición en tiempo real
para asegurar que el componente o el sistema que se monitorea
están funcionando dentro de los estándares preestablecidos.
La monitorización por excepción no realiza una medición, sino que
descubre y reporta alguna excepción, como puede ser la
terminación anormal de algún programa.
4- Desempeño o resultado
La monitorización de desempeño se centra en el funcionamiento de
los componentes, mientras que la monitorización a los resultados se
centra en la calidad del output producido. Cabe señalar que en ITIL
se presta mayor atención a los procesos.
118
Para cada tipo de componente o servicio que se desee monitorizar

siempre habrá la mejor combinación de tipos de monitorización, por lo
que podemos afirmar que un buen servicio de monitorización debe
combinar los diferentes tipos.
7.- Implementación de la disciplina
Indudablemente, una de las disciplinas más difíciles de implementar y
adaptar es la disciplina de monitorización y control. En cualquier
organización, grande o pequeña, sólo será posible lograr resultados
exitosos si su implementación se va haciendo gradualmente y para cada
grupo de componentes y servicios que se vayan incorporando a la
disciplina ir instalando herramientas, estableciendo procedimientos,
adiestrando al personal y comunicando a toda la organización los
progresos que se vayan haciendo. Así pues, para cada etapa será
necesario cumplir pasos como los siguientes:
• Determinar qué se va a monitorizar.
• Determinar qué nivel de monitorización.
• Establecer qué formas de monitorización se combinarán.
• Establecer qué formas de monitorización pueden aplicarse
• Seleccionar las herramientas a utilizar.
• Desarrollar procedimientos.
• Adiestrar el personal de monitorización.
• Adiestrar el personal de otros departamentos.
Si bien es importante evaluar el desempeño de cualquiera de las
disciplinas de administración de servicios, en el caso de monitorización y
control es fundamentalísimo evaluar su desempeño y la utilidad que
presta a la organización. Con tal fin, pueden o deben producirse
mediciones, métricas e indicadores clave, entendiendo estos conceptos de
la siguiente forma:
1- Mediciones
Una medición se refiere a las técnicas para evaluar el alcance, la
dimensión o la capacidad de algún ítem de configuración, con
respecto a una norma.
119
Capítulo VIII
2- Métricas
Una métrica es el conjunto de procedimientos que se cumplen para
evaluar cuantitativamente con cierta periodicidad un proceso o un
sistema, junto con los procedimientos para interpretar los
resultados. Es decir, en una métrica se establece lo que se va a
medir, la forma como se va a medir y la forma como se van a
interpretar los resultados.
3- Indicadores clave
Un indicador clave corresponde a un nivel de desempeño o
medición, establecido y acordado previamente, para calificar la
efectividad de una organización o de un servicio.
120
Capítulo IX

N ive le s de Se rvic io
Capítulo IX

Tabla de contenido
1.- ¿En qué consiste la administración de niveles de servicio?......123

1.1.- Ventajas ...........................................................................124
1.2.- Barreras............................................................................125
2.- Terminología ............................................................................125
2.1.- Proveedores, clientes y usuarios ......................................125
2.2.- Catálogo de servicios - Service Catalog (SC)..................126
2.3.- Acuerdo de nivel de servicio............................................127
2.4.- Acuerdo de nivel operacional (OLA) ..............................127
2.5.- Programa de calidad de servicio (SQP) ...........................128
3.- Creación del catálogo de servicios ...........................................128
4.- Proceso .....................................................................................130
4.1.- Preparación ......................................................................130
4.2.- Seguimiento .....................................................................131
4.3.- Revisión continua ............................................................132
122
1.- ¿En qué consiste la administración de niveles de

servicio?
Es frecuente presenciar discusiones sobre la calidad de un servicio,
mientras unos opinan que es adecuada, otros opinan que no, que es de
bajo nivel. Es muy difícil establecer quién tiene la razón si no existe, para
ese servicio, un patrón que defina cuando es de calidad y cuando no lo es.
Ese es el origen de los niveles de servicio, poder establecer los
patrones de calidad para cada uno de los servicios que presta la
organización de informática y tomar las acciones necesarias para asegurar
que tales servicios se ajusten a ese patrón.
Claro está, la idea anterior es un poco simplista, ya que la disciplina
de administración de niveles de servicio es un poco más que eso, ya que
esta disciplina debe velar por la calidad de los servicios TI, alineando
tecnología con procesos de negocio, dentro de unos niveles de costo
razonables.
Para cumplir esos objetivos resulta imprescindible que la
administración de niveles de servicio:
• Conozca las necesidades de sus usuarios.
• Establezca los rangos de costo que pueden acarrear los diferentes
niveles de calidad –a mayor calidad mayor costo-.
• Acordar con los usuarios los niveles de calidad requeridos para los
servicios que reciben, dentro de rangos de costo razonables.
• Monitorizar que la calidad de los servicios cumplen con los
acuerdos establecidos.
• Establecer planes de acción para mejorar en forma continua la
calidad del servicio.
Así pues podemos decir que la administración de niveles de servicio
es el proceso por el cual se define, negocia y supervisa la calidad de los
servicios TI. Para ello, la disciplina busca establecer compromisos
123
Capítulo IX
realistas entre las necesidades y expectativas del usuario o cliente y la

posibilidad de satisfacerlas a un costo razonable.
En líneas generales, podemos decir que la administración de niveles
de servicio debe incluir actividades como las siguientes:
• Documentar los servicios que ofrece TI.
• Presentar los servicios en forma comprensible para el usuario.
• Centrar la atención en el usuario y sus procesos, no en la
tecnología.
• Trabajar con el usuario para determinar niveles de calidad para los
servicios que requiere, dentro de parámetros realistas y ajustados a
sus necesidades reales.
• Establecer los indicadores claves de rendimiento del servicio TI,
que permitan verificar si se cumplen los niveles de calidad
acordados.
• Monitorizar la calidad de los servicios acordados, buscando en
todo momento mejorarlos a un costo razonable.
• Elaborar los informes sobre la calidad del servicio y planes de
mejora.
1.1.- Ventajas
La adopción de la disciplina de administración de niveles de servicio,
puede tener las siguientes ventajas:
• Los servicios TI se ajustan para cumplir las necesidades de los
usuarios.
• Se simplifica la comunicación con los usuarios y se evitan los
malentendidos sobre la calidad de los servicios requeridos.
• Se establecen objetivos claros y mesurables.
• Se establecen claramente las responsabilidades tanto de TI, como
de los usuarios.
• Los usuarios toman conciencia y aceptan los niveles de calidad
ofrecidos.
• El seguimiento permanente del servicio permite detectar
debilidades y aspectos a mejorar.
• El personal del centro de atención dispone de la documentación
necesaria para llevar una relación fluida con usuarios, clientes y
proveedores.
124
• Los acuerdos de servicio, permiten que la gerencia de TI pueda

calcular los costos y justificar sus presupuestos.
• El esquema que aplica TI con sus usuarios, puede ser adoptado
con sus proveedores, con el fin de asegurar una calidad creciente
de sus servicios.
Todo lo cual repercutirá en un mejor servicio y la consecuente
satisfacción de usuarios y ejecutivos de la empresa.
1.2.- Barreras
Una de las disciplinas más difíciles de adoptar es la administración de
niveles de servicio, pues tropieza con innumerables barreras, como las
que citamos a continuación:
y No existe un verdadero compromiso con la calidad de los servicios
ofrecidos por TI.
y No se alinean adecuadamente los servicios TI con los procesos del
negocio.
y No existe una buena comunicación con los usuarios por lo que los
acuerdos de niveles de servicios no expresan las necesidades reales.
y Los acuerdos de niveles de servicio están basados más en deseos y
expectativas del cliente que en las capacidades reales que la
infraestructura TI permite ofrecer.
y Los acuerdos de servicio incluyen demasiados detalles técnicos, lo
cual impide que los usuarios se identifiquen con ellos.
y No se asigna suficiente personal calificado a la administración de
niveles de servicio.
y Por fallas de comunicación, algunos usuarios desconocen las
características de los acuerdos.
y No se monitoriza adecuada y consistentemente el cumplimiento de
los niveles de servicio, lo cual minimiza el valor de la disciplina y
dificulta la posibilidad de mejorar la calidad del servicio.
2.- Terminología
2.1.- Proveedores, clientes y usuarios
Cliente es una empresa u organismo que contrata los servicios de TI.
Los usuarios son las personas que utilizan los servicios de TI para el
cumplimiento de sus funciones.
125
Capítulo IX
Proveedor es una empresa u organismo que presta los servicios que

requiere un cliente.
2.2.- Catálogo de servicios - Service Catalog (SC)
El catálogo de servicios es una herramienta que contribuye al
conocimiento y comprensión de los procesos de TI y resulta de enorme
ayuda para establecer una comunicación clara con clientes y usuarios.
Un catálogo de servicios debe incluir:
y Descripción de los servicios ofrecidos en forma comprensible para
los clientes y personal no especializado.
y Una guía para orientar a los usuarios y clientes, facilitando su uso.
y Los niveles de servicio asociados con cada uno de los servicios
ofrecidos.
Los catálogos de servicio deben estar disponibles para ser consultados
por cualquier técnico de TI y especialmente por los del centro de
atención. Normalmente, se facilitará su acceso, publicándolos en la
intranet o en los archivos públicos de la red.
Como ejemplo de los servicios que podrían estar en un catálogo de
servicios TI podríamos citar los siguientes:
Servicio de telefonía
Servicio de fax
Servicio de acceso externo
Conexión inalámbrica
Servicio de impresoras para grupos de usuarios
Centro de reproducción
Servicio de mensajería electrónica
Servicio de envío de mensajes SMS
Servicios de acceso a internet
Servicios de intranet
Servicio de videoconferencia
Servicio de salvaguarda y restauración de datos
Servicio de archivos públicos y privados en la red
Servicio de administración de usuarios (nuevos y cambios)
Servicios para las estaciones de trabajo:
o Servicio de instalación, mantenimiento y renovación
de equipamiento estándar
126
o Servicio de instalación y mantenimiento de software

base
o Servicio de adquisición de software especial
o Servicio de prevención, detección y eliminación de
virus y malware
2.3.- Acuerdo de nivel de servicio - Service Level Agreement
(SLA)
Un acuerdo de nivel de servicio presenta en un lenguaje no técnico,
fácilmente comprensible para el usuario, los detalles de los servicios que
se le brindan. Su aceptación por ambas partes –función y TI- constituye el
marco de referencia para la relación con el TI-usuario en todo lo que
referente a los servicios acordados. En este tipo de acuerdos,
normalmente se incluyen los aspectos más esenciales del servicio como
su descripción, nivel de disponibilidad, niveles de calidad, tiempos de
recuperación, etc.
Los acuerdos de nivel de servicio pueden ser de dos tipos:
• Basados en el servicio
Un acuerdo de nivel de servicio basado en el servicio es un
acuerdo genérico, que se aplica para todos los usuarios, como
pueden ser los acuerdos de servicio para el correo electrónico o
los servicios de telefonía.
• Basados en el usuario
Un acuerdo de nivel de servicio basado en el usuario, como su
nombre lo indica, es un acuerdo que se establece para un grupo
específico de usuarios, tomando en cuenta sus necesidades
específicas, como puede ser un servicio de información o el
servicio de una aplicación particular.
2.4.- Acuerdo de nivel operacional - Operational Level
Agreement (OLA)
Un acuerdo de nivel operacional es la contrapartida del acuerdo de
nivel de servicio; es un documento interno de la organización TI en el que
se establecen las responsabilidades y los compromisos que adquiere cada
unidad dentro de TI, con el fin de asegurar el cumplimiento de los niveles
de servicio acordados con los usuarios.
127
Capítulo IX
2.5.- Programa de calidad de servicio - Service Quality Program

(SQP)
Un programa de calidad de servicio complementa los aspectos
establecidos en los acuerdos de niveles de servicio y en los acuerdos de
niveles operacionales, con el fin de establecer cuáles son los aspectos que
deben ser monitorizados para que dichos acuerdos se cumplan
cabalmente.
Así pues, en un programa de calidad de servicio se incluye toda la
información necesaria para administrar eficientemente los niveles de
calidad de cada servicio en particular, como por ejemplo:
• Objetivos de cada servicio
• Estimación de recursos
• Indicadores clave de rendimiento
• Procedimientos de monitorización
3.- Creación del catálogo de servicios
Una de las tareas importantes para poder darle viabilidad a varias
disciplinas de administración de servicios y en especial a la
administración de niveles de servicio, es la creación del catálogo de
servicios. Para su creación deben cumplirse varios pasos como los
siguientes:
1. Identificación de servicios TI
Entenderemos por servicio de TI el conjunto de capacidades
tecnológicas y/o profesionales que por sus características son
percibidas por el usuario como un todo, utilizado para dar soporte a
sus operaciones, como son los servicios de impresión, correo, etc.
Para identificar los servicios, se deberán revisar los diferentes
procesos que cumplen los usuarios e ir identificando los diferentes
elementos tecnológicos que apoyan su realización.
De esta forma se desarrollará una definición de servicios hecha desde
la perspectiva del negocio y no desde un punto de vista técnico.
2. Caracterización de los servicios de TI
Desarrollar una descripción formal y completa de los servicios de TI,
incluyendo elementos como los siguientes:
• Nombre del servicio
• Responsable del servicio en TI
128
• Procesos y usuarios del servicio

• Servicios de TI relacionados
• Especificaciones del servicio de TI, incluyendo:
Descripción del servicio - narrativo-
Elementos o componentes tecnológicos que intervienen
Horario
Criticidad
Nivel de servicio requerido
3. Definición de métricas
Establecer las mediciones que se deben o pueden aplicar, para
establecer los niveles de calidad del servicio:
• Disponibilidad
• Capacidad actual y potencial de crecimiento con la
infraestructura actual
• Calidad o percepción del usuario sobre la calidad del
servicio.
4. Definición de interrelaciones
Desarrollar la especificación de los ítems de configuración u otros
servicios TI que participan en la producción de cada servicio.
Esta información, será crucial para poder evaluar los recursos
necesarios para ofrecer cada servicio con el nivel de calidad necesario
o, si fuese necesario contratar servicios de outsourcing, permitirá
establecer las bases de contratación.
Cumpliendo los pasos arriba señalados, podrán identificar los
servicios de TI, se podrán establecer cuáles son sus aspectos y
componentes más relevantes y se podrán definir métricas específicas,
útiles para cuantificar y valorar cada servicio.
La elaboración del catálogo de servicios puede resultar una tarea
compleja pues es necesario alinear muchos aspectos técnicos con
políticas del negocio, pero es un documento cuya importancia no puede
exagerarse, ya que:
• Delimita las funciones y compromisos de la organización TI
• Evita malentendidos entre los diferentes actores implicados en la
prestación de servicios
• Sirve de base para el desarrollo de la administración financiera
129
Capítulo IX
• Sirve de guía para el personal del centro de atención

4.- Proceso
Las principales actividades que conforman la disciplina de
administración de niveles de servicio pueden resumirse como:
• Preparación
• Seguimiento
• Revisión continua
4.1.- Preparación
Las actividades de preparación de la administración de niveles de
servicio requieren la participación y el compromiso de toda la
organización TI, así como también la colaboración activa de los usuarios
de los servicios TI.
El proceso de preparación incluye todas las tareas para desarrollar:
• Catálogo de servicios
• Requerimientos de nivel de servicios
• Acuerdos de niveles de servicios
130
• Acuerdos de nivel operacional

• Programa de calidad de servicio
Es frecuente que, aunque el catálogo de servicios sea detallado y
completo, la complejidad de los servicios ofrecidos requiera un proceso
de negociación con el cliente, que, en definitiva, permita depurar la
definición de requerimientos y acuerdos de niveles de servicio.
En primer término, los resultados de esta negociación permitirán
clarificar los requerimientos de nivel de servicio, estableciendo las
necesidades del usuario en los siguientes términos:
• Descripción y características del servicio
• Disponibilidad y continuidad requerida
• Nivel de calidad o forma de calificar el nivel de calidad
A su vez, la información de requerimientos permitirá desarrollar los
acuerdos de niveles de servicio y de niveles operacionales, estableciendo,
como paso previo:
• La descripción del servicio con todos los detalles técnicos
necesarios sobre cómo se presta –o prestará- el servicio.
• Cuáles podrían ser los indicadores de calidad del servicio
• Quiénes son los responsables técnicos
En función de los requerimientos de servicio y la información
desarrollada se puede elaborar un plan de acción que permita establecer
metas claras basadas en los indicadores de calidad, asignar los recursos
de la organización TI y asegurar que los niveles de calidad
comprometidos se adaptan a las necesidades de los clientes y a las
capacidades de la organización.
En los casos en los que se determine que los recursos existentes no
son suficientes o se considere oportuno tercerizar parte de los servicios, el
plan de calidad de servicio servirá de documento base para negociar los
contratos con proveedores externos.
La fase de planificación concluye con la aceptación de los acuerdos de
servicio y su puesta en vigor para la prestación del servicio de TI.
4.2.- Seguimiento
Una vez establecidos los acuerdos de servicio, será necesario verificar
que día a día se cumplen, determinar las causas de cualquier desviación y
establecer las acciones para mejorar continuamente la calidad del
servicio. Puede afirmarse que el proceso de monitorización o seguimiento
131
Capítulo IX
de los niveles de servicio es imprescindible si se desea mejorar la calidad

del servicio ofrecido, su rentabilidad y la satisfacción de los usuarios.
El seguimiento de los niveles de servicio requiere una constante
monitorización sobre el cumplimiento de los procedimientos, de los
parámetros de medición establecidos y de la percepción de los usuarios.
Para cumplir esta tarea de manera eficiente es necesario haber
alcanzado un punto de madurez en las disciplinas de administración de
servicios que facilite la integración perfecta entre las disciplinas de
monitorización y control, administración de disponibilidad,
administración de la capacidad, centro de atención, manejo de incidentes,
manejo de problemas, administración de cambios y administración de la
configuración.
4.3.- Revisión continua
La administración de niveles de servicio debe diseñarse como un
proceso continuo que incluye también la continua revisión de los
servicios ofrecidos y los niveles acordados. Esta revisión debe realizarse
con base en las experiencias, los acuerdos vigentes y la evolución que
tengan la infraestructura y el catálogo de servicios.
El proceso de revisión no debe limitarse a aquellos acuerdos de
servicio que por una razón u otra no han sido cumplidos, sino que debe
tener un amplio alcance, siempre con la meta de mejorar continuamente
la calidad del servicio, tomando en cuenta aspectos como:
• Problemas del servicio TI y sus posibles causas
• Nuevas necesidades del cliente
• Avances tecnológicos
•Experiencias en el cumplimiento de los niveles de servicio
•Evaluación de los costos reales del servicio
•Implicaciones de una degradación de la calidad del servicio en la
estructura organizativa del cliente
• Percepción de los usuarios sobre la calidad de servicio
El proceso de revisión permitirá que se lleven a cabo nuevas
negociaciones y se renueven los acuerdos de servicio.
Es claro que el objetivo de la administración de niveles de servicio no
es otro que el de mejorar la calidad del servicio y la satisfacción del
cliente; tal propósito requiere una continua revisión de los
132
procedimientos, para lo cual será importante poder contar con

información y reportes como se señala a continuación:
• Indicadores de desempeño como:
Avance de la disciplina, indicando el porcentaje de
servicios amparados bajo acuerdos de niveles de servicio
Porcentaje de incumplimiento de los acuerdos de niveles
de servicio clasificados por su impacto en la operación
de los usuarios
Encuestas de satisfacción del cliente.
• Informes estadísticos de desempeño en los que se detalle el nivel
de cumplimiento de los acuerdos, los costos asociados al proceso,
etc.
• Informes de periódicos de seguimiento, especificando las acciones
de seguimiento que se realizan, sus resultados y el grado de
satisfacción de los clientes
• Planes de mejora en los que se especifiquen tanto medidas
correctivas a las fallas detectadas, como propuestas de mejora
basadas en la experiencia o en los avances que se introduzcan en
la plataforma tecnológica.
133
Capítulo IX
134
Capítulo X
Adm inist ra c ión

Fina nc ie ra de T I
Capítulo X
Tabla de contenido
1.- ¿En qué consiste la administración financiera de TI?...............137

1.1.- Ventajas ...........................................................................138
1.2.- Barreras............................................................................138
2.- Terminología ............................................................................138
2.1.- Costos y gastos.................................................................139
2.2.- Depreciación y amortización ...........................................141
3.- Planificación .............................................................................142
3.1.- Catálogo de servicios .......................................................143
3.2.- Costeo de servicios ..........................................................144
3.3.- Proyectos..........................................................................145
3.4.- Costeo de proyectos .........................................................145
4.- Elaboración del presupuesto .....................................................146
5.- Contabilidad .............................................................................147
6.- Actividades de la administración financiera de TI ...................148
136
Administración financiera de TI
1.- ¿En qué consiste la administración financiera de los

servicios de TI?
A pesar de que casi todas las empresas y organizaciones utilizan las
tecnologías de la información para apoyar prácticamente todos sus
procesos de negocio, es muy común que no exista una conciencia real de
los costos de esta tecnología y de los servicios que presta; esto hace que
se desperdicien recursos o que no se presupuesten correctamente los
gastos asociados.
El propósito de la administración financiera de los servicios de TI es
evaluar y controlar los gastos y costos que acarrean los servicios de TI y,
dentro de lo posible, poder informar a la gerencia y a los usuarios de los
costos asociados a cada uno de los servicios que reciben.
En algunas empresas la administración financiera se limita a
contabilizar y controlar los gastos y desembolsos de TI, mientras que en
otras se busca determinar los costos de los diferentes servicios y la
alícuota de los costos que le corresponde a cada una de las unidades del
negocio, por concepto de los servicios de TI que reciben.
Esta última práctica, es uno de los objetivos más importantes de la
administración financiera de los servicios de TI, ya que ello permite que
las unidades del negocio y los usuarios tomen conciencia del costo de los
servicios, para que, como consecuencia, los controlen y aprovechen
juiciosamente. Adicionalmente, una clara conciencia de costos permitirá
que la función de TI pueda ajustar la calidad de sus servicios, dentro de
parámetros de eficiencia.
Como ya hemos señalado, la administración financiera de los servicios
de informática tiene como objetivo central administrar de manera eficaz y
rentable los servicios y la organización TI, permitiendo que esa
organización funcione como una unidad de negocio, en la que sea posible
evaluar su desempeño de manera transparente.
Normalmente, en cualquier empresa, mientras mayor es la calidad de
los servicios de TI, mayor es su costo, por lo que la administración
137
Capítulo X
financiera ayuda a establecer parámetros que permitan contrastar los

costos con las necesidades de los usuarios y del negocio, con el fin de
optimizar la razón calidad / costo. Tales propósitos pueden lograrse:
• Evaluando los costos y gastos reales asociados a cada uno de los
servicios.
• Proporcionando a la organización TI toda la información exacta
para la toma de decisiones.
• Asesorando a usuarios y clientes sobre el valor añadido que
proporcionan los servicios TI que reciben.
• Evaluando el retorno de las inversiones TI.
1.1.- Ventajas
La implantación de una adecuada administración financiera de los
servicios de informática ofrece ventajas como las siguientes:
• Pueden optimizarse los costos de los servicios
• Puede mejorarse la rentabilidad de los servicios
• La organización TI puede planificar mejor sus inversiones
• Los servicios TI se utilizan con mayor eficiencia
1.2.- Barreras
En general, las principales barreras que encuentra la implementación
de la administración financiera de los servicios de TI son:
• No es fácil encontrar personal que esté familiarizado tanto con los
servicios TI como con aspectos financieros y/o contables.
• No es sencillo determinar costos por servicio, pues existen
muchos componentes de la infraestructura que son comunes a
varios servicios.
• Existen múltiple costos ocultos o difíciles de valorar.
• Es difícil lograr el compromiso de toda la organización TI con el
proceso de administración.
2.- Terminología
Para comprender los aspectos relacionados con la administración
financiera es importante que revisemos, como primer paso, la
terminología contable y presupuestaria relacionada.
138
2.1.- Costos y gastos

En general diremos que costo es la suma de esfuerzos y
recursos que se han invertido para producir algo.
La contabilidad de costos consiste en una serie de procedimientos que
tienen como propósito determinar el costo de un producto o un servicio y
de los distintos elementos que se requieren para su producción.
Es oportuno observar que entre costo y gasto, aunque puedan
parecernos sinónimos, existen pequeñas diferencias de concepto. Por lo
general un costo puede identificarse con un producto, servicio o ingreso;
por ejemplo, en el caso de una aplicación los recursos invertidos para
cubrir los sueldos de los programadores que han trabajado en su
desarrollo se identifican claramente como componente del producto final.
Hay una correspondencia clara entre un servicio o producto y los recursos
requeridos para su producción.
Con los gastos no ocurre lo mismo, un gasto es un sacrificio
económico que se realiza para adquirir un bien o servicio requerido por la
operación normal de la organización, pero que no puede identificarse con
ningún servicio o producto en particular. En el giro normal de un negocio
es imprescindible realizar gastos, ya que de otra forma este no podría
funcionar, tal es el caso de los alquileres, de los servicios de electricidad,
de los sueldos y salarios de los empleados administrativos, etc. Los
gastos, normalmente afectan los resultados financieros de una empresa y
se reflejan en su estado de ganancias y pérdidas.
Si se desea determinar el costo real de los servicios que la
organización TI produce, será necesario hilar fino, para identificar los
gastos y hacer una distribución de éstos, de acuerdo a algún criterio que
exprese la cantidad de gasto que debe atribuirse a cada servicio TI.
En cualquier empresa, podemos encontrar una enorme variedad de
rubros –conceptos- de costos y gastos que conforman el costo de los
servicios de TI, entre ellos podemos citar:
• Alquiler de equipos de computación
• Mantenimiento de equipos de computación
• Depreciación de equipos de computación
• Costo de licencias de software
• Alquiler de equipos de telecomunicaciones
• Depreciación de equipos de telecomunicaciones
• Mantenimiento de equipos de telecomunicaciones
139
Capítulo X
• Servicios de comunicación
• Gastos de personal
• Viáticos
• Servicios profesionales
• Servicios de outsourcing
• Alquiler de oficinas y locales
• Depreciación de mobiliario y equipos de oficina
• Repuestos
• Servicios de capacitación y adiestramiento
• Libros, revistas y suscripciones
Desde el punto de vista de los servicios de TI, estos costos pueden ser
de varias categorías:
• Costos directos:
Son los costos que se pueden relacionar específica y
exclusivamente con un producto o servicio, como por ejemplo,
cuando intentamos determinar el costo del servicio de internet, el
costo de los servidores que están dedicados únicamente a
soportar este servicio, constituyen un costo directo. Esto es hay
una relación clara entre el rubro de costo y el servicio.
• Costos indirectos:
Son aquellos rubros que no son específicos o exclusivos de un
servicio, como por ejemplo, cuando queremos calcular el costo
de los servicios de una aplicación, podemos observar que esa
aplicación comparte los servicios del servidor de bases de datos,
del servidor de aplicaciones y los servicios de conexión a la red.
Se hace, en estos casos, necesario establecer la “proporción” que
de cada uno de esos servicios utiliza la aplicación.
La determinación de estos costos es un poco más difícil, por lo
general, se prorratean entre los diferentes servicios y productos
que los utilizan. La dificultad estriba en que no siempre es clara
la forma como se debe determinar la proporción de uso.
Desde el punto de vista de su asociación con el funcionamiento de los
servicios de TI, estos costos pueden ser de varias categorías:
140
• Costos de operación
En la lista de rubros de costo que mostramos, podemos observar
que hay costos o gastos que están asociados al funcionamiento
diario, como son los servicios de mantenimiento; estos costos se
denominan costos de operación.
• Costos de capital
Existen otros rubros de costo, como es la depreciación de los
equipos o de las inversiones hechas para acondicionar los locales
para los equipos, que se denominan costos de capital.
2.2.- Depreciación y amortización
En contabilidad, el término depreciación es una rebaja o deducción
que se le hace anualmente al valor de una propiedad, mueble o equipo, en
razón de su desgaste.
Por ejemplo, sabemos que un servidor puede tener una vida útil de
unos cinco años y que después de ese período deberá ser reemplazado por
un nuevo servidor con tecnología actualizada. Así pues, si para adquirir el
servidor la empresa tuvo que desembolsar diez mil dólares -USA $
10.000- podemos decir que cada año el servidor debe depreciarse en
2.000 dólares -10.000 entre 5 años-. Esto es, anualmente debe imputarse a
los servicios que utilizan este servidor un monto de USA dólares 2.000.
La depreciación en contabilidad permite determinar el valor real de las
inversiones que hace una empresa, estableciendo la disminución que
periódicamente sufre su potencial de servicio.
Simultáneamente, la depreciación permite establecer el costo real que
corresponde a los servicios de cada período. Para los contadores, la
depreciación es la forma de asignar o atribuir el costo de las inversiones a
los diferentes ejercicios en los que se hace uso o se disfruta de los activos
adquiridos con esas inversiones.
Los activos se deprecian basándose en diferentes criterios
económicos: considerando el período de tiempo en el que serán utilizados
para la actividad productiva –vida útil-, o considerando su utilización
efectiva en dicha actividad –por ejemplo, por cada unidad producida-.
La depreciación es, pues, una deducción anual que se hace al valor
contable de las propiedades y los equipos, proporcional a su valor
original. Al final de su vida útil, el valor contable de esas propiedades o
equipos será cero.
141
Capítulo X
Un concepto parecido al de depreciación es el concepto de

amortización, con la diferencia que la amortización no corresponde a
ningún activo tangible, sino que corresponde a un gasto que realiza la
empresa para cubrir varios ejercicios, como pudiera ser una prima de
seguro o un alquiler que se pague adelantadamente. La alícuota de ese
gasto que se imputa a cada ejercicio, se denomina amortización.
3.- Planificación
La administración financiera se cumple en dos grandes ciclos o
tiempos diferentes, uno corresponde a la elaboración del presupuesto, que
constituye la expresión monetaria de los planes operativos de la unidad de
TI. El otro, corresponde al ciclo de control, en el cual se lleva el cómputo
de los gastos y costos reales.
La elaboración de los presupuestos requiere unos insumos

fundamentales, que son los planes estratégico y operativo de TI.
• Planes Estratégicos
En general, los planes estratégicos de la empresa son planes cuyo
horizonte es el largo plazo, entre 3 y 10 años, en los que se
establecen los objetivos y lineamientos generales para la
definición de los demás planes -tácticos y operativos-.
Normalmente, los planes estratégicos son diseñados por los
ejecutivos de mayor nivel dentro de la jerarquía de la empresa y
su propósito es establecer la dirección que deberán seguir todas
las actividades del negocio en los próximos años, para alcanzar
los objetivos que se han propuesto.
• Planes Estratégicos de TI
Un plan estratégico de TI, corresponde al grupo de los planes
tácticos que se desarrollan en la empresa; estos planes son más
142
específicos, normalmente definen el marco de actuación

particular de un área del negocio, una división o un departamento
y su horizonte es menor, entre 1 y 3 años.
Los planes tácticos, como el PETI –plan estratégico de tecnología
de información-, deben estar alineados y subordinados al plan
estratégico de la empresa.
Los ejecutivos del área son los encargados de definir los planes
tácticos, con el fin de darle viabilidad a los objetivos estratégicos
de la empresa, dentro del ámbito de su competencia o área del
negocio.
• Planes Operativos
Los planes operativos son planes cuyo horizonte es el corto
plazo, 1 año, que se formulan dentro de los parámetros
establecidos por los planes táctico y estratégico. Tienen como
función formular y asignar proyectos y actividades detalladas,
que deberán ser ejecutadas por el nivel operativo del negocio.
Normalmente, cada unidad organizativa formula sus planes
operativos y este plan constituye la base para cuantificar y
justificar sus requerimientos de recursos o presupuesto.
En TI, la elaboración de presupuestos tiene como objetivos
principales:
• Planificar los gastos e inversiones de TI, para cumplir con las
metas, compromisos y proyectos establecidos en el plan operativo
de TI.
• Analizar los requerimientos de flujo de caja, para asegurar que los
servicios y los proyectos TI estarán financiados
convenientemente.
• Establecer los elementos que permitirán evaluar el desempeño de
la organización TI.
El presupuesto de una organización TI se construye sobre la base de
dos componentes centrales, que se ajustan a los planes operativos: el
catálogo de servicios y los proyectos que han sido propuestos para el
período que se planifica.
3.1.- Catálogo de servicios
El catálogo de servicios, como se discutió en el capítulo
correspondiente a la administración de niveles de servicio, constituye el
143
Capítulo X
compendio de los servicios que produce TI para sus usuarios, en el que se

incluye:
y Descripción de los servicios ofrecidos en forma comprensible para
los clientes y personal no especializado.
y Una guía para orientar a los usuarios, facilitando su uso.
y Los niveles de servicio asociados con cada uno de los servicios
ofrecidos.
Para la administración financiera de TI, el catálogo de servicios
permitirá establecer los centros en los que se acumularán y distribuirán
los costos y gastos de TI, de acuerdo con los criterios que se adopten para
establecer la proporción que de cada rubro utiliza el servicio.
3.2.- Costeo de servicios
Ciertamente, la determinación del costo de los servicios no es una
tarea simple, pues existen muchos componentes de hardware, software y
recursos, como el personal técnico, que intervienen en varios servicios y
no siempre resulta clara la forma de establecer la proporción que debe
atribuírsele a cada servicio.
Por ejemplo, si queremos valorar los servicios de impresión, nos
daremos cuenta que existen costos directos, perfectamente identificables,
como son el costo de las impresoras –depreciación o alquiler-, el costo de
los servidores de impresión –en caso de que existan servidores dedicados
exclusivamente a los servicios de impresión-, los servicios de
mantenimiento técnico de esos dos componentes –servidores e
impresoras-, los gastos de cintas o de tonner, el consumo de papel, etc.;
sin embargo, existen costos que no son tan fáciles de atribuir como son el
uso de los componentes de la red y el personal técnico del centro de
atención, que procesa los incidentes que se reportan cuando falla alguna
impresora.
Si quisiéramos tener un costo real de esos servicios, calculado al
céntimo, deberíamos considerar otros elementos, como por ejemplo la
parte proporcional del costo del local donde se hospedan los servidores de
impresión, la electricidad que consumen tanto servidores de impresión
como impresoras, los sueldos del personal de soporte que mantienen esos
servidores en correcto funcionamiento, los administradores de TI que,
entre muchas cosas, coordinan actividades para que esos servicios de
impresión operen correctamente y dispongan de suministros.
Es fácil comprender lo importante que será establecer límites a la
complejidad que puede representar la valoración de los diferentes
144
servicios, ya que, de lo contrario, puede convertirse en “el cuento de

nunca acabar” y hacer que todo el proceso de administración financiera
de los servicios de TI resulte inviable.
En líneas generales, la valoración de servicios debe determinar el
costo de los servicios hasta un nivel que la empresa considere realista,
con el fin de que ejecutivos y usuarios puedan tener una visión razonable
de la magnitud de tales costos.
3.3.- Proyectos
Junto con el catálogo de servicios, las carteras de proyectos de
desarrollo o mantenimiento de la infraestructura tecnológica y de
sistemas constituyen el universo de los costos de TI.
Los proyectos son actividades grandes o pequeñas, que se cumplen
una sola vez, con un propósito específico, como puede ser: desarrollar
una aplicación, diseñar y cablear un segmento de red, etc.
Es común que, para los proyectos, se acumulen los costos
correspondientes a los recursos que participan en su desarrollo y,
posteriormente, se amortice el total en varios períodos, durante el tiempo
que se estime se utilizará el producto o servicio –vida útil- que resulte del
proyecto.
Para efectos del cálculo del presupuesto, las carteras de proyectos
permitirán establecer los centros en los que se acumularán los costos y
gastos de TI, de acuerdo con los recursos necesarios para asegurar su
cumplimiento.
3.4.- Costeo de proyectos
La determinación del costo exacto de un proyecto tampoco es una
tarea simple, pues existen muchos componentes de hardware, software y
recursos que se utilizan para varios proyectos simultáneamente –ej. los
servidores de prueba- y no existe una forma simple para establecer la
proporción que debe atribuírsele a cada proyecto.
Si, a título de ejemplo, deseamos establecer el costo de un proyecto de
desarrollo de sistemas, deberemos considerar diversos elementos, como
el costo del personal de desarrollo -analistas y programadores-, el costo
de las estaciones de trabajo que utilizan, el costo de las licencias del
lenguaje o software utilizado para desarrollar los programas, etc.
Al igual que con los servicios, si quisiéramos hilar fino, deberemos
considerar la parte proporcional del costo de los ambientes de desarrollo
y prueba, del local donde programadores y analistas operan, de los
145
Capítulo X
sueldos del personal de soporte que brindan apoyo al proyecto, de los

administradores de TI, etc.
También para los proyectos, es fácil comprender lo importante que
será establecer límites a la complejidad que puede representar el costeo
exacto de cada proyecto, ya que, de lo contrario, al igual que el costeo de
servicios, puede convertirse en “el cuento de nunca acabar” y hacer que
todo el proceso de administración financiera de los servicios de TI resulte
inviable.
Así pues, el costeo de proyectos debe determinar el costo de los
proyectos hasta un nivel que la empresa considere realista, con el fin de
que ejecutivos y usuarios puedan tener una visión razonable de la
magnitud de tales costos.
4.- Elaboración del presupuesto
Un presupuesto puede definirse como la cuantificación monetaria de
los resultados previstos para un plan, un proyecto o una estrategia. A
diferencia de la contabilidad, los presupuestos están orientados hacia el
futuro y no hacia el pasado.
Presupuestar es la actividad de hacer un cálculo anticipado del costo,
de los gastos y de los ingresos de un negocio; normalmente, los
presupuestos se realizan con base en el conocimiento acumulado que la
organización tiene acerca de sus actividades, de los cambios y
pronósticos sobre cantidades y precios.
146
El presupuesto es una herramienta que permite anticipar el

comportamiento de indicadores económicos y sus relaciones con los
diferentes aspectos administrativos, contables y financieros de la
empresa.
Debe distinguirse entre un presupuesto analítico -que es la proyección
de los resultados contables de una unidad o de la empresa-, un
presupuesto de erogaciones o desembolsos de capital -que establece con
anticipación los requerimientos de recursos financiero que la
organización necesita para desarrollar sus operaciones- y un presupuesto
financiero –que incluye los gastos e ingresos que afectarán la posición de
la tesorería de la empresa-.
Una vez establecido y aprobado un presupuesto, comienza el ciclo de
control presupuestario, que consiste en comparar lo que realmente se está
haciendo con los datos presupuestados, para conocer o prever las
desviaciones, analizar las causas y remediar las diferencias.
La importancia de los presupuestos reside en que:
1. Permiten planear los resultados de la organización
2. Facilitan que los miembros de la organización puedan cuantificar en
términos financieros los diversos componentes de su plan operativo
3. Sirven como medios de comunicación entre diferentes unidades
4. Permiten controlar el manejo de ingresos y egresos de la organización
5. Por medio del control presupuestario se asegura el cumplimiento del
plan de operaciones
6. Permiten coordinar y relacionar las actividades de la organización.
5.- Contabilidad
En una empresa, la contabilidad asociada a los servicios TI sigue
patrones similares a la contabilidad asociada a otros servicios o
departamentos, por lo que, dada la complejidad de las interrelaciones
entre los componentes humanos y tecnológicos de TI, muchas veces la
información que suministra el sistema de contabilidad no tiene el grado
de desagregación necesario para poder analizar los cosos reales de los
servicios y los proyectos.
Se hace, pues, necesario utilizar los sistemas contables como fuentes
de datos -especialmente los subsistemas de personal, nómina de pagos,
compras, cuentas por pagar y activos fijos- y mantener una base de datos
o datamart con la información de los sistemas mencionados.
147
Capítulo X
De esta forma, con la finalidad de actualizar la base de datos o

datamart de administración financiera de TI, de acuerdo a la periodicidad
que se establezca, las herramientas de extracción que se implementen
deberán importar los datos de los sistemas contables, para después
desagregarlos y/o resumirlos, combinándolos en la forma requerida para
adaptarse a los requerimientos de análisis de costos de TI.
Tal como ya habíamos señalado, es esencial que el proceso de análisis

de los datos contables no tenga como alcance un excesivo de detalle que
lo complique más allá de lo razonable. Las actividades de análisis de
datos contables deben facilitar:
• La evaluación de los costos reales para su comparación con los
presupuestados
• La toma de decisiones de negocio basadas en los costos de los
servicios
• La evaluación de la eficiencia financiera de cada uno de los
servicios TI
• Cargar a los usuarios adecuadamente los servicios TI, si se utiliza
tal práctica
6.- Actividades de la administración financiera de TI
Las principales actividades de la administración financiera de TI son
las siguientes:
1. Elaboración de presupuesto:
148
1.1. Determinar los requerimientos de recursos para mantener en

funcionamiento los servicios definidos en el catálogo:
Hardware – alquileres y adquisiciones
Accesorios, suministros y repuestos
Alquileres de oficinas
Licencias de software – adicionales y renovaciones
Servicios de telecomunicaciones
Personal de soporte
Personal de operación
Gastos de adiestramiento del personal
Servicios profesionales
Servicios de outsourcing
Gastos de publicaciones
1.2. Determinar los requerimientos de recursos para cumplir los
proyectos definidos en el plan operativo:
Hardware – alquileres y adquisiciones
Accesorios, suministros y repuestos
Alquiler de oficinas
Licencias de software – nuevas y renovaciones
Servicios de telecomunicaciones
Personal para el desarrollo del proyecto
Personal de soporte
Gastos de adiestramiento del personal
Servicios profesionales
Porción a utilizar de los servicios del catálogo –Ej.
base de datos, ambiente de desarrollo, ambiente de
prueba
Servicios de outsourcing
1.3. Proyectar los flujos de caja de acuerdo a las fechas en que se
requieren los recursos para servicios y proyectos
1.4. Proyectar la distribución de costos de servicios y proyectos por
unidad usuaria o funcional
2. Preparación del control contable
2.1. Diseñar las estructuras de datos o datamart de TI
149
Capítulo X
2.2. Analizar las operaciones contables relacionadas con los servicios

y los proyectos de TI - personal, nómina de pagos, compras,
cuentas por pagar, activos fijos, etc.
2.3. Determinar la información que debe ser extraída de los sistemas
contables
2.4. Establecer la forma que esa información debe ser desagregada e
incluida en el datamart
2.5. Cargar el presupuesto aprobado de servicios y proyectos en el
datamart
3. Control contable periódico
3.1. Realizar la actualización del datamart
3.2. Preparar reportes de inconsistencias detectadas en la data
extraída
3.3. Realizar el análisis de costos reales vs. presupuestados
3.4. Preparar reportes gerenciales
3.5. Preparar reportes de excepción
3.6. Realizar la distribución de costos de servicios y proyectos, por
función o grupos de usuarios
Es importante observar que en aquellas organizaciones que facturan
sus servicios a sus clientes, la administración financiera incluye una
actividad adicional, que es la fijación de precios, la cual incluye las tareas
de:
Elaboración de una política de fijación de precios
Establecimiento de tarifas por los servicios prestados o
productos ofrecidos
Para poder evaluar la función de administración financiera se hace
necesario calificar algunas características como las siguientes:
• ¿Está comprometida la organización con la disciplina de
administración financiera?
• ¿Conoce la organización los costos reales de los servicios TI?
• ¿Conoce la organización los costos reales de los proyectos TI?
• ¿Colaboran los responsables de los otros procesos TI con la
administración financiera?
150
• ¿Opera la organización TI como una verdadera unidad de

negocio?
• ¿Los gastos TI están correctamente planificados y
presupuestados?
• ¿Se cumple una cuantificación razonable para cada servicio?
• ¿Se cumple una cuantificación razonable para cada proyecto?
• ¿Se analiza la eficiencia de cada uno de los servicios TI?
151
Capítulo X
152
Capítulo XI

la Ca pa c ida d
Capítulo XI
Tabla de contenido
1.- ¿Qué es administración de la capacidad? .................................155

1.1.- Ventajas ...........................................................................157
1.2.- Barreras............................................................................157
2.- Actividades ...............................................................................158
2.1.- Plan de Capacidad............................................................159
2.2.- Estimación .......................................................................160
2.3.- Asignación de recursos ....................................................160
2.4.- Monitorización.................................................................161
3.- Administración de la demanda .................................................161
154
1.- ¿Qué es administración de la capacidad?

La administración de la capacidad es la disciplina encargada de
asegurar que todos los servicios de TI estén soportados por una
infraestructura tecnológica con capacidades acordes con las necesidades
de la empresa, dentro de costos razonables.
En sus orígenes, la administración de capacidad se denominaba
administración de espacio en discos, pues ese era el recurso más crítico
para el funcionamiento de los servicios de TI; con el tiempo, el concepto
se ha ido extendiendo, para adaptarse a las nuevas tecnologías, su
flexibilidad y sus capacidades de crecimiento.
Cuando no se establecen normas y procedimientos de administración
de capacidades, existe la tendencia a desaprovechar los recursos
disponibles y, peor aun, a realizar inversiones que realmente no son
necesarias. También es posible que la ausencia de una buena
administración de capacidades impida que una organización de TI prevea
sus requerimientos de recursos y caiga en una situación de
congestionamiento, que afecte la calidad y la continuidad de los servicios.
Las principales funciones de la administración de la capacidad
pueden resumirse de la siguiente forma:
• Asegurar que se cubren las necesidades de capacidad TI tanto
presentes, como futuras
• Controlar el desempeño de la infraestructura TI
• Desarrollar planes de crecimiento requeridos para cumplir con los
niveles de servicio acordados con los usuarios
• Analizar y armonizar el uso de los recursos de TI –memoria,
discos, canales de comunicación, etc.-
El objetivo central de la administración de la capacidad es asegurar
que los servicios de TI dispongan de suficientes recursos tecnológicos
para poder brindar sus servicios en forma eficiente, dentro de un esquema
razonable de costos, para ello, esta disciplina deberá:
155
Capítulo XI
• Analizar el desempeño de la infraestructura instalada, para

asegurar un uso racional de la capacidad existente
• Administrar los nuevos requerimientos de servicios –como puede
ser un nuevo sistema- dotándolos de recursos adecuados, sin
perjudicar los niveles de servicio de los servicios existentes
• Proyectar las capacidades necesarias para mantener la calidad de
los servicios, alineándolos a los procesos de negocio y sus
necesidades reales
• Participar en el desarrollo de los planes y acuerdos de niveles de
servicio, con el fin de dotar los servicios con las capacidades
necesarias
• Evaluar la tecnología que ofrece el mercado, con el fin de
establecer alternativas de crecimiento
La administración de la capacidad intenta evitar las situaciones

inconvenientes, como son invertir en tecnología, por encima de las
necesidades reales o, en el extremo opuesto, mantener la infraestructura
con una capacidad por debajo de esas necesidades.
Es común observar esas situaciones y, a veces, pueden observarse
dentro de una misma empresa, en la que se privilegian ciertos servicios,
156
dotándolos exageradamente de recursos tecnológicos, y se subestiman

otros.
Decíamos que ambos escenarios son habituales, ya que a menudo se
pueden encontrar conviviendo en una misma organización tecnología
innecesaria, adquirida porque ha deslumbrado a directivos o técnicos de
informática, junto con equipos y servicios a los que podría mejorar su
desempeño y productividad.
1.1.- Ventajas
La implementación de la disciplina de administración de capacidades
puede brindar una serie de ventajas, como las siguientes:
• Se optimizan el desempeño de los recursos informáticos.
• Se asegura que la capacidad necesaria estará disponible para
atender los diferentes servicios en el momento en que sea
requerida.
• Se evitan gastos innecesarios producidos por compras no
justificadas adecuadamente
• Se planifica el crecimiento de la infraestructura de acuerdo con las
necesidades reales de los servicios
• Se reducen de los gastos de mantenimiento y de administración
asociados a equipos y aplicaciones obsoletos o innecesarios
Como conjunto, los procedimientos de administración de capacidades
permitirán armonizar el desarrollo de la infraestructura de TI y los
requerimientos de servicios, con la consiguiente reducción de costos y
optimización del desempeño.
1.2.- Barreras
La implementación de la disciplina de administración de la capacidad
normalmente tropieza con muchas dificultades, entre las cuales podemos
distinguir las siguientes:
• No se dispone de suficiente información para proyectar una
planificación realista de las capacidades
• Se crean expectativas exageradas en cuanto a los ahorros y
mejoras del desempeño
• Ausencia de compromiso suficiente por parte de la dirección
• Insuficientes recursos para realizar una correcta medición del
desempeño
157
Capítulo XI
• Plataformas muy descentralizadas o muy complejas, en las que

resulta difícil realizar una buena recopilación de datos
2.- Actividades
Las actividades de la administración de las capacidades pueden ser de
dos formas:
•Reactivas
Monitorización
Medición
• Proactivas
Predicción de requerimientos futuros
Predicción de tendencias
El proceso de administración de la capacidad incluye tres
subprocesos, encargados de analizar las capacidades de TI desde
diferentes puntos de vista:
• Administración de la capacidad para el negocio
Centra su atención en las necesidades actuales y futuras de los
usuarios y clientes. Dentro de este subproceso se cumplen varias
actividades importantes como son:
Soporte al desarrollo de acuerdos de servicio
Cuando se desarrolla un acuerdo de niveles de servicio,
la administración de capacidades debe colaborar,
asegurando la viabilidad de los acuerdos que se
suscriben y proponiendo mediciones de desempeño
adecuadas.
Soporte al diseño o modificación de servicios
La administración de capacidades también debe estar
presente en la definición de nuevos servicios o en la
modificación de servicios existentes, con el fin de
asegurar que los recursos necesarios para soportarlos
estarán disponibles.
• Administración de la capacidad del servicio
Analiza el desempeño de los servicios TI con el objetivo de
asegurar el cumplimiento de los niveles de servicio acordados.
158
• Administración de la capacidad de componentes

Analiza tanto el desempeño global de la infraestructura TI, como
de sus componentes y proyecta las tendencias para asegurar que
se dispondrá de recursos suficientes.
2.1.- Plan de Capacidad

Un plan de capacidad incluye:
• La información relativa a la capacidad de la infraestructura TI
• Las proyecciones de necesidades futuras, con base en los acuerdos
existentes y al crecimiento de volúmenes
• Los cambios necesarios para renovar la capacidad TI con nuevas
tecnologías
Adicionalmente, un plan de capacidad también debe incluir la
información sobre los costos de la capacidad actual y proyectada,
necesaria para que la gerencia de TI tomar decisiones.
159
Capítulo XI
2.2.- Estimación
En la medida que las instalaciones se hacen más complejas, resulta
mucho más complicado administrar las capacidades y escoger los
caminos para el crecimiento de la infraestructura de TI. Es necesario
evaluar alternativas y los costos asociados a cada alternativa, para lo cual
pueden seguirse varios métodos:
• Analizar tendencias para evaluar los volúmenes de trabajo que se
esperan y poder estimar los aumentos de capacidad necesarios.
• Modelar y simular diferentes escenarios, con el fin de “observar”
el impacto de los volúmenes previstos y poder tomar las
previsiones para el crecimiento de la infraestructura informática.
• Realizar benchmarks con configuraciones reales, con el fin de
asegurar que las nuevas capacidades que se adquieran
responderán adecuadamente a las necesidades futuras.
Normalmente, los benchmarks se llevan a cabo con facilidades
que ofrecen los proveedores.
2.3.- Asignación de recursos
Una de las actividades esenciales de la administración de la capacidad
es la asignación de recursos de hardware, software y personal a cada uno
de los servicios y sistemas. Ello requiere que se cuente con información
confiable sobre:
• Los niveles de servicio acordados y previstos
• Impacto del servicio o del sistema en los procesos de negocio del
cliente
• Impacto del servicio o del sistema en la capacidad instalada
• Márgenes disponibilidad
• Costo los equipos de hardware y otros recursos TI necesarios para
operar los nuevos servicios o sistemas
Es frecuente que no se tomen en cuenta todos los aspectos relativos a
la evaluación de magnitudes de un nuevo servicio o sistema, por lo que se
puede subestimar el impacto o, por el contrario, sobreestimar el poder de
cómputo de la infraestructura actual, creando situaciones de inestabilidad,
al pretender lograr desempeños que sobrepasen la capacidad real.
160
2.4.- Monitorización
La administración de la capacidad es un proceso continuo e iterativo
que monitoriza, analiza y evalúa el desempeño y la capacidad de la
infraestructura de TI; con esos datos analiza las posibilidades de mejorar
la calidad de los servicios, bien sea por la vía de la optimización del
manejo de los recursos o de la ampliación de la base instalada. Siempre,
manteniendo en perspectiva que el objetivo central es asegurar que el
desempeño de la infraestructura informática cumpla con los niveles de
servicio acordados.
3.- Administración de la demanda

Dentro de la disciplina de administración de capacidades, la actividad
de administración de la demanda tiene como objetivo la optimizar y
racionalizar el uso de los recursos TI. Es una actividad de gran
importancia, especialmente, cuando se observa una degradación del
servicio por aumentos no previstos de la demanda o interrupciones
intermitentes del servicio por fallas en el hardware o software.
161
Capítulo XI
La administración de demanda en estos casos incluye las acciones

necesarias para redistribuir recursos, con el fin de asegurar que los
servicios críticos no se vean afectados o sufran el menor impacto posible.
También, para el mediano y largo plazo, la administración de la
demanda busca identificar los puntos débiles de la infraestructura, con el
fin de robustecer su capacidad.
Una correcta monitorización de la capacidad permite reconocer las
debilidades de la infraestructura TI y los cuellos de botella, con el fin de
determinar si es posible una redistribución de recursos o se requerirá un
incremento de la capacidad instalada.
Por ejemplo, una incorrecta distribución de tareas puede causar que la
capacidad de los servicios de impresión se degrade durante ciertas horas
de oficina, a causa de la elaboración concurrente de largos trabajos de
impresión, como nóminas de pago, estados de cuenta de clientes,
balances, etc. Si la producción de esos reportes compite por los mismos
recursos para la elaboración de los documentos de oficina normales, es
posible que se observen demoras -inexplicables para el usuario- en la
impresión de los documentos. Una adecuada asignación de recursos,
prioridades y horarios permitirá que todos esos requerimientos de
impresión puedan “convivir” satisfactoriamente sin “tropezar” unos con
otros.
La administración de la capacidad también debe evaluar con base en
las mediciones, proyecciones, experiencias y tendencias del mercado,
cuándo la acción de añadir más capacidad puede ser más rentable que la
búsqueda de correctivos, tomando en cuenta que los correctivos también
implican un costo, ya que para implementar esos correctivos se requerirá
la intervención del personal de soporte. En términos de la sabiduría
popular, es necesario evitar las situaciones en que “sale más cara la
mecha que el candil”.
Para la adecuada evaluación de la disciplina de administración de
capacidades, es necesario elaborar informes para la gerencia, que
periódicamente le permitan evaluar su desempeño, entre ellos podemos
mencionar:
• Niveles de utilización de recursos
• Incrementos de volúmenes o de demanda no planificados
• Análisis de tendencias en la utilización de recursos
162
• Métricas establecidas para el evaluar la capacidad y el desempeño

• Proyecciones de las necesidades de capacidad
• Análisis de costos asociados a las capacidades
• Cumplimiento de los acuerdos de servicio
163
Capítulo XI
164
Capítulo XII
Cont inuida d de los

Se rvic ios de T I
Capítulo XII

Tabla de contenido
1.- ¿Qué es administración de la continuidad? ..............................167

1.1.- Ventajas ...........................................................................169
1.2.- Barreras............................................................................169
2.- El plan de continuidad del negocio - (BCP) .............................170
3.- Terminología ............................................................................172
4.- Preparación ...............................................................................173
4.1.- Evaluación de riesgos ......................................................173
4.2.- Identificar procesos críticos .............................................173
4.3.- Selección de estrategias de recuperación .........................174
5.- Alcance de la continuidad de servicios.....................................175
6.- Organización y planificación....................................................177
6.1.- Plan de mitigación de riesgos ..........................................177
6.2.- Plan de manejo de emergencias .......................................177
6.3.- Plan de recuperación ........................................................178
7.- Continuidad de servicios en el día a día ...................................178
7.1.- Adiestramiento.................................................................179
7.2.- Actualización ...................................................................179
166
1.- ¿Qué es administración de la continuidad?

La administración de la continuidad de los servicios de TI -IT Service
Continuity Management- se encarga de prevenir y proteger a la empresa
de los efectos que pudiera tener una interrupción de los servicios de TI,
bien sea que haya sido ocasionada por alguna falla técnica o por causas
naturales, o que haya sido provocada, voluntaria o involuntariamente, por
alguna persona.
La administración de la continuidad de los servicios de TI debe
combinar equilibradamente procedimientos:
• Preventivos:
Medidas y procedimientos que buscan eliminar o mitigar los
riesgos de interrupción y sus posibles efectos.
• Reactivos:
Procedimientos cuyo propósito es reanudar el servicio tan
pronto como sea posible después de cualquier interrupción.
No cabe duda que las políticas y procedimientos destinados a prevenir
y limitar los efectos de un desastre son preferibles a las políticas para
reaccionar frente a tales eventos, sin embargo la experiencia demuestra
que debe disponerse de una juiciosa combinación de medidas.
Los objetivos principales de la administración de la continuidad de los
servicios pueden resumirse como:
• Asegurar la pronta recuperación de los servicios críticos de TI
después de cualquier desastre.
• Establecer políticas, tomar medidas y desarrollar procedimientos
para evitar, dentro de lo posible, las consecuencias de cualquier
desastre natural -como terremoto-, evento accidental -como
incendio- o actos de terrorismo –como explosivos-.
La administración de la continuidad de los servicios de TI requiere de
una labor de “evangelización” a todo lo largo de la organización, pues es
167
Capítulo XII
difícil de justificar, es costosa y sus beneficios sólo se perciben a largo

plazo. Implementar la administración de la continuidad de los servicios
de TI equivale a la contratar un seguro, ya que cuesta dinero y parece
inútil mientras no ocurre ninguna eventualidad; sin embargo, resulta
sumamente valioso frente a cualquier contingencia.
La administración de la continuidad de TI no puede concebirse como
una disciplina exclusiva de TI, sino que debe formar parte de la disciplina
de continuidad del negocio y debe estar en perfecta coordinación con esa
disciplina. Obsérvese, que no tendría ningún sentido que se hagan
esfuerzos para que un sistema de entrada de órdenes esté funcionando y
disponible bajo cualquier condición, si no se toman las medidas para que
el personal de atención al cliente esté listo para operarlo, aunque sea
prestando un nivel mínimo de atención.
Existe una diferencia entre desastres tales como terremotos, incendios,

inundaciones, etc. y desastres informáticos, tales como los que generan
las fallas de equipos, de software, los virus o los ataques de hackers. Para
ambos tipos de eventualidades, la disciplina de administración de la
continuidad de los servicios debe incluir los procedimientos para
mantener el negocio en funcionamiento. Sin embargo, en el último caso –
falla informática- además de buscar la restauración del servicio TI con
168
prontitud, se deben prever las consecuencias en el funcionamiento del

negocio ya que:
• Sólo se afectan los servicios TI, pero pueden paralizar toda la
organización.
• Son más previsibles y más comunes.
• La percepción del cliente es diferente, pues los desastres naturales
se aceptan con resignación y no se asocian a una actitud
negligente de los técnicos de TI.
1.1.- Ventajas
La implementación adecuada de la disciplina de administración de la
continuidad de los servicios de TI tiene una gran cantidad de ventajas,
entre las cuales cabe destacar las siguientes:
• Se manejan y se mitigan los riesgos.
• Se reducen los periodos de interrupción no planificados del
servicio de TI.
• Se fortalece la confianza en la calidad del servicio, por parte de
usuarios y clientes.
• Se constituye en el apoyo indispensable que requiere el proceso
continuidad de las operaciones del negocio.
1.2.- Barreras
La implementación de la disciplina de administración de la
continuidad de los servicios de TI es una tarea compleja y laboriosa y,
además, normalmente tropieza con diferentes obstáculos como los
siguientes:
• Hay resistencia a realizar inversiones que no van a tener una
rentabilidad inmediata, por lo que no se presupuestan ni asignan
suficientes recursos.
• No existe un compromiso dentro de la organización a cumplir con
las tareas y actividades que requiere la disciplina, por lo que
continuamente se demoran los planes, para atender otras tareas de
mayor prioridad.
• No se actualizan los procedimientos y guías cada vez que se
realiza un cambio en la plataforma de servicios de TI.
• No se cumple con un análisis completo de riesgos y se dejan de
lado amenazas y vulnerabilidades importantes.
169
Capítulo XII
• No se prepara convenientemente el personal, ni se realizan

simulacros que permitan que toda la organización esté
familiarizada con los procedimientos a seguir en caso de
presentarse cualquier contingencia que interrumpa los servicios.
• Falta de coordinación con los planes de continuidad del negocio -
Business Continuity Plan (BCP)-.
2.- El plan de continuidad del negocio - (BCP)
Es importante conocer un poco la terminología y los temas más
relevantes de los planes de continuidad del negocio, con el fin de
entender el contexto en el que se debe desarrollar la disciplina de
administración de la continuidad de los servicios de TI:
• Plan de recuperación de desastres - Disaster Recovery Plan (DRP)
El plan de recuperación de desastres centra su atención en la
recuperación de los servicios de TI y sus recursos, para aquellos
casos en los que algún evento ocasione una interrupción
significativa en su funcionamiento; por ejemplo, explosión, falla
prolongada de electricidad, incendio, inundación, terremoto, etc.
• Plan de continuidad de operaciones - Continuity of Operations
Plan (COOP)
El plan de continuidad de operaciones incluye las guías y
procedimientos para la recuperación de los procesos críticos y
estratégicos de una empresa. Si bien el plan de continuidad del
negocio es la integración todos los planes de recuperación, es
frecuente que al plan de continuidad de operaciones se le de esa
denominación –BCP-.
170
• Plan de contingencia - Contingency Plan (CP)

El plan de contingencia centra su atención en la recuperación de
los servicios y recursos de TI después de una falla,
independientemente de su magnitud, mayor o menor. Establece
procedimientos y lineamientos para la recuperación de equipos y
servicios, así como también para las áreas de la empresa que
puedan resultar afectadas.
• Plan de reanudación del negocio - Business Resumption Plan
(BRP)
El plan de reanudación del negocio centra su atención en la
reanudación de los procesos del negocio que resulten afectados
por una falla en los servicios de TI. Focaliza su atención en
establecer los procedimientos y guías de trabajo para el
funcionamiento de las áreas del negocio en situación de
contingencia.
• Plan de respuesta a emergencias - Emergency Response Plan
El objetivo del plan de respuesta a emergencias es brindar
protección a los empleados, al público, el ambiente y los activos
de la empresa. En última instancia, busca poner bajo control
cualquier situación de crisis de manera inmediata.
171
Capítulo XII
Cada una de estas disciplinas se centran en la protección de aspectos

específicos de la organización, integrándose entre si, para poder proteger
el personal y todas las áreas críticas de la organización. El plan de
continuidad del negocio es el concepto que integra el alcance y los
objetivos de todas estas disciplinas.
3.- Terminología
Dentro de las diferentes disciplinas arriba descritas, se manejan varios
términos de importancia, como son:
• Objetivo de tiempo de recuperación -Recovery Time Objetive
(RTO)
El objetivo de tiempo de recuperación es un resultado
fundamental del análisis de impacto –Business Impact Análisis
(BIA)-, que establece el intervalo de tiempo en el cual un
servicio, proceso o actividad crítica de la empresa debe ser
recuperado. En términos del Instituto de Continuidad del Negocio
-Business Continuity Institute (BCI)- es “el período de tiempo en
el que un proceso puede estar inoperativo”.
• Centro de operaciones alternas del negocio –COAN-
El centro de operaciones alternas del negocio es el local escogido
por la empresa para cumplir con sus operaciones en caso de que,
por cualquier motivo, no pueda tenerse acceso a las oficinas de la
empresa. Normalmente el centro alterno debe ubicarse en una
localidad que no esté cercana a las oficinas regulares, previendo
los estragos que un terremoto o motín político pudiera generar.
En él se deberá disponer de los recursos necesarios para hacer
funcionar el negocio, aunque sea en una mínima versión:
mobiliario, suministros, equipos, teléfonos, etc.
• Centro Alterno de Operaciones de Tecnología -CAOT-
El centro alterno de operaciones de tecnología es el local
escogido por la empresa para operar los servicios de TI en caso
de que, por cualquier motivo, no pueda tenerse acceso a las
instalaciones normales. Es muy frecuente que el CAOT se ubique
en un centro de procesamiento contratado, ya que en el mercado
existen varios excelentes proveedores de servicios de
recuperación y soporte.
172
4.- Preparación
La preparación de la disciplina de administración de la continuidad de
operaciones requiere el cumplimiento de varias actividades bastante
complejas y laboriosas, como son:
• Revisar los procesos del negocio y evaluar los riesgos
• Identificar procesos críticos y analizar el impacto que sufrirán
esos procesos si faltan los servicios de TI
• Seleccionar las estrategias de recuperación
4.1.- Evaluación de riesgos
Las actividades de evaluación de riesgos en los diferentes procesos del
negocio determinan las amenazas de un desastre, pormenorizan las
vulnerabilidades existentes, permiten visualizar los posibles impactos de
los diferentes eventos de desastre e identifican los controles necesarios
para prevenir o mitigar los riesgos de cada evento.
Al realizar una evaluación de riesgos se desarrolla un informe de
riesgos y controles que establece recomendaciones y plan de acciones
para controlar y mitigar los riesgos que pudiesen alterar el normal
desempeño del negocio
Para la elaboración de este informe es necesario:
• Revisar los procesos del negocio y sus dependencias de los
servicios de TI
• Identificar los puntos más vulnerables
• Analizar las posibles amenazas sobre estos procesos y estimar su
probabilidad
Gracias a los resultados de este análisis detallado, se dispondrá de
información suficiente para proponer diferentes medidas de prevención y
recuperación que se adapten a las necesidades reales del negocio.
La prevención frente a riesgos genéricos y poco probables puede ser
muy costosa y difícil de justificar, sin embargo, las medidas preventivas o
de recuperación frente a riesgos específicos pueden resultar sencillas, de
rápida implementación y relativamente económicas.
4.2.- Identificar procesos críticos
Al identificar los procesos críticos, que contribuyen más a la misión
de la empresa –mission critical-, se analiza en detalle el impacto que
podría tener cualquier evento que impidiera su correcto funcionamiento y
las pérdidas potenciales que podría acarrear esa interrupción.
173
Capítulo XII
Como resultado, se desarrolla el informe de análisis de impacto –

Business Impact Análisis (BIA)- en el cual se identifican las áreas del
negocio que son críticas, así como la magnitud de los impactos
potenciales, tanto operativos como financieros, de una interrupción en su
funcionamiento:
Pérdida de rentabilidad
Pérdida de participación de mercado
Mala imagen
Otros efectos
4.3.- Selección de estrategias de recuperación
Para establecer los planes de recuperación es necesario establecer el
tipo de recuperación que puede adoptarse para cada área del negocio, en
relación con la criticidad y las necesidades de recuperación que tenga el
área.
En general, los tipos de recuperación que pueden adoptarse son:
• Manual
Procedimientos manuales o semi manuales para llevar a cabo las
tareas del área, como por ejemplo, para autorizar compras de los
clientes, disponer de un listado de saldos y registrar los pedidos
en una hoja de EXCEL. Una vez que se recupere la operación
normal, se transferirán al sistema los pedidos registrados en
EXCEL.
• Recuperación gradual –cold standby-
El método de recuperación gradual consiste en poner a
disposición del negocio las facilidades de oficina y de servicios
de TI, en el COAN y CAOT, en forma gradual, con varios días
de espera –hasta 4 días o más-.
• Recuperación intermedia –warm standby
El método de recuperación intermedia consiste en recuperar las
operaciones en la localidad de contingencia –COAN y COAT-
dentro de un plazo de 2 ó 3 días. Muchas veces los locales para
llevar a cabo la recuperación de las operaciones son facilidades
que se comparte con otras empresas.
• Recuperación rápida – hot standby-
El método de recuperación rápida busca recuperar las
operaciones de los servicios más importantes, dentro de un plazo
de 24 horas. Normalmente para este método, el CAOT asume la
174
modalidad de local “sombra”, en el que se dispone de los equipos

necesarios y se pueden poner a funcionar con cierta rapidez, con
una pequeña pérdida de información.
• Recuperación inmediata –también hot standby-
Es un método que se utiliza para los procesos más críticos y
requiere un local de contingencia –CAOT- en el que se
encuentren instalados equipos “espejo”, que permiten reanudar
operaciones en cuestión de minutos, sin pérdida de información.
Excepto para el método de recuperación manual, todos los restantes
métodos requieren la elaboración de copias de bases de datos y librerías
de software, que servirán como punto de arranque de los servicios y las
operaciones.
En el caso de la recuperación inmediata, estas copias de respaldo se
actualizan con cada operación que se registra, utilizando las nuevas
tecnologías de arreglos de discos que permiten replicar instantáneamente
cualquier operación en discos “espejo” ubicados en localidades distantes.
Para los otros métodos de recuperación, normalmente se elaboran
copias de respaldo con la periodicidad requerida -diaria o semanal- que se
almacenan en una localidad segura. Es bueno observar que, para estos
métodos, la información de las operaciones que se ejecuten entre la
última toma de respaldo y el momento en que ocurra un desastre, será
información que no está respaldada y que, en algún momento u otro,
habrá que incluir en los sistemas, a riesgo de tener unas bases de datos
inexactas.
Por lo arriba señalado, algunos especialistas establecen que el objetivo
de tiempo de recuperación –RTO- para un área del negocio debe estar
dado por la cantidad de información que el área puede perder.
5.- Alcance de la continuidad de servicios
Uno de los pasos iniciales para desarrollar la disciplina de
administración de la continuidad del servicio debe ser establecer
claramente sus objetivos generales, su alcance y el compromiso de la
organización TI.
También la dirección de la empresa debe demostrar su compromiso
con el proceso, pues la implantación de la administración de la
continuidad de servicios de TI puede resultar compleja y costosa sin una
visible contraprestación o un retorno de inversión.
175
Capítulo XII
El énfasis de los alcances de la administración de la continuidad del

servicio debe ser puesto en las prioridades del negocio; esto es, una vez
establecidas cuáles son las áreas críticas y los servicios de TI que apoyan
su funcionamiento, desarrollar los planes de continuidad y, una vez que
las áreas más críticas se hayan asegurado, se pueden ir incluyendo
paulatinamente otras áreas de menor prioridad.
Así pues, deben evitarse enfoques demasiado ambiciosos y establecer

alcances realistas para la administración de la continuidad de servicios de
TI en función de:
• Los servicios estratégicos de TI –requeridos por las áreas
prioritarias del negocio-.
• Los planes generales de continuidad del negocio.
• La historia de interrupciones graves de los servicios TI.
• Las expectativas de negocio.
• La disponibilidad de recursos.
La administración de la continuidad del servicio estará destinada a
fracasar si no se destinan suficientes recursos, tanto técnicos, como
equipos –hardware y software-.
Será importante recordar que una buena cantidad del esfuerzo de
desarrollo de la disciplina debe destinarse al adiestramiento del personal,
con el fin de que, en momentos de crisis, conozca las responsabilidades
que deberá asumir y las tareas que deberán ser cumplidas.
176
6.- Organización y planificación

Una vez determinado el alcance que habrá de dársele a la
administración de la continuidad de servicios de TI, analizados los
riesgos y vulnerabilidades y definidas unas estrategias de prevención y
recuperación es necesario asignar y organizar los recursos necesarios.
Con ese objetivo la administración de la continuidad del servicio debe
elaborar una serie de documentos entre los que se incluyen:
• Plan de mitigación de riesgos
• Plan de manejo de emergencias
• Plan de recuperación
6.1.- Plan de mitigación de riesgos
Un plan de mitigación de riesgos tiene como objetivo principal evitar
o minimizar el impacto de un desastre en la infraestructura TI. Entre las
medidas se incluyen en este tipo de planes, pueden encontrarse las
siguientes:
• Utilización de sistemas alternos de suministro eléctrico –plantas
eléctricas alternas-
• Uso de unidades de electricidad ininterrumpibles –
Uninterruptible Power Supply (UPS´s)–
• Políticas de respaldo y custodia para los archivos y las bases de
datos.
• Duplicación de elementos críticos, como switches, canales de
comunicación, etc.
• Utilización de sistemas de seguridad pasivos, como cajas de
seguridad
6.2.- Plan de manejo de emergencias
Las crisis suelen provocar reacciones de pánico, que pueden ser
contraproducentes que, en algunos casos, pueden causar mayores daños
que el incidente que las haya podido causar. Por ello es imprescindible
que estén claramente definidas las responsabilidades y funciones del
personal en caso de alguna situación de emergencia, así como también
deben estar definidas las guías de actuación correspondientes.
En principio los planes de manejo de emergencias deben tomar en
cuenta aspectos tales como:
• Evaluación del impacto de la contingencia en la infraestructura TI
177
Capítulo XII
• Asignación de funciones de emergencia al personal de servicio TI

• Comunicación a los usuarios y clientes en caso de una grave
interrupción o degradación del servicio
• Procedimientos de contacto y colaboración con los proveedores
involucrados
• Guías y protocolos para la puesta en marcha del plan de
recuperación correspondiente
6.3.- Plan de recuperación
Cuando una interrupción del servicio es un hecho inevitable, es el
momento de poner en marcha los procedimientos de recuperación. Para
ello, el plan de recuperación debe incluir todo lo necesario para:
• Reorganizar al personal involucrado
• Reestablecer los sistemas de hardware y software necesarios
• Recuperar los datos y reiniciar el servicio TI
Los procedimientos de recuperación pueden depender de la
importancia de la contingencia y de la opción de recuperación asociada –
cold, warm o hot stand-by-, pero en general deben detallar:
• Asignación de personal y recursos
• Instalaciones y hardware alternativos
• Planes de seguridad que garanticen la integridad de los datos
• Procedimientos de recuperación de datos
• Acuerdos de colaboración con otras organizaciones
• Protocolos de comunicación con los clientes
Cuando se tiene que poner en marcha un plan de recuperación, no
oportunidad para la improvisación, cualquier decisión puede tener graves
consecuencias tanto en la percepción que los usuarios tengan del personal
de TI, como en los costos asociados al proceso.
7.- Continuidad de servicios en el día a día
Una vez establecidas las políticas, estrategias y planes de prevención y
recuperación es indispensable que estos no queden en carpetas “llevando
polvo”, es necesario que la organización TI esté perfectamente preparada
para su correcta implementación. Ello dependerá de dos factores clave, la
adecuada preparación del personal y la continua adecuación a las
necesidades reales del negocio, a medida que evolucione la
infraestructura de TI y los procesos del negocio.
178
Uno de los factores clave para el éxito de la administración de la

continuidad del servicio es mantener un interés permanente en la
disciplina, ya que si el interés decayera, después de tener varios periodos
en los que la prevención y la buena suerte hayan impedido que se
presenten interrupciones graves, en el momento menos pensado podría
presentarse alguna dificultad grave y no estar en condiciones de
reaccionar adecuadamente frente a ella.
Es imprescindible llevar controles rigurosos que impidan que la
inversión y compromiso inicial se diluyan o que la administración de la
continuidad de servicios de TI no se mantenga al nivel adecuado para
enfrentar cualquier situación. En todo momento, la administración de la
continuidad de servicios de TI debe garantizar:
• La puesta en marcha de los planes preestablecidos.
• La supervisión de los mismos.
• La coordinación con la administración de la continuidad del
negocio.
• La asignación de recursos necesarios.
7.1.- Adiestramiento
Es inútil disponer de unos planes de prevención y recuperación
concienzudamente preparados, si las personas que deberán ponerlos en
práctica no están familiarizadas con los mismos. Es indispensable que la
administración de la continuidad de servicios de TI prepare al personal:
• Dando a conocer los planes de prevención y recuperación
• Ofreciendo adiestramiento en el uso de los diferentes
procedimientos de prevención y recuperación.
• Realizando periódicamente simulacros de diferentes tipos de
desastres, con el fin de asegurar la capacitación del personal
involucrado.
7.2.- Actualización
Tanto las políticas, estrategias y planes han de ser actualizados
periódicamente para asegurar que responden a los requisitos de la
organización en su conjunto.
Cualquier cambio en la infraestructura TI o en los planes de negocio
puede requerir de una profunda revisión de los planes en vigor y una
consecuente auditoría que evalúe su adecuación a la nueva situación.
179
Capítulo XII
En ocasiones en que el dinamismo del negocio y los servicios TI lo

haga recomendable, estos procesos de actualización y auditoria pueden
establecerse de forma periódica.
La Gestión de Cambios juega un papel esencial en asegurar que los
planes de recuperación y prevención estén actualizados manteniendo
informada a la administración de la continuidad de servicios de TI de los
cambios realizados o previstos.
La administración de la continuidad del servicio debe elaborar
periódicamente informes sobre su gestión que muestren información
relevante para el resto de la organización TI.
Estos informes deben incluir:
• Análisis sobre nuevos riesgos y evaluación de su impacto.
• Evaluación de los simulacros de desastre realizados.
• Actividades de prevención y recuperación realizadas.
• Costes asociados a los planes de prevención y recuperación.
• Preparación y capacitación del personal TI respecto a los planes y
procedimientos de prevención y recuperación.
180
Capítulo XIII

la Disponibilida d
Capítulo XIII
Tabla de contenido
1.- ¿Qué es administración de la disponibilidad? ..........................183

1.1.- Cálculo de la disponibilidad.............................................185
1.2.- Ventajas ...........................................................................185
1.3.- Barreras............................................................................186
2.- Requerimientos de disponibilidad ............................................186
3.- Plan de disponibilidad ..............................................................187
4.- Monitorización de la disponibilidad .........................................187
5.- Mediciones ...............................................................................189
182
1.- ¿Qué es administración de la disponibilidad?

Cuando hemos ido diez veces a una máquina de cajero y sólo hemos
logrado obtener el dinero solicitado en ocho oportunidades, decimos que
esa máquina de cajero ha estado disponible para nosotros un 80 %, o que
ese cajero automático tiene una disponibilidad del 80 %.
En la vida de los negocios modernos, dada la alta dependencia de la
tecnología de información, se espera que esa tecnología ofrezca una
disponibilidad del 100% durante los siete días de la semana.
Sabemos que la disponibilidad de una determinada infraestructura de
TI depende de muchos factores, del correcto diseño de los servicios, de la
confiabilidad de los componentes que la integran, de su adecuado
mantenimiento, etc. Es fácil comprender, por lo tanto, que un nivel de
disponibilidad de 100 % es prácticamente imposible de alcanzar, pues
siempre puede haber algún componente de la infraestructura que puede
fallar y que, en mayor o menor grado, puede afectar la disponibilidad del
servicio.
Con estas ideas en mente, podemos decir que la administración de la
disponibilidad busca optimizar los niveles de disponibilidad de los
servicios de TI, de tal forma que estos funcionen correctamente,
atendiendo las necesidades de los usuarios, dentro de parámetros de costo
razonables y cumpliendo los acuerdos de servicio que se hayan
establecido con usuarios o clientes.
Para cumplir con tales propósitos, la administración de la
disponibilidad deberá:
• Realizar acciones de seguimiento
• Conocer los compromisos establecidos en los acuerdos de
niveles de servicio o, si no existen estos acuerdos, determinar
los requerimientos de disponibilidad de los usuarios,
trabajando en estrecha relación con estos.
183
Capítulo XIII
• Hacer seguimiento a los niveles de disponibilidad que

realmente ofrecen los servicios de TI.
• Evaluar la disponibilidad de los nuevos servicios o las
modificaciones hechas a los servicios existentes.
• Utilizar la información recabada por la disciplina de
monitorización y control, con el fin de cuantificar la
disponibilidad de los servicios TI.
• Elaborar informes de seguimiento sobre disponibilidad,
confiabilidad, matenibilidad y cumplimiento de acuerdos de
servicio.
• Realizar acciones preventivas
• Evaluar riesgos y recomendar la implementación de acciones
de mitigación.
• Participar en el diseño de nuevos servicios o modificaciones
de los servicios existentes.
• Establecer criterios de diseño para disponibilidad
• Proponer planes de acción para mejorar la infraestructura de
servicios TI, con la finalidad de mejorar los niveles de
disponibilidad.
184
Para desarrollar los procedimientos de administración de la

disponibilidad en forma correcta, se debe mantener en perspectiva las
siguientes consideraciones:
• La disponibilidad de los servicios es uno de los elementos más
importantes para mantener alta la satisfacción de los usuarios.
• En el caso de fallas una rápida restauración de los servicios puede
ayudar a mantener los niveles de satisfacción de los usuarios.
• La disponibilidad de un servicio dependerá del grado de
disponibilidad del componente más débil en la cadena de
componentes que participan en la prestación del servicio.
1.1.- Cálculo de la disponibilidad
Normalmente, la disponibilidad se calcula como un porcentaje, de la
siguiente manera:
Disponibilidad = ((TAS – TTI) / TAS) X 100
En donde:
TAS es el tiempo acordado de servicio, esto es, el tiempo que el
servicio debe estar disponible y TTI es el tiempo total de interrupción del
servicio durante los períodos en que debió estar disponible.
Supongamos que un servicio requiere una disponibilidad de 24 horas
diarias durante los 7 días de la semana, esto es debe estar disponible 720
horas mensuales (TAS). Si este servicio se ha interrumpido, por las
razones que sean, por un total de 10 horas (TTI), entonces la
disponibilidad real habrá sido de 98,6 %:
Disponibilidad = ((720 – 10) / 720) X 100 = 98,6 %
1.2.- Ventajas
disponibilidad de los servicios de TI puede brindar una serie de ventajas,
como las siguientes:
• Los usuarios reciben los servicios de TI oportunamente, cuando
los requieren.
• Los usuarios reciben un servicio con un nivel de calidad acorde
con sus necesidades.
185
Capítulo XIII
• Pueden optimizarse los costos asociados a un alto nivel de

disponibilidad.
• Se pueden mejorar paulatinamente los niveles de disponibilidad.
1.3.- Barreras
disponibilidad de los servicios de TI normalmente tropieza con algunas
dificultades, entre las cuales podemos distinguir las siguientes:
• No existe compromiso con la disciplina dentro de la organización
TI.
• No se hace un adecuado seguimiento de la disponibilidad de los
servicios.
• No se dispone de las herramientas ni del personal adiestrado.
• Los objetivos de disponibilidad no están debidamente ajustados a
las necesidades del negocio.
• Falta de coordinación con otras disciplinas, como monitorización
y control, etc.
2.- Requerimientos de disponibilidad
Es lógico pensar que, para poder establecer acuerdos de servicio con
los usuarios y clientes, es necesario tener, por un lado, una idea bastante
precisa de los niveles de disponibilidad de los servicios y, por el otro, de
los requerimientos que en esta materia tengan los usuarios.
En especial, será necesario cuantificar los niveles de disponibilidad
que requieren los usuarios, para poder establecer hasta que punto pueden
ser satisfechos esos requerimientos, con la infraestructura actual.
Es posible que algunos usuarios soliciten una disponibilidad de 100 %
7 días a la semana, 24 horas diarias. Sin embargo, tal tipo de
disponibilidad debe sopesarse con respecto a los costos en que habría que
incurrir, para alcanzar esos niveles de perfección.
Por tales razones, al negociar los niveles de servicio, hay que
mantener en perspectiva que la disponibilidad propuesta debe
determinarse armonizando las necesidades reales del negocio y las
posibilidades reales de la organización TI.
Es posible que la falta de un determinado servicio por ciertos períodos
represente sólo un pequeño inconveniente, mientras que la certeza de un
servicio prácticamente continuo y sin interrupciones puede requerir la
186
replicación de equipos y sistemas, así como otras medidas costosas que

no van a contribuir a la rentabilidad del negocio.
Así pues, es fundamental que la administración de la disponibilidad:
• Identifique las actividades clave del negocio.
• Cuantifique los intervalos de interrupción aceptables para los
diferentes servicios, de acuerdo con el impacto que tales
interrupciones puedan tener sobre la buena marcha del negocio.
• Determine los niveles de disponibilidad que deben tener los
servicios TI.
• Establezca las brechas entre los requerimientos reales del negocio
y el nivel de disponibilidad que TI puede cumplir.
• Establezca planes de acción para alcanzar los niveles de
disponibilidad requeridos.
3.- Plan de disponibilidad
Tal como discutíamos en la sección anterior, una adecuada
planificación permitirá establecer unos niveles de disponibilidad
ajustados tanto a las necesidades reales del negocio, como a las
capacidades de la organización e infraestructura de TI.
El documento en el que se recogen los objetivos de disponibilidad y
las acciones necesarias para su cumplimiento es el plan de disponibilidad.
Este plan debe precisar:
• La situación actual de disponibilidad de los servicios TI.
• Herramientas que deben ser añadidas para la monitorización de la
disponibilidad.
• Métodos y técnicas de análisis a utilizar.
• Definiciones relevantes y precisas de las métricas a utilizar.
• Planes de mejora de la disponibilidad.
• Expectativas futuras de disponibilidad.
Este plan que debe actualizarse periódicamente, además de establecer
los requerimientos de disponibilidad, debe contener todos los cambios
necesarios para satisfacer tales requerimientos.
4.- Monitorización de la disponibilidad
Los trabajos de monitorización de la disponibilidad de los servicios de
TI deben incluir la consideración de un conjunto de variables, que
187
Capítulo XIII
permiten tener una clara visión de las diferentes fases del “ciclo de vida
de la interrupción de los servicios”, con el fin de afinar los compromisos
que, en materia de niveles de disponibilidad, la organización TI puede
adquirir.
Desde el momento en que se presenta una interrupción de servicio
hasta su restitución, un incidente pasa por distintas etapas que deben ser
cuantificadas de la siguiente forma:
1. Tiempo de detección: es el tiempo que transcurre desde que ocurre
una falla hasta que la organización TI toma conocimiento de la
misma.
2. Tiempo de respuesta: es el tiempo que transcurre desde la
detección del problema hasta que se realiza un diagnóstico del
mismo.
3. Tiempo de reparación/recuperación: periodo de tiempo utilizado
para reparar la falla o encontrar alguna solución temporal que
permita poner operativo el servicio.
Análogamente, la administración de la disponibilidad debe publicar

informes sobre la disponibilidad de los servicios que incluyan factores
como los siguientes:
• Tiempo Medio de Parada (Downtime): que es el tiempo
promedio de duración de las interrupciones de servicio,
incluyendo el tiempo de detección, respuesta y resolución.
• Tiempo Medio entre Fallas (Uptime): es el promedio de
duración de los intervalos en los que el servicio ha esta do
disponible sin interrupciones.
• Tiempo Medio entre Incidentes: es el tiempo promedio que
transcurre entre incidentes, que es la suma del tiempo medio de
parada y el tiempo medio entre fallas. El tiempo medio entre
188
incidentes es una buena medida de la confiabilidad de un servicio

o de un componente en particular.
5.- Mediciones
La administración de la disponibilidad debe realizar un conjunto de
mediciones que permitan comprender la importancia de los factores que
intervienen en la disponibilidad del servicio, lo cual permitirá prever el
los recursos que deberán asignarse para mejorar, prevenir y mantener la
infraestructura, así como elaborar planes de mejora a partir del análisis de
dichas mediciones. Entre estas podemos citar las siguientes:
1. Análisis del impacto de la falla de un componente (CFIA -
Component Failure Impact Análisis)
Este análisis permite identificar el impacto que tiene cada ítem de
configuración en la disponibilidad de los servicios TI en los que
interviene.
2. Análisis del árbol de fallas (FTA - Failure Tree Análisis)
Este análisis busca establecer la forma cómo se “propagan” las
fallas a través de la infraestructura TI, con el fin de comprender
mejor las vulnerabilidades del servicio.
3. Análisis y manejo de riesgos (RAMM - Risk Analysis and
Management Method)
El objetivo de este análisis es identificar los riesgos y
vulnerabilidades a los que se halla expuesta la infraestructura TI,
con el objetivo de adoptar acciones de mitigación, que permitan
reducir el riesgo o que permitan recuperar rápidamente el servicio
en caso de cualquier interrupción.
4. Análisis de las interrupciones de servicio (SOA - Service Outage
Análisis)
Este análisis tiene como propósito complementar las acciones de
administración de problemas, con el fin de proponer soluciones a
los problemas que han causado o pueden causar interrupciones de
servicio.
El objetivo de la administración de la disponibilidad es mejorar la
calidad del servicio y la satisfacción del cliente, por lo que se requiere
disponer de información y reportes como los que se señalan a
continuación:
189
Capítulo XIII
•Técnicas y métodos utilizados para la prevención y el análisis de

fallas.
• Cumplimiento de los acuerdos de servicio en relación con la
disponibilidad y confiabilidad de los servicios.
• Información estadística sobre:
Tiempos de detección y respuesta a los fallas.
Tiempos de reparación y recuperación del servicio.
Tiempo medio de servicio entre fallas.
Disponibilidad real de los diferentes servicios.
Es lógico que, para darle sentido a la información, sea necesario
establecer comparaciones entre lo ocurrido en la realidad y la situación
deseable o establecida en los acuerdos de servicio.
190
Capítulo XIV
Se gurida d de la
I nform a c ión
Capítulo XIV
Tabla de contenido
1.- ¿En qué consiste la administración de seguridad?....................193

1.1.- Ventajas ...........................................................................194
1.2.- Barreras............................................................................195
2.- La seguridad en el nivel de la empresa.....................................195
3.- Actividades ...............................................................................197
4.- Políticas de seguridad ..............................................................198
5.- El plan de seguridad .................................................................198
6.- Cumplimiento de la normativa de seguridad ............................199
7.- Evaluación y mantenimiento ....................................................200
192
1.- ¿En qué consiste la administración de seguridad de

la información?
La administración de seguridad de la información tiene como
propósito alinear la seguridad de TI con la seguridad de la empresa y
velar para que la seguridad de la información se maneje adecuadamente
en todos los servicios de TI.
Una adecuada administración de la seguridad de la información
permitirá asegurar que la información que se almacena y maneja con la
infraestructura de TI:
• Está debidamente protegida de su uso por parte de personas
no autorizadas –confidencialidad-.
• Está debidamente protegida de cambios que intenten hacer
personas no autorizadas –integridad-.
Podemos decir que los principales objetivos de la administración de
seguridad son:
• Diseñar una política de seguridad alineada con las políticas de
seguridad y necesidades de la empresa.
• Asegurar el cumplimiento de las políticas de seguridad acordadas.
• Mitigar los riesgos de seguridad que puedan amenazar la
continuidad del servicio o la confidencialidad e integridad de la
información.
Será fundamental comprender que la administración de la seguridad
no es únicamente responsabilidad de los técnicos de seguridad de TI, sino
que es una responsabilidad de toda la empresa. Siempre se cita, como
ejemplo, el caso de aquellas empresas en las que todos los servicios de TI
están rodeados de las más rigurosas normas de seguridad, mientras que
los reportes que imprimen los usuarios, circulan libremente o descansan
sobre los escritorios sin que nadie vele por su confidencialidad. Por esto,
no dejamos de enfatizar que la seguridad de la información que maneja y
193
Capítulo XIV
procesa TI y la seguridad de la empresa deben estar perfectamente

alineadas.
Es importante mantener en perspectiva que la seguridad también debe
establecerse en función de las necesidades del negocio. Si se cae en el
error de establecer la seguridad como una prioridad por sí misma, se
limitarán las oportunidades que ofrecen las capacidades de computación y
telecomunicaciones para realizar un intercambios de información con los
diferentes asociados de negocio, con los que se comparten procesos,
como son los clientes -a los que se les da acceso vía Web para realizar
transacciones- y los proveedores –con los que se comparten procesos para
ordenar bienes o servicios y para cancelar cuentas por pagar-.
La administración de la seguridad debe tomar en cuenta las
características del negocio y los servicios que presta la organización TI,
para establecer normas, procedimientos y protocolos de seguridad, que
aseguren que la información esté debidamente resguardada, pero
accesible cuando se necesita, para aquellos usuarios debidamente
autorizados.
Una vez establecidos los requerimientos de seguridad del negocio, la
administración de la seguridad en TI debe supervisar que tales
requerimientos estén contemplados dentro de cualquier acuerdo de
servicio que se establezca con los usuarios y, además, debe garantizar su
cumplimiento.
La administración de la seguridad debe asimismo, identificar los
riesgos a los que está expuesta la infraestructura TI, con el fin de
proponer medidas que los mitiguen o eliminen. Esto es, será también
importante para la administración de seguridad de información, que esta
sea proactiva y evalúe permanentemente los riesgos de seguridad que
pueden ir surgiendo a medida que los sistemas y la infraestructura
tecnológica vayan evolucionando.
1.1.- Ventajas
Entre las principales ventajas que aporta una adecuada implantación
de la disciplina de administración de seguridad de la información, pueden
citarse los siguientes:
• Se preserva la integridad de los datos.
• Se preserva la confidencialidad de los datos y la privacidad de
clientes y usuarios.
• Se cumple la normativa de la empresa relacionada con la
seguridad de información.
194
• Se evitan interrupciones del servicio causadas por virus, ataques

de hackers, etc.
• Mejora la percepción y confianza de los usuarios y clientes en
cuanto a la calidad del servicio.
1.2.- Barreras
La implementación de la disciplina de seguridad de la información
tropieza con barreras como las siguientes:
• No existen políticas de seguridad en el nivel de la empresa.
• No existe el suficiente compromiso de todos los miembros de la
organización TI con la seguridad.
• No se dispone de las herramientas necesarias para monitorizar y
garantizar la seguridad del servicio –como software de seguridad,
antivirus, hardware de seguridad como firewalls, etc.-
• Se establecen políticas de seguridad excesivamente restrictivas
que afectan la buena marcha de las operaciones.
• El personal no recibe una formación adecuada para aplicar
correctamente los procedimientos de la disciplina.
• No se realiza una minuciosa identificación y evaluación de
riesgos.
2.- La seguridad en el nivel de la empresa
Señalábamos en párrafos anteriores que la administración de
seguridad de la información no es sólo un problema de TI, sino que la
disciplina debe formar parte de la estrategia y normativa que se hayan
establecido en el nivel de la empresa.
En tal sentido, como mínimo, en el nivel de la empresa se deben haber
establecido:
1. Categorías
Cada empresa, de acuerdo con las características de sus operaciones,
establece diferentes categorías en la confidencialidad de su
información; a título de ejemplo podemos citar los siguientes niveles:
• Estrictamente confidencial
• Confidencial
• Sólo para uso interno
• Público
195
Capítulo XIV
2. Criterios de categorización
Los criterios de categorización, permiten establecer cuando un
documento, reporte, memorando, plano, registro de base de datos,
etc. es estrictamente confidencial, confidencial, sólo para uso interno
o público.
Las empresas acostumbran a identificar en forma visible la categoría
de seguridad de cada documento. Así, por ejemplo, veremos
memorandos en los que aparecen claramente visibles las palabras
“confidencial” o “sólo uso interno”; análogamente, las aplicaciones
hacen una indicación similar en los reportes que imprimen.
3. Procedimientos
Los procedimientos establecen qué normas deben cumplirse para
proteger la información, de acuerdo con su categoría. Así mismo,
establecen qué funcionarios, de acuerdo con su nivel, pueden tener
acceso a información clasificada como estrictamente confidencial o
confidencial.
Adicionalmente, los procedimientos también establecen las
responsabilidades que cada funcionario tiene sobre la información a
la que accede y los pasos que deberán darse para cumplir con la
normativa al utilizar la información
4. Funcionarios de seguridad por área funcional
Una vez que en el nivel de la empresa se establecen normas y
procedimientos de seguridad, normalmente, se establecen las
funciones del coordinador de seguridad de cada área del negocio,
quien será responsable de velar por la adecuada clasificación de los
documentos e información del área, de verificar que los
procedimientos de seguridad son viables para su área y de velar por
su cumplimiento.
Es costumbre que este rol opere en estrecho contacto con el
administrador de seguridad en TI, ya que tendrá como
responsabilidad autorizar o revocar los niveles de acceso que se
otorguen a los funcionarios de su área, con el fin de poder tener
acceso a servicios y aplicaciones, de acuerdo con sus
responsabilidades.
196
3.- Actividades
La administración de la seguridad esta estrechamente relacionada con
todas las disciplinas de administración y todos los procesos de TI, por lo
que para resultar exitosa requiere el concurso y la colaboración de toda la
organización.
Para que esa colaboración sea eficaz es necesario que la
administración de la seguridad:
• Establezca una clara y definida política de seguridad que sirva de
guía a todos los otros procesos.
• Elabore un plan de seguridad que incluya los niveles de seguridad
adecuados tanto en los servicios prestados a los clientes como en
los acuerdos de servicio firmados con proveedores internos y
externos.
• Implemente el plan de seguridad.
• Monitorice y evalúe el cumplimiento de dicho plan.
• Supervise proactivamente los niveles de seguridad analizando
tendencias, nuevos riesgos y vulnerabilidades.
• Realice periódicamente auditorías de seguridad.
197
Capítulo XIV
4.- Políticas de seguridad

Es imprescindible disponer de un marco general que establezca los
criterios para todas las disciplinas y procesos de TI. En especial, la
política de seguridad debe establecer:
• La relación con las políticas y normas de seguridad de la empresa.
• La coordinación con las otras disciplinas de administración de
servicios de TI.
• La coordinación con los funcionarios responsables de la seguridad
de información en las áreas funcionales.
• La estructura organizativa y los responsables del proceso de
administración de la seguridad.
• Los recursos necesarios: software, hardware y personal.
• Los programas de divulgación y formación.
• Los procedimientos de análisis de riesgos.
• El nivel de monitorización de la seguridad.
• Los informes que deben ser generados periódicamente.
• Las auditorías externas e internas de seguridad.
5.- El plan de seguridad
El objetivo del plan de seguridad es fijar los niveles de seguridad que
deben ser incluidos como parte de los acuerdos de servicio que se
establecen con los usuarios y en el nivel operacional.
El plan debe ser desarrollado conjuntamente con la administración de
niveles de servicio, responsable en última instancia de la calidad del
servicio prestado a los clientes, así como también de la calidad de los
servicios que recibe la organización TI de los proveedores externos.
El plan de seguridad debe diseñarse para ofrecer un servicio a los
usuarios mejor y más seguro, nunca como un obstáculo para el
desenvolvimiento de las actividades del negocio:
• Debe ser coherente
Los procedimientos de seguridad deben ser coherentes en todas
las fases del servicio de TI y para todos los niveles de la
organización. Deben tomar en cuenta que "una cadena es tan
resistente como el más débil de sus eslabones", por lo que carece
de sentido, por ejemplo, establecer estrictas normas de acceso si
en las aplicaciones se mantienen vulnerabilidades por un uso
198
inadecuado de las facilidades de seguridad que ofrecen los

manejadores de bases de datos utilizados en la empresa.
• Indicadores Clave
Siempre que sea posible deben definirse métricas e indicadores
clave que permitan evaluar los niveles de seguridad y el
cumplimiento de las normas.
6.- Cumplimiento de la normativa de seguridad
La administración de seguridad de la información es responsable de
motorizar y coordinar la implementación de los procedimientos y las
medidas de seguridad establecidas en el plan de seguridad.
El administrador de la seguridad debe velar por que:
• El personal conozca y acepte las normas de seguridad establecidas
y sus responsabilidades.
• Exista una aceptación formal, asegurando que los empleados
firmen acuerdos de confidencialidad acordes con su cargo y
responsabilidades.
• Se está impartiendo al personal una formación adecuada.
• Se está comunicando adecuadamente la normativa y las
consecuencias de las infracciones.
Al establecerse la disciplina de administración de la seguridad de la
información, se deben:
• Asignar los recursos necesarios.
• Instalar y mantener las herramientas de hardware y software
necesarias para garantizar la seguridad.
• Documentar adecuadamente toda la normativa, los procedimientos
e instructivos.
• Establecer las políticas y procedimientos de acceso a la
información.
• Establecer acuerdos con el centro de atención en relación con el
manejo de incidentes relacionados con la seguridad.
• Establecer acuerdos con la administración de cambios y de
versiones, con el fin de asegurar que no se introduzcan
vulnerabilidades en las aplicaciones que pasan al ambiente de
producción.
199
Capítulo XIV
• Establecer acuerdos con la administración de la continuidad de los

servicios, para asegurar que, bajo ninguna circunstancia, peligra la
integridad o la confidencialidad de los datos.
• Establecer procedimientos e implementar herramientas que
permitan monitorizar las redes y los servicios para detectar
intrusiones y ataques.
Es necesario que tanto la gerencia de TI, como todos los niveles
ejecutivos de la empresa otorguen suficiente autoridad a los
administradores y se establezcan medidas disciplinarias que deben ser
aplicadas cuando los empleados o cualquier otro personal relacionado con
los servicios de TI no cumpla con la normativa de seguridad.
7.- Evaluación y mantenimiento
Normalmente las empresas practican evaluaciones en forma continua
mediante auditorías de seguridad externas e internas, realizadas por
personal independiente de la administración de la seguridad.
El propósito de estas evaluaciones y auditorias deben calificar el nivel
de seguridad y proponer mejoras que permitan perfeccionar los
procedimientos y las normas de seguridad.
Además de las evaluaciones periódicas, cada incidente relacionado
con seguridad deberá investigarse, con el propósito de tomar las medidas
correctivas necesarias para evitar su repetición.
La administración de la seguridad debe concebirse como un proceso
en continuo perfeccionamiento, por lo que tanto la normativa, como el
plan de seguridad deben actualizarse constantemente, al igual que debe
renovarse y mejorarse, en forma continua, el conjunto de herramientas de
hardware y software implementadas. No existe nada tan vulnerable como
una seguridad basada en medidas obsoletas.
Será fundamental que la administración de la seguridad maneje
información actualizada sobre nuevos riesgos frente a virus, software
espía, malware y ataques de hackers, con el fin de adoptar las medidas
necesarias para actualizar hardware y software, sin dejar a un lado los
aspectos de comunicación y formación.
200

Al igual que para todas las disciplinas de administración de servicios
de TI, para la administración de la seguridad debe realizarse un riguroso
control que asegure el cumplimiento de sus objetivos:
• Acceso eficiente a la información por el personal autorizado.
• Disminución del número de incidentes relacionados con
seguridad.
• Identificación proactiva de vulnerabilidades, antes de que estas
puedan provocar un incidente de seguridad.
La producción periódica de informes permitirá que la gerencia de TI
evalúe el desempeño de la administración de la seguridad de la
información y aportará información valiosa a otras áreas de TI. Entre los
reportes más importantes a producir, podemos citar:
Entre la documentación generada cabría destacar:
• Relación de incidentes relacionados con seguridad clasificados
por su impacto sobre la calidad de los servicios.
• Relación del cumplimiento de los programas de formación y
evaluación de sus resultados.
• Identificación de nuevos riesgos y vulnerabilidades que enfrenta la
infraestructura TI.
• Resultados de auditorías de seguridad.
• Informes sobre el grado de implementación y cumplimiento de los
planes de seguridad establecidos.
• Informes sobre el cumplimiento de los acuerdos de servicio y
acuerdos operacionales, en lo relacionado a la seguridad de la
información.
201
Capítulo XIV
202
Capítulo XV
M e dic ión
Capítulo XIV
Medición
Tabla de contenido
1.- ¿En qué consiste la medición de los servicios de TI?............205

1.1.- ¿Por qué medir? .................................................................206
1.2.- ¿Qué debemos medir?........................................................207
1.3.- ¿Quiénes participan en la medición? .................................207
1.4.- Criterios para definir indicadores ......................................207
1.5.- Interpretación de indicadores.............................................208
2.- Uso de los indicadores ...........................................................209
3.- Algunos indicadores o mediciones ........................................211
204
Medición
1.- ¿En qué consiste la medición de los servicios de

tecnología de información?
La gerencia de los servicios TI constituye un eslabón adicional en la
cadena de valor de una organización de TI, lo que le permite dejar de ser
sólo un proveedor de tecnología, para convertirse en un proveedor de
servicios de para el negocio. Esto significa que una adecuada gestión de
los servicios de TI aporta valores adicionales como son:
• Atención de las necesidades del negocio mediante de servicios
integrales.
• Alineación de los servicios TI con el negocio.
• Compromiso con el negocio a través de acuerdos de niveles de
servicio.
• Propuestas proactivas para mejorar los servicios.
Sin embargo, para que estos servicios de TI puedan alinearse
realmente con el negocio, debe disponerse de indicadores que permitan
calibrar el grado de alineación y el nivel de calidad de los servicios.
Es importante señalar que, si bien el uso de un buen conjunto de
indicadores permite controlar la organización TI y orientar los servicios
hacia niveles de calidad creciente; no es menos cierto, que un conjunto de
indicadores mal concebidos sólo contribuirán a crear burocracia y restarle
iniciativa a la organización.
También es importante puntualizar que las mediciones no son niveles
de servicio, pues no involucran ningún tipo de acuerdo o negociación y
sólo buscan reflejar objetivamente una situación.
En el desarrollo de una métrica es necesario responder a las preguntas
claves:
• ¿Qué debemos medir?
• ¿Quiénes participarán en la medición?
• ¿Qué indicadores se requieren?
205
Capítulo XIV
1.1.- ¿Por qué medir?

En general, se mide para conocer o calificar una realidad y poder
tomar decisiones destinadas a modificar su comportamiento.
Desde el punto de vista de la alineación de TI al negocio, se mide para
mejorar los servicios, ya que dicha mejora se traducirá en satisfacción de
los usuarios y en operaciones más eficaces y eficientes. También se mide
para controlar la infraestructura tecnológica, que es la base fundamental
para proporcionar los servicios que requiere el negocio.
Así pues podemos afirmar que la medición en la gerencia de servicios

de TI cumple funciones diversas:
• Evaluación del grado de alineación de TI con las necesidades y
objetivos del negocio
• Evaluación del nivel de soporte a los usuarios
• Control gerencial, tanto de la organización TI, como de las áreas
medulares del negocio
206
• Información para los entes interesados como: usuarios, gerentes,

empleados, comité de sistemas1, comité de dirección, autoridades
externas, etc.
• Comparación de la gestión de servicios de TI con otras
organizaciones, estándares y “mejores prácticas”
1.2.- ¿Qué debemos medir?
Indudablemente, la medición debe hacerse sobre los servicios del
catálogo, ya que los servicios incluidos en ese catálogo constituyen la
mejor forma de establecer una comunicación inteligente entre los
usuarios y la organización de TI. Sin embargo, para poder medir los
servicios tenemos que hacer mediciones sobre los componentes que los
soportan, sobre los procesos que administran dicha tecnología y sobre los
equipos de trabajo que los soportan.
Con toda esa información, por agregación, se generan indicadores que
califican el servicio, que en definitiva son los que necesitamos para
asegurar que la gestión está alineada con los intereses del negocio.
1.3.- ¿Quiénes participan en la medición?
Para establecer un verdadero sistema de medición, deberemos contar
con la participación de los diferentes niveles de la organización:
responsables de servicio, gestores de proceso, responsables de
departamentos y personal técnico. Cada uno de ellos deberá participar en
la definición y posterior publicación periódica de los indicadores de su
ámbito de competencia.
1.4.- Criterios para definir indicadores
Los datos requeridos para calcular un indicador o, en general, para
alimentar una métrica deben poderse recopilar en forma sencilla, pues de
lo contrario se arriesga a imponer una considerable carga de trabajo a la
organización, que puede acarrear que se descuide la atención de los
servicios en aras de poder medirlos, lo cual sería un verdadero
contrasentido.
1
Muchas empresas utilizan la figura del comité de sistemas o comité
directivo, integrado por los ejecutivos más importantes del negocio y de
informática. Todos los planes de TI se presentan al comité de sistemas,
con el fin de obtener su aprobación. Esta aprobación, dada la estructura
del comité, representa un acuerdo entre las áreas del negocio e
informática, para desarrollar los sistemas de información y los servicios
en términos de requerimientos, recursos y calendarios..
207
Capítulo XIV
Existen ciertos criterios que la experiencia ha creado, como SMART

(specific, measurable, achievable, realistic, timely), que nos dice que los
indicadores deben ser específicos, mesurables, viables, realistas y
oportunos.
Todos estos criterios, como conjunto, nos aconsejan que en el
desarrollo de mediciones se mantenga en perspectiva que las mediciones
deben ser:
• Significativas, deben ayudar realmente a calificar un servicio.
• Corresponder a un solo proceso o a parte de uno, ya que de lo
contrario será difícil establecer responsabilidades.
• Viable, es decir, de nada vale pensar en mediciones para las cuales
no se dispone del instrumental adecuado para tomar la medición.
Por ejemplo, si no disponemos de un ACD, no podemos medir
qué porcentaje de llamadas al centro de atención son abandonadas
por los usuarios.
• Oportuna, pues de nada nos sirve, por ejemplo, el promedio de
llamadas recibidas en el centro de atención hace un año,
necesitamos conocer la carga actual.
1.5.- Interpretación de indicadores
Además de establecer los datos que deberán utilizarse para el cálculo
de un indicador y su periodicidad, será fundamental establecer:
• El significado del indicador, ¿qué nos dice?, ¿para qué nos sirve?
• Los rangos de valores, para establecer cuándo un valor nos indica
que el proceso está bien o cuándo está mal.
Normalmente se establecen:
• Los valores posibles
• Los valores normales, que indican que el proceso se desempeña en
forma normal
• Los valores de alerta, que indican que el proceso está cercano a
una situación de problema
• Los valores que indican que el proceso experimenta algún
problema
• El valor meta, que es el valor que la gerencia espera alcanzar en
una próxima evaluación, como consecuencia de las decisiones y
acciones tomadas.
208
2.- Uso de los indicadores

Es obvio que las mediciones las realizamos para calibrar algún
proceso y tomar las acciones que permitan corregir una situación
inconveniente o mejorar un proceso en forma continua.
El método más popular para crear una situación de mejora continuada
es el PDCA, conocido también como el "círculo de Deming" -por
Edwards Deming-. Se trata de un método de mejora continua de la
calidad de los procesos que integra cuatro pasos, originalmente diseñado
por Walter Shewhart -conocido como el padre del control estadístico de
la calidad-.
Este método, que muchos denominan “espiral de mejora continua” ha
sido adoptado por las normas ISO.
PDCA es el acrónimo de “Plan, Do, Check, Act” -Planificar, Hacer,
Verificar, Actuar-. Su adopción permite que las organizaciones adquieran
la disciplina de planificar una acción, tomarla, revisar su cumplimiento y
sus resultados y actuar según lo que se ha aprendido.
PLAN - Planificar, establecer los planes
1. Identificar el proceso que se quiere mejorar
2. Recopilar datos para profundizar en el conocimiento del
proceso
3. Analizar e interpretar los datos
4. Establecer los objetivos de mejora
5. Especificar los resultados esperados
6. Definir las acciones necesarias para conseguir los objetivos de
mejora
DO - Llevar a cabo los planes
7. Ejecutar las acciones definidas en el paso anterior.
8. Documentar las acciones realizadas.
CHECK - Verificar si los resultados concuerdan con los planes
9. Pasado un periodo de tiempo previsto de antemano, volver a
recopilar datos de control y a analizarlos, comparándolos con
los objetivos y especificaciones iniciales, para evaluar si se ha
producido la mejora esperada.
10. Documentar las conclusiones.
ACT - Actuar para corregir los problemas identificados
209
Capítulo XIV
11. Si fuese necesario, modificar los procesos según las

conclusiones del paso anterior.
12. Aplicar nuevas mejoras, si se han detectado en el paso anterior.
13. Documentar el proceso
210
3.- Algunos indicadores o mediciones

A continuación presentamos algunos indicadores que pueden ser
adoptados para calibrar los servicios de TI.
1- Número de usuarios servidos por técnico
2- Número de empleados cumpliendo actividades TI
3- Número de técnicos TI para desarrollar y manejar las
relaciones con usuarios
4- Número de técnicos TI para manejar el negocio de TI
5- Número de técnicos TI para manejar riesgos
6- Número de técnicos TI para desarrollar y mantener
soluciones
7- Número de técnicos TI para implementar soluciones
8- Número de técnicos TI para dar soporte a soluciones
9- Número de técnicos de proveedores externos
10- Número de técnicos para dar soporte a la arquitectura de
información
11- Número de técnicos para manejar recursos de información
12- Número de técnicos cumpliendo el rol de arquitectos TI
13- Tiempo promedio para alcanzar el punto de equilibrio (break
even) para nuevos servicios de TI
14- Tiempo promedio de puesta en operación de nuevos servicios
o mejorados por nivel de inversión
15- Total presupuesto TI por empleado
16- Porcentaje de cambio en el presupuesto de TI para el
próximo año
17- Porcentaje de presupuesto TI usado para operar versus usado
para crecimiento
18- Distribución de gastos operativos de TI versus presupuesto
de capital
19- Distribución de presupuesto operativo para hardware,
software, personal, proveedores externos de servicios,
redes/telecomunicaciones, facilidades, y otros
20- Distribución de presupuesto TI operativo relacionado con
software
211
Capítulo XIV

personal
redes/telecomunicaciones
23- Distribución de presupuesto TI de capital relacionado con
equipos de computación, de almacenamiento, software,
red/telecomunicaciones, proveedores externos de servicios y
otros
24- Distribución de presupuesto de capital relacionado con
equipos de computación y de almacenamiento
25- Distribución geográfica de usuarios TI
26- Distribución geográfica de técnicos TI
27- Porcentaje de elementos de información con custodios
asignados
28- Número de proyectos de desarrollo cumplidos
29- Número de proyectos en ejecución
30- Número de proyectos en backlog
31- Porcentaje de proyectos entregados a tiempo o antes
32- Porcentaje de proyectos entregados por debajo de lo
presupuestado
33- Porcentaje de funcionalidad ofrecida al inicio realmente
entregada
34- Tiempo promedio para atender a problemas de alta prioridad
35- Tiempo promedio para resolver problemas de alta prioridad
36- Tiempo promedio para atender a problemas de mediana
prioridad
37- Tiempo promedio para resolver problemas de mediana
prioridad
38- Tiempo promedio para atender a problemas de baja prioridad
39- Tiempo promedio para resolver problemas de baja prioridad
40- Número de correcciones realizadas que requirieron retrabajo
41- Tiempo promedio para atender requerimientos de
información, por categoría
42- Tiempo promedio para desarrollar un plan estratégico de TI
para un área del negocio
212
43- Horizonte de planificación

44- Tiempo promedio para atender un requerimiento del negocio
con soluciones de TI relevantes, por nivel de costo
45- Cantidad de suspensiones de servicio no planificadas
ocasionadas por cambios realizados
46- Cantidad de suspensiones de servicio no planificadas
ocasionadas por implementación de versiones
47- Tiempo promedio para implementar un cambio en el
ambiente de producción
48- Tiempo promedio para implementar una nueva versión en el
ambiente de producción
49- Tiempo promedio para resolver una interrupción de servicio
213
Anexo I
I m pla nt a c ión de la s Disc iplina s de
Adm inist ra c ión de Se rvic ios de T I
Una vez que se toma la decisión de incorporar las disciplinas de

administración de servicios en una organización de TI, no puede
esperarse una implementación instantánea, sino todo lo contrario, la
implementación tiene que ser paulatina, bien planificada y con
expectativas realistas para cada paso.
Para comenzar, es importante tomar conciencia de que la inserción de
las disciplinas van a significar cambios importantes en la organización y,
como normalmente ocurre con cualquier cambio, van a ser recibidos con
resistencia. Cada disciplina va a representar un cambio cultural que habrá
que manejar con decisión, pero realizando todos los esfuerzos que sean
necesarios para que todo el personal técnico y de gerencia comprenda y
acepte esos cambios.
Una campaña de charlas, folletos y cursos será imprescindible para
dar inicio a la implementación de las disciplinas y, posteriormente, para
implementar cada disciplina en particular, habrá que cumplir tareas
similares, pero específicas para cada disciplina.
Ninguna disciplina debería ser puesta en funcionamiento sin estar
dotada de procedimientos escritos, perfectamente definidos y discutidos
previamente con personas claves dentro de la organización TI y de las
áreas funcionales.
Para su implementación, podrían cubrirse diferentes fases como las
siguientes:
Fase I.- Inicialmente, las disciplinas que dada su importancia
debieran ser implementadas son:
1. Administración de la seguridad de información
4. Administración de la continuidad de los servicios TI
Fase II.- En una segunda fase deberían implementarse las
disciplinas de:
213
5. Centro de atención
6. Manejo de incidentes
7. Manejo de problemas
Fase III.- En una tercera fase debería implementarse la
disciplina de:
8. Administración de versiones
Fase IV.- En una cuarta fase debería implementarse la
disciplina de:
9. Monitorización y control
Fase V.- En la quinta fase debería implementarse la disciplina
de:
10. Administración de la disponibilidad
11. Administración de la capacidad
12. Administración de niveles de servicio – Catálogo de servicios
13. Administración financiera de los servicios TI
Fase VI.- En la fase final completarse el proyecto
implementando las disciplinas de:
14. Administración de niveles de servicio
Para cada fase y cada disciplina, al preparar los planes de trabajo, será
fundamental cumplir un proceso de evaluación y selección de
herramientas. Claro está, que si se selecciona una herramienta de gran
alcance como son Tívoli o Unicenter, sólo será necesario para cada
disciplina, revisar la forma como los módulos correspondientes serán
utilizados.
Cada disciplina, a su vez, debe implementarse por etapas, ya que es
poco probable que de un solo golpe pueda cubrirse el alcance completo
para cada disciplina. A título de ejemplos veamos la forma como
podemos definir las etapas para la disciplina de administración de la
seguridad de información:
1. Asignación de responsables para la administración de la disciplina.
2. Creación de responsables de seguridad en cada una de las áreas del
negocio (coordinador funcional de seguridad).
3. Establecer procedimientos para la cooperación entre el
administrador de seguridad, los coordinadores de seguridad por
área del negocio y el administrador de la red, con el fin coordinar la
creación de nuevos usuarios, cambio de niveles de autoridad y
214
manejo de suspensiones de servicio temporales, por vacaciones, o
definitivos.
4. Asegurar el uso adecuado de los elementos de seguridad para tener
acceso a la red.
5. Desarrollar la normativa sobre actualización y cambios periódicos
y forzosos de claves.
6. Revisión de la estructura física de la red destinada a robustecer la
estructura de seguridad, como pueden ser la creación de zonas
desmilitarizadas de alta seguridad - separando los ambientes de
internet, extranet, intranet y ambientes de base de datos- y la
creación de virtuales para agrupar y aislar usuarios.
7. Implantación de normativa relativa a la seguridad de acceso a las
bases de datos, utilizando las facilidades del manejador, eliminando
prácticas inadecuadas como utilizar un usuario único de base de
datos por cada aplicación y pretender que, en el nivel de la
aplicación, puede manejarse mejor la seguridad. Este tipo de
práctica, muy generalizada por cierto, crea brechas de seguridad
importantes, ya que cualquier persona que conozca ese único
código de usuario, puede tener acceso a la base de datos y
modificar la información sin estar autorizado para ello.
8. Desarrollar la normativa de manejo de seguridad en las
aplicaciones y comenzar a hacer los ajustes necesarios para que
todas las aplicaciones se adapten a la nueva normativa.
9. Contratar servicios de auditorías externas a la seguridad de la red e
implementar recomendaciones dirigidas a robustecer los
procedimientos.
En líneas generales, para cada disciplina deberán cumplirse
actividades como las siguientes:
1) Definir el alcance para la disciplina
2) Definir las etapas que serán cubiertas y el alcance para cada etapa
3) Diseñar el modelo de funcionamiento deseado –utilizando DFD´s,
Diagramas de Actividad, Diagramas de Use Case o cualquier otra
herramienta-
4) Evaluar herramientas –si es necesario-
5) Seleccionar herramienta –si es necesario-
6) Hacer ajustes en el modelo de funcionamiento, según sea necesario
para adaptarlo a la forma de operar de la herramienta seleccionada
215
7) Cumplir tareas de desarrollo y ajuste
a) Probar la herramienta en ambiente de desarrollo, seleccionar
opciones y ajustar parámetros según sea necesario
b) Desarrollar procedimientos
c) Probar herramientas y procedimientos en ambiente de prueba
8) Desarrollar planes de acción
a) De adiestramiento
b) De comunicación a TI y a la empresa
c) Para implementar la herramienta en producción
d) Para poner en vigor la disciplina
9) Implementar la disciplina cumpliendo los planes de acción trazados
10) Desarrollar plan de trabajo a mediano y largo plazo para cumplir las
restantes etapas definidas en el paso 3
11) Evaluar resultados de la etapa y plantear plan de mejoras
216
Anexo II
COBI T
Proc e sos de T I
I - PLANIFICACIÓN Y ORGANIZACIÓN
1. Definición de un plan estratégico de TI
2. Definición de la arquitectura de Información
3. Determinación de la dirección tecnológica
4. Definición de la organización y de las relaciones de TI
5. Manejo de la Inversión en TI
6. Comunicación de la dirección y expectativas de la gerencia
7. Administración de recursos humanos
8. Asegurar el cumplimiento de requerimientos externos
9. Evaluación de Riesgos
10. Administración de proyectos
11. Administración de calidad
II - ADQUISICIÓN E IMPLEMENTACIÓN
1. Identificación de soluciones
2. Adquisición y mantenimiento de software de aplicaciones
3. Adquisición y mantenimiento de arquitectura de tecnología
4. Desarrollo y mantenimiento de procedimientos
5. Instalación y acreditación de sistemas
III - ENTREGA DE SERVICIOS Y SOPORTE

1. Definición de niveles de servicio
2. Administración de servicios prestados por terceros
3. Administración de desempeño y capacidad
4. Aseguramiento de servicio continuo
5. Asegurar la seguridad de los sistemas
6. Identificación y atribución de costos
217
7. Educación y entrenamiento de usuarios
8. Apoyo y asistencia a los clientes de TI
10. Manejo de problemas e incidentes
11. Administración de datos
12. Administración de instalaciones
13. Administración de operaciones
IV - SEGUIMIENTO
1. Monitorización del proceso
2. Evaluar adecuación a normas de control interno
3. Obtención de evaluación independiente
4. Proveer auditoría independiente
218
Anexo III
COBI T
Re la c ione s de los Obje t ivos de Cont rol
Dom inios, Proc e sos y Obje t ivos de
Cont rol
En COBIT se define control como:

El conjunto de políticas, procedimientos, prácticas y
estructuras organizativas diseñadas para crear una seguridad
razonable de que se lograrán los objetivos del negocio y de
que se toman acciones para detectar, prevenir o corregir los
efectos de eventos indeseables.
Análogamente, objetivo de control se define como:

Una declaración del resultado deseado o propósito a ser
alcanzado, implementando procedimientos de control en
alguna actividad particular.
A continuación se listan los objetivos de control que establece COBIT,
relacionados con los procesos de TI.
I - PLANIFICACIÓN Y ORGANIZACIÓN
1. Definición de un plan estratégico de TI
OC-1.1. TI como parte del plan de la organización a corto y largo
plazo
OC-1.2. Plan a largo plazo de TI
OC-1.3. Plan a largo plazo de TI - enfoque y estructura
OC-1.4. Cambios al plan a largo plazo de TI
OC-1.5. Planificación a corto plazo para la función de TI
OC-1.6. Evaluación de sistemas existentes
2. Definición de la arquitectura de Información
219
OC-2.1. Modelo de la arquitectura de información
OC-2.2. Diccionario de datos y reglas de sintaxis de los datos de
la corporación
OC-2.3. Esquema de clasificación de datos
OC-2.4. Niveles de seguridad
3. Determinación de la dirección tecnológica
OC-3.1. Planificación de la infraestructura tecnológica
OC-3.2. Monitorización de tendencias futuras y regulaciones
OC-3.3. Contingencias en la infraestructura tecnológica
OC-3.4. Planes de adquisición de hardware y software
OC-3.5. Estándares de tecnología
4. Definición de la organización y de las relaciones de TI
OC-4.1. Comité de planificación o dirección de la función de TI
OC-4.2. Ubicación de los TI en la organización
OC-4.3. Revisión de logros organizacionales
OC-4.4. Funciones y responsabilidades
OC-4.5. Responsabilidad de la función de aseguramiento de
calidad
OC-4.6. Responsabilidad de la función de seguridad lógica y
física
OC-4.7. Propiedad y custodia
OC-4.8. Propiedad de datos y sistemas
OC-4.9. Supervisión
OC-4.10. Segregación de funciones
OC-4.11. Asignación de personal para TI
OC-4.12. Descripción de puestos para el personal de la función de
TI
OC-4.13. Personal clave de TI
OC-4.14. Procedimientos para personal contratado
220
OC-4.15. Relaciones
5. Manejo de la Inversión en TI
OC-5.1. Presupuesto operativo anual para la función de servicio
de información
OC-5.2. Monitorización de costo - beneficio
OC-5.3. Justificación de costo - beneficio
6. Comunicación de la dirección y expectativas de la gerencia
OC-6.1. Ambiente positivo de control de la información
OC-6.2. Responsabilidad de la gerencia en cuanto a políticas
OC-6.3. Comunicación de las políticas de la organización
OC-6.4. Recursos para la implementación de políticas
OC-6.5. Mantenimiento de políticas
OC-6.6. Cumplimiento de políticas, procedimientos y estándares
OC-6.7. Compromiso con la calidad
OC-6.8. Política sobre el marco de referencia para la seguridad y
el control interno
OC-6.9. Derechos de propiedad intelectual
OC-6.10. Políticas específicas
OC-6.11. Comunicación para estimular la conciencia de seguridad
en TI
7. Administración de recursos humanos
OC-7.1. Reclutamiento y promoción de personal
OC-7.2. Personal calificado
OC-7.3. Entrenamiento de personal
OC-7.4. Entrenamiento cruzado para desarrollar personal de
respaldo
OC-7.5. Procedimientos de evaluación de antecedentes del
personal
OC-7.6. Evaluación de desempeño de los empleados
221
OC-7.7. Cambios de puesto y despidos
8. Asegurar el cumplimiento de requerimientos externos
OC-8.1. Revisión de requerimientos externos
OC-8.2. Prácticas y procedimientos para el cumplimiento de
requerimientos externos
OC-8.3. Cumplimiento con regulaciones de seguridad y
ergonomía
OC-8.4. Privacidad, propiedad intelectual y flujo de datos
OC-8.5. Comercio electrónico
OC-8.6. Cumplimiento con contratos de seguros
9. Evaluación de Riesgos
OC-9.1. Evaluación de riesgos del negocio
OC-9.2. Enfoque de la evaluación de riesgos
OC-9.3. Identificación de riesgos
OC-9.4. Medición de riesgos
OC-9.5. Plan de acción contra riesgos
OC-9.6. Aceptación de riesgos
OC-9.7. Selección de medidas preventivas
OC-9.8. Compromiso con la evaluación de riesgos
10. Administración de proyectos
OC-10.1. Marco de acción para la administración de proyectos
OC-10.2. Participación de los departamentos usuarios en la
iniciación de proyectos
OC-10.3. Miembros y responsabilidades del equipo del proyecto
OC-10.4. Definición del proyecto
OC-10.5. Aprobación del proyecto
OC-10.6. Aprobación de las fases del proyecto
OC-10.7. Plan maestro del proyecto
222
OC-10.8. Plan de aseguramiento de la calidad de sistemas
OC-10.9. Planificación de métodos de aseguramiento de calidad
OC-10.10. Administración formal de riesgos de proyectos
OC-10.11. Plan de prueba
OC-10.12. Plan de entrenamiento
OC-10.13. Plan de revisión post implementación
11. Administración de calidad
OC-11.1. Plan general de calidad
OC-11.2. Enfoque de aseguramiento de calidad
OC-11.3. Planificación de aseguramiento de calidad
OC-11.4. Revisión de aseguramiento de calidad sobre el
cumplimiento de estándares y procedimientos
OC-11.5. Metodología del ciclo de desarrollo de sistemas
OC-11.6. Metodología del ciclo de desarrollo de sistemas para
realizar cambios mayores a la tecnología actual
OC-11.7. Actualización de la metodología del ciclo de desarrollo
de sistemas
OC-11.8. Coordinación y comunicación
OC-11.9. Marco de referencia para la adquisición y mantenimiento
de la infraestructura de tecnología
OC-11.10. Relaciones con terceras partes como implementadores
OC-11.11. Estándares para la documentación de programas
OC-11.12. Estándares para pruebas de programas
OC-11.13. Estándares para pruebas de sistemas
OC-11.14. Pruebas piloto/en paralelo
OC-11.15. Documentación de las pruebas de sistemas
OC-11.16. Evaluación de aseguramiento de la calidad sobre el
cumplimiento de estándares de desarrollo
223
OC-11.17. Revisión de aseguramiento de calidad sobre el logro de
los objetivos de TI
OC-11.18. Métricas de calidad
OC-11.19. Reportes de revisiones de aseguramiento de calidad
II - ADQUISICIÓN E IMPLEMENTACIÓN
1. Identificación de soluciones
OC-1.1. Definición de requerimientos de información
OC-1.2. Formulación de acciones alternativas
OC-1.3. Formulación de estrategias de adquisición.
OC-1.4. Requerimientos de servicios de terceros
OC-1.5. Estudio de factibilidad tecnológica
OC-1.6. Estudio de factibilidad económica
OC-1.7. Arquitectura de información
OC-1.8. Reporte de análisis de riesgos
OC-1.9. Controles de seguridad económica
OC-1.10. Diseño de huellas de auditoría
OC-1.11. Ergonomía
OC-1.12. Selección de software de sistemas
OC-1.13. Control del proceso de adquisición
OC-1.14. Adquisición de productos de software
OC-1.15. Mantenimiento de software de terceras partes
OC-1.16. Contratos de programación de aplicaciones
OC-1.17. Aceptación de facilidades
OC-1.18. Aceptación de tecnología
2. Adquisición y mantenimiento de software de aplicaciones
OC-2.1. Métodos de diseño
224
OC-2.2. Cambios significativos a sistemas actuales
OC-2.3. Aprobación del diseño
OC-2.4. Definición y documentación de requerimientos de
archivos
OC-2.5. Especificaciones de programas
OC-2.6. Diseño para la recopilación de datos fuente
entrada de datos
OC-2.8. Definición de interfases
OC-2.9. Interfases usuario-máquina
procesamiento
OC-2.11. Definición y documentación de requerimientos de salidas
de datos
OC-2.12. Controlabilidad
OC-2.13. Disponibilidad como factor clave de diseño
OC-2.14. Medidas de protección de la integridad de TI en
programas de aplicaciones
OC-2.15. Pruebas de software de aplicación
OC-2.16. Materiales de consulta y soporte para usuario
OC-2.17. Reevaluación del diseño del sistema
3. Adquisición y mantenimiento de arquitectura de tecnología
OC-3.1. Evaluación de nuevo hardware y software
OC-3.2. Mantenimiento preventivo para hardware
OC-3.3. Seguridad del software del sistema
OC-3.4. Instalación del software del sistema
OC-3.5. Mantenimiento del software del sistema
OC-3.6. Controles para cambios del software del sistema
OC-3.7. Utilización y seguimiento de los programas utilitarios
225
4. Desarrollo y mantenimiento de procedimientos
OC-4.1. Requerimientos operativos y niveles de servicio
OC-4.2. Manual de procedimientos para usuarios
OC-4.3. Manual de operaciones
OC-4.4. Material de entrenamiento
5. Instalación y acreditación de sistemas
OC-5.1. Entrenamiento
OC-5.2. Desempeño y magnitud del software de aplicación
OC-5.3. Plan de implementación
OC-5.4. Conversión del sistema
OC-5.5. Conversión de datos
OC-5.6. Estrategias y planes de prueba
OC-5.7. Pruebas de cambios
OC-5.8. Criterios de desempeño de pruebas en paralelo/piloto
OC-5.9. Prueba de aceptación final
OC-5.10. Pruebas de seguridad y acreditación
OC-5.11. Prueba operacional
OC-5.12. Migración a producción
OC-5.13. Evaluación del cumplimiento de requerimientos del
usuario
OC-5.14. Revisión gerencial post - implementación
OC-6.1. Inicio y control de solicitudes de cambio
OC-6.2. Evaluación de impacto
OC-6.3. Control de cambios
OC-6.4. Cambios de emergencia
OC-6.5. Documentación y procedimientos
OC-6.6. Mantenimiento autorizado
226
OC-6.7. Política de implementación de software
OC-6.8. Distribución de software
III - ENTREGA DE SERVICIOS Y SOPORTE

1. Definición de niveles de servicio
OC-1.1. Marco de referencia para los acuerdos de nivel de
servicio
OC-1.2. Aspectos sobre los acuerdos de nivel de servicio
OC-1.3. Procedimientos de ejecución
OC-1.4. Monitorización y reporte
OC-1.5. Revisión de acuerdos y convenios de niveles de servicio
OC-1.6. Elementos sujetos a cargo
OC-1.7. Programa de mejoramiento del servicio
2. Administración de servicios prestados por terceros
OC-2.1. Interfaces con proveedores
OC-2.2. Relaciones con dueños
OC-2.3. Contratos con terceros
OC-2.4. Calificación de terceros
OC-2.5. Contratos de outsourcing
OC-2.6. Continuidad de servicios
OC-2.7. Relaciones de seguridad
OC-2.8. Monitorización
3. Administración de desempeño y capacidad
OC-3.1. Requerimientos de disponibilidad y desempeño
OC-3.2. Plan de disponibilidad
OC-3.3. Monitorización y reporte
OC-3.4. Herramientas de modelaje
OC-3.5. Manejo de desempeño proactivo
227
OC-3.6. Pronóstico de cargas de trabajo
OC-3.7. Administración de capacidad de recursos
OC-3.8. Disponibilidad de Recursos
OC-3.9. Calendarios de utilización de recursos
4. Aseguramiento de servicio continuo
OC-4.1. Marco de referencia de continuidad de TI
OC-4.2. Estrategia y filosofía de continuidad de TI
OC-4.3. Contenido del plan de continuidad de TI
OC-4.4. Minimización de requerimientos de continuidad de TI
OC-4.5. Mantenimiento del plan de continuidad de TI
OC-4.6. Pruebas del plan de continuidad de TI
OC-4.7. Capacitación sobre el plan de continuidad de TI
OC-4.8. Distribución del plan de continuidad de TI
OC-4.9. Procedimientos de procesamiento alternativo para
departamentos usuarios
OC-4.10. Recursos críticos de TI
OC-4.11. Centro de cómputo y hardware de respaldo
OC-4.12. Almacenamiento de respaldos fuera de las oficinas
OC-4.13. Procedimientos de retorna de un plan de continuidad de
TI
5. Asegurar la seguridad de los sistemas
OC-5.1. Administrar medidas de seguridad
OC-5.2. Identificación, autenticación y acceso
OC-5.3. Seguridad de acceso a datos en línea
OC-5.4. Administración de cuentas de usuario
OC-5.5. Revisión gerencial de cuentas de usuario
OC-5.6. Control hecho por los usuarios sobre las cuentas de
usuario
228
OC-5.7. Vigilancia de la seguridad
OC-5.8. Clasificación de datos
OC-5.9. Administración centralizada de identificación y derechos
de acceso
OC-5.10. Reportes de violaciones y de actividades de seguridad
OC-5.11. Manejo de incidentes
OC-5.12. Reacreditación
OC-5.13. Confianza en contrapartes
OC-5.14. Autorización de transacciones
OC-5.15. No rechazo
OC-5.16. Sendero seguro
OC-5.17. Protección de funciones de seguridad
OC-5.18. Administración de llaves criptográficas
OC-5.19. Prevención, detección y corrección de software
"malicioso"
OC-5.20. Arquitecturas de firewalls y conexión a redes públicas
OC-5.21. Protección de valores electrónicos
6. Identificación y atribución de costos
OC-6.1. Elementos sujetos a cargo
OC-6.2. Procedimientos de costeo
OC-6.3. Procedimientos de cargo y facturación a usuarios
7. Educación y entrenamiento de usuarios
OC-7.1. Identificación de necesidades de entrenamiento
OC-7.2. Organización de entrenamiento
OC-7.3. Entrenamiento sobre principios y conciencia de seguridad
8. Apoyo y asistencia a los clientes de TI
OC-8.1. Escritorio de ayuda
OC-8.2. Registro de llamadas del usuario
229
OC-8.3. Escalamiento de consultas de clientes
OC-8.4. Monitorización de atención a clientes y cierre de
llamadas
OC-8.5. Análisis y reporte de tendencias
OC-9.1. Registro de la configuración
OC-9.2. Definiciones de base (estándares) de los ítems de
configuración
OC-9.3. Registro de estatus
OC-9.4. Control de configuraciones
OC-9.5. Software no autorizado
OC-9.6. Almacenamiento de software
OC-9.7. Procedimientos de administración de configuraciones
OC-9.8. Responsabilidades en relación al software
10. Manejo de problemas e incidentes
OC-10.1. Sistema de administración de problemas
OC-10.2. Escalamiento de problemas
OC-10.3. Seguimiento de problemas y huellas de auditoría
OC-10.4. Autorizaciones de acceso de emergencia y temporales
OC-10.5. Prioridades de atención a emergencias
11. Administración de datos
OC-11.1. Procedimientos de preparación de datos
OC-11.2. Procedimientos de autorización de documentos fuente
OC-11.3. Recopilación de datos desde documentos fuente
OC-11.4. Manejo de errores de documentos fuente
OC-11.5. Retención de documentos fuente
OC-11.6. Procedimientos de autorización de entrada de datos
OC-11.7. Chequeos de exactitud, suficiencia y autorización
230
OC-11.8. Manejo de errores en la entrada de datos
OC-11.9. Integridad de procesamiento de datos
OC-11.10. Validación y edición en el procesamiento de datos
OC-11.11. Manejo de errores en el procesamiento de datos
OC-11.12. Manejo y retención de salidas
OC-11.13. Distribución de salidas
OC-11.14. Balanceo y conciliación de datos de salida
OC-11.15. Revisión de salidas y manejo de errores
OC-11.16. Provisiones de seguridad para reportes de salida
OC-11.17. Protección de información sensible durante transmisión y
transporte
OC-11.18. Protección de información crítica a de los servicios de TI
OC-11.19. Administración de almacenamiento
OC-11.20. Períodos de retención y términos de almacenamiento
OC-11.21. Sistema de administración de almacenamiento
OC-11.22. Responsabilidades de la administración de los medios de
almacenamiento
OC-11.23. Respaldo y restauración
OC-11.24. Jobs de Respaldo
OC-11.25. Almacenamiento de respaldo
OC-11.26. Archivos históricos
OC-11.27. Protección de mensajes sensitivos
OC-11.28. Autenticación e integridad
OC-11.29. Integridad de transacciones electrónicas
OC-11.30. Mantenimiento continuo de la integridad de los datos
almacenados
12. Administración de instalaciones
OC-12.1. Seguridad física
231
OC-12.2. Discreción de las instalaciones de TI
OC-12.3. Escolta de visitantes
OC-12.4. Salud y seguridad del personal
OC-12.5. Protección contra factores ambientales
OC-12.6. Suministro ininterrumpible de energía (UPS)
13. Administración de operaciones
OC-13.1. Manual de procedimientos de operación e instrucciones
OC-13.2. Documentación de procesos de inicio y otras operaciones
OC-13.3. Calendarios de trabajos
OC-13.4. Desviaciones de los calendarios de trabajos
OC-13.5. Continuidad de procesamiento
OC-13.6. Bitácoras de operación
OC-13.7. Salvaguarda de formas especiales y de dispositivos de
salida
OC-13.8. Operaciones remotas
IV - SEGUIMIENTO
1. Monitorización del proceso
OC-1.1. Recolección de datos de monitorización
OC-1.2. Evaluación de desempeño
OC-1.3. Evaluación de la satisfacción de clientes
OC-1.4. Reportes gerenciales
2. Evaluar adecuación a normas de control interno
OC-2.1. Seguimiento del cumplimiento del control interno
OC-2.2. Cumplimiento oportuno del control interno
OC-2.3. Reporte sobre el nivel de control Interno
OC-2.4. Seguridad de operación y aseguramiento de control
interno
232
3. Obtención de evaluación independiente
OC-3.1. Certificación/acreditación independiente del control y la
seguridad de los servicios de TI
OC-3.2. Certificación/acreditación independiente del control y la
seguridad de los proveedores externos de servicios
OC-3.3. Evaluación independiente de la efectividad
OC-3.4. Evaluación independiente de la efectividad de
proveedores externos de servicios
OC-3.5. Aseguramiento independiente del cumplimiento de leyes,
requerimientos regulatorios y compromisos
contractuales
OC-3.6. Aseguramiento independiente del cumplimiento de leyes,
requerimientos regulatorios y compromisos
contractuales por parte de los proveedores externos de
servicios
OC-3.7. Competencia de la función de aseguramiento
independiente
OC-3.8. Participación proactiva de auditoría
4. Proveer auditoría independiente
OC-4.1. Esquemas de auditoría
OC-4.2. Independencia
OC-4.3. Ética y estándares profesionales
OC-4.4. Competencia
OC-4.5. Planificación
OC-4.6. Desempeño del trabajo de auditoría
OC-4.7. Reportes de auditoría
OC-4.8. Actividades de seguimiento
233
234
Bibliogra fía
K. Brand & H. Boonen (2008). IT Governance CobiT 4.1 - A

Management Guide 3rd Edition. Van Haren Publishing. Holanda.
COBIT® - Publicaciones del COBIT Steering Committee y del IT

Governance Institute
James W. Cortada (1998). Best Practices in Information

Technology. Prentice Hall PTR. Van Haren Publishing. Estados
Unidos.
B. Johnson & J. Higgin (2007). ITIL and the Software Lifecycle:

Practical Strategy and Design Principles. Van Haren Publishing.
Holanda.
Info Tech Research Group (2005). Building a comprehensive

Disaster Recovery Plan. Canadá.
Harris Kern, Rich Schiesser, Mayra Muniz (2005). IT Production

Services Building Competitive Advantage. Harris Kern's Enterprise
Computing Institute Series. Estados Unidos.
Harris Kern and Kenneth Moskowitz (2005). Managing IT as an

Investment: Partnering for Success. Harris Kern's Enterprise
itSMF International (2006). Metrics for IT Service Management.

Van Haren Publishing. Estados Unidos.
Larry Klosterboer (2008). Implementing ITIL Configuration

Management. IBM Press. Estados Unidos
235
Alex Nghiem (2005). IT Web Services: A Roadmap for the
Enterprise. Harris Kern's Enterprise Computing Institute Series.
Estados Unidos.
Floyd Piedad and Michael Hawkins (2005). High Availability:

Design, Techniques and Processes. Harris Kern's Enterprise
Rich Schiesser (2005). IT Systems Management: Designing,

Implementing, and Managing World-Class Infrastructures. Harris
Kern's Enterprise Computing Institute Series. Estados Unidos.
Randy A. Steinberg (2006). Measuring ITIL. Trafford Publishing.

Canadá.
Anthony F. Tardugno, Thomas R. DiPasquale and Robert E.

Matthews (2005). IT Services: Costs, Metrics Benchmarking, &
Marketing. Harris Kern's Enterprise Computing Institute Series.
Estados Unidos.
The Office of Goverment & Commerce - OGC (2007). ITIL 3

Lifecycle Core Library Service Strategy. The Stationery Office.
Reino Unido.
The Office of Goverment & Commerce - OGC (2007). The Official

Introduction to the ITIL Service Lifecycle. The Stationery Office.
Reino Unido.

Lifecycle Publication Suite: Core Publications Collection. The
Stationery Office. Reino Unido.

Lifecycle Core Library Service Operation. The Stationery Office.
Reino Unido.
236
Efraim Turban, James Wetherbe, Ephraim McLean, Dorothy
Leidner (2007). Information Technology for Management:
Transforming Organizations in the Digital Economy. Wiley, John
& Sons, Incorporated. Estados Unidos.
Jan Van Bon (2008). IT Service Management based on ITIL V3: A

Pocket Guide. Van Haren Publishing. Holanda.
Jan Van Bon (2007). Foundations of IT Service Management

Based on ITIL V3. Van Haren Publishing. Holanda.
Jan Van Bon (2007). IT Service Management: An Introduction

Based on ISO 20000 & ITIL v3. Van Haren Publishing. Holanda.
Gary S. Walker (2005). IT Problem Management. Harris Kern's

Enterprise Computing Institute Series. Estados Unidos.
Sitios Internet (Fuentes electrónicas):
ITIL Site oficial: http://www.itil-

officialsite.com/home/home.asp
Site del Information Systems Audit and Control Association

(ISACA): http://www.isaca.org/
237
238

Tecnologia de Informacion Gerencia de Servicios Basado en ITIL PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tecnologia de Informacion Gerencia de Servicios Basado en ITIL PDF

Cargado por

Copyright:

Formatos disponibles

A mis hijos Miguel y Manuel

Gracias por su soporte e inspiración

Hasta hace pocos años en los departamentos IBM o de “procesamiento

Anexo I - Implantación de las Disciplinas de Administración de

Bibliografía ..................................................................................... 235

Disciplinas de administración de servicios de TI

1.- ¿Qué es Gobernanza de TI? .......................................................... 3

Disciplinas de administración de servicios de TI

1.- ¿Qué es Gobernanza de TI?

“Gobernanza corporativa es un conjunto de relaciones entre

• Establecer una cartera de proyectos

• COBIT (Control Objectives for Information and related

garantizando la integración de éstos a la cadena de valor de las unidades

COBIT establece un marco de trabajo que parte de una premisa muy

• Modelos de madurez, para que la gerencia de una organización

4.1.- Los procesos de ITIL

4.2.- ITIL versión 3

2. Funciones y procesos en la fase de diseño de servicios

5. Funciones y procesos en la fase de mejora continua de servicios

El portal de la GSTI, ISO 20000 Central -puede ser visitado en la

• ITIL cubre la gestión financiera mientras que ISO 20000 cubre

disponibilidad, administración de la capacidad,

6.- ¿Qué es CMM?

•Un marco de referencia para calificar y diagnosticar el progreso de

 No perder de vista los objetivos de negocio y

MOF es un modelo estructurado y flexible que está basado en lo

8.- Principales disciplinas de administración de TI

Todas las tareas de administración de operaciones se deben describir

de soporte sigan los mismos métodos, utilicen las herramientas

8.3.- Manejo de problemas

Esta disciplina tiene como objetivos:

• Negociar y establecer el nivel de calidad para los servicios

• Identificar aplicaciones críticas

1.- ¿Qué es un centro de atención a usuarios? .................................31

1.- ¿Qué es un centro de atención a usuarios?

Para el buen desenvolvimiento de las operaciones del negocio, es

Su objetivo es gestionar un alto volumen de llamadas y

• ¿Qué calificaciones profesionales deberán tener sus integrantes?

problemas reportados que aun no hayan recibido una solución

• Estar informados acerca de los criterios para escalar a instancias

3. Revisar la base de datos de configuraciones, con el fin de conocer en

6.3.- Manejo desde inicio hasta cierre

de los servicios TI. Para ello es imprescindible que se lleve un registro

1.- ¿En qué consiste el manejo de incidentes? .................................45

1.- ¿En qué consiste el manejo de incidentes?

En líneas generales, los objetivos del manejo de incidentes son:

Normalmente, el concepto de incidente se asocia con algún

siempre que la solicitud corresponda a uno de los servicios que se

incidentes que no corresponden a los servicios estándar o que no

La urgencia de un incidente depende del tiempo máximo de

4.- Escalamiento y soporte

Básicamente hay dos formas de escalar incidentes:

• Se completará el registro inicial, introduciendo en la base de datos

El tiempo de resolución del incidente corresponderá a los

Si la resolución del incidente escapa a las posibilidades del centro de

servicios de TI haga proyecciones sobre requerimientos de

1.- ¿En qué consiste el manejo de problemas? ...........................57

1.- ¿En qué consiste el manejo de problemas?

Las principales actividades del manejo de problemas son:

2.1.- Control de problemas

2.1.1.- Identificación y registro

sobre los diferentes elementos de configuración involucrados en el

manejado por los procedimientos de control de errores, para su posterior

No perder de vista los objetivos de negocio y

Presidir las reuniones del comité de cambios.