ITIL-01, 02, 03, 04, 05, 06, 07-Introduccion-1

Capítulo I
Disciplinas de
Administración de
Servicios de TI
Capítulo I
Disciplinas de administración de servicios de TI

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 Association 1) 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).
1
0
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
Administración financiera (Financial Management)
Administración de la cartera de servicios (Service Portafolio
Management -SPM)
Administración de la demanda (Demand Management)
11
Capítulo I
2. Funciones y procesos en la fase de diseño de servicios

Administración del catálogo de servicios (Service Catalogue
Management)
Administración de niveles de servicio (Service Level
Management)
Administración de la capacidad (Capacity Management)
Administración de la disponibilidad (Availability Management)
Administración de la continuidad de servicios de TI (IT Service
Continuity Management)
Administración de la seguridad de información (Information
Security Management )
Administración de proveedores (Supplier Management )
3. Funciones y procesos en la fase de transición de servicios
Planificación de la transición y soporte (Transition Planning
and Support )
Administración de cambios (Change Management)
Administración de la configuración (Service Asset and
Configuration Management)
Administración de versiones y su implantación (Release and
Deployment Management)
Validación y prueba de servicios (Service Validation and
Testing)
Evaluación (Evaluation)
Administración del conocimiento (Knowledge Management)
4. Funciones y procesos en la fase de operación de servicios
Administración de eventos (Event Management)
Administración de Incidentes (Incident Management)
Atención de requerimietos (Request Fulfillment)
Administración de problemas (Problem Management)
Administración de acceso (Access Management)
Monitorización y control (Monitoring and Control)
Operaciones de TI (IT Operations)
Escritorio de servicios (Service Desk)
1
2
5. Funciones y procesos en la fase de mejora continua de servicios

Mejora continua de procesos (CS improvement Process)
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.
1
4
 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.
1
6
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
1
8
 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.
2
0
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
2
2
 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.
2
4
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
2
6
 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 II
Centro de
Atenció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
40
Centro de atención
41
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
42
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 sumantenimiento.
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, talescomo:
 Tiempo promedio de respuesta a las solicitudes recibidas a travésde
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.
Capítulo II
Capítulo III
Manejo de
Incidentes
44
Capítulo III
Manejo de Incidentes
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 nohan

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 formacó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óndel
incidente, sin que la operación de su área del negociosufra
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 losusuarios 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
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
laurgencia de los incidentes.
 Porcentaje de incidentes, clasificados por impacto y prioridad,
quehan 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.
Capítulo III
Capítulo IV
Manejo de
Problemas
56
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
57
incidente aislado pero de importancia significativa.
Capítulo IV
58
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
Manejo de problemas
Capítulo IV
Capítulo V
Administración de
Configuraciones
68
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 facilidadespara
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 losrecursos
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 sistemasno

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 –datosde 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, peroen 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
 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
datosde 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.
Capítulo V
Capítulo VI
Administración de
Versiones
82
Capítulo VI
Administración de versiones
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 tareasde
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 queuna 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 coordinarsee
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íaso
bibliotecas de programas fuentes y ejecutables que han sido aceptadosen
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 versioneses 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, lasversiones
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 alos 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 precedena 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 habersido instalados,
causan una interrupción en el servicio o presentan unfuncionamiento
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 reemplazadadel
ambiente de producción, por lo que hablamos de que una versiónpuede
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 ode
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 versionesy ú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 unaserie 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, porlo 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 finde
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 restantesmiembros del
equipo de desarrollo o mantenimiento. Una pruebafuncional 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 realizaresta 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 queel 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 loscomponentes 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
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 ellolos
procedimientos deben contemplar la posibilidad de otorgarautorizaciones
temporales, para que estos técnicos puedan cumplir su cometido, con
agilidad.
Será muy importante para evaluar el desempeño de los equipos dedesarrollo
que, aunque estas tareas de soporte inicial se cumplanflexiblemente,
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.
Capítulo VI
Capítulo VII
Administración de
Cambios
96
Capítulo VII
Administración de cambios
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.
10
0
 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:
10
2
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?
10
4
 ¿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.
10
6
 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
10
8

ITIL-01, 02, 03, 04, 05, 06, 07-Introduccion-1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ITIL-01, 02, 03, 04, 05, 06, 07-Introduccion-1

Cargado por

Copyright:

Formatos disponibles

Capítulo I

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

2.- La administración de servicios de TI

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

3.- ¿Qué es COBIT?

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

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

4.- ¿Qué es ITIL?

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

5.- ¿Qué es ISO 20000?

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

7.- ¿Qué es MOF?

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 dirigir

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

problemas reportados que aun no hayan recibido una solución definitiva.

 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

7.- Evaluación de la disciplina

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 consideren

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

3.- Clasificación de los incidentes

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

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 acuerdos

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

6.- Evaluación de la disciplina

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