Tema 3.

Transición y operaciones
del servicio

Introducción
En la economía actual, las innovaciones de las empresas se logran gracias a las
iniciativas de proyectos que involucran tecnologías de información. En menor o
mayor medida, estos proyectos generan cambios en las operaciones o los eventos
que afectan. Pero ¿cómo se puede asegurar que estos cambios beneficien a la
empresa? La respuesta es sencilla: creando y mejorando servicios por medio de
un correcto diseño de ciclo de vida. De esta manera se puede garantizar que lo
planeado será implementado y, en consecuencia, se alcanzarán los objetivos
esperados. En resumen, se realizará una transición de servicios. 
Los principales elementos de la administración de servicios de ITIL son la
estrategia, el diseño y la transición de servicios, y contribuyen a la calidad de
servicios. Sin embargo, la fase de operación de servicio también tiene mucha
importancia, pues es donde los clientes de un negocio tocan la calidad de la
estrategia, el diseño y la transición cada vez que hacen uso de los servicios. 
La operación del servicio es la etapa del ciclo de vida de la administración del
servicio ITIL, que es responsable de las actividades usuales de una empresa. 
En este tema aprenderás las fases de transición y operaciones de servicio de
ITIL. 

Explicación
3.1 ITIL: Transición del servicio
3.1.1 Planeación de soporte a la transición y gestión de cambios
 
La fase de transición de servicio incluye la gestión y coordinación de los procesos,
sistemas y funciones necesarios para la construcción, prueba y despliegue de una
versión en producción, así como para la definición del servicio de acuerdo a las
especificaciones del cliente mencionadas en el paquete de diseño del servicio.
Los objetivos de esta fase de proceso son los siguientes:

 Planear y gestionar los recursos que se requieren para establecer un servicio

nuevo o modificado y llevarlo a producción exitosamente dentro del costo
acordado, con la calidad y tiempo estimado.
 Asegurar que los cambios de servicios puedan crear el valor de negocio esperado.
 Aumentar la satisfacción de clientes, usuarios y personal de la gestión de
servicios.
Como se mencionó en el tema 1 del módulo I, la fase de transición tiene siete
procesos que se encargan de realizar las diferentes actividades que permiten
garantizar una construcción eficaz, que incremente la satisfacción del usuario al
garantizar que cumple con los requerimientos pactados. El primer proceso que
estudiaremos es el de planeación y soporte a la transición.
Planeación y soporte a la transición
Este proceso es el encargado de coordinar los recursos de la organización TI para
poner en marcha el servicio en el tiempo, calidad y costo definidos previamente.
Garantiza que los recursos se planifican y coordinan adecuadamente para cumplir
las especificaciones del diseño del servicio.
Los objetivos de este proceso son los siguientes:

 Planear y coordinar los recursos para desplegar de manera exitosa un nuevo

servicio o cambio de servicio dentro de los costos, calidad y tiempos estimados.
 Asegurar que se adopten procesos y sistemas de soporte estándar y reutilizables.
 Proveer planes claros que permitan la alineación de clientes y el negocio.
 Identifica y gestiona los riesgos.

Las actividades que realiza el proceso se describen a continuación:

 Definir la estrategia de transición es decir las políticas y estándares que se usarán.

En este sentido la mayoría de las empresas tiene políticas de construcción, es
decir estándares de cómo debe codificarse, nombre de variables, módulos,
documentación, entre otros.
 Preparar la transición del servicio, planificar y coordinar la transición del servicio, y
el soporte. Coordina los recursos de tal forma que pueden realizarse transiciones
simultáneas.

Un ejemplo de este proceso es la planeación que haces cuando tienes que

preparar proyectos finales, entregar tareas y cumplir con tus labores en el trabajo.
Debes planificar tu tiempo, dar prioridades y medir el riesgo que representa no
cumplir con cada cosa de acuerdo a las políticas y estándares que te piden en
cada uno.
Gestión de cambios
La gestión de cambios es un proceso que busca asegurar que los cambios se
lleven a cabo de forma eficiente, siguiendo procedimientos establecidos, y que
aseguren en todo momento la continuidad del servicio de TI.
El objetivo de la gestión de cambios es garantizar que los cambios se aplican de
una manera controlada después de haber sido evaluados, priorizados,
planificados, probados, implementados y documentados.
Es importante que el proceso garantice que se utilizan métodos y procedimientos
estándar, que todos los cambios se registran en la CMDB (Configuration
Management Database) y se toman en cuenta los riesgos para el negocio.
Terminología importante que debes conocer:

 Solicitud de cambio (RFC): propuesta formal para que se haga un cambio a uno

o más elementos de configuración.
 Calendario/Programa de cambios: contiene los detalles de todos los cambios
aprobados y fechas en que van a ser implementados.
  Plan de remediación: plan que permite regresar al estado original antes de
haberse implementado el cambio.
 Siete R: serie de preguntas que se usan para evaluar con efectividad el impacto
potencial que tiene un cambio y decidir si se aprueba o no. Las preguntas a
realizar son las siguientes:
 ¿Quién levantó (raised) el cambio?
 ¿Cuál es la razón (reason) del cambio?
 ¿Cuál es el resultado (return) que se requiere del cambio?
 ¿Cuáles son los riesgos (risks) involucrados en el cambio?
 ¿Qué recursos (resources) se requieren para entregar el cambio?
 ¿Quién es el responsable (responsible) de la creación, prueba e
implementación del cambio?
 ¿Cuál es la relación (relationship) entre este cambio y otros cambios?

Entradas y salidas del proceso

Dependiendo de la urgencia y presupuesto necesario para realizar un

cambio, existen tres tipos de cambios los cuales se describen a
continuación:

 Cambio normal
Cambio que requiere de un RFC para llevarse a cabo. Es solicitado por una
persona o grupo de personas. Este tipo de cambios se lleva a cabo cuando debido
al costo o impacto requiere aprobase para su construcción. El detalle de las
actividades que deben realizarse se explica más adelante.
 Cambio estándar
Es un cambio a un servicio o infraestructura que está pre autorizado por la gestión
de cambios y tiene un procedimiento establecido para proporcionarlo. Son
cambios que ya están presupuestados por lo que no requieren aprobación,
ejemplos de ellos son mantenimientos planeados, cambios de equipos definidos
por política de la empresa cada cierto periodo.
 Cambio de emergencia
Un cambio que debe ser introducido lo más rápido e intenta reparar un error en un
servicio de TI que impacta de manera negativa al negocio. Este tipo de cambios se
realizan cuando hay una falla en la operación y para repararla se requiere un
cambio el cual debe hacerse de inmediato.

Las actividades del proceso para un cambio normal son:

 Creación y registro del RFC

El cambio aparece a partir de una necesidad de un grupo o una persona y es
 registrada con los detalles necesarios dependiendo del alcance e impacto del
mismo.
 Revisión del RFC y propuesta de cambio
Se revisa si es viable o no el cambio y se rechaza o queda en consideración o está
incompleta. Un cambio puede ser rechazado por ejemplo porque falta información
para determinar su beneficio, viabilidad y recursos necesarios o porque no
representa un beneficio al negocio.
 Valoración y evaluación del cambio
Se realiza la categorización de riesgo del cambio usando una matriz similar a la
que se presenta en la siguiente tabla:

Impacto alto Impacto alto

Baja probabilidad Baja probabilidad
Categoría de riesgo: 2 Categoría de riesgo: 1

Impacto
Impacto bajo Impacto bajo
del cambio
Baja probabilidad Baja probabilidad
Categoría de riesgo: 4 Categoría de riesgo: 3

Probabilidad
Una vez categorizado el cambio, el siguiente paso es evaluarlo, es decir, analizar
el riesgo, los beneficios y costos que tiene, por lo que es en esta actividad donde
se tienen que realizar las preguntas de las 7R’s del cambio. Es posible que llegan
muchos cambios al mismo tiempo por lo que es importante determinar el orden en
que se deben realizar, es decir su prioridad. La prioridad se determina con base en
dos variables: el impacto y la urgencia. El impacto se basa en los beneficios que
traerá el cambio al negocio y la urgencia indica cuánto tiempo se puede retrasar la
implementación, cada empresa determina su matriz de prioridad. Un ejemplo
puede ser el siguiente:

Impacto

Alto Medio Bajo

Alta 1 2 3

Urgencia Media 2 3 4

Baja 3 4 5
Una vez determinada la prioridad de los cambios, se genera un programa de
cambios, también llamado calendario de cambios, el cual contiene datos de todos
los cambios aprobados y las fechas de implementación. A continuación, se
presenta un ejemplo de un modelo de autorización del cambio:

 Autorización del cambio. Todos los cambios requieren autorización formal ya sea
de una persona, un rol o un grupo de personas (Consejo asesor de cambios CAB),
el nivel de aprobación depende del tipo de cambio tal como se muestra a
continuación.
 Figura 5.1 Ejemplo de un modelo de autorización del cambio. Fuente: Office of Government Commerce
(2011). Introduction to the ITIL® service lifecycle (2ª ed.). TSO (The Stationery Office).

 Planeación y coordinación de la implementación del cambio. Se comprueba y

actualizan los planes del cambio, transición, pruebas, despliegue de los RFC’s
autorizados y se pasan a los grupos encargados de construirlo, aquí se dispara el
proceso de Gestión de Implementación y despliegue del cual hablaremos más
adelante.
 Revisión y cierre del registro de cambio. EL CAB realiza las siguientes preguntas
como parte de la revisión post implementación:
o ¿Ha conseguido el cambio los resultados previstos?
o ¿Están satisfechos los clientes con los resultados?
o ¿Ha surgido algún efecto secundario?
o ¿Se han sobrepasado los costos y esfuerzos estimados?

Si el cambio tuvo éxito se procede al cierre y los resultados se incluyen como

parte de la revisión post implementación, en caso contrario la gestión de cambios
o el CAB debe decidir qué hacer, si regresan a la situación anterior usando el plan
de remediación o levantan un nuevo RFC.
Los elementos de los cambios estándar son los siguientes:
Hay un detonador predefinido para iniciar la solicitud de cambio.

 Las tareas son bien conocidas, documentadas y probadas.

 La autoridad es proporcionada de antemano, de manera efectiva, como ya se
explicó con anterioridad, este tipo de cambios son pre aprobados.
 La aprobación de presupuestos será típicamente pre ordenada o incluida en el
control del solicitante del cambio.
  El riesgo es usualmente bajo y siempre bien entendido, en donde se configura la
actualización del cambio y la configuración en la CMS.

Los roles del proceso son:

Los indicadores clave de desempeño (KPI) del proceso son:

Reducción en el número de interrupciones a los servicios y retrabajos

provocados por la especificación imprecisa o la evaluación incompleta
del impacto.

Reducción el número de cambios no autorizados.

KP Incremento en los registros de solicitudes de cambio.

I
Reducción en el porcentaje de cambios no planificados/cambios de
emergencia.

Reducción en los incidentes que se pueden atribuir a los cambios.

Reducción en los cambios donde se invoca el plan de remediación.

Hemos concluido el proceso de cambios, el cual permitirá tener controlados todos
los cambios que se hagan a los servicios, procesos, documentos y elementos de
configuración que se tengan bajo control. Para saber lo que queremos tener
controlado requerimos de un proceso en el cual se defina una base de datos que
contenga dichos elementos con sus atributos y relaciones entre ellos, es decir, las
dependencias entre ellos. Dicho proceso es la gestión de activos y configuración
del servicio el cual tratamos a continuación.
3.1.2 Gestión de activos y configuración del servicio, gestión de
implementación y despliegue
Gestión de activos y configuración del servicio
Las organizaciones no pueden ser consideradas eficientes o efectivas si no
administran o gestionan correctamente sus activos, particularmente aquellos que
son considerados como activos estratégicos. El proceso gestión de configuración y
activos del servicio se encargará de gestionarlos de tal manera que brinde soporte
a todos los demás procesos.
El objetivo es definir componentes de servicio e infraestructura y mantener
registros precisos de la configuración por lo cual es importante que la integridad de
los activos del servicio y elementos de configuración esté protegida y que todos se
localicen en el sistema de gestión de la configuración.
Terminología importante que debes conocer:

 Elemento de configuración CI. Cualquier activo o componente de servicio que

requiere ser gestionado para entregar un servicio de TI.

Figura 5.2 Categorías de los elementos de configuración. Fuente: Long, J. O. (2012). ITIL 2011 at a glance.
EE. UU: Springe v

 Línea base de configuración. Es una configuración de un servicio, producto o

infraestructura que ha sido formalmente revisada y acordada, y que
posteriormente sirve de base para actividades futuras.
 Sistema de gestión de configuraciones (CMS). Conserva toda la información de
los CI’s dentro del alcance designado. Mantiene las relaciones entre todos los
componentes del servicio y cualquier registro o documentación de gestión
 relacionados con el servicio. También conserva datos acerca de empleados,
proveedores, ubicaciones y unidades de negocio, clientes y usuarios.
 Base de datos de gestión de configuraciones (CMDB). Se utiliza para
administrar los registros de configuraciones durante su ciclo de vida. La CMDB
registra los atributos de todos los CI’s y las relaciones con otros CI. Puede
contener información vinculada a registro de incidentes, problemas o cambios.
 Modelo lógico. Muestra las relaciones entre los CI’s
 DML. Una o más ubicaciones en la cual versiones de todo el software (CI’s)
aprobado y definitivo son almacenados de forma segura.

Las actividades que realiza el proceso son:

 Gestionar y planear el nivel de la gestión de configuración requerido para el

servicio seleccionado y cómo es alcanzado.
 Identificar la configuración, definiendo tipos de CI. Es importante definir cómo los
tipos de activos y elementos de configuración serán seleccionados, agrupados,
clasificados y definidos por sus características propias y las relaciones entre ellos.
Las relaciones describen como se combinan los elementos para proporcionar un
servicio, algunas relaciones y un ejemplo son las siguientes:
o Es parte de un módulo de software, es parte de una aplicación.
o Está vinculado con una computadora, está conectada a una red.
o Utiliza un servicio de negocio, utiliza un servidor.
 Controlar la configuración, asegurando que hay mecanismos de control adecuados
sobre los CI’s al mismo tiempo que mantienen registro de los cambios de CI’s,
versiones, localización y propiedad.
 Contabilizar e informar el estado de CI’s, cada CI tiene uno o más estados
discretos mediante los cuales puede progresar. El significado de cada estado debe
ser definido en términos del uso que se le da al CI.
 Verificar y auditar, revisando que el CI existe y que su documentación es exacta.
Incluye una serie de revisiones y auditorías para asegurar que hay conformidad
entre las líneas de referencia documentados y el ambiente actual del negocio al
cual se refiere.

Los roles del proceso son:

Los indicadores clave de desempeño (KPI) del proceso:

Porcentaje de mejora y programación de mantenimiento sobre la vida

de un activo.

Activos identificados como la causa de fallas de servicios.

KP Mejora en la velocidad de la gestión de incidentes para identificar fallas

I en CI's y restablecer el servicio.

Porcentaje de licencias usadas contra pagadas.

Grado de alineación entre mantenimiento proporcionado y soporte de

negocio.
La actividad de identificar qué es lo que se quiere controlar es imprescindible y es
recomendable que se creen categorías de agrupación de CI’s y decir, por ejemplo,
computadora en lugar de mencionarla en partes: teclado, pantalla, etc., pues
debemos recordar que cualquier cambio que se desee hacer a cada uno debe
pasar por el proceso de cambios lo que puede hacer que el personal no
documente tantos cambios y al momento de auditar no concuerde lo físico con la
CMDB.
Ahora bien, ya hemos visto que en este proceso lo que se defina y requiera una
modificación requiere pasar por el proceso de cambios el cual, de acuerdo al tipo
de cambio, pasará por un proceso de aprobación o pre aprobación y será Cambios
quien se encargue de coordinar dicho ajuste. Entonces, ¿qué proceso es el que
implementa o construye los cambios? Este es el siguiente proceso a revisar:
Gestión de implementación y despliegue.
Gestión de implementación y despliegue
Es la encargada de la implementación y control de calidad de todos los servicios
(o cambios de servicios) que se van a introducir a la operación del negocio. Busca
construir, probar y liberar las capacidades necesarias para brindar los servicios
que fueron especificados en la fase de Diseño del servicio.
Debemos estar conscientes de que se generan muchos cambios en las
organizaciones, por lo que este proceso debe ser capaz de decidir si se juntan
más de un cambio en una sola liberación, es algo similar a un service pack en el
cual son varias actualizaciones a un mismo sistema.
El objetivo del proceso es asegurar que: se puede crear, instalar probar e
implementar servicios de TI, sistemas y componentes de manera eficiente, con
éxito y a tiempo, asegurando una transición tranquila de la infraestructura anterior
a la nueva o modificada.
Terminología importante que debes conocer:

 La entrega es un conjunto de elementos de configuración, nuevo o modificado que

son probados e implementados conjuntamente en el entorno de producción.
 La unidad de entrega porción del servicio o la infraestructura que está incluida en
la entrega, de acuerdo con las directrices de entrega de la organización.
Las actividades que realiza el proceso son:

 Planeación de entrega y despliegue. El plan debe incluir el alcance, riesgos,

responsabilidades y partes interesadas en el despliegue. Los planes más
importantes son los criterios de pase/fallo y los planes de construcción y pruebas.
Además, se debe tener la planificación de pilotos, planes de paquetes de entrega y
planes de despliegue.
 Construir y probar. En esta actividad se debe de documentar las versiones y
construcción, por ejemplo, plantillas, servicios, productos y CI’s necesarios para la
construcción. En caso de ser necesario, se debe adquirir y probar los
componentes y CI’s. Una vez hecho esto se empacan las versiones y se
construyen y prueban los entornos de prueba y pilotos.
 Probar el servicio y pilotos. La gestión de pruebas es la encargada de coordinar
las actividades de prueba y de planificar y controlar la implementación.
 Planear y preparar el despliegue. Se prepara al grupo para el despliegue.
 Realizar transferencias, despliegues y retiros. Se realizan las actividades
necesarias para distribuir e instalar el servicio.
 Verificar el despliegue. Verifica que todos los usuarios, personal de operación de
servicio, otros empleados y partes interesadas, puedan utilizar el servicio tal como
está previsto.
 Soporte post implementación. Se ofrece soporte adicional después del
despliegue de un servicio nuevo o modificado. Permite resolver problemas
operativos y de soporte con la mayor rapidez posible, lo que significa que los
usuarios no tienen que padecer interrupciones del servicio.
 Revisar y cerrar el despliegue. Se debe comprobar que la formación y
transferencia de conocimientos adecuados; se han documentado las experiencias
de todos los usuarios; se han satisfecho los criterios de calidad.

Los roles del proceso son:

Los indicadores clave de desempeño (KPI) del proceso:

Reducción de recursos y costos para diagnosticar y solucionar

problemas en despliegue y producción.

Porcentaje de software con defectos en producción.

KP
I Costo promedio de cada despliegue.

Cumplimientos de los plazos previstos para cada despliegue.

Cantidad de versiones de software ilegal.

Este proceso tiene como actividad garantizar que las pruebas se lleven a cabo.
3.1.3 Procesos de apoyo a la transición: validación y pruebas del servicio,
evaluación del cambio y gestión del conocimiento del servicio
Validación y pruebas del servicio
Las pruebas del servicio realizan una gran contribución a la calidad en la entrega
de servicios de TI dado que garantizan que los servicios nuevos o modificados
estén acordes a lo que el cliente espera y al uso que se espera de ellos.
El objetivo es comprobar que la entrega proporciona los resultados y el valor
esperado por los clientes dentro de los costos, capacidad y restricciones previstas,
además de que cumplen las especificaciones del cliente y las partes interesadas.
Terminología importante que debes conocer:
Modelo de servicio: describe la estructura y dinámica de un servicio
proporcionado por la operación del servicio. La estructura consta de servicios
esenciales, servicios de soporte y activos del servicio necesarios.
Estrategia de pruebas: define el planteamiento global de las pruebas y la
asignación de recursos necesarios
Modelo de pruebas: incluye un plan de pruebas, el objeto que se desea probar y
los guiones de pruebas que indican el método con el que se debe probar cada
elemento.
Las actividades que realiza el proceso son:
 Figura 5.3 Flujo de trabajo del proceso de validación y pruebas del servicio.
Fuente: Bon, J. et al. (2008). Fundamentos de la gestión de servicios de TI basada en ITIL® con fines
académicos. ITSM Library: Van Haren Publishing.

Los indicadores clave de desempeño (KPI) del proceso:

Reducción del impacto de incidentes y errores en producción que son

KP atribuibles a una nueva transición de servicio.
I
Uso más efectivo de los recursos e implicación del cliente.
El objetivo de realizar pruebas es validar que se esté cumpliendo con los
estándares que se deseen tenga un producto, en este caso un servicio. El
siguiente proceso a revisar apoya en dos partes de la fase de transición, la
primera es en apoyar con información a la gestión de cambios a decidir la
aprobación o no de un cambio y la segunda es cuando un cambio ya se ha
realizado y liberado da retroalimentación del costo-beneficio del mismo para poder
aportar conocimiento de lo que se hizo bien o no.
Evaluación del cambio
La evaluación es un proceso genérico con el que se considera si algo tiene un
rendimiento aceptable, si su relación valor-precio es adecuada o si se utilizará,
aceptará o pagará por ello.
El objetivo del proceso es determinar el rendimientode un cambio en un servicio,
tal rendimiento se evalúa en función del rendimiento esperado.
Las actividades que realiza el proceso son las siguientes:

 Planificación de la evaluación: se analizan los efectos, tanto previstos como

imprevistos, de la puesta en marcha de un cambio o nuevo servicio.
 Evaluación del rendimiento previsto: se realiza una revisión basada en los
requisitos del cliente (incluyendo criterios de aceptación) y el rendimiento
esperado. Si la evaluación indica que el rendimiento esperado supone un riesgo
inaceptable para el cambio o se desvía de los criterios de aceptación, se envía un
informe de evaluación a la Gestión de cambios y se interrumpen las actividades de
evaluación a la espera de una decisión por parte del proceso de cambios.
  Evaluación del rendimiento real: se realiza una vez el cambio ha sido ya
implementado, y consiste en analizar los efectos que ha provocado su puesta en
marcha.

Los indicadores clave de desempeño (KPI’s) del proceso:

Diferencias en el rendimiento del servicio.

Número de incidentes debido al rendimiento.

KPI
´s
Número de diseños fallidos.

Tiempo de evaluación.
Gestión del conocimiento del servicio
Es el proceso de reunir, analizar, almacenar y compartir el conocimiento e
información de la organización.
Los objetivos del proceso son permitir al proveedor de servicio ser más eficiente y
mejorar la calidad del servicio, incrementando la satisfacción y reduciendo el costo
del servicio, así como asegurar que el personal tenga un entendimiento claro y
común del valor del servicio que proveen a los clientes y las formas en que los
beneficios son obtenidos al usar dichos servicios.
Podemos concluir que su propósito es asegurar que la información correcta sea
entregada en el lugar apropiado o a la persona adecuada y en el tiempo correcto
para tomar una correcta decisión. Para lograrlo debe coordinar esfuerzos para
garantizar que personal hace uso de las herramientas, tanto para registrar como
para consultar los datos disponibles y se evalúan los datos almacenados y se
asegura que estén actualizados.
Terminología importante que debes conocer:

 Dato. Conjunto discreto de hechos sobre eventos. Son mediciones cuantificables y

objetivas.
 Información. Es típicamente almacenada en un contenido semiestructurado tal
como un documento, correo electrónico o multimedia. Contexto de los datos.
 Conocimiento. Compuesto de experiencias tácitas, ideas, valores y juicios de
individuos.
 Sabiduría. Habilidad de usar el conocimiento de tal forma que mejore los
resultados.
 Sistema de gestión del conocimiento del servicio SKMS. Herramienta y bases
de datos que proporcionan funcionalidades de presentación, procesamiento y
gestión para interactuar con la base de datos de gestión del conocimiento del
servicio de la organización TI.

Los indicadores clave de desempeño (KPI’s) del proceso:

KPI Número de solicitudes de entradas nuevas recibidas o

´s modificaciones en un periodo específico.

Número de entradas modificadas en la base de conocimiento en un

 periodo específico.

Número de incidentes que recurrieron a entradas existentes en la

base de conocimiento en un periodo específico.

Tiempo ahorrado gracias al uso de la base de conocimiento.

3.2 ITIL. Operación del servicio

3.2.1 Gestión de incidentes
Todos los servicios que usamos en el día a día son susceptibles a fallas, lo cual
merma o restringe el servicio. Cuando esto nos sucede, lo primero que pensamos
es en acudir a un lugar o realizar una llamada para que nos proporcionen una
solución a dicha falla para no quedarnos sin el servicio. El proceso que se encarga
de solucionar las fallas en los servicios que ya están siendo usados es gestión de
incidentes.
Este proceso trata todo tipo de incidentes ya sea fallas, preguntas o consultas
planteadas por los usuarios (llamadas al centro de servicio al usuario) o personal
técnico o bien detectadas automáticamente por herramientas de monitorización de
eventos. Su objetivo es restablecer la operación normal del servicio tan rápido
como sea posible, minimizando el impacto adverso en las operaciones del
negocio.
Terminología importante que debes conocer:

 Incidente: interrupción no planificada o una reducción de calidad de un servicio de

TI. El fallo de un elemento de configuración que no haya afectado todavía el
servicio también se considera un incidente.
 Escalas de tiempo: se definen límites de tiempo para todas las fases y se
emplean como objetivos de acuerdo al nivel operativo (OLA) y contratos de
soporte.
 Incidente grave: tiene como consecuencia una interrupción importante en el
servicio, por lo que requieren un procedimiento distinto con plazos más cortos.
 Solución temporal: método para abordar un incidente o problema, sea por una
solución temporal o a través de una técnica.
 Diagrama de flujo básico para manejo de incidentes.

A continuación, se presenta el diagrama de flujo básico para manejo de incidentes,

para entender las actividades que realiza este proceso.

 Identificación y registro.
Se registran detalles básicos del incidente, se alerta a especialistas de grupos de soporte,
cuando sea necesario.
 Clasificación, priorización y diagnóstico inicial.
Se clasifican los incidentes mediante códigos apropiados para los diferentes tipos de llamadas
y en caso de ser una solicitud de servicio se invoca el proceso de cumplimiento de la solicitud.
La asignación de la prioridad depende de dos variables: el impacto (número de usuarios
afectados) y la urgencia (rapidez con la cual debe solucionarse). Para esto, las empresas
tienen que crear una tabla para determinar la prioridad. Lo siguiente es proporcionar el
diagnóstico inicial, encontrando una solución rápida, para ello será importante contar con
guiones de diagnóstico y acceso a soluciones temporales o errores conocidos. En caso de
que el incidente haya sido solucionado, se debe pasar a la actividad de cierre, de lo contrario
es necesario escalar el incidente.
 Escalación, investigación y diagnóstico.
La escalación puede hacerse de dos maneras: escalado funcional, en la cual el incidente es
transferido a un técnico con mayor experiencia para ayudar en la solución; y el escalado
jerárquico, cuando no se cuenta con los recursos adecuados para resolver el incidente y se
requiere de niveles de la cadena de mando en la organización para que puedan tomar las
medidas oportunas. Una vez escalado se investiga que es lo que ha fallado y se realiza un
diagnóstico. Todas estas actividades deben de quedar documentadas en el registro del
incidente.
 Resolución y recuperación.
Si se ha determinado una solución se debe implementar y probar. Se debe estar consiente de
tener informado al usuario sobre el estado de la solución.
 Cierre.
Antes de cerrar el incidente se debe confirmar tanto que la categorización del incidente fue
correcta como la solución con el usuario o quien la haya registrado. Se realiza una encuesta
de satisfacción al usuario y se asegura que el incidente está completamente documentado.
Por último, se revisa si es recurrente, en cuyo caso se invoca el proceso de gestión de
problemas.
Los roles del proceso son:

Los indicadores clave de desempeño (KPI’s) del proceso:

KP Número total de incidentes.

I
Tiempo promedio transcurrido hasta lograr la resolución del incidente.

Costo promedio por incidente.

Porcentaje de incidentes manejados dentro de los tiempos de

respuesta acordados.
 Número y porcentaje de incidentes mayores.
Los retos del proceso son:

 Capacidad para detectar incidentes tan pronto como sea posible.

 Convencimiento del personal (equipos técnicos, así como usuarios) de que deben
registrar todos los incidentes.
 Disponibilidad de la información sobre problemas y errores conocidos.

Un ejemplo de un incidente en una clase es cuando el maestro no puede acceder a servicios

en línea para poder pasar lista debido a una falla, el maestro usará una solución temporal que
es pasar lista en una hoja y posteriormente cuando el servicio haya sido restablecido pasarla.
Es posible que el maestro acuda a reportar el incidente que tuvo y aunque no se le da un
ticket se procede a verificar el motivo del fallo para que los maestros puedan usar el servicio lo
más pronto posible.
Un incidente, debido a su criticidad, puede ser elevado a problema proceso cuyo principal
objetivo es reparar de manera definitiva la causa de fallo. Se dice que incidentes es el
equivalente a una aspirina para un dolor de cabeza y problemas será el que determine qué
causa el dolor para poder dar el medicamento apropiado para eliminarlo. El siguiente proceso
a analizar es precisamente la gestión de problemas.
3.2.2 Gestión de problemas
Se ocupa de controlar el ciclo de vida de todos los problemas, su objetivo es prevenir
problemas e incidentes, eliminar la repetición de incidentes y minimizar el impacto de los
incidentes que no se pueden evitar.
Terminología importante que debes conocer:

 Problema: causa de uno o más incidentes.

 Error conocido: problema del que se tiene una causa raíz documentada y una
solución temporal.
 Base de datos de errores conocidos: base de datos que tiene por objeto almacenar
conocimientos sobre incidentes y problemas, y cómo resolverlos de manera que sea
posible diagnosticarlos y resolverlos en menos tiempo si se vuelven a producir.

Actividades del proceso de gestión de problemas

Este proceso incluye dos subprocesos importantes:

1. Gestión proactiva de problemas.

Iniciada en la operación del servicio, pero normalmente realizada por la mejora
continua del servicio. Aquí se incluye el análisis de incidentes y eventos con el fin de
identificar tendencias o posibles puntos débiles.
2. Gestión reactiva de problemas.
Este subproceso tiene las siguientes actividades:
a. Identificación del problema: se puede identificar ya sea por grupos de
soporte técnico al analizar un incidente y descubren que hay un problema
subyacente, por un análisis de incidentes como parte de la gestión proactiva
de problemas, porque el centro de servicio sospecha o identifica una causa
desconocida para uno o más incidentes.
b. Registrar: independientemente de cómo se haya detectado se debe registrar
el problema para crear un informe histórico.
c. Categorizar: al igual que los incidentes, los problemas deben de clasificarse
para poder determinar su naturaleza de forma rápida y sencilla, esta
clasificación proporciona información útil para la gestión.
d. Priorización: al igual que en incidentes a los problemas se les asigna una
prioridad. Algunas preguntas que se deben de tomar en cuenta para asignar la
prioridad son:
  ¿Cuánto tiempo se necesita para resolver el problema?
 ¿Cuál es la gravedad del problema?
 ¿A cuánto ascienden los costos?
e. Investigación y diagnóstico: para encontrar la causa raíz que origina el
problema y hacer un diagnóstico, se debe hacer una investigación. La
naturaleza de la investigación depende del impacto, gravedad y urgencia del
problema. En ocasiones el replicar el problema ayuda a determinar qué lo ha
causado, pero existen otras técnicas de análisis, diagnóstico y solución de
problemas como: diagramas de Ishikawa, lluvia de ideas, análisis de Pareto y
método de Kepner-Tregoe.
f. Decisión sobre soluciones temporal: en algunos casos se puede usar una
solución temporal para incidentes causados por un problema, sin embargo, es
importante que se mantenga abierto el problema y se incluyan en él los datos
sobre la solución temporal.
g. Crear registro de error conocido: tan pronto se haya terminado con el
diagnóstico y se hayan encontrado soluciones temporales, los errores
conocidos se deben incluir en un informe en la base de datos de errores
conocidos.
h. Solución: se aplica la solución encontrada, en caso de que la solución
requiera de un cambio, es necesario generar un RFC y el control se pasa a la
Gestión de cambios. Una vez que el cambio se haya realizado se notifica a
problemas para que se aplique nuevamente la solución y se pueda proceder al
cierre.
i. Cierre: antes de cerrar se debe validar que se hayan registrado todos los
detalles del problema en cuestión.

Los roles del proceso son:

Los indicadores clave de desempeño (KPI’s) del proceso:

KP Cantidad de problemas.
I
Tiempo de resolución de problemas.

Cantidad de incidentes por problema.

Tiempo hasta la identificación del problema.

 Número de errores conocidos agregados a la base de datos de errores
conocidos.
Los retos del proceso son:

 Ligar las herramientas de incidentes y problemas.

 Relacionar los registros de incidentes y problemas.
 El personal de 2° y 3er nivel debe llevar una buena relación con el personal de 1er
nivel.
 Asegurar que se comprenda el impacto en el negocio.

Es muy importante no solo que se genere la base de datos de errores conocidos y soluciones
temporales, sino que ésta pueda ser accedida por el personal encargado de los incidentes
que, como veremos en el siguiente tema de funciones, es el centro de servicio al usuario. Un
problema se origina por varios incidentes, volviendo al ejemplo de servicios en línea, el
incidente se puede escalar a problema si es reportado por varios maestros y en varios
campus. Esto indica que hay que analizar a profundidad qué situación está causando esto
para encontrar la causa raíz.
3.2.3 Gestión de accesos, gestión de eventos y cumplimiento de la solicitud
Gestión de accesos
Proceso responsable de permitir a los usuarios el uso de los servicios de TI, datos u otros
activos. Ayuda a proteger la confidencialidad (quién tiene acceso), la integridad (está completa
la información), la disponibilidad (está la información cuando se requiere) de los activos
asegurando que solo los usuarios que tienen la autorización puedan accederlos o
modificarlos. Su objetivo es proporcionar el derecho para usar un servicio o grupo de servicios
y prevenir el acceso a usuarios no autorizados, lo cual implica la ejecución de las políticas y
acciones definidas para la seguridad de la información.
Terminología importante que debes conocer:

 Acceso: se refiere al nivel y extensión de la funcionalidad de un servicio o información

que un usuario está intentando usar.
 Identidad: hace referencia a la información sobre las personas reconocidas por la
organización y define su estado.
 Servicios o grupos de servicio: conjunto de servicios utilizados por varios usuarios.
 Directorio de servicios: hace referencia a un tipo de herramienta empleada para
gestionar accesos y derechos, lo que hace es gestionar información de la
infraestructura de TI disponible en una red y relacionando usuarios y derechos de
acceso.
 Derechos: se refiere a la configuración real de un usuario e indican los servicios o
grupo de servicios que está autorizado a acceder.

Las actividades que realiza el proceso son:

 Verificar: validar el requerimiento de acceso y verificar que los usuarios sean quien

dicen ser y si tienen un motivo válido para solicitarlo.
 Proveer privilegios: aplicar las políticas/regulaciones de accesos dictaminadas en la
gestión de seguridad y se proporciona el acceso.
 Monitorear estatus: monitorear el estatus de acuerdo con los cambios en las
necesidades y se busca identificar el ciclo de vida típico de cada usuario para ver si es
posible automatizarlo.
 Restringir y monitorización de accesos: comprobar que los derechos concedidos se
utilizan correctamente. Por ello se requiere monitorearlos para remover o restringir
permisos en caso de ser necesario.
 Revocación o limitación de derechos: responsable de revocar dichos permisos,
aunque no pueda tomar esa decisión.
Los indicadores clave de desempeño (KPI’s) del proceso:

Número de solicitudes de acceso.

Instancias de acceso concedidas: por servicio, por usuario, por

departamento.
KP
I
Número de incidentes que requieren renovar los permisos.

Número de incidentes causados por configuración incorrecta de

permisos de acceso.
Un ejemplo de este proceso es cuando entras a Tecmilenio y para que tengas correo
electrónico, acceso a la plataforma y servicios en línea, debes ser alumno inscrito. Cuando no
estás al corriente de tus pagos no puedes acceder a tus calificaciones. Si te das cuenta, este
proceso está presente pues se está monitoreando quién debe de acceder a los servicios de
acuerdo a las políticas.
Gestión de eventos
Un evento se puede definir como cualquier suceso detectable que tiene importancia para
gestión de la infraestructura de TI o para la entrega de un servicio de TI, así como para la
evaluación del impacto que podría causar una desviación sobre los servicios. El objetivo es
detectar eventos, analizarlos y determinar la acción apropiada.
Existen tres tipos de eventos que pueden ser detectados los cuales son:

 Eventos que indican una operación normal (informativos): como el acceso de un

usuario a una aplicación para usarla.
 Eventos que indican una excepción: como un usuario que intenta acceder a una
aplicación con una contraseña incorrecta o un análisis que detecta la instalación de un
software no autorizado en una computadora.
 Eventos que señalan una operación inusual: pero no de excepción; esto puede indicar
que la situación requiere de un nivel mayor de supervisión (por ejemplo, cuando el uso
de la memoria de un servidor está a menos del 5% de su nivel máximo aceptable).

Las actividades que realiza el proceso son:

a. Aparición del evento: los eventos suceden en cualquier momento y no siempre son

detectados o registrados, de ahí que es importante que se comprenda cuáles eventos
se pueden detectar.
b. Informe de eventos: los elementos de configuración comunican la información
usando una herramienta de gestión que analiza un dispositivo y recopila datos
específicos o bien ellos mismos generan un informe al cumplir ciertas condiciones.
c. Detección de eventos: un agente o herramienta detecta un informe de evento lo lee y
lo interpreta.
d. Filtrado de eventos: decide si el evento se comunica o no a la herramienta de
gestión; en caso negativo, el dispositivo incluye el evento en un registro y no inicia
ninguna acción.
e. Clasificación de eventos según su importancia: se clasifican en:
o Informativos: no requieren ninguna acción y no son una excepción.
o Alerta: se produce cuando un servicio o dispositivo alcanza el umbral.
o Excepción: Indica un comportamiento que no cumple con los requisitos del
OLA o SLA.
f. Correlación del evento: se analiza si existen eventos similares, así como la
importancia del evento en sí mismo y se decide si es necesario tomar medidas.
g. Disparadores: se ponen en marcha los mecanismos necesarios para dar respuesta al
evento.
 h. Opciones de respuesta: se eligen las soluciones a adoptar: registro de evento,
respuesta automática, alerta con intervención humana, RFC, incidente o problema.
i. Revisión de acciones y cierre: se revisan las excepciones o eventos importantes
para determinar si se han tratado correctamente; se cierra el proceso de gestión de
eventos.

Los indicadores clave de desempeño (KPI’s) del proceso:

Número de eventos por importancia.

Número y porcentaje de eventos que requirieron intervención humana.

Número y porcentaje de eventos que dieron como resultado

incidentes, problemas o cambios.
KP
I Número y porcentaje de eventos causados por problemas existentes o
errores conocidos.

Número y porcentaje de eventos repetidos o duplicados.

Número y porcentaje de eventos que indican futuros problemas de

disponibilidad.
Algunos ejemplos de eventos son las notificaciones que pones en tu celular, de tal manera
que cuando te llega un mensaje ya sea de Facebook, mensaje de texto o lo que hayas
configurado, te aparecerá en tu pantalla, estos son eventos informativos.
Habíamos comentado que los clientes de los servicios hablan para pedir, ya sea información o
contratar un servicio, estas acciones son manejadas por el proceso de cumplimiento de la
solicitud, el cual es el proceso encargado de procesar las solicitudes de servicio de los
usuarios, entre sus objetivos se encuentran:
Cumplimiento de la solicitud
Es el proceso encargado de procesar las solicitudes de servicio de los usuarios. Sus objetivos
son:

 Poner a disposición de los usuarios un canal a través del cual puedan solicitar y recibir
servicios para lo cual debe existir un proceso de aprobación.
 Proporcionar a los usuarios y clientes información sobre la disponibilidad de servicios y
el procedimiento para obtener dichos servicios.
 Facilitar información general, quejas y comentarios.
 Proporcionar los componentes de servicio estándar.

Terminología importante que debes conocer:

 Modelo de solicitud de servicio: contiene los pasos que deben tomarse, el orden

cronológico de los pasos, las dependencias, responsabilidades, escalas de tiempo,
procedimientos de escalación y quién debe ser contactado y cuándo.

Las actividades del proceso son:

 Generar solicitudes de servicio: se permite a los usuarios generar sus propias

solicitudes de servicio usando herramientas que le permitan seleccionar e introducir
detalles de su solicitud.
  Dar aprobación: identificar tipo de aprobación requerida sea financiera u otras
aprobaciones.
 Cumplimiento: dar seguimiento y monitorear el avance de la solución y mantener
informados a los usuarios.
 Cerrar: confirmar la solución con el usuario.

Los indicadores clave de desempeño (KPI’s) del proceso:

Número total de solicitudes de servicio.

Número de solicitudes pendientes de resolución.

KP Número y porcentaje de solicitudes atendidas de acuerdo a los

I tiempos establecidos.

Costo promedio por tipo de solicitud.

Nivel de satisfacción del usuario.

Un ejemplo de este proceso se da cuando un cliente de un servicio de telefonía quiere
contratar un servicio adicional, por ejemplo, identificador de llamadas, llamada en espera,
internet, entre otros. Para ello, habla a un centro de servicio y hace la solicitud del servicio
adicional que desea.
Tema 4. Funciones de operación y
mejora continua del servicio

Introducción
La gestión de la capacidad es uno de los cinco componentes en el área de la
prestación de servicios de ITIL. El trabajo es proactivo en lugar de reactivo en su
naturaleza y es responsable de asegurar que las necesidades del negocio y las
definiciones de servicio se cumplen con un mínimo de recursos informáticos.
Los equipos de administración de capacidad tienen estrechos vínculos con las
áreas de administración de los niveles de servicio y la administración financiera. A
través de los procesos de administración de la capacidad, el nivel de servicio más
completo y la información financiera correspondiente están a disposición de la
empresa, permitiendo que la toma de decisiones esté sustentada.

Explicación
4.1 ITIL: Funciones en la operación del servicio
4.1.1 Centro de servicio al usuario
Las funciones de la operación del servicio, se dividen en cuatro, tal como lo
expone la siguiente figura:

Funciones de operación del servicio ITIL v3

Centro de servicios al usuario
El centro de servicio al usuario es el lugar al que hablas para solicitar servicios,
pedir información, así como ver y reportar fallas. Este centro es una unidad
funcional cuyos miembros participan en diversos eventos del servicio, los cuales
pueden ser recibidos vía telefónica, internet, mediante una herramienta o pueden
generarse automáticamente (caso de eventos). Además, es el punto único de
contacto entre el proveedor de servicio y los usuarios.
Justificación y rol del centro de servicio al usuario
Es el mejor recurso para ser la primera línea de soporte, ya que ofrece las
siguientes ventajas:

 Mejor servicio al cliente, mejor percepción del servicio por parte del cliente y mayor
índice de satisfacción entre los clientes.
 Mayor accesibilidad al ser el único punto de contacto.
 Mejor impacto negativo sobre el negocio.
 Mejor gestión y manejo de la infraestructura.
 Mejor cooperación y comunicación.

Los objetivos del proceso son:

 Registrar el detalle de todos los incidentes y solicitudes de servicio, categorizarlos,

priorizarlos y resolverlos.
 Proporcionar investigación y diagnóstico de primer nivel.
 Escalar incidentes/solicitudes de servicio que no puedan ser resueltos dentro de
los tiempos acordados.
 Realizar encuestas de satisfacción de clientes/usuarios.
 Mantener informados a los usuarios del progreso de sus tickets, notificarlos
cuando existan cambios o no se vaya a cumplir con los tiempos establecidos.

Las organizaciones pueden optar por diferentes estructuras de centros de servicio

al usuario, dependiendo de sus necesidades:

 Centro de servicio al usuario local: está situado físicamente en el mismo lugar que
los usuarios a los que da el soporte o muy cerca de ellos.
 Centro de servicio al usuario centralizado: se reúnen todos los centros de servicio
locales en un sólo centro de servicio.
 Centro de servicio al usuario virtual: esparcidos geográficamente y hacen uso de la
tecnología para atender al cliente.

Los roles del proceso son:

 Roles del centro de servicio al usuario

Los indicadores clave de desempeño (KPI) son:

Porcentaje de llamadas resueltas en el primer nivel, sin escalación.

Tiempo promedio para solucionar un incidente (cuando se resuelve a

primer nivel).

Tiempo promedio para escalar un incidente (cuando no se resuelve en

primer nivel).
KP
I Costo promedio del centro de servicio por manejar un incidente.

Número de llamadas gestionadas por cada miembro del personal del

centro de servicios.

Tiempo promedio para revisar y cerrar una llamada resuelta.

Número de llamadas no atendidas.

El centro de servicio al usuario es el dueño del proceso de incidentes y
cumplimiento de la solicitud. Cuando se presentan incidentes se puede dar una
solución en línea, esto quiere decir que cuando se hace un reporte el analista
puede dar la solución al cliente y en ese caso se cierra el incidente, pero cuando
se tiene que escalar a grupos especializados, se trata de la gestión técnica y
gestión de aplicaciones. El decidir a qué grupo se escala depende de la naturaleza
del incidente. En caso de ser incidentes relacionados a software, será la gestión
de aplicaciones la que se encargue de ello; pero si es de hardware, se le asignará
a la gestión técnica. A continuación se detallará cada una de ellas:
4.1.2 Gestión técnica y gestión de aplicaciones
Gestión técnica
Responsable de proporcionar el conocimiento técnico para apoyar los servicios de
TI y la Gestión de la Infraestructura de TI. Se encarga, además, no solo de que los
recursos de TI estén disponibles en la fase de operación, sino también de que
tengan el nivel adecuado y de que realmente se estén utilizando. Toma parte en el
diseño, pruebas, despliegue y mejora de los servicios TI.
El objetivo del proceso es:
Ayudar a planear, administrar y a mantener una infraestructura técnica estable
para soportar los procesos de negocio de la organización mediante:

 Una topología técnica con buen diseño, altamente resistente y efectiva en costos.
 Uso de habilidades técnicas adecuadas para mantener la infraestructura técnica
en condiciones óptimas y para diagnosticar con rapidez y resolver fallas técnicas
cuando ocurran.

Las actividades básicas el proceso son:

 Identificar la necesidad de capacitación del personal de TI en relación a cuestiones

técnicas (infraestructura).
 Asegurar que el conocimiento requerido para diseño, pruebas, administración y
mejora de los servicios de TI sea identificado, desarrollado y mejorado.
 Definir estándares para diseñar nuevas arquitecturas, participando además en la
definición de las mismas durante las fases de estrategia y diseño.

Gestión de aplicaciones
Es el responsable de gestionar las aplicaciones en su ciclo de vida y de dar
soporte y mantenimiento a las aplicaciones. Tiene un rol importante en el diseño,
prueba y mejora de aplicaciones que forman parte de los servicios de TI.
Generalmente se divide en departamentos de acuerdo al portafolio de aplicaciones
de la organización, para permitir la especialización y enfocarse más al soporte.
Los objetivos del proceso son:

 Dar soporte a los procesos de negocio de la organización ayudando a identificar

los requisitos funcionales del software de aplicaciones.
 Prestar apoyo en el diseño y desarrollo de dichas aplicaciones y colaborar en el
soporte y mejora que siguen a su despliegue, mediante:
o Aplicaciones bien diseñadas.
o Asegurar que la funcionalidad requerida está disponible para alcanzar los
resultados de negocio deseados.
o Organizar las habilidades técnicas adecuadas para mantener aplicaciones
operacionales en condiciones óptimas.
o Uso de habilidades técnicas para un diagnóstico rápido y resolver cualquier
falla técnica que ocurra.

Actividades básicas del proceso:

 Participa en diseño de nuevos servicios.

  Vigila el conocimiento técnico y experiencia relacionada con el manejo de
aplicaciones.
 Apoya a la gestión técnica en la tarea de identificar el conocimiento y experiencia
necesarios para gestionar las aplicaciones a la hora de prestar servicios de TI.
 Apoya en la contratación al asegurar que la organización contrate los recursos
humanos necesarios para manejar aplicaciones y cumplir así con los objetivos del
negocio.
 Proporcionar asesoramiento en riesgos, identificando servicios críticos y
dependencias de sistema y definiendo e implementando contramedidas.

Para aquellas tareas que son rutinarias existe otra función encargada de
realizarlas, denominada gestión de operaciones.
4.1.3 Gestión de operaciones de TI
Su función dentro de un proveedor de servicio es el de ejecutar todas las
actividades del día a día, dedicadas al mantenimiento de la infraestructura y a
asegurar que los servicios se están prestando con normalidad.
Los objetivos del proceso son:

 Mantener un estatus adecuado para lograr estabilidad en los procesos y

actividades que se realizan diariamente.
 Investigar regularmente y proponer mejoras en el servicio, reduciendo costos, pero
manteniendo la estabilidad.
 Aplicación rápida de habilidades operacionales para diagnosticar y resolver
cualquier falla en operación de TI.

Las actividades básicas del proceso son:

 Control de operaciones: supervisa la ejecución y monitorización de la prestación

de servicios, así como de los eventos relacionados con la infraestructura de la
organización:
o Programación de tareas automatizadas.
o Back-up y restauración de archivos.
o Gestión de impresión.
 Gestión de instalaciones: gestiona el entorno físico de la infraestructura TI.

4.2 ITIL. Mejora continua del servicio y tecnología

4.2.1 Ciclo Deming y los siete pasos de la mejora
El proceso de mejora del servicio (CSI, Continual Service Improvement) de siete
pasos, describe cómo medir y reportar la mejora. Sin embargo, el proceso básico
de esta estructura de mejora se lleva a cabo de acuerdo con el ciclo de Deming,
también conocido como ciclo PDCA (Plan, Do, Check y Act), este ciclo es el centro
de la mejora continua, la siguiente figura presenta el ciclo de Deming:
Si la gestión de nivel de servicio descubre que algo podría mejorarse, inicia el
proceso de ciclo de mejora de siete pasos. Dicho proceso desarrolla actividades
para llevar a cabo estas mejoras, es aquí donde una mejora se convierte en un
proceso de TI con entrada, actividades, salidas, roles y reportes. A continuación se
describen los objetivos de la mejora continua:

a. Definir continuamente qué se debe y puede medir, así como transformar los datos
recopilados en un conjunto significativo de acciones correctivas mediante el uso de
técnicas y herramientas a lo largo del ciclo de vida.
b. Identificar e implementar actividades individuales para mejorar la calidad de los
servicios de TI y mejorar la efectividad y eficiencia de los procesos de ITSM (IT
Service Management).
c. Mejorar el costo de proveer servicios sin sacrificar la satisfacción del cliente.

La mejora debe estar orientada a la visión del negocio, para lo cual existe el
modelo de mejora continua que indica las preguntas que deben realizarse para
que a través de los indicadores que se recolecten de los procesos, se establezcan
los pasos a realizar con la finalidad de rectificar el rumbo y, por ende, tener las
mejoras requeridas.
 Modelo de mejora continua

A continuación se explica el proceso de mejora del servicio de siete pasos:

Paso 1. ¿Qué se debe medir? La respuesta a esta pregunta debe ir después de la visión y
antes de la evaluación de la situación existente del modelo de mejora continua.

Paso 2. ¿Qué se puede medir? El análisis de lo que la organización puede medir permitirá
detectar nuevos requisitos de negocio y opciones de TI. Se utiliza un análisis de gaps para
identificar áreas de mejora y planificar las mejoras.

Paso 3. Recopilar datos. La organización debe realizar mediciones para determinar si ha

alcanzado su objetivo. Las mediciones deben de ser consecuencia de la visión, misión y
objetivos de la organización.

Paso 4. Procesamiento de datos (información). Es necesario por motivos de monitorización.

Debe realizarse de acuerdo a los KPI’s determinados.

Paso 5. Análisis de datos. Se prepara la presentación de discrepancias, tendencias y posibles

explicaciones para el negocio.
Paso 6. Presentar y usar la información. Aquí es donde se informa a los interesados si los
objetivos establecidos se han alcanzado o no. En esta actividad se ejecutan las actividades
del proceso de reporteo del servicio.

Paso 7. Implementar medidas correctivas. En este paso se definen las mejoras, establecen
una nueva línea base e inician el ciclo desde la parte superior.
4.2.2 Reporte y medición del servicio
Reporte del servicio
Es el proceso que se encarga de la generación y suministro de reportes sobre los resultados
obtenidos y la evolución de los niveles de servicio. De acuerdo a cada organización, se
determina la disposición, el contenido y la frecuencia de los reportes. Las actividades que
realiza el proceso son:
 Recopilación de datos
El departamento de TI a menudo reúne grandes cantidades de datos, que no son igual de
importantes para todas las áreas del negocio. Por lo tanto, esta actividad inicia determinando
el grupo meta, el objetivo del reporte (considerando cómo el reporte se va a utilizar) y qué uso
se le dará al mismo.
 Procesamiento de datos y aplicación a la organización

a. Datos que hagan referencia a elementos de servicio contratado.

b. Emplear lenguaje de negocio.
c. No limitado a si TI cumple o no con SLA’s, sino indicar incidencias producidas, qué se
ha hecho para resolverlas y evitar que se repitan.
d. Que sea útil para la toma de decisiones.

 Publicación de la información

a. Dirigida al negocio: saber si el proveedor de servicios de TI ha cumplido con los SLA

(Service Level Agreement).
b. Dirigida a la dirección senior o gestores de procesos: le interesan los Factores Críticos
de Éxito y los Indicadores Clave de Rendimiento, para tomar decisiones estratégicas
de mejora. Dirigida a la organización interna.
c. Personal técnico: Indicadores Clave de Rendimiento y métricas para localizar,
planificar y coordinar oportunidades de mejora.

 Ajuste de los informes para el negocio

Aquí se considera si los datos son valiosos para el grupo objetivo, a continuación se presentan
los tipos de informes que generalmente requieren diversos niveles de la organización.

a. Estrategas: informes breves y que dediquen mucha atención a los riesgos, la imagen
de la organización, la rentabilidad y los recortes en costos.
b. Directores: informes más detallados que resuman la evolución en el tiempo indicando
qué hacen los procesos para facilitar los objetivos de la empresa e identificando
riesgos.
c. Gestores y supervisores: quieren ver los objetivos, el rendimiento de equipos y
procesos, la distribución de recursos y las iniciativas de mejora. Deben indicar cómo
contribuye el proceso a todos ellos.
d. Responsables de equipo y empleados: potenciar las contribuciones individuales a los
resultados de la empresa.

Para las primeras tres actividades del proceso de los siete pasos, se apoya en el proceso de
medición de servicio, el cual se explica a continuación.
Medición del servicio
La medición del servicio debe establecer:

 ¿Qué es lo que se necesita saber?

 ¿Dónde se obtiene dicha información?
 Que la información represente realmente a la realidad que se presenta en el negocio y
ayude a la toma de decisiones.
Las razones para medir son:

 Validar: para probar decisiones anteriores.

 Dirigir: para marcar el rumbo de las actividades a fin de cumplir los objetivos.
 Justificar: con evidencias o pruebas para explicar la necesidad de una determinada
acción.
 Intervenir: para identificar un punto en el que es preciso introducir acciones correctivas
o cambios en el proceso.

En todos los procesos hemos puesto los indicadores o métricas, pero existen otros tipos de
métricas, los cuales deben ser usados para las acciones que se deben de tomar en cuenta
para la mejora de los servicios. Los tipos de métricas son:

 De tecnología: asociadas con el desempeño y disponibilidad de componentes y

aplicaciones.
 De proceso: ayudan a determinar la salud general del proceso, calidad, desempeño,
valor y cumplimiento.
 De servicio: resultado del servicio final.

Las métricas deben adaptarse a los Factores Críticos de Éxito (CSF) que describen aquello
que “debe pasar” para que se cumplan los objetivos preestablecidos y se comparan contra
una línea de tiempo, un objetivo o meta, entre unidades de negocio, servicios diferentes u
otras empresas. Por lo cual se definen roles y responsabilidades para saber:

 ¿Quién define las mediciones y objetivos?

 ¿Quién monitorea y mide?
 ¿Quién recolecta la información?
 ¿Quién procesa y analiza los datos?
 ¿Quién prepara los reportes?
 ¿Quién presenta los reportes?

4.2.3 Tecnología y arquitectura en la gestión de servicio

El uso de la tecnología permite la centralización de los procesos clave y la automatización e
integración de los procesos de la gestión del servicio.
La automatización de servicios es primordial para su prestación. Pero antes de implementar
ITIL hay que pensar primero en la adopción de los procesos, después en los requerimientos
de la herramienta que permitan gestionar estos procesos, hay que ser realista de que se
puede automatizar, pensar de manera estratégica, táctica y operacional. Una vez que
tenemos los procesos definidos debemos hacer una lista de los requerimientos que
quisiéramos tenga la herramienta tecnológica sobre el flujo de actividades de cada proceso y
hacer el análisis MoSCoW.
Análisis MoSCoW para priorizar los requerimientos de la herramienta tecnológica
Con base en la lista de requerimientos, se debe realizar un análisis en el cual se clasifica a
cada uno de los requerimientos de la lista:

 Poner una M a aquellos que debe tener (Must).

 Poner una S a los que debería tener, si es posible (Should).
 Poner una C a los que podría tener si no afecta a nadie (Could).
 Poner una W a aquellos que por el momento no son necesarios (Would).

Después de tener una lista de lo que requerimos que tenga la herramienta, debemos proceder
a evaluar las alternativas del mercado, para ello existe un proceso el cual ayuda a determinar
la mejor opción.
El proceso de evaluación de la herramienta es el siguiente:
 Proceso de evaluación de la herramienta

Los elementos a tomar en cuenta antes de la decisión de la herramienta son:

 Considerar el rendimiento y la funcionalidad.

 Costo de licencias, infraestructura, actualizaciones, etc.
 Requerimientos funcionales actuales y futuros.
 Requerimientos no funcionales.
 Reputación del vendedor.
 Referencias de la herramienta y vendedor.
 Hay que tener cuidado con los costos ocultos.

Como para todo proyecto, en la búsqueda de la herramienta se debe de validar si no se

pagará más de los beneficios que se obtienen al comprar una herramienta, para ello es
necesario determinar el retorno de inversión (ROI):
  Numero de licencia
 Cantidad de personal de TI
 Cantidad de usuarios
 Costos por incidente, cambio o problema
 Costo del centro de servicio al usuario
 Presupuesto de TI

4.3 ITIL Versión 4
ITIL® ha marcado una tendencia clara y moderna en muchas empresas a nivel mundial, tales
como Infosys, TCS, y otras organizaciones de sectores alternos a las tecnologías de
información, como Boeing, Procter & Gambley Barclays. La propuesta de brindar un marco de
mejores prácticas que puedan ser adaptables a las necesidades de la organización ha
mejorado la estandarización en la forma en que la infraestructura de servicios de TI
se implementa en las organizaciones. 
Pese a que las metodologías ágiles (Scrum, Kanban, entre otras) dieron sus primeros pasos
desde la década de los ochenta, no fue sino hasta inicios del año 2000 que comenzaron a
tomar importancia y a expandirse desde la aparición del Agile Manifesto (Agilemanifesto.org,
2001), principalmente en el desarrollo de proyectos de software. 
Según la empresa Paradigma, existe una forma de comparar los elementos del manifiesto ágil
con las mejores prácticas de ITIL (Paradigma, 2019): 

Declaración del manifiesto ágil Presencia de ITIL

ITIL ha sido un marco regulador de

mejora de procesos formales, sin
Individuos e interacciones sobre
embargo, en 2019 ha relegado el
procesos y herramientas.
elemento de personas y sus
relaciones.

ITIL asiente al respecto, debido a los

Producto funcional sobres
documentación exhaustiva.
requerimientos que demandan los
sectores donde funciona
regularmente, que en ocasiones
requieren documentación muy
formal.

Colaboración con el cliente sobre
relación contractual.
ITIL piensa en introducir el concepto
de cocreación en los diversos
elementos de la cadena de valor, sin
prescindir de los SLA, pues estos
sirven para definir expectativas y
validar resultados.

ITIL comienza en 2017 ha

reestructurar su marco como
Respuesta al cambio sobre
respuesta al cambio de lo que
planificación.
demandan las nuevas generaciones
y modo de trabajo.
Como respuesta a la necesidad de cambiar y ofrecer mejores formas a las organizaciones
para implementar una infraestructura de servicios de tecnologías de información, ITIL lanza la
versión 4 con el objetivo de ayudar a las empresas a conectarse y alinearse al concepto de
“ser más ágil”, que tiene un impacto no solo en los profesionales en el área de infraestructura
de servicios de TI, sino en muchos otros expertos envueltos en el trabajo del mundo digital.
Esta nueva versión de ITIL utiliza elementos de la versión 3 que no dejan de ser
fundamentales, pero evoluciona a la vez para ofrecer un modelo totalmente nuevo de
operación digital.
Los cambios establecidos comenzaron a lanzarse al público de manera masiva en el primer
trimestre de 2019, y se prevé que para 2021 la mayoría de las organizaciones alineadas a ITIL
habrá concluido las adaptaciones al nuevo modelo. Estos cambios ofrecen una base más
sencilla y flexible para dar soporte a empresas digitales, pues se considera el impacto
tecnológico que ha sufrido el negocio con su integración al trabajo ágil, DevOps y soporte
para la transformación digital.
Por primera vez, se modifica la idea de tener un ciclo de vida del servicio, para convertirse en
un sistema de valor del servicio (SVS), que es el componente principal de ITIL V4 (Axelos,
2019), quien facilita el valor de cocreación, es decir, establecer servicios donde haya una
relación más íntima en el involucramiento de todos los interesados. Debido al enfoque de
creación de valor, el SVS establece relaciones con otras organizaciones y genera un
ecosistema en el que puede crearse un valor no solo para la organización, sino para los
clientes y todos los involucrados en la cadena de valor.
El sistema de valor del servicio (SVS) se compone de los siguientes elementos (Axelos,
2019): 

 Los siete principios de la guía

 El gobierno
 Cadena de valor de servicio
 Prácticas (en lugar de un enfoque de procesos)
 Mejora continua

El corazón del SVS es la cadena de valor de servicio, y una forma flexible para la creación,
entrega y mejora continua de los servicios ofrecidos. Esta cadena de valor de servicio
define seis actividades principales: planear, mejorar, involucrar, diseño y transición,
obtención/construcción y entrega/soporte. La flexibilidad de este esquema permite que una
empresa pueda, de una manera efectiva y eficiente, reaccionar a las necesidades inherentes
de los involucrados en el servicio. Observa la siguiente imagen:
 Sistema de valor de servicio. Traducido de la imagen original propietaria de Axelos (2019),
solo para fines educativos.
El enfoque holístico de la versión 4 de ITIL es un elemento clave, pues define cuatro
dimensiones críticas para facilitar una entrega exitosa de valor para los clientes y otros
interesados. Las dimensiones son las siguientes (Axelos, 2019): 

Para comprender mejor las dimensiones de ITIL versión 4, revisa la siguiente imagen:
Dimensiones de la gestión del servicio. Traducido de la imagen original propiedad de Beyond
20 (2019), solo para fines educativos.
Por su parte, ITIL V4 establece siete elementos o principios como guía principal, los
cuales se asume que deben existir en un carácter universal y duradero (Paradigma, 2019),
aplicando en cualquier escenario de negocio: 

 Enfoque en el valor
 Iniciar con lo disponible
 Progreso iterativo con retroalimentación (feedback)
 Colaborar y promover transparencia
 Pensamiento y trabajo holístico
 Mantenerlo sencillo y práctico
 Optimizar y automatizar

Hasta ahora, ITIL había manejado el concepto de procesos para gestionar servicios de TI, sin
embargo, la versión 4 expande sus fronteras al incorporar no solo el aspecto técnico y de
proceso, sino el aspecto cultural, informacional y de gestión de datos, como parte de lograr
una visión holística en la manera de trabajar.
Este nuevo enfoque revoluciona al término de prácticas, incorporando en la nueva versión 34
prácticas de gestión que se ofrecen como un conjunto de recursos organizacionales para
trabajar o lograr alcanzar objetivos (Axelos, 2019).
En el corazón del sistema de valor del servicio (SVS), volviendo a la cadena de valor un
sistema flexible de recursos operativos, se sitúan las seis actividades principales ya
mencionadas. Observa la siguiente imagen para tener una visión más amplia:
Actividades principales del SVC. Traducido de la imagen original propiedad de Axelos (2019),
solo para fines educativos.
De acuerdo con el análisis expuesto por la organización Beyond 20, analiza las principales
diferencias entre las versiones 3 y 4 de ITIL en la siguiente tabla (Beyond 20, 2019):

ITIL Versión 3 ITIL Versión 4

34 prácticas, cada una puede incluir

36 procesos organizados en el ciclo
diversos procesos libremente
de vida de servicio
organizados en tres prácticas

Cadena de valor de servicio:

Ciclo de vida del servicio:
 Planear
 Estrategia de servicio
 Mejorar
 Diseño del servicio
 Involucrar
 Transición del servicio
 Diseño y transición
 Operación del servicio
 Obtención/construcción
 Mejora continua del servicio
 Entrega/soporte

4 dimensiones de la gestión del

4 P del diseño del servicio:
servicio:
 Personas
 Organizaciones y personas
 Procesos
 Tecnologías de información
 Productos
 Socios (partners) y proveedores
 Socios (partners)
 Procesos y flujos de valor

Sin duda, la innovación en la era digital es un factor importante en todos los ámbitos, tal es el
caso de las metodologías y procesos para la gestión de servicios en todos los tipos de
negocio. No solo ITIL ha respondido a las tendencias actuales del trabajo ágil, pues los demás
competidores en temas de proceso a su vez están evolucionando para adaptarse a esta
nueva necesidad. Por ahora, existe un gran reto en las empresas alineadas al ciclo de vida de
servicio de ITIL V3, el cambio de paradigma y la renuencia al cambio será un aliciente para
revolucionar y adaptarse a lo que exige la sociedad en el entorno digital.