Itil v3 4 - operacion

0. Introducción
1. Estrategia del servicio
2. Diseño del Servicio
3. Transición del Servicio
4. Operación del Servicio
5. Mejora Continua

La fase de Operación del Servicio es, sin duda, la más crítica entre todas. La percepción que los
clientes y usuarios tengan de la calidad de los servicios prestados depende en última instancia de
una correcta organización y coordinación de todos los agentes involucrados.
Todas las otras fases del Ciclo de Vida del Servicio tienen como objetivo último que los servicios
sean correctamente prestados aportando el valor y la utilidad requerida por el cliente con los niveles
de calidad acordados. Es evidente que de nada sirve una correcta estrategia, diseño y transición del
servicio si falla la “entrega”.
Los principales objetivos de la fase de Operación del Servicio incluyen:
Coordinar e implementar todos los procesos, actividades y funciones necesarias para la
prestación de los servicios acordados con los niveles de calidad aprobados.
Dar soporte a todos los usuarios del servicio.
Gestionar la infraestructura tecnológica necesaria para la prestación del servicio.

Los principales procesos asociados directamente a la Fase de Operación del Servicio son:
Gestión de Eventos: responsable de monitorizar todos los eventos que acontezcan en la
infraestructura TI con el objetivo de asegurar su correcto funcionamiento y ayudar a prever
incidencias futuras.
Gestión de Incidencias: responsable de registrar todas las incidencias que afecten a la calidad
del servicio y restaurarlo a los niveles acordados de calidad en el más breve plazo posible.
Petición de Servicios TI: responsable de gestionar las peticiones de usuarios y clientes que
habitualmente requieren pequeños cambios en la prestación del servicio.
Gestión de Problemas: responsable de analizar y ofrecer soluciones a aquellos incidentes que
por su frecuencia o impacto degradan la calidad del servicio
Gestión de Acceso a los Servicios TI: responsable de garantizar que sólo las personas con los
permisos adecuados pueda acceder a la información de carácter restringido

Gestión de Eventos
Gestión de Incidentes
Gestión de Peticiones
Gestión de Problemas
Gestión de accesos a los servicios TI

Una vez que el servicio está operando es necesario monitorizar todos los sucesos importantes que
se produzcan para poder anticiparse a los problemas, resolverlos o incluso prevenirlos. Esta función
representa una tarea en sí misma y por tanto constituye un proceso independiente dentro del ciclo
de vida: la Gestión de Eventos.
A efectos de la operación del servicio, se denomina evento a todo suceso detectable que tiene
importancia para la estructura de la organización TI, para la prestación de un servicio o para la
evaluación del mismo. Ejemplos típicos de eventos son las notificaciones creadas por los servicios,
los elementos de configuración o las herramientas de monitorización y control.
Un aspecto clave en la Gestión de Eventos es, como resulta evidente, una buena monitorización y
unos efectivos sistemas de control. Encontramos dos tipos:
Herramientas de monitorización activa. Se comprueban los CIs uno a uno para verificar su
estado y disponibilidad. Si detecta excepciones, la herramienta de monitorización genera una
alerta y la envía al equipo o mecanismo de control asignado.
Herramientas de monitorización pasiva. Detectan y correlacionan alertas operacionales
generadas por los propios CIs.

El principal objetivo de la Gestión de Eventos, en su función de monitorizar todos los sucesos
importantes, consiste en detectar y escalar condiciones de excepción para así contribuir a una
operación normal del servicio:
Proporcionando puntos de entrada para varios procesos de la fase de Operación (p. ej. Gestión
de Incidencias).
Posibilitando la comparación entre el rendimiento real del servicio con los estándares de diseño
y los SLAs.
Contribuyendo a la Mejora Continua del Servicio mediante informes de mejora

Las actividades de la Gestión de Eventos son
Aparición de eventos. El proceso se inicia cuando ocurre el suceso, ya sea detectado o no.
Notificación de eventos. El evento es notificado al equipo o responsable de gestión.
Detección y filtrado de eventos. La notificación llega a un agente o herramienta de gestión que
la lee e interpreta el suceso con el fin de determinar si merece mayor atención o no.
Clasificación de eventos. Se le asigna una categoría y un nivel de prioridad.
Correlación. Se analiza si existen eventos similares, así como la importancia del evento en sí
mismo y se decide si es necesario tomar medidas.
Disparadores. Se ponen en marcha los mecanismos necesarios para dar respuesta al evento.
Opciones de respuesta. Se eligen las soluciones a adoptar.
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

El flujo de trabajo del proceso de Gestión de Eventos se inicia cuando aparece un evento. Los
eventos ocurren continuamente, pero no todos son detectados o registrados.
Por ello, es importante que todos los implicados en el diseño, desarrollo, gestión y soporte de los
servicios IT y la infraestructura IT comprendan cuáles son los eventos que es preciso detectar.

La mayoría de los elementos de configuración (CIs) son diseñados para comunicar información
sobre sí mismos de las siguientes formas:
• Una herramienta de gestión demanda periódicamente determinados datos a un dispositivo del
CI.
• El propio CI genera un informe al darse unas determinadas condiciones definidas previamente.
Las notificaciones de eventos pueden estar registradas en un formato propietario, aunque la
mayoría de los CIs emplean el estándar SNMP (Simple Network Management Protocol).
En general, cuanta más información acerca del evento quede recogida en la notificación, y cuanto
mejor se determine el destinatario de dicha información, más fácil resultará tomar decisiones
respecto al mismo. A menudo, se registran mensajes de error codificados y el personal encargado
de resolver los problemas no alcanza a comprender su significado completo.
Si los roles y responsabilidades no han sido bien definidos desde la fase de Diseño, es muy
probable que cuando se presente un evento que requiera una respuesta, nadie sepa quién está
haciendo qué. En tal caso, hay que redactar una RFC.

Una vez generada la notificación, ésta llega a su destinatario, que puede ser un agente que trabaje
sobre el sistema o bien una herramienta de gestión diseñada específicamente para recibir los datos
relacionados con el evento e interpretarlos.
El filtrado consiste en decidir si el suceso merece una consideración en profundidad por parte de
otra unidad de gestión o si por el contrario, una vez leído puede ser ignorado. Por ejemplo, cuando
se trata de un grupo de notificaciones relacionadas que se emiten de forma seriada, es habitual
optar por transmitir sólo la primera.
En otros CIs, en cambio, todos los eventos son significativos y se trasladan directamente a un
sistema de correlación automatizado, incluso aunque la notificación esté duplicada.

No todos los eventos son iguales ya que no tienen la misma importancia para el servicio ni la
infraestructura TI y por tanto, no deben tratarse de la misma manera.
La mejor manera de asignar distintas prioridades a cada evento, pero que al mismo tiempo guarden
cierta coherencia, es confeccionar una clasificación de eventos. Lo más habitual es que cada
organización TI disponga de su propia categorización, ya que es lo más eficaz. Sin embargo, existen
tres categorías que no pueden faltar:
Informativo. Se asigna a aquellos eventos que no requieren, en principio, ninguna respuesta y
que por tanto no representan una excepción.
Alerta. Se asigna a aquellos eventos que indican que el servicio se aproxima a un umbral. Su
objetivo es notificar a las personas, herramientas o procesos apropiados para que revisen la
situación y tomen las medidas necesarias para evitar que se produzca una excepción.
Excepción. Se asigna a los eventos cuando indican que el servicio está operando de manera
irregular: los SLAs y OLAs se han incumplido, etc. Las excepciones pueden representar un fallo
total, un cese en una funcionalidad o una disminución del rendimiento. Sin embargo, no tienen
por qué ser errores.

La Correlación consiste en dimensionar la importancia del evento y, si se diera el caso, establecer
conexiones con otros eventos relacionados para ahorrar tiempo. La importancia y significado del
evento en sí mismo depende de los siguientes factores:
Número de eventos similares registrados con anterioridad.
Número de elementos de configuración (CIs) que generan eventos similares.
Si existe alguna acción asociada al evento.
Si el evento representa una excepción.
Comparación de la cantidad de información utilizada en el evento respecto a un estándar.
Si se requieren datos adicionales para investigar el evento con posterioridad o incluso datos
procedentes de otros sistemas de información.
Categorización asignada al evento.
Nivel de prioridad asignado al evento.

Una vez que la Correlación ha reconocido la importancia de un evento, es preciso poner en marcha
los mecanismos pertinentes para que se produzca una respuesta desde dentro de la organización
TI. A este mecanismo, que sirve como desencadenante de una tarea o serie de tareas, lo
denominamos “disparador”.
Existen varios tipos de disparadores:
Disparadores de Incidentes. Crean un registro en el Sistema de Gestión de Incidencias,
generando un input para este proceso de la fase de Operación.
Disparadores de Cambios. Generan una solicitud de cambio (RFC) y enviándola a la Gestión de
Cambios, en la fase de Transición.
Disparadores procedentes de una RFC aprobada o desautorizada. Se envía toda la información
relacionada para que la Gestión de Cambios investigue lo ocurrido.
Scripts automatizados que ejecutan acciones específicas (p. ej. reiniciar un equipo).
Notificaciones por teléfono móvil.
Disparadores de base de datos, que restringen el acceso de un usuario a determinados
registros o campos, o que crean/eliminan entradas en la base de datos

Existen numerosas respuestas posibles a la hora de actuar frente a un evento. Entre las más
comunes están:
Registro de eventos. Independientemente de las acciones que se lleven a cabo, se documenta
lo ocurrido.
Respuesta automática. En algunos casos, se pueden programar respuestas automáticas a
determinados eventos que la organización TI conoce en profundidad. Por ejemplo: reiniciar un
dispositivo, cambiar un parámetro, bloquear una aplicación para evitar accesos no autorizados,
etc.
Alerta e intervención humana. La alerta tiene como objeto advertir e informar a la persona más
cualificada para que desempeñe una acción específica, probablemente en un tiempo
determinado y en un dispositivo concreto.
Emisión de una solicitud de cambio (RFC). Las solicitudes de cambio pueden crearse en cuanto
ocurre la excepción o en el momento en que la actividad de Correlación concluye que es
necesario hacer cambios.
Apertura de un registro de incidencia. Al igual que con la RFC, el registro de incidencias puede
efectuarse en cuanto se detecta la excepción o cuando la Correlación lo considera necesario.
Apertura de un vínculo a un registro de problema. Los problemas suelen estar asociados a uno
o más incidentes. Esto ayuda al equipo encargado de la Gestión de Problemas para determinar
el impacto y la severidad del problema.

Antes de dar por terminado el proceso de Gestión de Eventos, es preciso revisar todas las
excepciones o eventos importantes para garantizar que se han tratado correctamente

A la hora de evaluar la eficiencia y efectividad del proceso de Gestión de Eventos deben verificarse
los siguientes indicadores:
Número de eventos, por categorías.
Número de eventos, por importancia.
Número y porcentaje de eventos que requirieron de intervención humana y cómo fue esa
intervención.
Número y porcentaje de eventos que desembocaron en el registro de una nueva incidencia o
solicitud de cambio.
Número y porcentaje de eventos ocasionados por problemas ya existentes o errores conocidos.
Número y porcentaje de eventos repetidos o duplicados. Esto es relevante para optimizar la
función de Correlación.
Número y porcentaje de eventos relacionados con problemas de rendimiento.
Número y porcentaje de eventos que indican futuros problemas de disponibilidad.
Número y porcentaje de cada tipo de evento, por plataforma o aplicación.
Número y ratio de eventos por comparación al número de incidentes.

La Gestión de Incidencias tiene como objetivo resolver, de la manera más rápida y eficaz posible,
cualquier incidente que cause una interrupción en el servicio.
La Gestión de Incidencias no debe confundirse con la Gestión de Problemas, pues a diferencia de
esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado
incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte
interrelación entre ambas.
Por otro lado, también es importante diferenciar la Gestión de Incidencias de la Gestión de
Peticiones, que se ocupa de las diversas solicitudes que los usuarios plantean para mejorar el
servicio, no cuando éste falla.

Los objetivos principales de la Gestión de Incidencias son:
Detectar cualquier alteración en los servicios TI.
Registrar y clasificar estas alteraciones.
Asignar el personal encargado de restaurar el servicio según se define en el SLA
correspondiente.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios
debe jugar un papel esencial en el mismo.
Según el libro de Soporte del Servicio de ITIL una incidencia es:
“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”.
El siguiente diagrama resume el proceso de Gestión de Incidencias:

Clasificación y Registro
Es frecuente que existan múltiples incidencias concurrentes, por lo que es necesario determinar un
nivel de prioridad para la resolución de las mismas

Escalado y Soporte
Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un
incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones
que se escapan de su responsabilidad. A este proceso se le denomina escalado.

• Registro y clasificación
• Análisis, resolución y cierre.

Registro : La admisión y registro de la incidencia es el primer y necesario paso para una correcta
gestión del mismo.
Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones,
el mismo Centro de Servicios o el soporte técnico, entre otros.
El proceso de registro debe realizarse inmediatamente, pues resulta mucho más costoso hacerlo
posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore
indefinidamente el proceso.
Clasificación :La clasificación de un incidente tiene como objetivo principal el recopilar toda la
información que pueda ser utilizada para la resolución del mismo.
El proceso de clasificación debe implementar, al menos, los siguientes pasos:
Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles)
dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se
identifican los servicios afectados por el incidente.
Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina,
según criterios preestablecidos, un nivel de prioridad.
Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera
instancia, designará al personal de soporte técnico responsable de su resolución (segundo
nivel).
Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente
(por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de
resolución del incidente en base al SLA correspondiente y la prioridad.

En primera instancia, se examina el incidente con ayuda de la KB para determinar si se puede
identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado.
Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste
redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos
expertos no son capaces de resolver el incidente, se seguirán los protocolos de escalado
predeterminados.
Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las
correspondientes bases de datos para que los agentes implicados dispongan de cumplida
información sobre el estado del mismo.
Si fuera necesario, paralelamente a la resolución de la incidencia se puede emitir una Petición de
Cambio (RFC) que se enviaría a la Gestión de Peticiones. Por otro lado, si la incidencia fuera
recurrente y no se encontrase una solución definitiva, se deberá informar a la Gestión de Problemas
para el estudio detallado de las causas subyacentes.
Cuando se haya solucionado el incidente se:
Confirma con los usuarios la solución satisfactoria del mismo.
Incorpora el proceso de resolución al SKMS.
Reclasifica el incidente si fuera necesario.
Actualiza la información en la CMDB sobre los elementos de configuración (CIs) implicados en
el incidente.
Cierra el incidente.

Para el correcto seguimiento de todo el proceso, es indispensable la utilización de métricas que
permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los
aspectos clave a considerar son:
Número de incidentes clasificados temporalmente y por prioridades.
Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
Nivel de cumplimiento del SLA.
Costes asociados.
Uso de los recursos disponibles en el Centro de Servicios.
Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el
Centro de Servicios.
Grado de satisfacción del cliente.

La Gestión de Peticiones, como su nombre indica, es la encargada de atender las peticiones de
los usuarios proporcionándoles información y acceso rápido a los servicios estándar de la
organización TI.
La Gestión de Peticiones recibe las siguientes entradas para poder iniciar su labor:
Peticiones de servicio, planteadas por los usuarios.
RFCs, también de la misma fuente.
Descripción detallada del servicio, proporcionada por el Portfolio de Servicios.
Políticas de Seguridad, de la Gestión de Seguridad.

Los objetivos de la Gestión de Peticiones incluyen:
Proporcionar un canal de comunicación a través del cual los usuarios puedan solicitar y recibir
servicios estándar para los que existe una aprobación previa.
Proporcionar información a los usuarios y clientes sobre la disponibilidad de los servicios y el
procedimiento para obtenerlos.
Localizar y distribuir los componentes de servicios estándar solicitados.
Ayudar a resolver quejas o comentarios ofreciendo información general.
Las dificultades y desafíos a los que se puede enfrentar la Gestión de Peticiones son:
A la hora de documentar y definir claramente el tipo de peticiones que van a ser gestionadas.
Al establecer funcionalidades de autoayuda para que los usuarios interactúen mejor con el
proceso de envío de peticiones.
Si el alcance del proceso de Gestión de Peticiones no está bien definido, las personas
implicadas no tendrán una idea clara sobre cómo se desarrollará.
Si las interfaces de envío de peticiones tienen un diseño pobre o la implementación no es
correcta, resultará muy complicado a los usuarios remitir sus sugerencias, quejas, etc.
Si las aplicaciones de gestión interna no son adecuadas, la Gestión de Peticiones puede ver
disminuida considerablemente su capacidad para asumir gran cantidad de trabajo.
Una monitorización insuficiente o ineficaz.

Las actividades incluidas en el proceso de Gestión de Peticiones son:
Selección de peticiones. Los usuarios, a través de las herramientas destinadas a tal fin por la
Gestión de Peticiones, emiten sus peticiones conforme a una serie de tipologías predefinidas.
Aprobación financiera de la petición. Dado que la mayoría de peticiones tienen implicaciones
financieras, se considera su coste y se decide si tramitar la petición o no.
Tramitación. La petición es cursada por la persona o personas adecuadas según cada caso.
Cierre. Tras notificar al Centro de Servicios y comprobar desde aquél que el usuario ha quedado
conforme con la gestión se procede a cerrarla.

La Gestión de Peticiones hace posible que los propios usuarios emitan sus peticiones de servicio a
través de una interfaz web. En ella, el cliente podrá escoger de entre las “peticiones tipo”
predefinidas la que más se ajusta a su caso.
Esto se puede combinar con otras herramientas destinadas a enviar la petición directamente al
equipo de back-end.

La mayoría de las peticiones conllevan un gasto, independientemente de los acuerdos financieros
en vigor. Por eso, antes de autorizar una petición es principal determinar primero los costes que ésta
acarreará de ser cursada.
Se pueden definir, para determinadas peticiones estándares, unos precios fijos que ayuden a
gestionar con rapidez aquellos casos más frecuentes.

Esta actividad consiste en cursar la propia petición, por lo que las acciones a desempeñar
dependerán de la naturaleza de la misma.
El Centro de Servicios puede encargarse de las más simples, mientras que otras precisarán de una
intervención especializada. Algunas organizaciones disponen de grupos de expertos para cursar
cada tipo de petición, o incluso derivan ciertas actividades a proveedores externos.
El Centro de Servicios, independientemente de si la unidad que tramita la petición es interna o
externa, debe monitorizar todo el proceso y perseguir nuevos progresos.
Una vez resuelta la petición, se notifica al Centro de Servicios para que compruebe si el usuario está
satisfecho con el resultado y proceda a su cierre.

Número total de peticiones de servicio.
Ruptura de peticiones de servicio en cada etapa.
Tamaño de la copia de seguridad de las peticiones más destacadas.
Tiempo medio que dura la gestión de cada tipo de petición de servicio.
Número y porcentaje de peticiones de servicio completadas en los tiempos acordados.
Coste medio de cada tipo de petición de servicio.
Nivel de satisfacción del cliente con la gestión de las peticiones de servicio.

Las funciones principales de la Gestión de Problemas son:
Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.
Determinar posibles soluciones a las mismas.
Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.
Realizar Revisiones Post-Implementación (PIR) para asegurar que los cambios han surtido los
efectos buscados sin crear problemas de carácter secundario.
La Gestión de Problemas puede ser:
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los
mismos.
Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el
objetivo de prevenir incidentes incluso antes de que éstos ocurran.

Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la
infraestructura TI, es la función de la Gestión de Problemas el determinar sus causas y encontrar
posibles soluciones.
Cabe diferenciar entre:
Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente
aislado de importancia significativa.
Error conocido: Un problema se transforma en un error conocido cuando se han determinado
sus causas.
Entre las funciones principales de la Gestión de Problemas figuran:
Identificar, registrar y clasificar los problemas.
Dar soporte a la Gestión de Incidencias, proporcionando información y soluciones temporales o
parches.
Analizar y determinar las causas de los problemas y proponer soluciones.
Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la
infraestructura TI.
Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto
funcionamiento.
Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que
también sirvan de soporte a la estructura TI en su conjunto.
Analizar tendencias para prevenir incidentes potenciales

Las principales actividades de la Gestión de Problemas son:
Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus
causas y convertirlos en errores conocidos.
Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante
RFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post
Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.
Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas
Proactiva que ayude a detectar problemas incluso antes de que éstos se manifiesten provocando
un deterioro en la calidad del servicio.

El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores
Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.
El Control de Problemas se compone en esencia de tres fases:
1. Identificación y Registro
2. Clasificación y asignación de recursos
3.- Analisis y Diagnostico : Error Conocido

Una vez que el Control de Problemas ha determinado las causas de un problema, es
responsabilidad del Control de Errores el registro del mismo como error conocido.

El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la
infraestructura TI, y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de
los procesos relacionados y evaluar su rendimiento.
En particular, una buena gestión de problemas debe traducirse en una:
Disminución del número de incidentes y una más rápida resolución de los mismos.
Mayor eficacia en la resolución de problemas.
Gestión proactiva, que permita identificar problemas potenciales antes de que éstos se
manifiesten o provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y
aporta información de vital importancia a otras áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:
Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de
errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el
impacto en la Gestión de Incidencias
Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la
prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación
de las estructuras TI a las necesidades de la empresa.
Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del
servicio de los productos y servicios contratados y que eventualmente pueda permitir adoptar
decisiones informadas sobre cambios de proveedores, etc.
x

La Gestión de Acceso a los Servicios TI es el proceso por el cual a un usuario se le brindan los
permisos necesarios para hacer uso de los servicios documentados en el Catálogo de Servicios de
la organización TI. En ocasiones recibe el nombre de Gestión de Derechos o Gestión de
identidades.
La Gestión de Acceso a los Servicios TI se relaciona con algunos procesos de la fase de Diseño:
• La Gestión de la Seguridad establece las políticas de seguridad que luego la Gestión de Acceso
debe tener en cuenta a la hora de otorgar el acceso a los servicios TI.
• El Catálogo del Servicio aporta la documentación sobre los servicios cuyo acceso solicitan los
usuarios.
También se relaciona con otros procesos de la fase de Operación, como es el caso de la Gestión de
Peticiones o el Centro de Servicios, procesos desde los cuales pueden llegar solicitudes de acceso
a servicios.
Asimismo, proporciona información de salida para:
• Gestión de Incidencias, que se hará cargo de aquellas peticiones de acceso o actividades
relacionadas con los accesos que representen una excepción.
• Gestión Técnica y Gestión de Aplicaciones, que deben monitorizar los accesos y comprobar si
son autorizados o no.

El objetivo de la Gestión de Acceso a los Servicios TI es otorgar permisos de acceso a los
servicios a aquellos usuarios autorizados e impedírselo a los usuarios no autorizados.
En una palabra, es la puesta en práctica de las políticas y acciones definidas en la Gestión de la
Seguridad y la Gestión de la Disponibilidad.
La Gestión de Acceso a los Servicios TI proporciona una serie de ventajas a la organización TI que
justifican su implantación:
Mayor garantía de confidencialidad de la información, gracias a un acceso controlado a los
servicios.
Mayor efectividad de los empleados, al minimizarse los conflictos y problemas derivados de la
asignación de permisos.
Menor probabilidad de errores en servicios críticos relacionados con la actividad de usuarios no
cualificados.
Capacidad de monitorizar el uso de los servicios y detectar casos de abuso de los mismos.
Mayor rapidez y eficacia al revocar permisos en caso de ser necesario, algo que puede ser
crítico para la seguridad en determinadas circunstancias.
La Gestión de Acceso puede, además, ser un requisito indispensable para la adecuación a
determinados estándares de calidad e incluso, a la legislación vigente (en el sector sanitario,
por ejemplo).

Las actividades de la Gestión de Acceso a los Servicios TI incluyen:
Petición de acceso, que puede llegar por distintas vías como el departamento de RRHH, una
solicitud de cambio, una instrucción autorizada…
Verificación. Se comprueba la identidad del usuario que solicita el acceso, así como de aquellos
que lo autorizan. También se examina si los motivos para otorgar el acceso son pertinentes.
Monitorización de identidad. Los cambios en la asignación de permisos suelen estar asociados
a un cambio de estatus dentro de la organización: ascensos, despidos, jubilaciones…
Registro y monitorización de accesos. La Gestión de Accesos es responsable de asegurar que
los permisos que ha otorgado se están usando apropiadamente.
Eliminación y restricción de derechos. En algunos casos, los derechos pueden ser eliminados
por completo: fallecimiento, dimisión, despido, traslados

La petición de acceso puede llegar a través de numerosas vías:
Una petición estándar generada por el sistema de Recursos Humanos. Por ejemplo, al contratar
a una persona, al ascenderla, transferirla o cuando abandonan la empresa.
Una solicitud de cambio (RFC).
Una petición de servicio enviada por la Gestión de Peticiones.
Al ejecutar una tarea automática previamente autorizada.
Las reglas para establecer las peticiones de acceso normalmente están documentadas en el
Catálogo de Servicios.

La Gestión de Acceso debe verificar cada petición desde dos perspectivas:
El usuario que solicita el acceso, ¿es realmente quien dice ser?
¿Tiene un motivo válido para usar el servicio?
El primer punto se comprueba, habitualmente, comprobando el nombre y la clave del usuario. En la
mayor parte de organizaciones, estos datos bastan para acreditar al usuario, aunque depende de
las políticas de seguridad y de lo sensible que sea la información registrada en el sistema del
servicio (p.ej. datos biométricos).
El segundo punto requiere una comprobación paralela e independiente de la que aporta el usuario.
En caso de que se trate de un nuevo empleado, por ejemplo, será necesaria una notificación por
escrito procedente del departamento de Recursos Humanos.

A medida que los usuarios trabajan en la organización, sus roles van cambiando y, con ellos, sus
necesidades de acceso a servicios. Algunos ejemplos de cambios incluyen:
Cambio de tarea. En este caso, es muy posible el usuario necesite acceso a nuevos servicios,
o incluso a otros completamente diferentes.
Ascensos. Lo más probable es que el usuario requiera niveles de permisos superiores en los
mismos servicios a los que ya tenía acceso.
Dimisión o fallecimiento. Es preciso eliminar por completo el acceso para evitar que la cuenta
de usuario se convierta en un agujero de seguridad.
Jubilación. En muchas organizaciones, los empleados ya retirados todavía conservan el
privilegio de acceder a ciertos servicios, como por ejemplo descuentos en sus compras en
determinadas plataformas de e-commerce.
Acción disciplinar. En algunos casos, es posible que la organización necesite restringir el
acceso durante un tiempo para evitar que el usuario acceda a determinados servicios. Esta
circunstancia debería estar prevista en el sistema de asignación de permisos, evitando así tener
que eliminar los derechos y luego crearlos de nuevo.
Despido. Cuando un empleado es despedido, o cuando se emprenden acciones legales contra
un cliente, el acceso debe ser revocado inmediatamente. Además, la Gestión de Accesos, en
conjunto con la Gestión de Seguridad, debe tomar medidas para prevenir, detectar y evitar
ataques contra la organización procedentes de ese usuario.
La Gestión de Accesos debe comprender en profundidad el ciclo de vida de cada tipo de usuario y
documentarlo. Esto puede servir para automatizar el proceso y ahorrar tiempo.

Además de responder a las peticiones, la Gestión de Acceso es responsable de asegurar que
los permisos que ha otorgado se están usando apropiadamente. Por este motivo es necesario
que la monitorización y control de los accesos esté incluida entre las actividades de las
funciones de la Gestión Técnica y Gestión de Aplicaciones y en todos los otros procesos de
operación de servicio.
En caso de detectarse abusos, habrá que documentar la situación como una excepción y
enviarla a la Gestión de Incidencias para que proceda a su resolución.
La Gestión de la Seguridad de la Información juega un papel fundamental a la hora de detectar
accesos no autorizados y en compararlos con los permisos que se habían asignado desde la
Gestión de Accesos.
Si se sospecha que un usuario está vulnerando las normas de acceso, haciendo un uso
inapropiado de los recursos o utilizando datos de forma fraudulenta, corresponderá la Gestión
de Accesos proporcionar evidencias de los datos, tiempos e incluso contenido al que el usuario
tiene acceso en determinados servicios.

Naturalmente, la Gestión de Acceso no sólo se encarga de otorgar permisos, sino también de
revocarlos o limitarlos.
Las circunstancias que suelen motivar la eliminación de derechos:
Fallecimiento.
Dimisión.
Despido.
Cambio de roles dentro de la organización, por lo que ya no se necesita acceder al servicio
Traslado del usuario a otra área donde existe un acceso regional distinto.

La eficacia del proceso de Gestión de Acceso a los Servicios TI puede controlarse mediante los
siguientes indicadores:
Número de peticiones de acceso.
Instancias de acceso garantizado, por servicio, usuario, departamento, etc.
Instancias de acceso garantizado por derechos de acceso de departamento o individuo.
Número de incidentes que requirieron la revocación de los permisos de acceso.
Número de incidentes causados por una configuración incorrecta de los accesos.

Una función es una unidad especializada en la realización de una cierta actividad y es la
responsable de su resultado. Las funciones incorporan todos los recursos y capacidades necesarias
para el correcto desarrollo de dicha actividad.
Las funciones involucradas en la fase de Operación del servicio son las responsables de que
los servicios cumplan los objetivos solicitados por los clientes y de gestionar toda la tecnología
necesaria para la prestación de dichos servicios:
Centro de Servicios: responsable de todo los procesos de interacción con los usuarios de los
servicios TI.
Gestión de Operaciones TI: responsable de la operación diaria del servicio.
Gestión Técnica: es una unidad funcional que incluye a todos los equipos, grupos y
departamentos involucrados en la gestión y soporte de la infraestructura TI.
Gestión de Aplicaciones: esta unidad funcional es la responsable de la gestión del ciclo de vida
de la aplicaciones TI

Centro de Servicios
Gestión de Operaciones TI
Gestión Técnica
Gestión de Aplicaciones

El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto
entre los usuarios y la Gestión de Servicios TI.
Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de
todos los procesos de soporte al servicio:
• Registrando y monitorizando incidentes.
• Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de
Problemas.
• Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de
datos correspondientes.
• Gestionando cambios solicitados por los clientes mediante peticiones de servicio en
colaboración con la Gestión de Cambios y de Entregas y Despliegues.
Pero también debe jugar un papel importante dando soporte al negocio, identificando nuevas
oportunidades en sus contactos con usuarios y clientes.

El punto de contacto con el cliente puede tomar diversas formas, dependiendo de la amplitud y
profundidad de los servicios ofrecidos:
Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios,
excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.
Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte
técnico que permita resolver en el menor tiempo las interrupciones del servicio.
Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los
servicios TI ofrecidos por la organización, con un enfoque centrado en los procesos de negocio.
Aparte de ofrecer los servicios citados anteriormente, ofrece servicios adicionales a clientes,
usuarios y la propia organización TI tales como:
Supervisión de los contratos de mantenimiento y niveles de servicio.
Canalización de las Peticiones de Servicio de los clientes.
Gestión de las licencias de software.
Centralización de todos los procesos asociados a la Gestión TI.

La implementación de un Centro de Servicios requiere una meticulosa planificación. En primera
instancia deben establecerse los siguientes puntos:
Cuáles son las necesidades.
Cuáles han de ser sus funciones.
Quiénes serán los responsables del mismo.
Qué cualificaciones profesionales poseerán sus integrantes.
Si se deben externalizar ciertos servicios como, por ejemplo, el soporte técnico del hardware.
Qué estructura de Centro de Servicios (distribuido, central o virtual) se adapta mejor a nuestras
necesidades y las de nuestros clientes.
Qué herramientas tecnológicas necesitamos.
Qué métricas determinarán el rendimiento del Centro de Servicios.

Como ya se ha comentado anteriormente, el Centro de Servicios es "EL" punto de contacto de
toda la organización TI con clientes y usuarios. Es por lo tanto imprescindible que:
Sea fácilmente accesible.
Ofrezca un servicio de calidad consistente y homogéneo.
Mantenga puntualmente informados a los usuarios y lleve un registro de toda la interacción con
los mismos.
Sirva de soporte al negocio.
Para cumplir estos objetivos es necesario implementar la adecuada estructura física y lógica.

Estructura lógica
Los integrantes del Centro de Servicios deben:
Conocer todos los protocolos de interacción con el cliente: guiones, checklists…
Disponer de herramientas de software que les permitan llevar un registro de la interacción con los
usuarios.
Saber cuándo se debe realizar un escalado a instancias superiores o entrar en discusiones sobre
cumplimiento de SLAs.
Tener rápido acceso a las bases de conocimiento para ofrecer un mejor servicio a los usuarios.
Recibir formación sobre los productos y servicios de la empresa.
Estructura física
• A la hora de elegir la estructura del Centro de Servicios deben tenerse muy presentes las
necesidades del servicio: locales, globales, 24/7, etc.
• De acuerdo a estos factores, existen distintas opciones que el Centro de Servicios puede
adoptar:
Local
Centralizado
Virtual
24/7
Especializado
• En la práctica, cada organización configurará su Centro de Servicios de acuerdo a sus
circunstancias y necesidades particulares. A continuación, profundizaremos en las opciones
enumeradas anteriormente

Centro de Servicios 24/7
Este modelo, también conocido como follow the sun, consiste en ubicar una serie de Centros de
Servicios Locales en distintas zonas horarias con el fin de cubrir de forma conjunta las 24 horas del
día durante los 7 días de la semana. Esta configuración es adoptada principalmente por
organizaciones internacionales.
Centros de Servicios Especializados
En ciertas organizaciones en las que los Servicios IT son muy específicos, los incidentes
relacionados con éstos se derivan a grupos especializados mejor capacitados para resolverlos.
Virtual

Las actividades del Centro de Servicios pueden abarcar de una manera u otra casi todos los
aspectos de la Gestión de Servicios TI. Sin embargo, no cabe duda de que su función principal
consiste en gestionar la relación con los clientes y usuarios, manteniéndoles puntualmente
informados de todos aquellos procesos de su interés.
A continuación, describimos algunas de las actividades que un Centro de Servicios debería ofrecer
para merecer ese nombre:
 Gestión de Incidentes
 Centro de Información
 Relación con Proveedores

La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente, aunque ésta,
obviamente, no sea responsabilidad exclusiva de éste.
Es importante que se intenten establecer métricas bien definidas para medir el rendimiento del
Centro de Servicios y la apreciación que los usuarios tienen de éste.
En los informes de control se deben considerar aspectos tales como:
Tiempo medio de respuesta a solicitudes cursadas por correo electrónico y teléfono o fax.
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.
Cumplimiento de los SLAs.
Número de llamadas gestionadas por cada miembro del personal del Centro de Servicios.
Otra importante tarea de control es supervisar el grado de satisfacción del cliente. Esto se puede
conseguir mediante el uso de encuestas que permitan evaluar la percepción del cliente respecto a
los servicios prestados.

La Gestión de Operaciones es la unidad responsable del mantenimiento y la gestión continua de la
infraestructura de la organización TI, y se centra especialmente en asegurar que los servicios
cumplen los niveles acordados.
En otras palabras, podríamos decir que la Gestión de Operaciones engloba 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.
A continuación, resumiremos algunos aspectos clave de la Gestión de Operaciones:
Trabaja para asegurar que un dispositivo, sistema o proceso está funcionando.
Lleva a cabo los planes.
Está enfocada a las actividades a corto plazo, aunque éstas generalmente se repiten durante
un largo periodo de tiempo.
El equipo que ejecuta estas actividades ha de estar muy especializado, por lo que a menudo
requiere de una formación específica.
Hay una tendencia a establecer acciones repetitivas y fiables para asegurar el éxito de la
operación del servicio.
Es en la Gestión de Operaciones es donde el valor real de la organización se mide y distribuye.
Depende directamente de las inversiones tanto en equipamiento como recursos humanos.
El valor generado debe superar el coste de la inversión y otros gastos indirectos.

Los objetivos de la Gestión de Operaciones TI consisten en:
Mantenimiento del status quo de los procesos y actividades de la organización para alcanzar
estabilidad en el día a día.
Escrutinio regular y mejoras para alcanzar un servicio mejorado con costes reducidos,
manteniendo la estabilidad.
Aplicación rápida de habilidades operacionales para diagnosticar y resolver cualquier fallo que
ocurra en las operaciones.

Esta labor se desarrolla de acuerdo a los estándares de rendimientos definidos durante la fase de
Diseño. Los requisitos generales para que la Gestión de Operaciones desempeñe correctamente su
trabajo son:
Comprender en profundidad cómo se emplea la tecnología para prestar servicios.
Comprender la importancia relativa y el impacto de esos servicios en el negocio.
Los procedimientos y manuales que delimitan los roles operacionales tanto en la gestión de la
tecnología como en la prestación de servicios.
Disponer de un conjunto de métricas claramente diferenciadas que informen sobre la
culminación de objetivos de servicio, y mantengan informados a los gestores TI sobre la
eficiencia y efectividad de las Operaciones TI.
Los equipos de operaciones TI deben comprender exactamente cómo afecta el rendimiento de
la tecnología a la prestación de servicios.
Una estrategia de gasto orientada a equilibrar los requisitos de las distintas unidades de
negocio con los ahorros disponibles gracias a la optimización de la tecnología existente o la
inversión en nueva tecnología.
Una estrategia de inversión basada en retorno del valor, más que retorno del gasto.

En algunas organizaciones, un solo departamento se ocupa de desarrollar las actividades de la
Gestión de Operaciones TI, mientras que en otros algunas actividades se centralizan y otras las
asumen otros departamentos especializados de la organización.
Las dos funciones de la Gestión de Operaciones, que trataremos en profundidad en el siguiente
apartado, suelen conformar estructuras organizacionales por sí mismas:
Control de Operaciones, cuya plantilla generalmente se organiza en turnos de operadores
encargados de asegurar que las tareas rutinarias se llevan a cabo. El Control de Operaciones
también desempeña tareas de monitorización y control, para lo que a menudo recurre a
unidades específicas como el Puente de Operaciones o un Centro de Operaciones en Red.
Gestión de Instalaciones, encargada de supervisar el mantenimiento de todo el equipamiento
físico. A menudo está ubicada junto a la Gestión Técnica y de Aplicaciones en grandes centros
de datos.

Las actividades de la Gestión de Operaciones TI están íntimamente ligadas con la monitorización y
supervisión, al ser ésta la responsable de que la infraestructura de la organización funcione,
especialmente en lo que se refiere a la prestación de servicios.
A continuación, describimos algunas de las actividades que desarrolla la Gestión de Operaciones TI
dentro de la organización:
Control de Operaciones
Gestion de Instalaciones

El rendimiento de la unidad puede monitorizarse mediante la comprobación periódica de los
siguientes indicadores:
Finalización con éxito de las tareas programadas.
Número de excepciones que se presentaron en las tareas y actividades programadas.
Número de restauraciones del sistema o de datos requeridas.
Estadísticas de instalación de equipo, incluyendo el número de elementos instalados por tipo,
instalaciones exitosas, etc.
Métricas del proceso. La Gestión de Operaciones TI ejecuta muchas actividades de otros
procesos de la gestión de servicios. Su capacidad para desempeñar este trabajo se cuantificará
como parte de las métricas de los otros procesos:
Tiempo de respuesta a eventos.
Tiempos de resolución de incidentes.
Número de incidentes relacionados con la seguridad.
Número de escalado de incidentes y razones.
Número de cambios implementados y retirados.
Número de cambios no autorizados que se detectaron.
Número de versiones desplegadas de forma total y exitosa.
Rastreo de SIPs.
Gasto por comparación al presupuesto.

La Gestión Técnica aporta las habilidades técnicas y los recursos necesarios para dar soporte a la
fase de Operación del servicio. La Gestión Técnica también toma parte en el diseño, pruebas,
despliegue y mejora de los servicios TI.
El papel de la Gestión Técnica es doble:
Es la responsable del conocimiento técnico y la experiencia relacionada con la gestión de la
infraestructura TI. Debe asegurarse de que el conocimiento requerido para diseñar, probar,
gestionar y mejorar los servicios TI es identificado, distribuido y perfeccionado.
Proporciona los recursos reales destinados a dar soporte al ciclo de vida. Así, la Gestión
Técnica debe encargarse no sólo de que esos recursos 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.
Para orientar su labor, la Gestión Técnica toma como base los requisitos definidos en la fase de
Estrategia del Servicio, desarrollados en el Diseño del Servicio, validados en la Transición y
perfeccionados en la Mejora Continua.

El objetivo principal de la Gestión Técnica consiste en ayudar en la planificación, implementación y
mantenimiento de una infraestructura técnica estable para apoyar los procesos de negocio de la
organización mediante:
Una topología técnica bien diseñada, elástica y económica.
Uso de habilidades técnicas adecuadas para mantener la infraestructura técnica en condiciones
óptimas.
Uso ágil de habilidades técnicas para una diagnosis rápida y resolución de cualquier error
técnico que pueda ocurrir.

La Gestión Técnica debe procurar que exista un equilibrio entre el nivel de habilidad, la utilización y
el coste de los recursos. Se trata de corregir situaciones como, por ejemplo, que se contrate un
recurso de alto nivel a un coste elevado y que después sólo se utilice un 10% de sus capacidades.
Algunas de las estrategias a emplear para equilibrar el gasto en recursos en Gestión Técnica son:
Identificar cuándo se necesitan determinadas habilidades de alto nivel
Contratar a terceros sólo en los momentos puntuales en que se necesitan sus habilidades.
Montar un equipo táctico que, además de sus tareas propias, desempeñe tareas que requieran
habilidades específicas.

La estructura de la Gestión Técnica depende de las dimensiones de la organización TI. Si ésta es
pequeña, a menudo se centralizan las actividades en un solo departamento, mientras que en las de
mayor tamaño se subdividen en varios departamentos especializados técnicamente. El criterio
principal es, por lo tanto, la especialialización: los trabajadores se agrupan de acuerdo a sus
habilidades técnicas, que a su vez dependen de la tecnología que hay que gestionar.ç
Algunos ejemplos de equipos o departamentos de Gestión Técnica:
Equipo/departamento central
Equipo/departamento de servidor
Equipo/departamento de almacenamiento de datos
Equipo/departamento de soporte de redes
Equipo/departamento de aplicaciones de escritorio
Equipo/departamento de base de datos
Equipo/departamento de software intermedio
Equipo/departamento del directorio de servicios
Equipo/departamento de web
Equipo/departamento de telefonía basada en IP

Identificar el conocimiento y experiencia necesarios para prestar servicios y gestionar la
infraestructura TI:
Diseñar y desarrollar (aunque no impartir) programas de formación relacionados con los
recursos técnicos.
La Gestión Técnica a menudo participa en la contratación
La Gestión Técnica también se encarga de definir estándares para
La Gestión Técnica interviene en el diseño
La Gestión Técnica, además, se ocupa de investigar y desarrollar soluciones que ayuden a
expandir los servicios, o que simplifiquen los que ya se prestan (reduciendo costes, p.ej.).

Métricas de los entregables acordados. Esto puede incluir:
Contribución a logros para el negocio
Porcentajes de transacción y disponibilidad en transacciones de negocio críticas
Formación del Centro de Servicios
Resolución de problemas de grabación en la KEDB
Mediciones de la calidad de los entregables
Instalación y configuración de componentes bajo su control
Mediciones de procesos. Los equipos de Gestión Técnica se ocupan de ejecutar numerosas
actividades de otros procesos de la gestión de servicios, como por ejemplo:
Tiempos de respuesta medios a eventos y porcentajes de completado de eventos.
Tiempos de resolución de incidentes en segunda y tercera líneas de soporte.
Estadísticas de resolución de problemas.
Número de incidentes escalados y razones para esos escalados.
Número de cambios implementados y retirados.
Número de cambios no autorizados detectados.
Rendimiento de la tecnología.
Tiempo promedio entre incidencias de determinado equipamiento.
Medición de las actividades de mantenimiento.
Formación y desarrollo de habilidades

La Gestión de Aplicaciones es responsable del soporte y mantenimiento de las aplicaciones que
toman parte en la Operación del servicio. Al igual que ocurría con la Gestión Técnica en relación a la
infraestructura TI, la Gestión de Aplicaciones también desempeña un doble papel:
Es la responsable del conocimiento técnico y la experiencia relacionada con las aplicaciones.
Debe asegurarse de que el conocimiento requerido para diseñar, probar, gestionar y mejorar los
servicios TI es identificado, distribuido y perfeccionado.
Proporciona los recursos reales destinados a dar soporte al ciclo de vida. Así, la Gestión de
Aplicaciones debe encargarse no sólo de que esos recursos 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.
La Gestión de Aplicaciones participa, además, en las siguientes actividades del ciclo de vida:
Diseño, prueba y mejora de las aplicaciones.
La decisión de desarrollar una aplicación o comprársela a un tercero.
Integrar la Gestión de Aplicaciones en el Ciclo de Vida.

La Gestión de Aplicaciones tiene como principal objetivo 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.
Para lograr este fin, se precisa:
Aplicaciones bien diseñadas, elásticas y que optimicen costes.
Garantizar que la funcionalidad requerida está disponible para alcanzar los resultados de
negocio deseados.
Organizar las habilidades técnicas adecuadas para mantener aplicaciones operacionales en
condiciones óptimas.
Uso ligero de habilidades técnicas para una diagnosis rápida y la resolución de cualquier fallo
técnico que pueda presentarse.
La Gestión de Aplicaciones se encarga de que exista un equilibrio entre el nivel de los recursos
y su coste.

Es habitual en las organizaciones TI dividir la Gestión de Aplicaciones en departamentos según el
catálogo de aplicaciones. Esto permite una mayor especialización y un soporte más centrado.
A pesar de que todos los equipos, departamentos o grupos de Gestión de Aplicaciones desempeñan
actividades similares, cada aplicación o conjunto de aplicaciones precisa un conjunto específico de
requisitos de gestión y operación, en función de:
El propósito de la aplicación. Los equipos deben tener en cuenta los objetivos de negocio.
La funcionalidad de la aplicación.
La plataforma en la que corre la aplicación.
El tipo/marca de tecnología empleada.

Los equipos y departamentos de Gestión de Aplicaciones suelen organizarse según las distintas
categorías de aplicaciones a las que dan soporte. Algunos ejemplos típicos son:
Aplicaciones financieras.
Aplicaciones de mensajería y colaboración.
Aplicaciones de RRHH
Aplicaciones de soporte industrial
Aplicaciones de automatización de fuerza de ventas (CRM)
Aplicaciones de procesamiento de ventas.
Aplicaciones del centro de llamadas y marketing
Aplicaciones específicas del negocio (sanidad, seguros, banca, etc.)
Aplicaciones TI, como Centro de Servicios, Sistemas de Gestión de la Empresa (SKMS, CMS),
etc.
Portales web.
Tienda online.

• Ayudar a la Gestión Técnica
• Diseñar y desarrollar (aunque no impartir) programas de formación destinados al usuario final.
• La Gestión de Aplicaciones también interviene en labores de contratación
• La Gestión de Aplicaciones también se encarga de definir estándares
• La Gestión de Aplicaciones interviene en el diseño
• Investigación y desarrollo de soluciones que ayuden a expandir el Portfolio de Servicios o al
menos a mejorar la prestación de los mismos.
• Proporcionar asesoramiento en riesgos, identificando servicios críticos y dependencias de
sistema y definiendo e implementando contramedidas.

Tiempo de respuesta a eventos y porcentajes de finalización.
Tiempos de resolución de incidentes en la segunda y tercera líneas de
soporte.
Estadísticas de resolución de problemas.
Número de incidencias escaladas y razones que motivaron su escalado.
Número de cambios implementados y revertidos.
Número de cambios no autorizados que se detectaron.
Número de versiones desplegadas (total y exitosas)
Problemas de seguridad detectados y resueltos
Utilización real del sistema comparada con las previsiones del Plan de
Capacidad.
Seguimiento de sesiones.
Gasto en comparación con el presupuesto

Uno de las principales dificultades para la correcta puesta en marcha de la fase de Operación del
Servicio reside en el “abismo” existente entre teoría y práctica.
Las fases previas del ciclo de vida de los servicios se han preocupado de diseñar, planificar y
desplegar una serie de procesos y servicios que ahora han de ponerse en marcha y es frecuente
eso conlleve las habituales dificultades:
Los responsables del diseño no conocen en detalle las complicaciones asociadas a las labores de
mantenimiento y tareas recurrentes de la fase de operación con las consiguientes consecuencias
indeseables:
Se toman “atajos” que rompen con las buenas prácticas de gestión.
Se crean resistencias a la aplicación de los protocolos diseñados.
No se han asignado los recursos necesarios para implementar correctamente la fase de operación y
el personal la percibe como una nueva capa “burocrática” que sólo dificulta su trabajo.
Las estructuras de gestión no son lo suficientemente flexibles y por tanto no son capaces de asimilar
la complejidad de los nuevos procesos y actividades.
Las métricas definidas se centran en exceso en aspectos “internos” de la organización TI y obvian
importantes aspectos “externos” relativos a la percepción de los clientes.

• El monitoreo consiste en la observación atenta de una determinada situación con el fin de
detectar cambios a lo largo del tiempo
Podemos distinguir distintos tipos de monitorización según tres factores:
• Monitorización activa vs. pasiva. La monitorización activa consiste en hacer una
comprobación directa del estado de un sistema o dispositivo. La pasiva, en cambio, genera y
transmite eventos a un agente de monitorización de forma automática. La pasiva es más
frecuente, reservándose la activa para la diagnosis.
• Monitorización reactiva vs. proactiva. La primera está diseñada para ejecutar acciones al
producirse cierto tipo de eventos o fallos. La monitorización proactiva, por otro lado, se utiliza
para detectar los patrones de eventos que predicen el fallo de un dispositivo.

Entre los factores de éxito y retos a los que se debe confrontar la correcta implementación de la
Fase de Operación del Servicio se encuentran:
Disponer de personal convenientemente formado sobre los procesos y actividades necesarias
para una correcta gestión del servicio.
Contar con el adecuado soporte tecnológico que facilite y automatice, cuando esto sea posible,
las actividades asociadas a la prestación y gestión del servicio.
Contar con el apoyo necesario de los órganos de dirección de la organización TI para disponer
de los recursos y capacidades necesarias.
Disponer de las métricas adecuadas para evaluar la calidad de la operación del servicio.
Generar los informes y documentación necesarios para la futura mejora del servicio.
Trabajar en estrecha colaboración con las unidades de negocio para conocer sus necesidades y
garantizar que estas son cubiertas.
Los principales riesgos se resumen en:
Diseños defectuosos del servicio que impiden una operación eficiente.
Recursos y capacidades insuficientes.
Falta de soporte de la organización TI.

Itil v3 4 - operacion

Más contenido relacionado

La actualidad más candente (20)

Similar a Itil v3 4 - operacion (20)

Más de S (9)

Último (20)

Itil v3 4 - operacion