Las prácticas de la gestión de servicios

 Introducción

Las prácticas de la gestión de servicios son diecisiete:

• Gestión de la disponibilidad
• Business analysis
• Gestión de la capacidad y del rendimiento
• Gestión de cambios
• Gestión de incidentes
• Gestión de problemas
• Gestión de los activos de servicios
• Supervisión y gestión de eventos
• Gestión de las entradas en producción (MEP)
• Gestión del catálogo de servicios
• Gestión de las configuraciones de servicios
• Gestión de la continuidad de servicios
• Diseño de los servicios
• Centro de servicios
• Gestión de niveles de servicios
• Gestión de las peticiones de servicios
• Validación y pruebas de los servicios

En cada uno de los párrafos siguientes, se mencionará el objetivo de la práctica, sus grandes principios, en la medida de lo posible lo que produce, las principales partes integrantes relativas y las actividades implicadas, a través del mapa de calor. Hay que recordar que todas estas prácticas están en proceso de definición detallada y se publicarán en los libros oficiales a lo largo del año 2020. También se mencionará el soporte de un proceso ya conocido en la versión V3 de ITIL y las modificaciones eventualmente aportadas.

Gestión de la disponibilidad

1. Objetivo de la práctica

Esta práctica se basa en el proceso Gestión de la disponibilidad, ya presente en las versiones V2 y V3 de ITIL.

La misión de la práctica Gestión de la disponibilidad es garantizar que los niveles de disponibilidad de los servicios contratados en los acuerdos de servicios, cumplan con los contratos, es decir, que se alcanzan o superan los niveles con los mejores costes. Estos niveles de servicio se deben corresponder con las expectativas de los clientes y de los usuarios.

Para realizar esta misión de disponibilidad de los servicios (servicios de principio a fin), la gestión se va a basar en la disponibilidad de los elementos que compongan este servicio.

2. Las actividades de la práctica

Las actividades de la práctica Gestión de la disponibilidad, son las siguientes:

• La elaboración del plan de mejora de la disponibilidad del servicio tomando en cuenta las necesidades actuales y las futuras.
• Aconsejar a las líneas de negocio para ayudarlas en la expresión de sus necesidades, en términos de disponibilidad.
• La oferta de las herramientas y de los medios para medir la disponibilidad.
• La reducción del número y duración de los incidentes y problemas relacionados con la disponibilidad.
• La supervisión, el análisis y la oferta de informes sobre la disponibilidad.
• La evaluación del impacto de los cambios.
• La optimización continua durante la vida de los servicios.

3. La terminología de la práctica

a. Disponibilidad de un componente o de un servicio

La disponibilidad, es la capacidad de un componente o de un servicio para cumplir las funciones solicitadas durante un periodo o momento determinado.

La gestión de la disponibilidad debe ser eficaz en los dos niveles siguientes:

• La disponibilidad de los servicios, es decir, la disponibilidad garantizada de principio a fin y según los objetivos del contrato de servicios. La disponibilidad de los servicios se basa en la disponibilidad de los componentes.
• La disponibilidad de los componentes: es la capacidad de los elementos de infraestructura de garantizar su función, conforme a los niveles de servicio convenidos.

La disponibilidad de los servicios es equivalente al nivel de disponibilidad del eslabón más débil de los elementos que lo componen. Por lo tanto, la eliminación de los SPOF (Single Points Of Failure en inglés) o de los componentes no fiables, contribuirá notablemente a la disponibilidad de los servicios.

b. Fiabilidad de un componente o de un servicio

La fiabilidad, es la aptitud de un componente o servicio para funcionar de manera perdurable sin desfallecimiento. En un sistema, la fiabilidad se mide respecto a la fiabilidad del eslabón más débil del sistema.

c. Mantenibilidad de un componente o de un servicio

Es la capacidad de volver a poner en el mercado un componente o un servicio que ha fallado. Con la noción de mantenibilidad, abordamos las nociones de solución de problemas y reparación, pero también la noción de repuestos (Spare parts en inglés).

d. Tasa de disponibilidad

La tasa de disponibilidad es el porcentaje de tiempo durante el que el componente o el servicio funciona correctamente (estado normal, ver el proceso de gestión de los niveles de servicio), en un periodo convenido.

La tasa de disponibilidad se calcula sobre los periodos donde el servicio está abierto.

Ejemplo 1: si un servicio está abierto desde las 08:00 hasta las 18:00, el cálculo de la tasa de disponibilidad en una jornada con un fallo de 1 hora, es de = 90%.

Ejemplo 2: si un servicio está abierto 24 horas al día, el cálculo de la tasa de disponibilidad en una jornada con un fallo de 1 hora, es de = 96%.

e. El tiempo medio de restablecimiento

Tiempo Medio de Restablecimiento (MTTR, Mean Time To Restore): el MTTR es el tiempo medio de solución de problemas, restablecimiento de un componente o servicio después de un fallo, en un periodo convenido. Esta noción es importante ya que complementa la noción anterior de tasa de disponibilidad. El MTTR va a permitir afinar la noción de disponibilidad del componente o del servicio.

f. El tiempo medio entre dos errores

Tiempo medio entre dos fallos (MTBF, Mean Time Between Failure): el MTBF es el tiempo medio entre dos fallos de un componente o servicio, en un periodo convenido.

4. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de la disponibilidad, es el siguiente:

Planificar: la gestión de la disponibilidad se debe presentar en la actividad de planificación y en particular, en las grandes elecciones tomadas por la Gestión de los porfolios.

Optimizar: la optimización y las decisiones de mejora se deben validar por la gestión de la disponibilidad, para estar seguros de que no impactan en la disponibilidad actual de los servicios.

Compromiso: la gestión de la disponibilidad da sus obligaciones para los cambios.

Diseñar y Transformar: todos los cambios deben tener en cuenta las obligaciones de la gestión de la disponibilidad.

Obtener y Construir: el nivel de disponibilidad solicitado debe estar presente para cada componente desarrollado internamente u obtenido de manera externa.

Suministrar y Dar soporte: la gestión de la disponibilidad vigila los componentes y servicios y reacciona si es necesario.

Business analysis

1. Objetivo de la práctica

Esta práctica es una de las prácticas nuevas definidas por ITIL 4.

Su misión es analizar las unidades de negocio de la empresa o los componentes de este negocio, para recomendar soluciones que van a aportar una creación de valor o una mejora del valor existente.

La creación de valor va a tener en cuenta dos aspectos que son la utilidad y la garantía. Como recordatorio:

• la utilidad representa las funcionalidades expresadas por los clientes y los usuarios,
• la garantía representa el uso que se hará por parte de los usuarios. Se va a expresa por medio de obligaciones no funcionales.

La práctica Business analysis va igualmente a participar en la elaboración de los criterios mínimos de validación para la puesta en servicio de los cambios, sobre el aspecto de la garantía.

2. Las tareas de la práctica

Las principales tareas de la práctica son las siguientes:

• El análisis de los procesos de negocio, los servicios existentes o la arquitectura.
• La identificación de las prioridades para la mejora.
• La proposición de acciones de mejora, incluso fuera del entorno informático.

3. El mapa de calor de la práctica

El mapa de calor de la práctica Business analysis, es el siguiente:

Planificar: el Business analysis contribuye a la toma de decisiones estratégicas.

Optimizar: el Business analysis proporciona a la actividad de optimización, la información sobre las oportunidades de creación de valor.

Compromiso: el Business analysis es un actor clave en el compromiso para la creación de valor.

Diseñar y Transformar: esta práctica aporta su visión para la elección de la mejor solución o arquitectura.

Obtener y Construir: el Business analysis ayuda a la elección de los mejores componentes o productos.

Suministrar y Dar soporte: el Business analysis recoge la información de los servicios en producción.

Gestión de la capacidad y del rendimiento

1. Introducción

Esta práctica se basa en el proceso Gestión de la capacidad, presente en las versiones V2 y V3 de ITIL y en una parte de las actividades del proceso de gestión de la demanda, definido en la fase de la estrategia de los servicios de la versión V3 de ITIL. El nombre de la práctica ha evolucionado. Hablamos ahora de capacidad y de rendimiento. La utilización del cloud computing hace la gestión de la capacidad menos crucial.

2. Objetivo de la práctica

La misión del proceso de gestión de la capacidad es garantizar que el rendimiento actual del sistema de información se genere con los mejores costes, teniendo en cuenta las necesidades solicitadas por la empresa y garantizar la capacidad de este SÍ para responder a las peticiones de rendimiento en el futuro.

La gestión de la capacidad y del rendimiento cubre los productos, servicios, personas, organizaciones y prácticas.

3. Las actividades de la práctica

Las actividades de gestión de la capacidad y del rendimiento son:

• Construir un plan de capacidad que analice el estado actual de la capacidad del sistema de información, posicionándolo respecto a las necesidades expresadas e identifique las acciones que van a garantizar un soporte del rendimiento en el futuro.
• Garantizar que se alcanzan los objetivos de rendimiento, incluso se superen, con el mejor ratio coste/calidad.
• Ayudar al diagnóstico y la resolución de eventos, incidentes y problemas relacionados con el rendimiento y la capacidad.
• Mejorar continuamente el rendimiento del sistema de información, vigilando el ratio coste/calidad.

4. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de la capacidad y del rendimiento, es el siguiente:

Planificar: la gestión de la capacidad y de rendimiento intervienen a nivel de la planificación en las actividades tácticas y operativas, proporcionando la información de la demanda y el rendimiento actual y futuro.

Optimizar: la optimización debería ser controlada por una necesidad de mejora del rendimiento.

Compromiso: la actividad de compromiso debe tener en cuenta la expresión de necesidades proporcionada por los clientes, en términos de rendimiento y las restricciones relacionadas con las capacidades del SI.

Diseñar y Transformar: el diseño debe tener en cuenta las obligaciones en términos de capacidad y rendimiento.

Obtener y Construir: la gestión de la capacidad y del rendimiento debe ayudar a la actividad de obtención y construcción, asegurándose de que los componentes y los servicios serán adecuados a las obligaciones solicitadas.

Suministrar y Dar soporte: la gestión de la capacidad y del rendimiento debe ayudar a la actividad de oferta y de soporte, garantizando que los componentes y los servicios son adecuados respecto a las obligaciones solicitadas a lo largo de todo de su vida.

Gestión de cambios

1. Introducción

Esta práctica se basa en el proceso Gestión de cambios, definido en las versiones V2 y V3 de ITIL.

Esta práctica no se debe confundir con la práctica descrita en el capítulo anterior, que se llama Gestión de cambios organizativos y que trata de los cambios en términos de organización.

2. Objetivo de la práctica

La misión de la práctica Gestión de cambios es maximizar el éxito de la implementación de cambios, sobre los productos y los servicios. Garantiza que todos los cambios se guardan, evalúan, autorizan, priorizan y que su realización, integración y despliegue sigan un procedimiento definido.

3. Las actividades de la práctica

Las actividades de la práctica Gestión de cambios son:

• asegurarse que los procedimientos y los métodos utilizados para tratar los cambios son eficaces, incluso eficientes,
• asegurarse que las modificaciones aportadas a los elementos de configuración durante un cambio, se guardan correctamente en la base de datos apropiada,
• responder a las evoluciones expresadas por las necesidades de los clientes, minimizando los riesgos de interrupción de servicio y maximizando el valor proporcionado,
• tener una planificación completa de todos los cambios actuales o futuros.

4. Perímetro de la práctica

La práctica Gestión de cambios se aplica a un perímetro que se debe definir de manera explícita (mencionando también lo que no forma parte de él). Es propio de cada organización.

Cubre:

• cualquier modificación, adición o retirada de un elemento de configuración a lo largo de todo su ciclo de vida, ya sea de manera interna o por un proveedor externo.

No cubre:

• los cambios de actividad o de organización de negocio,
• los cambios a nivel operativo relacionados con los consumibles (ejemplo, cambio de cartucho de tinta).

5. Terminología de la práctica

a. Definición de un cambio

Esta definición de un cambio es importante, ya que normalmente es el objeto de muchas discusiones en las empresas. En el sentido ITIL, un cambio es una modificación de uno o varios elementos de configuración (CI’s, Configuration Items) que componen el sistema de información o de uno o varios servicios proporcionados por este sistema de información. Modificación quiere decir adición, modificación de uno o varios atributos del CI o retirada de uno o varios CI’s. Un cambio tiene un impacto directo o indirecto sobre uno o varios servicios.

A continuación se muestran algunos otros ejemplos de cambios: una nueva versión de un software aplicativo, la instalación de un puesto de trabajo, la introducción de un nuevo servidor, la sustitución de una impresora, etc.

Una modificación de una documentación o de un contrato es un cambio (ver la sección relativa al proceso de gestión de las configuraciones).

Por lo tanto, la modificación de un dato (Data) no es un cambio. La asignación de un derecho de acceso no es un cambio. Una modificación de una actividad de un proceso de negocio no es un cambio.

Un cambio tiene origines diversos. Se puede dar una lista no exhaustiva:

• Las correcciones (evento, incidente, problema, etc.).
• La legislación.
• La organización.
• Las directivas o los estándares.
• Las evoluciones de los servicios existentes.
• Nuevos servicios.
• Un nuevo modelo de abastecimiento.
• Una innovación tecnológica, etc.

b. La petición de cambio

Una petición de cambio, RFC (Request For Change en inglés) es la formalización de una modificación de uno o varios elementos de configuración (CI, Configuration Item, en inglés). Todo cambio se debe formalizar por una RFC. Existen diferentes tipos de RFC, que se corresponden con los diferentes tipos de cambio.

Todos los usuarios o las ramas de negocio están habilitadas para realizar una petición de cambio, pero esto no quiere decir que sea aceptada.

c. Los tipos de cambio

En las buenas prácticas ITIL 4, se identifican tres tipos de cambio:

• El cambio llamado normal: hace necesario una evaluación completa y una autorización antes de su realización.
• El cambio estándar: afecta a los cambios preautorizados y que van a seguir procedimientos predefinidos.
• El cambio urgente: implica una reacción más rápida de lo habitual para limitar los impactos en el negocio.

d. Las características de un cambio llamado normal

Es un cambio que no es estándar ni urgente. Se caracteriza por una necesidad de evaluación y de seguimiento (o de control), que será más o menos importante en función de los riesgos, de la complejidad y del esfuerzo necesario para la realización del cambio.

La autoridad de gestión del cambio es una instancia que va a evaluar, autorizar o rechazar el cambio, planificarlo y seguirlo hasta su cierre. Este comité de los cambios se debe adaptar a la naturaleza del cambio propuesto.

e. Las características de un cambio estándar

Las acciones necesarias para implementar un cambio estándar son conocidas, documentadas, ya realizadas y probadas (under control como dicen los anglosajones). Los riesgos son bajos y bien controlados. Los recursos y los costes son conocidos. Se ha hecho una pre-validación técnica. Solo es necesaria una validación presupuestaria.

Por lo tanto, los cambios estándares son cambios pre-aprobados, ya controlados y asociados a procedimientos establecidos. Normalmente se asocian a los modelos de cambios. Los puntos clave son:

• El desencadenamiento está claramente definido.
• Las tareas están bien controladas y documentadas.
• La autorización se ha hecho efectiva.
• La aprobación presupuestaria está preautorizada o bien gestionada completamente por el solicitante.
• La mayor parte del tiempo, son cambios bien conocidos y con riesgo bajo.

Como un cambio estándar tiene elementos desencadenantes bien definidos, a menudo implementamos solicitudes de cambio estándar a través de formularios predefinidos que proporcionarán un mini catálogo de cambios autorizados previamente.

La siguiente lista proporciona algunos ejemplos de cambios estándares:

• La instalación de un puesto de trabajo,
• La configuración de un servidor,
• La sustitución de una impresora, etc.

f. Las características de un cambio urgente

En primer lugar, la urgencia no es la normalidad, es la excepción. Utilizaremos cambios urgentes de manera excepcional. La urgencia se solicita por el emisor de la demanda (RFC), pero se debe validar y autorizar por una instancia apropiada. La urgencia va a permitir cortocircuitar los procedimientos de realización e implementación del cambio para reducir los plazos, por ejemplo rechazando la escritura de documentación después de la puesta en servicio, incluso minimizando las pruebas. Por el contrario, un cambio urgente siempre tendrá que contemplar los procedimientos de revisión y probarlos. Un cambio urgente puede hacer necesario eliminar la planificación de otros trabajos o una asignación de recursos adicionales, en detrimento de otras actividades.

6. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de cambios, es el siguiente:

Planificar: en este mapa de calor vemos que la actividad de planificación es baja respecto a la gestión de cambios. En la versión V3, el proceso de gestión de cambios tenía una fuerte responsabilidad en la planificación de los cambios. Este ya no es el caso en ITIL 4. La práctica Gestión de cambios se refocaliza en el control, dejando la responsabilidad de la planificación a la gestión del porfolio, por ejemplo.

Optimizar: la gran mayoría de las proposiciones de optimización o de mejora, pasarán bajo el control de la gestión de cambios.

Compromiso: la gestión de cambios provocará su ayuda y su soporte a la actividad de compromiso.

Diseñar y Transformar: la gestión de cambios es la práctica principal de la actividad global de diseño y transformación.

Obtener y Construir: la gestión de cambios es la práctica principal de la actividad global de la obtención y construcción.

Suministrar y Dar soporte: la gestión de cambios debe minimizar los impactos sobre la producción y el soporte, con la implementación de nuevos cambios.

Gestión de incidentes

1. Objetivo de la práctica

Esta práctica se basa en el proceso definido en las versiones ITIL V2 y V3.

La práctica de gestión de incidentes tiene dos objetivos distintos que no hay que confundir, ya que la finalidad no es la misma:

• Restablecer el servicio a un estado normal lo más rápidamente posible, conforme al acuerdo de nivel de servicio asociado.
• Minimizar el impacto del incidente sobre los usuarios.

a. Restablecer el servicio

Restablecer el servicio no quiere decir encontrar una solución, sino volver a poner el servicio en marcha, para que funcione de nuevo en un estado llamado normal (o estándar).

Restablecer el servicio, normalmente es volver a lanzar el servidor o la aplicación sin entender la causa. Si el servicio funciona de nuevo en el estado normal (o estándar), el incidente está solucionado. Esto es lo principal para el cliente y los usuarios del servicio. Por el contrario, esto puede no ser satisfactorio para los equipos informáticos. La sección siguiente, Gestión de problemas, abordará la manera de responder a esta situación.

Para resumir, restablecer el servicio, es encontrar una solución, incluso un paliativo, que va a volver a lanzar el servicio en su estado normal.

b. Minimizar el impacto

El segundo objetivo de la gestión de incidentes es minimizar las consecuencias para los usuarios.

Restablecer el servicio en los plazos contractuales, es un compromiso de resultado frente al cliente. Minimizar el impacto del incidente, es comprometerse con los medios y de esta manera, el departamento informático hará lo mejor según sus recursos disponibles (best effort, como dicen los anglosajones).

c. Qué hace la gestión de incidentes

La práctica Gestión de incidentes no tiene como objetivo encontrar las causas de los incidentes. Se centra en la restauración del servicio. El análisis de las causas es responsabilidad de la práctica Gestión de problemas, que realizará este análisis en back office, fuera de la presión de la gestión del incidente. Por supuesto, si la gestión de incidentes incluye las fuentes de funcionamiento incorrecto, el proceso los tendrá en cuenta para restaurar el servicio y los comunicará a la gestión de problemas.

El objetivo es ahorrar tiempo a los equipos de gestión de incidentes y hacerlos más disponibles para tratar los nuevos incidentes.

2. Terminología de la práctica

a. Definición de un incidente

Es importante entender bien la noción de incidente y sobre todo, no confundir incidente con evento o problema (nociones que se abordarán en las secciones siguientes).

Para una buena comprensión, facilitamos un recordatorio de la noción de evento: un evento es un hecho detectable que sucede en la infraestructura del sistema de información; un incidente es un evento que altera o degrada un servicio entregado a un usuario. Se dice que un incidente aparece cuando el servicio se detiene o cuando la calidad del servicio disminuye.

Todos los incidentes tienen como origen un evento, se detecte o no. Por el contrario, todos los eventos no van a implicar la creación de un incidente.

Un incidente solo puede aparecer cuando el servicio está operativo en producción, en caso contrario es una anomalía.

Un incidente se detecta por un usuario que va a contactar con el centro de servicios, o por medio de las herramientas de supervisión o control, a través de la práctica Gestión de eventos.

b. Impacto, urgencia, prioridad

Durante cada incidente, es importante identificar la información que va a permitir codificar este incidente. Codificar un incidente, es determinar la prioridad que le vamos a asignar. Para esto, se identificará el impacto y la urgencia de este incidente:

• El impacto es el efecto del incidente en la utilización del servicio. Ejemplos: pérdida de explotación, número de usuarios bloqueados que no pueden trabajar, no respeto a las disposiciones legales, etc. Para el impacto se usa una calificación que normalmente se basa en una escala de 1 a 3 o de 1 a 5 (1 = Elevada, 3 o 5 = Baja).
• La urgencia es el tiempo del que dispone el departamento informático para restablecer el servicio antes de que los efectos del incidente se sientan. Por ejemplo, si el servidor que soporta la aplicación de gestión de la paga se avería el tercer día del mes, la urgencia relacionada con este incidente es menor que si este servidor se para el día 25 del mes. Para la urgencia se usa una calificación que normalmente se basa en una escala de 1 a 3 o de 1 a 5 (1 = Elevada, 3 o 5 = Baja).

La prioridad del incidente es la conjunción de estas dos nociones: el impacto y la urgencia. Por lo tanto, la prioridad va a permitir identificar la importancia relativa de los incidentes unos respecto a los otros y permitir asignar los recursos en consecuencia.

A cada nivel de prioridad (P1, P2, P3), se le asigna un plazo de restablecimiento (por ejemplo, P1 = 2 h, P2 = 8 h, P3 = 24 h).

Todas estas nociones sirven para la codificación de un incidente (Impacto, Urgencia, matriz de asignación de los niveles de prioridad y plazos de restablecimiento), se deben explicitar en el documento ‘Acuerdo de nivel de servicio’ para cada servicio y negociar con las ramas de negocio, antes de la implantación del servicio.

c. Incidente principal

Algunos incidentes tienen un fuerte impacto sobre las ramas del negocio o sobre la empresa. Estos incidentes se llaman principales. Están fuera de la cuadrícula de codificación y por lo tanto, tienen una prioridad más elevada que P1. Se tratan de manera diferente a los otros incidentes: se va a desarrollar un procedimiento llamado de "crisis", con el establecimiento de una célula de crisis para tratar estos incidentes principales. La comunicación al exterior de la informática para estos incidentes principales, es específica para cada situación y se debe tratara como tal.

Algunos incidentes principales pueden provocar el desencadenamiento del plan de continuidad de los servicios informáticos (ver la sección dedicada a la práctica Gestión de la continuidad de servicios informáticos).

d. Ticket de incidente

Todo incidente se debe registrar en una base de datos de incidentes, a través de un ticket de incidente que consigne toda su información relativa (hora, fecha, contexto, efecto, seguimiento de los procesos de escalado de problemas, resolución, cierre, etc.).

3. Gestión de los procesos de escalado de problemas

Los incidentes se pueden diagnosticar y resolver por diferentes organizaciones, según la complejidad del incidente. Por lo tanto, va a ser necesario poner en marcha un mecanismo de escalado descrito por un procedimiento.

En primer lugar, los usuarios pueden diagnosticar y resolver los incidentes.

El centro de servicios (Service Desk en inglés), se encarga del primer nivel de la gestión de incidentes y del seguimiento de estos.

Los incidentes más complejos se escalan a los grupos de soporte de nivel 2 y de nivel 3.

El siguiente diagrama de flujo muestra cómo los grupos de soporte de nivel 2 y de nivel 3, intervienen en la escalada al centro de servicios (soporte de nivel 1). Los grupos de soporte de nivel 3 pueden ser proveedores externos.

Durante su intervención, los grupos de soporte pueden, si es necesario, estar en contacto con los usuarios (para obtener información complementaria o para entender un entorno o una configuración o incluso, para verificar una solución).

De cualquier manera, incluso si los grupos de soporte resuelven el incidente y restauran el servicio, la validación final con el usuario sigue siendo responsabilidad del centro de servicios.

En las buenas prácticas ITIL, se identifican dos tipos de escalado: escalado funcional y escalado jerárquico.

Estos dos tipos de escalado son independientes y se deben gestionar por separado:

• El escalado funcional: un escalado funcional ocurre cuando un equipo que fue asignado al tratamiento del incidente, no es capaz de realizar este tratamiento (diagnóstico o restablecimiento). Este equipo transfiere entonces el incidente a otro equipo de nivel de experiencia más elevada o incluso del mismo nivel de experiencia pero de otro dominio. Esta situación se llama escalada funcional. Es el caso del diagrama de flujo anterior.
• El escalado jerárquico: un escalado jerárquico permite alertar a la jerarquía (el management), de una situación particular: incidente principal potencial, impacto fuerte sobre las ramas del negocio, bloqueo debido a una ausencia de recursos y de medios, etc.

4. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de incidentes, es el siguiente:

Planificar: por supuesto la gestión de incidentes no se aplica en la actividad de planificación. La aparición de un incidente no es planificable.

Optimizar: los tickets de incidente son elementos importantes para determinar las oportunidades de mejora.

Compromiso: los incidentes son muy visibles por los usuarios y las unidades de negocio. Por lo tanto, la gestión de incidentes es una práctica que deberá rendir cuentas al más alto nivel de las organizaciones, es decir, basándose en la dirección para comunicarse frente a los usuarios. Por lo tanto, va a estar presente en la actividad de compromiso.

Diseñar y Transformar: la gestión de incidentes puede intervenir para validar la resolución de las situaciones de anomalías en esta actividad de diseño y transformación.

Obtener y Construir: la gestión de incidentes puede intervenir para la resolución de las situaciones de anomalías en esta actividad de obtención y construcción.

Suministrar y Dar soporte: es por supuesto en la actividad de soporte donde la gestión de incidentes interviene.

Gestión de problemas

1. Objetivo de la práctica

La práctica Gestión de problemas se basa en el proceso Gestión de problemas, definido en las versiones ITIL V2 y ITIL V3.

La práctica Gestión de problemas tiene cuatro objetivos principales:

• Hacer disminuir el número de incidentes: es el objetivo principal de este proceso.
• Prevenir la aparición de nuevos incidentes y problemas: este objetivo es la consecuencia del objetivo anterior, pero se va a responsabilizar de las acciones mucho más orientadas a la anticipación, la proactividad.
• Minimizar el impacto de los incidentes.
• Optimizar la eficacia de los equipos de soporte.

2. Terminología de la práctica

a. Definición de un problema

Un problema es una situación en la que buscamos la causa desconocida de uno o varios incidentes.

En primer lugar, no se puede hablar de problema si inicialmente no ha habido uno o varios incidentes. Los incidentes se tratan por el proceso de gestión de incidentes y van a promover una restauración del servicio. La gestión de problemas va a observar las causas reales, para aportar soluciones.

La gestión de incidentes trata en tiempo real las situaciones (en front line como dicen los anglosajones) y la gestión de problemas trata más tarde las causas de estas situaciones (en back office).

No hay problema si inicialmente no ha habido al menos un incidente. Por el contrario, no todos los incidentes generan una situación de problema. Esta frase es muy importante, ya que es base de la gestión de servicios. Lo importante es restablecer el servicio. Se intentará más tarde entender las causas de los incidentes y encontrar las soluciones. Entender las causas y encontrar las soluciones tiene un coste en tiempo y dinero.

Se abre un problema en caso de incidentes recurrentes. La recurrencia depende del contexto de la empresa. Otro caso de apertura de un problema es un contexto de incidente principal. Podemos ver que cuando se restablece el servicio sobre un incidente principal, con un fuerte impacto sobre la empresa, no queremos que se vuelva a producir. Por lo tanto se abrirá sistemáticamente un problema, incluso si la recurrencia es una.

b. Definición de un error conocido

Un error conocido (en inglés known error), es un problema del que conocemos la causa y hemos identificado una solución temporal o definitiva, pero del que todavía no tenemos implementación.

Si se investiga la causa, se encuentra esta causa y/o se encuentra una solución (solución temporal o correctiva), entonces el problema se convierte en un error conocido.

Sin embargo, no cerramos el problema cuando hemos entrado en un error conocido, sino que para realizar este cierre, se espera al establecimiento de la solución definitiva que erradica el problema.

La base de los errores conocidos contiene el conjunto de información relativa a los problemas sobre los que hemos encontrado la causa y una solución temporal o definitiva. Esta base, bajo la responsabilidad de los grupos de soporte, también se pone a disposición del centro de servicios.

c. Definición de una solución temporal ("workaround")

Una solución temporal (en inglés workaround), es una solución que reduce o elimina el impacto de un incidente o problema, cuando no hay disponible una solución definitiva.

3. La relación entre gestión de incidentes y gestión de problemas

El siguiente esquema muestra el encadenamiento entre incidentes repetitivos que pueden generar un problema, que él mismo será transformado en un error conocido (con el conocimiento de la causa y de una solución) y la implementación de esta solución, para una resolución definitiva.

4. Las actividades de la práctica

Las principales actividades de la práctica Gestión de problemas de problemas, son las siguientes:

• El análisis de las situaciones de incidentes que se pueden convertir en problemas.
• La detección de situaciones ya registradas como problema.
• La transformación de los problemas en errores conocidos.
• La gestión de incidentes principales transformados en problemas.
• La gestión de corrección del error a través de la práctica Gestión de cambios.
• El análisis proactivo de la información transmitida por los proveedores internos o externos, sobre las situaciones que pudieran degradar el nivel de los servicios.

5. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de problemas, es el siguiente:

Planificar: por supuesto, como la aparición de los incidentes, los problemas no se planifican con antelación.

Optimizar: la razón de ser de la gestión de problemas reside en la mejora de los productos y servicios.

Compromiso: la actividad de compromiso debe gestionar la priorización de los problemas, incluso la selección de los problemas en sí mismos.

Diseñar y Transformar: la gestión de problemas proporciona información relativa a las situaciones de problemas y errores conocidos.

Obtener y Construir: la gestión de problemas interviene en el análisis de las situaciones problemáticas sobre los componentes que se están construyendo.

Suministrar y Dar soporte: la gestión de problemas interviene principalmente en esta actividad para determinar las situaciones de problemas (recurrencia de los incidentes).

Gestión de los activos de servicios

1. Preámbulo

Esta práctica no se basa directamente en un proceso del enfoque ITIL V3. Esta práctica retoma las tareas gestionadas por los procesos ITIL V3, gestión de los activos de servicios y de las configuraciones y, de las configuraciones y gestión financiera.

2. Objetivo de la práctica

Los objetivos principales de la práctica Gestión de los activos de servicios, son planificar y gestionar el ciclo de vida de los activos de servicios, de manera que se maximice el valor de estos activos, se controle sus costes y se gestionen sus riesgos. Va a ayudar a la práctica Gestión de los proveedores, proporcionando la información de la adquisición de nuevos activos, su retirada o su reutilización.

3. Terminología de la práctica

a. Activo de servicio

Un activo de servicio es un componente que contribuye a la oferta de uno o varios servicios y que tiene un valor financiero. En inglés, se llama asset.

No hay que confundir activo de servicio con elemento de configuración CI (Configuration Item). Los CI se gestionan por la práctica Gestión de configuraciones.

b. Tipos de activos de servicio

Los tipos de activos de servicio cubren todos los componentes del sistema de información, es decir:

• Los componentes de hardware, por ejemplo servidores, puestos de trabajo, unidades de disco, periféricos, etc.
• Los componentes de software, por ejemplo sistemas operativos, drivers, herramientas de supervisión, planificadores, herramientas de copia de seguridad, etc.
• Los componentes de software de aplicaciones, por ejemplo desarrollos específicos, ERP, etc.
• Las bases de datos, por ejemplo bases de datos, archivos de configuración, etc.
• Los equipamientos de red y telecomunicaciones, por ejemplo rúters, puentes, teléfonos y PBX, videoconferencia, etc.
• Los componentes de infraestructura ambientales, por ejemplo sitios web, energía e inversores, aires acondicionados, armarios y racks, etc.

c. Los atributos de un activo de servicio

Los atributos de un activo de servicio son el conjunto de datos que van a describir el elemento y su comportamiento, durante su ciclo de vida. Se trata de sus referencias técnicas y su información financiera y contractual. Los atributos son estáticos (fecha de compra) o dinámicos, es decir que pueden evolucionar a lo largo del ciclo de vida del elemento (depreciación y amortización por ejemplo). Vamos a encontrar la siguiente información:

• Referencia técnica
• Nombre del proveedor
• Referencia del contrato de proveedor
• Fecha de compra o de aprovisionamiento
• Fecha provisional de retirada
• Coste
• Amortización
• Estado (solicitado, entregado, en stock, instalado, en producción, inactivo, retirado, etc.)

4. Las actividades de la práctica

Las actividades de la práctica Gestión de activos de servicio se parecen mucho a lo que llama actividades relacionadas con el inventario. De hecho, el inventario debe reunir todos los componentes que tienen un valor financiero y seguir su ciclo de vida hasta su retirada o descarte.

Esto quiere decir que esta práctica debe gestionar:

• El etiquetado de todos los activos de hardware,
• El registro (referencia, número de versión, número de instancia, etc.) de todos los activos de software básicos y software de aplicaciones,
• el seguimiento y el control de todos los activos.

Las buenas prácticas ITIL 4 prevén combinar la base de los activos de servicio con la base de los elementos de configuración, la CMS (Configuration Management System).

5. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de los activos de servicio, es el siguiente:

Planificar: esta práctica está muy relacionada con la gestión financiera. Va a proporcionar información sobre los activos de servicio a la gestión financiera, que la usará en la actividad de planificación.

Optimizar: esta práctica aporta su visión sobre los costes de los activos de servicio en las proposiciones de mejora.

Compromiso: esta práctica aporta su visión sobre los costes de los activos de servicio en las proposiciones de mejora.

Diseñar y Transformar: esta práctica tiene en cuenta todos los cambios de estado de los activos de servicio, durante esta actividad de diseño y transformación.

Obtener y Construir: esta práctica debe poner en marcha todos los mecanismos de rastreo de los activos de servicio durante esta actividad de aprovisionamiento y construcción.

Suministrar y Dar soporte: esta práctica proporciona la información sobre la localización de los activos de servicio durante su ciclo de vida.

Supervisión y gestión de eventos

1. Objetivo de la práctica

En primer lugar, el nombre de esta práctica ha evolucionado respecto al proceso definido en ITIL V3. En efecto, en ITIL V3 se hablaba únicamente de gestión de eventos. Con ITIL 4 se amplía el perímetro tomando completamente la actividad de supervisión (monitoring en inglés).

La práctica Supervisión y gestión de eventos tiene dos objetivos principales: minimizar el número de los incidentes y garantizar el nivel de calidad de servicio del sistema de información.

a. Minimizar el número de los incidentes

Es el objetivo principal de esta práctica. Seremos más eficaces en la gestión de eventos, cuanto menos incidentes haya. Vigilar los eventos y entenderlos e instaurar umbrales que darán alarmas, permitirá anticipar las acciones y actuar antes de que la situación se haya degradado y por lo tanto, tenga un fuerte impacto en el servicio y los usuarios. Detectar lo antes posible los eventos, va a permitir emprender las acciones necesarias antes de que los incidentes se produzcan. Un indicador sobre la reducción del número de incidentes, es un muy buen indicador de la eficacia del proceso de gestión de eventos. Por lo tanto, un aumento del número de eventos pero una disminución del número de incidentes, muestra que el sistema de información está bajo control.

b. Garantizar el nivel de calidad de servicio del sistema de información

La práctica Supervisión y gestión de eventos también tiene un objetivo de anticipación sobre las situaciones, que pueden terminar deteriorando el nivel de calidad del servicio del sistema de información. Posicionando los umbrales sobre los componentes claves, la gestión de eventos va a intervenir proactivamente para mantener y garantizar el nivel de calidad del servicio.

2. Terminología de la práctica

a. Definición de un evento

Un evento es un hecho detectable que sucede sobre el sistema de información y que tiene un significado para la gestión de la infraestructura o sobre la oferta de los servicios ofrecidos. Por ejemplo: cuando llega a su oficina cada mañana, enciende su puesto de trabajo y abre su correo. Abrir su correo es generar un evento. En el servidor de mensajería, se registra una notificación de apertura de su correo. Es la pasarela del servidor de mensajería. Esta pasarela representa la lista de los eventos aparecidos en el servicio de mensajería. Habrá otro evento, cuando por la noche cierre su correo electrónico y apague su puesto de trabajo. Otro mensaje se registrará en la pasarela del servidor de mensajería.

Un evento también es un cambio de estado de uno o varios componentes de la infraestructura. Si, por ejemplo, un rúter se añade a la red interna de la empresa, cuando se pone en servicio, se produce un cambio de estado de este rúter (inactivo a activo) y se genera un evento a nivel de la herramienta de supervisión o administración de la red.

Estos dos ejemplos muestran que durante la detección de un evento, no hay manifestación visible del lado del usuario. Un evento no tiene impacto visible para el usuario cuando este evento se llama normal. Veremos que determinados eventos llamados anormales o excepciones, podrán ser visibles por los usuarios sin que se degrade la calidad del servicio ofrecido.

Un evento es aleatorio, observable y por supuesto medible. Para detectarlo y medirlo, son necesarias herramientas de supervisión, explotación y control: sin herramientas, no hay evento.

b. Tipo de eventos

Existe tres tipos de eventos: Información, Advertencia y Excepción.

Eventos de Información

Este tipo de evento dará testimonio de un funcionamiento normal (inicio o fin de actividad), es el ejemplo del buzón de correo electrónico, el fin de trabajos en batch, etc.

Eventos de Advertencia

Este tipo de evento es inusual y no anormal, no excepcional.

Es una advertencia (warning en inglés). Un ejemplo es el enfoque de un umbral crítico, un pico de actividad. Todavía no hay impacto negativo sobre el servicio.

Todavía es necesaria una supervisión.

Eventos de Excepción

Esto tipo de evento se llama anormal. Señala una excepción, un hecho anormal, que aparece sobre la infraestructura. Estos eventos pueden ser visibles por los usuarios sin degradar el nivel de calidad del servicio ofrecido. Un evento de excepción se puede transformar en un incidente, si la situación impacta a nivel de la calidad del servicio. Va a ser necesario una intervención, una acción sobre uno o varios componentes, uno o varios servicios. El evento de excepción también sirve para garantizar que una persona va a conocer de manera efectiva este evento.

3. El mapa de calor de la práctica

El mapa de calor de la práctica Supervisión y gestión de eventos, es el siguiente:

Planificar: supervisión y gestión de eventos no es una práctica planificable: la supervisión es permanente y la gestión de eventos se desencadena cuando un evento aparece.

Optimizar: esta práctica debería tener un rol importante en la optimización, ya que con la supervisión tiene una visión clara del nivel de calidad proporcionado y sobre la estabilidad del sistema de información.

Compromiso: esta práctica puede alimentar la actividad de compromiso con propuestas originadas en situaciones parecidas dentro del sistema de información.

Diseñar y Transformar: esta práctica va a supervisar las transformaciones del sistema de información.

Obtener y Construir: esta práctica debe intervenir en esta actividad para garantizar que las herramientas de supervisión se aprovisionen correctamente o se desarrollen.

Suministrar y Dar soporte: esta práctica interviene principalmente en esta actividad. Se trata de la explotación del sistema de información.

Gestión de las entradas en producción

1. Objetivo de la práctica

En primer lugar, esta práctica se basa en un proceso de V3 de ITIL, titulada gestión de los despliegues y de las entradas en producción. ITIL 4 ha reducido su título para conservar solo Gestión de las entradas en producción: término más genérico que engloba las tareas de puesta en servicio. Esta práctica se va a basar en una práctica tecnológica titulada Gestión de los despliegues.

El objetivo principal de la gestión de las entradas en producción es poner en servicio lo que llamamos, en la traducción ITIL V3 del término inglés Release, una unidad de entrada en producción.

2. Terminología de la práctica

a. Una unidad de producción

Una unidad de producción (release en inglés), es un conjunto de elementos de configuración (CI) coherente, que se entrega para ponerse en producción. Este conjunto es conforme a las obligaciones descritas en el documento de política de entrada en producción. Una unidad de producción puede contener hardware, software, documentación o una mezcla de todos los tipos de elementos de configuración.

Por ejemplo, una organización puede decidir que la unidad de entrada en producción para una aplicación de negocio crítica es la aplicación completa, de manera que se garantice la integridad de la aplicación. Por otro lado, puede decidir que la unidad de entrada en producción más apropiada para un sitio web, reside a nivel de la página, incluso a nivel de un campo de la página.

Atención al término inglés release, que puede provocar confusiones. Con frecuencia, detrás de la palabra release esperamos "versión de software". Para el enfoque ITIL, la palabra release cubre todo tipo de unidad de producción.

Una unidad de producción se puede agrupar (package release en inglés). Esto permite incorporar en una misma entrada en producción, varios cambios que tienen relación entre ellos. Por ejemplo, es lo que llamamos comúnmente en informática un paquete tecnológico o funcional. Ponemos en una misma versión un conjunto de evoluciones o modificaciones de un software o de una aplicación.

Por ejemplo, una nueva versión de una aplicación hace necesario una actualización del sistema de explotación (Unix, Windows, etc.) y una evolución del hardware. En este caso, hay que prever una entrada en producción agrupada.

Una unidad de producción agrupada incluye el conjunto de los cambios necesarios para garantizar el servicio, como:

• la modificación de la infraestructura técnica,
• la formación de los equipos de soporte,
• la documentación de explotación y de mantenimiento,
• la actualización de los servicios deductivos.

b. La PIR

La PIR (Post Implementation Review) es un comité que analiza los resultados de las entradas en producción de los cambios.

Este comité identifica todos los cambios que, después de la entrada en producción, no han alcanzado sus objetivos, los que han tenido dificultades no previstas de implementación y aquellos que han generado incidentes post-MEP. Todos estos cambios llamados en error, se analizan dentro del comité PIR para identificar las causas de estos fallos y deducir las medidas para evitar que esto se reproduzca.

3. Las tareas de la práctica

Las tareas de la práctica Gestión de las entradas en producción, son las siguientes:

• Asegurar una planificación de todas las actividades de implementación de uno o varios cambios. De esta manera, se va a encargar de validar el contenido de los lotes de entrada en producción.
• Construir, integrar, probar, validar, instalar, desplegar y poner en producción un cambio de manera eficaz, incluso eficiente. La automatización y de manera más global, la industrialización de los procedimientos de despliegue y de entrada en producción, es un objetivo principal. Esta práctica se garantiza igualmente que el correcto establecimiento de los repositorios del hardware y de software.
• Asegúrese de que la versión proporcione el servicio requerido, en particular del buen funcionamiento de cada elemento puesto en producción con el nivel de servicio solicitado. Dicho de otra manera, ser responsable de la utilidad y de la garantía del servicio puesto en producción, en conformidad con los acuerdos de servicios.
• Minimizar el impacto de una entrada en producción sobre el servicio en sí mismo, es decir perturbar lo menos posible el o los servicios existentes (parada de servicio, compatibilidad ascendente, etc.)
• Transferir los conocimientos y las competencias a las entidades de explotación y mantenimiento.
• Globalmente, garantizar que el cliente y los usuarios están satisfechos de las actividades de la fase de transición. La práctica Gestión de las entradas en producción es el proceso más visible de la fase de transición para el cliente y los usuarios. Va a gestionar las expectativas del cliente y se encarga de garantizar que los usuarios tienen la información y la formación necesarias para recibir la versión que lleva consigo la entrada en producción.

4. Técnicas de entrada en producción

Las buenas prácticas ITIL 4 dan dos recomendaciones para desarrollar las entradas en producción. Difieren según los entornos, tradicional ("waterfalls") o ágil.

En el primer caso, ITIL 4 prevé realizar las tareas de despliegue y puesta en servicio en un mismo proceso: se despliega y pone en servicio al mismo tiempo.

En un entorno ágil, ITIL 4 propone desplegar el software y el hardware por pequeños incrementos tan pronto como estén validados y posteriormente, realizar la puesta en servicio globalmente.

5. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de las entradas en producción, es el siguiente:

Planificar: esta práctica se basa en el documento Política de entrada en producción, que planifica las diferentes entradas en producción.

Optimizar: esta práctica pone en servicio todas las nuevas unidades de producción, vengan de proposiciones de mejora o no.

Compromiso: la práctica Gestión de las entradas en producción pone en servicio las unidades de producción que surgen de las proposiciones que hayan tenido el visto bueno del compromiso.

Diseñar y Transformar: el rol principal de esta práctica es garantizar que las unidades de producción estarán disponibles para los usuarios.

Obtener y Construir: una unidad de producción es la construcción de componentes suministrados.

Suministrar y Dar soporte: esta práctica debe participar en la transferencia de conocimientos a los grupos de soporte.

Gestión del catálogo de servicios

1. Objetivo de la práctica

Esta práctica se basa en el proceso Gestión del catálogo de servicios de ITIL V3.

La práctica Gestión del catálogo de servicios tiene por vocación desarrollar y mantener actualizado un catálogo de servicios único. Este catálogo de servicios contiene el conjunto de información de los servicios en producción y de los servicios que están a punto de ser operativos. Esta práctica igualmente tiene por objetivo garantizar la promoción frente a todas las ramas del negocio de la empresa.

2. Terminología de la práctica

a. El catálogo de servicios

Un catálogo de servicios es la parte visible por los clientes y los usuarios, del porfolio de servicios. Va a contener toda la información de los servicios producidos y del saber hacer de la informática.

El catálogo de servicios se compone de tres documentos que cubren tres misiones diferentes: un catálogo de servicios de negocio, un catálogo de servicios de usuario y un catálogo de servicios técnicos informáticos.

b. El catálogo de servicios de negocio

Un catálogo de servicios de negocio contiene el detalle de los servicios ofrecidos a las diferentes ramas de negocio. Se escribe en un lenguaje comprensible por los clientes, es decir, en su lenguaje de negocio. Da una visión de los servicios proporcionados por la informática en el contexto de los procesos de negocio de los clientes. Mencionará en particular el rendimiento de los servicios, el nivel de calidad ofrecido y los costes o precio asociados. Es la vista del cliente del catálogo de servicios.

c. El catálogo de servicios de usuario

El catálogo de servicios de usuario proporciona una visión muy operativa de los servicios: cómo pedirlos, cómo instalarlos, cuáles son los requisitos previos, etc.

d. El catálogo de servicios técnicos informáticos

Un catálogo de servicios técnicos informáticos contiene el detalle de los servicios ofrecidos a los clientes, con un enfoque tecnológico, de componentes. Resalta los elementos de configuración implicados (CI, Configuration Item), los recursos, medios, herramientas necesarias, el nivel de seguridad, etc. que van a componer los servicios. Contiene los detalles de todos los servicios informáticos proporcionados a los clientes y las relaciones con los servicios de soporte, los servicios compartidos, así como los componentes necesarios para soportar la oferta de los servicios a las unidades de negocio. Debe apoyar el catálogo de servicios de negocio, pero no formar parte de la vista del cliente del catálogo de servicios.

3. La interfaz con el porfolio de los servicios

El catálogo de servicios se incluye en la herramienta de porfolio de los servicios, que aporta la práctica Gestión de porfolios de servicios. Solo el catálogo de servicios es visible por los clientes y usuarios.

El catálogo de servicios es una parte primordial del porfolio de los servicios, ya que proporciona la información de los servicios existentes y muestra de esta manera, las mejoras posibles sobre estos servicios.

4. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión del catálogo de servicios, es el siguiente:

Planificar: esta práctica da la información de los servicios existentes, para planificar mejor las evoluciones de los servicios.

Optimizar: la actividad de optimización se basa en la información proporcionada por el catálogo de servicios.

Compromiso: el catálogo de servicios es primordial en las relaciones con los niveles estratégicos, tácticos u operativos, ya que es la fuente única para obtener la información de los servicios en producción.

Diseñar y Transformar: la práctica catálogo de servicios debe recoger la información necesaria para elaborar estos tres tipos de catálogos de servicios.

Obtener y Construir: el catálogo de servicios se utiliza por esta actividad para el aprovisionamiento.

Suministrar y Dar soporte: el catálogo de servicios es indispensable para esta actividad de soporte.

Gestión de las configuraciones de servicios

1. Preámbulo

En el enfoque ITIL 4, dos prácticas se encargan de gestionar los elementos de configuración: se trata de la gestión de los activos de servicio, abordada anteriormente y esta, la gestión de las configuraciones de servicios.

Incluso si estas dos prácticas no tienen los mismos objetivos, normalmente se gestionan de manera conjunta, incluso con las mismas bases de datos.

Esta práctica se basa en el proceso Gestión de los activos de servicio y de las configuraciones de ITIL, versiones V2 y V3.

2. Objetivo de la práctica

La misión de la práctica Gestión de las configuraciones, es definir y controlar los componentes de servicio y de infraestructura y mantener la información necesaria y exacta de su estado actual, sobre su histórico y sus estados planificados.

3. La terminología de la práctica

a. La noción de elemento de configuración

Un elemento de configuración, llamado CI (Configuration Item en inglés), es un componente del sistema de información que va a contribuir a la oferta de uno o varios servicios, y sobre el que vamos a aplicar un control.

Los tipos de elementos de configuración afectan a todos los componentes del sistema de información, es decir:

• Componentes de hardware, por ejemplo, servidores, puestos de trabajo, unidades de disco, periféricos, etc.
• Componentes de software, por ejemplo, sistemas operativos, controladores de periféricos o de hardware, herramientas de supervisión, planificadores, herramientas de copia de seguridad, etc.
• Componentes de software de aplicaciones, por ejemplo, desarrollos específicos, ERP, etc.
• Bases de datos, por ejemplo, bases, archivos de configuración, etc.
• Flujo de datos técnicos o aplicativos.
• Equipamientos de red y telecomunicaciones, por ejemplo, rúters, puestos, teléfonos (puestos y auto conmutadores), vídeoconferencia, etc.
• Componentes de infraestructura del entorno, por ejemplo, lugares, energía e inversores, aires acondicionados, armarios y racks, etc.
• Servicios, por ejemplo, funcionalidades de los servicios, contratos de servicio (SLA, OLA, UC), etc.
• Documentación, por ejemplo, funcional, técnica, de explotación, de mantenimiento y los diarios, etc.
• Elementos del ciclo de vida, como el esquema director, los planes de urbanismo, las restricciones de arquitectura, las directivas de pruebas y las directivas de validación.
• Elementos de la explotación, como los procedimientos y las consignas de explotación y supervisión.
• etc.

Esta lista no es exhaustiva. En determinadas implementaciones, incluso se va a hacer referencia a los recursos, usuarios, entidades internas o externas (proveedores) o los procesos de negocio, como elementos de configuración.

Estos elementos de configuración se identifican, modelizan por tipo, lo que llamamos clase de CI, o CI genérico o modelo de configuración.

Las clases de elementos de configuración se van a instanciar y poblar de información correspondiente a cada elemento existente en el sistema de información. Cada servidor, cada puesto de trabajo, etc., se convierte en un CI con su propia información. Rápidamente por supuesto, se puede alcanzar un gran volumen de CI (centenares de miles para sistemas de información importantes).

b. Los atributos de un elemento de configuración

Los atributos de un CI son el conjunto de información que va a describir el elemento y su comportamiento, durante su ciclo de vida. Se trata de sus características técnicas, financieras, administrativas, etc. Los atributos son estáticos (fecha de compra) o dinámicos, es decir, que pueden evolucionar siguiendo el ciclo de vida del elemento (depreciación y amortización, por ejemplo).

A continuación se muestra como ejemplo una lista no exhaustiva de los atributos de un CI "puesto de trabajo":

• Nombre
• Número de serie
• Categoría, tipo, modelo
• Localización, responsable
• Constructor, vendedor
• Fechas de entrega, instalación y puesta en marca
• Estado (ver la sección siguiente)
• Precio, coste, amortización, depreciación
• Relaciones (ver la sección siguiente)
• Dependencias con el resto de base de datos (incidentes, problemas, cambios, etc.)

c. El estado de un elemento de configuración

El estado de un elemento de configuración (status en inglés), representa su avance en su ciclo de vida y su explotabilidad, es decir, para un CI de tipo elemento de hardware: solicitado, entregado, en stock, configurado, instalado, puesta en servicio, en fallo, descartado, etc. El estado va a vivir bajo el efecto de las acciones del resto de procesos.

d. Las relaciones

Las relaciones sirven para identificar las relaciones que existen entre los diferentes elementos de configuración (CI), indicando su naturaleza. Es realmente la mayor ganancia que van a aportar la CMDB y la CMS al resto de procesos que piden datos a estas bases. Con estas relaciones, el solicitante (el proceso solicitante) obtiene a partir de un elemento de configuración, la información del resto de elementos de configuración a los que está relacionado: según el perfil del solicitante (naturaleza del proceso, o cualificación de la persona, técnica, administrativa, etc.), obtendrá toda o una parte de esta información.

A continuación se muestran algunos ejemplos de relaciones:

• Situación: se sitúa a…, está en el paso x, está en el rack n° x, etc.
• Relación física de tipo padre-hijo: está relacionado con tal servidor, es periférico de x, está conectado a tal rúter, etc.
• Relación funcional: está compuesto de, funciona en el entorno x, actualiza el componente x…

e. El modelo de configuración

Cada tipo de elemento de configuración se va a modelizar, es decir, se va a definir y estructurar. Cada elemento del mismo tipo se va a describir con el mismo tipo de información, los mismos tipos de atributos y los mismos tipos de relaciones. Por ejemplo, como modelo de configuración tendremos un servidor, un puesto de trabajo, un módulo software o una aplicación.

Un modelo de configuración permite consolidar el análisis de impacto que podrá implicar el proceso de gestión de cambios, para evaluar los impactos de un cambio. Por otro lado, el modelo de configuración va a permitir también optimizar la utilización de los activos y de los costes asociados.

Los modelos de configuración consolidados, darán una modelización del sistema de información.

A continuación se muestra un ejemplo de los modelos de configuración de un sistema de información modelizado:

f. La CMDB

La CMDB (Configuration Management DataBase en inglés), la base de datos de las configuraciones, hace referencia a la base de datos y la herramienta de gestión asociada. Los registros de la CMDB son los elementos de configuración (CI). La CMDB es la declinación de la modelización anterior en una herramienta de base de datos.

Muchas organizaciones ya utilizan determinados elementos de la gestión de los activos de servicio y de la configuración, normalmente a través de tableros o bases de datos locales o de herramientas de gestión del parque de datos. En las infraestructuras informáticas complejas y extendidas, el uso de herramientas de CMDB automatizadas, se convierte en indispensable (actualización de la información sobre los CI automáticamente a través de las herramientas de delivery). 

g. La CMS

La CMS (en inglés, Configuration Management System, sistema de gestión de la configuración), es un sistema que contiene el conjunto de información relativa a los elementos de configuración, en el perímetro definido.

Por ejemplo, un elemento de configuración de tipo CI "servicio" va a contener los detalles del proveedor, el coste de compra, la fecha de renovación, el contrato de mantenimiento y la documentación relativa al contrato de sub-contratación. La CMS va a mantener las relaciones entre los componentes de tipo servicio y los incidentes, problemas, errores conocidos, cambios y entradas en producción asociados.

La CMS es un conjunto de herramientas y bases de datos que permiten gestionar los datos de configuración. La CMS toma los datos que proviene de varios CMDB para formar una CMDB compartidos.

Un ejemplo de CMDB múltiple: cuando un determinado número de elementos se gestionan de manera externa y de manera interna, cada uno utiliza una CMDB. Si queremos que el centro de servicios acceda a la información de cada una de las CMDB sin preocuparse de saber si los CI se gestionan de manera interna o externa, va a acceder a esta información a través de la CMS.

4. Las tareas de la práctica

Las principales tareas de la práctica Gestión de las configuraciones, son las siguientes:

• Identificar, controlar y guardar los activos de servicio y los elementos de configuración (CI, Configuration Item).
• Editar los informes del estado de los activos de servicios y de los elementos de configuración.
• Auditar y verificar los activos de servicio y los elementos de configuración.
• Proteger la integridad de los activos de servicio y de los elementos de configuración.

Globalmente, la práctica Gestión de las configuraciones garantiza la integridad de los bienes y de las configuraciones, administrando un sistema de gestión de configuración (CMS).

5. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de las configuraciones de servicios, es el siguiente:

Planificar: la actividad de planificación utiliza el CMS para planificar los cambios.

Optimizar: la gestión de las configuraciones tiene una visión de los componentes (los CI) que son susceptibles de mejorar.

Compromiso: la gestión de las configuraciones tiene una visión de los componentes (los CI) que son susceptibles de mejorar.

Diseñar y Transformar: la CMS, con las relaciones entre los diferentes componentes, permite tener una visión clara para diseñar los nuevos servicios o cambios sobre los servicios existentes.

Obtener y Construir: la CMS debe estar absolutamente actualizado durante esta actividad de construcción.

Suministrar y Dar soporte: la CMS es indispensable en las actividades de soporte, en particular para la gestión de incidentes y problemas.

Gestión de la continuidad de servicios

1. Objetivo de la práctica

Esta práctica se basa en el proceso Gestión de la continuidad de servicios informáticos, descrita en las buenas prácticas ITIL V3.

La práctica Gestión de la continuidad de servicios tiene como objetivo apoyar a las actividades globales de la empresa y de las ramas del negocio, garantizando que los servicios informáticos tendrán un nivel de rendimiento y de calidad suficiente en caso de catástrofe, y que se restablecerán en los plazos necesarios y convenidos. En otros términos, como consecuencia de una catástrofe que genera una interrupción de la actividad, este proceso va a permitir cubrir un funcionamiento predeterminado. Este modo de funcionamiento predeterminado puede ser en modo degradado y seguidamente, en modo normal.

Esta práctica va a permitir reducir los efectos y el impacto de la catástrofe en la empresa, por supuesto restableciendo en los plazos definidos el o los servicios que se vieron impactados, pero también intentando conservar la confianza de los clientes y de los usuarios en su informática.

Es importante entender bien que esta práctica no tiene la intención de prevenir desastres, sino que reducir los efectos y consecuencias de esta desastre.

La práctica Gestión de la continuidad de servicios contribuye al proceso global de gestión de la continuidad de la empresa. De esta manera, garantiza que el plan de continuidad de los servicios informáticos está adecuado con el global de la empresa. Muy habitualmente, vemos que la informática construye planes de seguridad sin que la empresa o las unidades de negocio estén implicados, y sin que la empresa en sí misma haya reflexionado sobre esta noción de continuidad del servicio.

Un plan de Gestión de la continuidad de servicios es una garantía de credibilidad frente a los usuarios y los clientes de la informática.

2. La terminología de la práctica

a. Una amenaza

Una amenaza es una acción, una situación o un hecho que puede poner en riesgo el buen funcionamiento de un activo de servicio o de un conjunto de activos de servicio. Las amenazas se registran y clasifican:

• catástrofe natural (incendio, inundación, terremoto de tierra, etc.)
• terrorismo
• ataque vírico
• conflicto social
• ruptura de la cadena de aprovisionamiento
• epidemia
• etc.

b. La vulnerabilidad

La vulnerabilidad es la probabilidad de que la amenaza se produzca en el activo o los activos implicados. La vulnerabilidad es un porcentaje que se asocia a cada activo de servicio. Por supuesto, es lo más complicado que hay de identificar. En cualquier caso, la vulnerabilidad de un activo evoluciona con el tiempo. Esto no es un valor fijo. Un ejemplo del ciclo de vida diario, sobre la noción de vulnerabilidad, es el nivel del plan NNA: todas las semanas o todos los meses, el Ministerio de Interior evalúa el nivel NNA (de 1 a 4). Se trata de la vulnerabilidad de determinados sitios (estaciones, aeropuertos, etc.).

c. Un riesgo

El riesgo es el análisis de esta situación (activo, amenaza y vulnerabilidad) para entender los efectos, las consecuencias.

d. RTO "Recovery Time Objective"

Este acrónimo inglés normalmente se utiliza tal cual y no se traduce en castellano. La RTO es la duración máxima aceptable de no disponibilidad de un servicio, antes de que la empresa se vea seriamente impactada. En otros términos, la RTO es el compromiso que va a tomar la informática para restablecer el servicio en caso de catástrofe.

e. RPO "Recovery Point Objective"

El RPO, acrónimo en inglés, es el punto de retorno de los datos en caso de no disponibilidad de un servicio. Es el compromiso de la informática para restaurar los datos tal y como estaban en un determinado momento.

f. El análisis de impacto en el negocio

El análisis de impacto en el negocio (en inglés BIA: Business Impact Analysis), es el documento que va a identificar los impactos y efectos de las catástrofes en la empresa. Se van a resaltar las actividades indispensables de la empresa y de las ramas de negocio. Es muy importante centrarse únicamente en las actividades que son vitales para el negocio. Vamos a hablar de funciones vitales para la empresa (en inglés VBF, Vital Business Function). Para hacerlo sencillo, se debe hacer la siguiente pregunta: si en la empresa vamos a conservar una sola actividad, ¿cuál deberíamos conservar? Todo no es vital. Un determinado número de actividades se pueden retrasar en el tiempo.

La BIA va a resaltar las obligaciones y restricciones legales en términos de continuidad de las ramas del negocio y del sector de la empresa.

g. La gestión de la continuidad del negocio

La gestión de la continuidad negocio (en inglés BCM, Business Continuity Management), es el enfoque que se ha definido para que el negocio pueda funcionar incluso si una catástrofe sucede o si se produce una amenaza. La gestión de la continuidad del negocio se basa en el documento BIA.

h. El plan de seguridad

Un plan de seguridad (en inglés disaster recovery plan), es un documento que describe la manera en la que se van a restablecer los servicios informáticos después de una catástrofe. Se identifica los criterios de desencadenamiento y la cronología del restablecimiento. También se llama plan de seguridad, un plan de continuidad de las actividades informáticas (PCA) o un plan de recuperación de las actividades informáticas (PRA). En un PCA, no se acepta la interrupción de las actividades, pero en un PRA se acepta un plazo de restablecimiento que se precisa en este plan.

Normalmente, va a ser necesario un plan de seguridad para poner en marcha uno o varios sitios de seguridad (en inglés, de back-up). Un sitio de seguridad debería tener isoconformidad con el sitio principal del que sirve de respaldo, sobre un perímetro funcional idéntico, por supuesto.

Un plan de seguridad debería contener como mínimo la siguiente información:

• El perímetro del plan, es decir la lista de los servicios informáticos afectados.
• Los criterios de desencadenamiento.
• La lista de las personas autorizadas a desencadenar el plan, con su información de contacto (número de teléfono, dirección e-mail, etc.): las buenas prácticas ITIL mencionan que estas personas deben ser los dirigentes responsables operativos.
• Los plazos de restablecimiento de los diferentes servicios informáticos.
• El cronograma de este restablecimiento.
• Las funcionalidades del modo degradado (si es necesario).
• Las condiciones de retorno a la normalidad.

3. Relaciones entre la gestión de la continuidad  de servicios y la gestión de incidentes

Normalmente, la gestión de la continuidad de servicios se encarga únicamente de gestionar las situaciones relacionadas con una catástrofe. La gestión de incidentes se encarga del resto de situaciones de interrupción no programadas de servicios. Para esto, es necesario definir a priori las situaciones de catástrofe, para poder desencadenar la gestión de la continuidad en el momento adecuado. Observamos que muchas empresas, para evitar recubrir actividades o las zonas no cubiertas, nombran a los mismos actores que para la gestión de la continuidad y la gestión de incidentes principales.

4. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de la continuidad de servicios, es el siguiente:

Planificar: esta práctica va a aportar la información de las funciones vitales y los riesgos y amenazas potenciales.

Optimizar: esta práctica garantiza que las oportunidades de mejora tengan en cuenta los planes de seguridad.

Compromiso: esta práctica debe informar a las partes integrantes, de los riesgos en los que se incurre y de la necesidad de tomar garantía en consecuencia.

Diseñar y Transformar: la práctica Gestión de la continuidad informática debe garantizar que todas las transformaciones, tienen en cuenta el plan de seguridad.

Obtener y Construir: la práctica Gestión de la continuidad informática debe garantizar que todos los componentes y productos, tienen en cuenta el plan de seguridad.

Suministrar y Dar soporte: el plan de seguridad se debe desarrollar en caso de catástrofe.

Diseño de los servicios

1. Objetivo de la práctica

Esta práctica se refiere a un proceso del enfoque ITIL V3 2011, la coordinación del diseño de servicios.

La misión de esta práctica Diseño de los servicios, es coordinar todas las actividades, todas las prácticas, todos los procesos y todos los recursos para diseñar servicios para los clientes y los usuarios.

Tiene como objetivo garantizar la eficacia, incluso la eficiencia, de los nuevos servicios y de las modificaciones que hay que añadir a los servicios existentes, verificar que las arquitecturas del sistema de información son adecuadas a la política de arquitectura definida y garantizar que los procedimientos y procesos se despliegan de manera coherente.

El diseño de los servicios va a garantizar que los nuevos servicios responden a un determinado número de criterios. Deberá plantear las siguientes preguntas:

• ¿El servicio está orientado al negocio?
• ¿Es rentable?
• ¿Es flexible y mantenible?
• ¿Puede absorber un pico de carga en términos de volumen de información o de transacciones?
• ¿El servicio podrá continuar existiendo si la empresa se reorganiza?
• ¿La explotación del servicio puede provocar riesgos en las unidades de negocio?
• Etc.

2. El mapa de calor de la práctica

El mapa de calor de la práctica Diseño de los servicios, es el siguiente:

Planificar: esta práctica, como coordina los recursos, se presenta en la actividad de planificación.

Optimizar: esta práctica es una fuente de propuestas para las mejoras.

Compromiso: esta práctica aporta la vista de cliente y usuario, para hacer los servicios más eficaces y eficientes.

Diseñar y Transformar: el objetivo de esta práctica es diseñar los servicios.

Obtener y Construir: esta práctica es parte integrante en la opción de los componentes y productos.

Suministrar y Dar soporte: esta práctica interviene en la gestión de soporte de los servicios, para que sea lo más eficaz y eficiente posible.

Centro de servicios

1. Preámbulo

El centro de servicios se ha convertido en una práctica en el enfoque ITIL 4. Inicialmente, en la versión V3 de ITIL, el centro de servicios era una función. Una función que es una entidad operativa con sus propios recursos y medios, lo que planteaba muchas preguntas, ya que teníamos dificultades para posicionar el centro de servicios y los procesos Gestión de incidentes y Ejecución de las consultas. En ITIL 4 es mucho más simple, ya que se convierte en una práctica encargada de la relación con los usuarios.

2. Objetivo de la práctica

La práctica Centro de servicios, en inglés service desk, es el punto de contacto único entre los usuarios y el departamento informático. Es portador de toda la relación con los usuarios. Esta relación es bidireccional: los usuarios llaman al centro de servicios para comunicarse con el departamento informático y cuando este quiere enviar mensajes de información a los usuarios, llama al centro de servicios. El centro de servicios es responsable de la información de los usuarios a diario.

El centro de servicios es lo que los ingleses llaman un SPOC (Single Point Of Contact), punto de contacto único desde el punto de vista de los usuarios. Esto no quiere decir que sea único, sino que un usuario solo tendrá enfrente a un único centro de servicios.

La misión del centro de servicios es servir a los usuarios y satisfacerlos: la noción de satisfacción de los usuarios es un poco diferente de la noción de satisfacción de cliente (ver la práctica Gestión de los niveles de servicio). El centro de servicios es responsable de que los usuarios tengan una buena imagen del departamento informático. Es el escaparate del departamento informático, es decir, la parte visible del iceberg.

Esta misión va a permitir alcanzar los dos objetivos principales siguientes:

• Responder a las preguntas y peticiones de los usuarios en los plazos definidos y que se fijan en los contratos.
• Restaurar el servicio a un estado normal, estándar, lo más rápidamente posible en los plazos definidos y fijados en los contratos.

Para realizar estos objetivos, el centro de servicios garantiza las actividades de soporte de nivel 1 (investigación y diagnóstico inicial) y gestiona los procesos de escalado de problemas con los grupos de soporte de nivel 2 o de nivel 3. Es el punto de coordinación de los grupos de soporte para responder a una petición de usuario.

3. Los desafíos de la práctica

La informática es vital para todas las empresas. Por lo tanto, el soporte a los usuarios también es muy importante. El nivel de calidad de soporte aportado a los usuarios, es crucial. Cuando los usuarios se bloquean por un error informático o no se les informa del avance de la solución de los problemas o no saben cuándo se van a restablecer los servicios, todo esto proporciona a los usuarios motivos para estar descontentos con la informática. No pueden seguir trabajando, por lo tanto, la producción para la empresa se detiene o se degrada. Las respuestas rápidas y comprensibles del centro de servicio al usuario brindan inmediatamente ganancias significativas de productividad.

Por otro lado, el hecho de poner en marcha un centro de servicios va a provocar una centralización de la información relativa a las llamadas de los usuarios. De esta manera, el centro de servicios es una función primordial para el departamento informático, ya que aporta la visión de los usuarios. Es importante entender cómo los usuarios utilizan los servicios y qué dificultades encuentran.

El centro de servicios tiene un rol proactivo importante para hacer llegar esta información a los grupos de estudio y desarrollo.

4. Las tareas de la práctica

Las tareas de la práctica del centro de servicios son:

• El soporte de la llamada del usuario: esta actividad consiste en la recepción de la llamada telefónica o del mensaje electrónico del usuario. Se abre un ticket de llamada en la herramienta de gestión del centro de servicios. Se puede ofrecer la posibilidad a los usuarios de abrir ellos mismos su ticket de llamada en la herramienta de gestión de tickets.
• El registro de la información relacionada con la llamada del usuario: se trata de anotar en el ticket de llamada, su nombre o más exactamente, su identidad (nombre, apellidos, número de registro, etc.), un número de contrato (si procede) y el objeto de la solicitud.
• La categorización: esta actividad va a permitir clasificar las llamadas por tipos: incidentes o consultas llamadas petición de servicios (la definición de estos términos se proporciona en este capítulo de las secciones relativas al proceso de gestión de incidentes y al proceso de ejecución de las consultas).
• La codificación: es la actividad que va a evaluar la prioridad asociada a la solicitud y deducir el plazo contractual para responder a esta llamada.
• La investigación y el diagnóstico, donde el centro de servicios tiene un valor añadido real intentando entender el problema del usuario. Es el primer nivel de soporte.
• La respuesta al usuario, que depende de la petición: si esta solicitud es un incidente, la respuesta es la restauración del servicio, si esta solicitud es una consulta, el centro de servicios va a ejecutar esta consulta.
• La gestión del escalado a los grupos de soporte de nivel 2 y de nivel 3, si es necesario.
• El seguimiento de la llamada, es decir, la información al usuario del avance de su solicitud.
• El cierre de todas las llamadas, incluso si han sido "escaladas" a los grupos de soporte. Se debe obligatoriamente advertir al centro de servicios de los trabajos de los grupos de soporte en modo escalado, para poder informar al usuario del avance de su solicitud y poder cerrarla de manera administrativa.
• La gestión de encuestas de satisfacción del usuario: el centro de servicio debe garantizar la satisfacción del usuario a diario.
• La actualización de las bases de conocimiento: esta actividad consiste en la actualización, en particular de la base de datos que mantiene la información sobre la infraestructura (CMS, Configuration Management System). En efecto, hablando con el usuario o tomando el control de su puesto de manera remota, el centro de servicios se puede dar cuenta de que la información en esta base de datos no está actualizada.

5. La configuración del centro de servicios

La configuración, el tamaño y la arquitectura de un centro de servicios, son las actividades cruciales para su éxito. Es el escaparate de la informática y no puede fallar en su implementación y en su rendimiento. Se debe definir todo en primer lugar, el perímetro (funcionalidades, horarios, etc.), la tipología de las llamadas que se van a recibir, así como los periodos de carga y los periodos de menor actividad, para deducir la cantidad y los tipos de recursos (las personas que van a trabajar en el centro de servicios, los hotliners) y los medios (las herramientas) necesarias. La arquitectura de la implementación incluso del centro de servicios, también es importante. Las buenas prácticas ITIL 4 ofrecen tipos de arquitectura, cada una con sus ventajas y sus inconvenientes.

a. El centro de servicios local

El centro de servicios local o de proximidad es un centro de servicios, que se implanta en el mismo sitio que los usuarios a los que sirve. Esta arquitectura normalmente es un mostrador, un despacho donde los usuarios pueden acudir a plantear sus peticiones o quejas.

b. El centro de servicios centralizado

En la hipótesis de una empresa implantada en varios lugares, el centro de servicios centralizado puede ser una respuesta para la elección de su implementación. Un centro de servicios centralizado está ubicado en un sitio único, en el que se accederá a través de los canales de telecomunicaciones de tipo teléfono, portátil, internet, e-mail, chat, etc.

c. El centro de servicios virtual

Un centro de servicios virtual es un centro de servicios centralizado, que va a relacionar directamente al usuario que llama con la persona del centro de servicios que está disponible y que tiene el mejor perfil para responder a su petición. Es decir, que en función de la hora (por ejemplo horas de oficina, mañana o noche), del país o del lugar de llamada (España o un país extranjero, sitio administrativo o sitio de producción, etc.), del negocio, del perfil del usuario que llama, se va a derivar la llamada a un hotliner adaptado al contexto y al negocio del solicitante. A continuación, se muestran algunos ejemplos:

• En horas de noche, se deriva la llamada al centro de guardia.
• Para una llamada que proviene de Inglaterra, se mandará la llamada a una persona que hable inglés.
• Para una llamada que viene de la entidad contabilidad, va a responder un hotliner con conocimientos de las aplicaciones financieras.
• Cuando un director llama, automáticamente se redirige al centro encargado de gestionar los VIP de la empresa.

6. Las herramientas del centro de servicios

La práctica centro de servicios se debe basar en herramientas y la elección de las herramientas va a tener influencia en su eficacia y eficiencia. En primer lugar, va a ser necesario identificar los canales que se van a elegir para contactar con el centro de servicios: el teléfono por supuesto (con una extensión interna), pero también la dirección de correo (genérica), el SMS, un portal de intranet, internet, un chat, etc.

Esta selección de los canales determina la elección de las herramientas. A continuación, se muestra una lista de posibles herramientas:

• Distribuidor automático de llamadas (ACD, Automatic Call Distributor): distribuye las llamadas telefónicas a los hotliners, en función de la carga y de la proveniencia de la llamada.
• El servidor de voz interactivo (IVR, Interactive Voice Response): va a permitir una precalificación de la llamada haciendo preguntas ("marque 1 si llama para una petición, 2 para un incidente, etc."), para compensar los recursos limitados (fin de semana, noche, etc.) y gestionar situaciones de saturación de llamadas.
• Integración de telefonía informática (CTI, Computer Telephony Integration): la ficha del cliente se muestra al mismo tiempo que el hotliner atiende la llamada telefónica.
• El software de relación con el usuario (CRM, Customer Relationship Management): gestionará los tickets de llamada, ayudará a introducir esos tickets, hará seguimiento de los mismos y acumulará las llamadas anteriores.
• La integración con otras herramientas que soportan el resto de procesos del enfoque ITIL, como el CMS (Configuration Management System), la base de datos de los errores conocidos, etc. y también el enlace con la gestión documental de la empresa, en general, la integración con herramientas de gestión de servicios.

Las herramientas del centro de servicios, puede permitir el establecimiento de un centro de servicios llamado autoservicio, es decir, que permite al usuario, sin intervención humana, registrar él mismo su llamada (su petición, su incidente) y hacer seguimiento. La integración con las bases de conocimiento, también pueden permitir al usuario tener acceso y encontrar directamente las respuestas a sus preguntas.

7. El mapa de calor de la práctica

El mapa de calor de la práctica Centro de servicios, es el siguiente:

Planificar: el centro de servicios siempre está activo. Por lo que no hay actividad de planificación.

Optimizar: el centro de servicios se evalúa permanentemente por una serie de indicadores que controlan la calidad de su trabajo. La mejora del centro de servicios debe ser continua.

Compromiso: el centro de servicio es responsable del compromiso de la dirección informática delante de los usuarios.

Diseñar y Transformar: el centro de servicios debe estar presente en las decisiones de diseño y transformación.

Obtener y Construir: el centro de servicios también debe estar presente en la elección de los componentes y de los productos.

Suministrar y Dar soporte: el centro de servicios es el punto central de la interfaz de usuario.

Gestión de niveles de servicio

1. Objetivo de la práctica

Esta práctica se basa en el proceso Gestión de niveles de servicio, definido en el enfoque ITIL V3 y V2.

La práctica de gestión de los niveles de servicio ostenta toda la relación con las ramas de negocio, es decir, los clientes. Es responsable. Esta práctica escucha las necesidades del cliente, las tiene en cuenta y las implementa. Garantiza su satisfacción y aporta la llamada visión de servicios de "extremo a extremo".

Esta práctica se basará en las nociones de "utilidad" y de "garantía" para garantizar que los servicios proporcionan el valor esperado. ¿Los servicios proporcionados responden a las funcionalidades solicitadas? ¿Los servicios actuales que se proporcionan a los clientes, tienen de manera continua el nivel de calidad de servicio convenido? Por otro lado, ¿los servicios que se están realizando en la actualidad, tienen objetivos realistas y alcanzables, adecuados con los definidos por el cliente?

Los objetivos principales de la práctica Gestión de niveles de servicio son:

• Implementar los mecanismos de relación con los clientes.
• Desarrollar y mejorar esta relación con los clientes para obtener su confianza.
• Obtener y conservar la satisfacción de los clientes.
• Asegurarse de que el cliente y el departamento informático tienen la misma comprensión de los niveles de calidad de servicio esperados.
• Definir y documentar los compromisos de niveles de servicio en los contratos.
• Hacer validar los contratos de compromiso por los clientes y el departamento informático.
• Asegurar que los servicios proporcionados tienen el nivel de servicio convenido.
• Ser responsable de las acciones proactivas para la mejora de los servicios proporcionados a los clientes.

2. La terminología de la práctica

a. Nivel de servicio

El nivel de servicio se forma por uno o varios indicadores que van a permitir medir la calidad del servicio proporcionado. El o los indicadores tienen dos valores: el objetivo de compromiso y el valor real medido. En España, normalmente llamamos a este término de nivel de servicio, la calidad del servicio.

b. SLA: Service Level Agreement

Este acrónimo está muy extendido en España, usando esta terminología inglesa. La traducción en castellano es "acuerdo sobre el o los servicios ofrecidos y sobre los niveles de servicio asociados". Este acuerdo es el resultado de una negociación entre el cliente y el proveedor de los servicios informáticos, basado en el SLR (Service Level Requirement en inglés, la expresión de las necesidades). Este acuerdo se describe en un documento contractual que vamos a llamar contrato de servicio o convención de servicio. Este documento va a definir el o los servicios propuestos y los destinos de niveles de servicio a alcanzar. Un SLA cubre uno o varios servicios y está unido a uno o varios clientes. Se debe validar y firmar por las dos partes (cliente y proveedor). Se trata de un compromiso de resultado sobre el grado de consecución de objetivos para los servicios.

3. Las características de un SLA

Para elaborar un SLA, las buenas prácticas ITIL 4 recomiendan de plantear a los clientes preguntas sencillas abiertas. Se presenta a continuación algunos ejemplos:

• ¿Cuál es su misión?
• ¿Cómo la tecnología le puede ayudar en su trabajo?
• ¿Cuáles son los actores clave de su negocio?
• ¿Cuáles son las actividades más importantes para usted?
• ¿Hay horas o días más importantes para su negocio?
• ¿Cuál es la diferencia entre una buena jornada o una mala jornada de trabajo?
• ¿Cuáles son sus objetivos anuales y cómo se va a medir estos objetivos?
• ¿En qué se traduce el éxito en su negocio?
• ¿Según usted, es necesario evaluar la calidad de un servicio?
• ¿Cómo podemos ayudarle más?

Las respuestas a estas preguntas van a permitir elaborar el SLA.

El documento SLA debe contener la siguiente información (esta lista es no exhaustiva): 

• La descripción del servicio en términos de funcionalidades (o un puntero a la información que describen el servicio en el catálogo de servicios).
• Las horas de apertura del servicio (horas, días, periodos del año).
• La tasa de disponibilidad en un periodo dado.
• La duración máxima de no disponibilidad.
• El tiempo de respuesta a una petición de cambio.
• El número máximo de cambios sobre un periodo dado.
• Las modalidades de las entradas en producción y en particular, de las franjas horarios, días y periodos asignados a la entrada en producción.
• Las modalidades de soporte y en particular las horas de apertura del centro de servicios.
• Los niveles de seguridad de los datos (confidencialidad, integridad, disponibilidad, incluso autentificación y no-repudio).
• El rendimiento del servicio de extremo a extremo.
• Los términos del plan de continuidad informática o un puntero a este plan.
• Los periodos críticos del servicio y las implicaciones sobre los compromisos.
• Los costes o los precios asociados a la producción del servicio (eventualmente en jornadas de trabajo).
• Los indicadores asociados a todos estos datos que van a mostrar realmente si los compromisos se respetan. Con estos indicadores, se precisan las condiciones de medición, las fórmulas de cálculo, el tipo de las herramientas de medición, etc.
• Las modalidades de reporting: los cuadros de mando con los ejemplos, la difusión (cadencia y lista de difusión).
• Las modalidades del seguimiento: se identifican las instancias, su frecuencia, sus roles, su misión y los participantes de las dos partes.
• Las penalizaciones por no respetar los compromisos de la parte del proveedor del servicio. Por supuesto, en el caso de una relación entre el cliente interno y el departamento informático de una misma empresa, normalmente es muy difícil aplicar penalizaciones.
• Los deberes del cliente: como mínimo, la obligación de participar en las diferentes instancias y formalizar sus obligaciones, en materia de servicios.
• La lista de los contactos significativos para las dos partes.
• Los procedimientos de escalado en caso de reclamación o queja.
• La fecha de inicio del contrato.
• La duración del contrato.

4. La satisfacción del cliente

La práctica Gestión de niveles de servicios debe medir la satisfacción de los clientes. Para esto, es necesario recoger cierta información. ITIL 4 recomienda como mínimo dos fuentes de información: la encuesta de satisfacción y de los indicadores de negocio.

a. La encuesta de satisfacción

Puede tener dos formas:

• La encuesta en caliente: se trata de obtener un feedback de información inmediato, después de una situación (la resolución de un incidente por ejemplo); por lo tanto, se hace al cliente algunas preguntas sencillas y cerradas, pocas, normalmente con una respuesta en forma de escala de valores (de Muy bien a Muy mal, pasando por Bien o Normal). Se obtiene una impresión en caliente.
• La encuesta en frío: se trata de un cuestionario más completo, preferentemente también con preguntas sencillas cerradas, pero que no estén correlacionadas con eventos particulares. La encuesta se puede llevar a cabo todos los años, por ejemplo. Se obtiene una sensación más global.

Los dos tipos de encuestas son interesantes para medir la satisfacción de los clientes.

b. Los indicadores de negocio

En el SLA, se pueden identificar los indicadores clave que van a reflejar la satisfacción del cliente. Por ejemplo, esto puede estar relacionado con un tipo de transacción particular que es clave para el negocio del cliente. No se trata de tomar todos los indicadores o de observar el nivel del servicio, sino de centrarse en un número reducido de indicadores importantes para el negocio.

c. El síndrome de la sandía

El enfoque ITIL 4 resalta una situación frecuente estos últimos años en las empresas que han puesto en marcha las buenas prácticas ITIL y más particularmente, la gestión de los niveles de servicio con un indicador de calidad de servicio en el SLA. Se trata del síndrome de la sandía (en inglés the watermelon SLA effect).

Una sandía está verde en el exterior y roja en el interior y normalmente, tiene muchas de pepitas.

Esto refleja muchas situaciones en las que el indicador de calidad de servicio que se muestra a la dirección, normalmente está verde, por lo tanto todo va a bien, la calidad de los servicios proporcionados es buena y se corresponde con los compromisos alcanzados y las expectativas del cliente. Por ejemplo, la tasa de disponibilidad del servicio en el mes pasado fue del 99,5% con un compromiso del 98%. Por el contrario, cuando se mira más cerca, se produjo un incidente en el peor momento (durante un periodo crítico para el negocio). Incluso si la informática pudo resolver rápidamente el incidente (en los plazos pactados), el perjuicio pudo ser importante. Por lo tanto, tenemos una situación en la que el cliente está muy descontento, rojo por dentro, pero con el indicador verde por fuera.

5. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de los niveles de servicio, es el siguiente:

Planificar: esta práctica proporciona toda la información del nivel de calidad del servicio a la planificación de los productos y de los servicios, para formar el porfolio de productos y servicios.

Optimizar: esta práctica aporta el retorno de los clientes, su satisfacción y su impresión de los servicios proporcionados, lo que permitirá elaborar proposiciones de mejora.

Compromiso: la gestión de los niveles de servicio lleva la actividad de compromiso frente a los clientes.

Diseñar y Transformar: la gestión de los niveles de servicio aporta la visión de los clientes sobre los cambios que hay que añadir a los servicios.

Obtener y Construir: la gestión de los niveles de servicio aporta la información del rendimiento y la calidad de los componentes, de los productos y de los servicios.

Suministrar y Dar soporte: esta práctica recoge la información sobre la calidad del servicio.

Gestión de las peticiones de servicio

1. Objetivo de la práctica

Esta práctica retoma la misión de los procesos Ejecución de las consultas y Gestión de accesos, del enfoque ITIL V3.

La práctica Gestión de las peticiones de servicio tiene por misión responder a todas las solicitudes de los usuarios, que se han definido inicialmente y esto, de la manera más sencilla posible.

De hecho, esta práctica tiene cuatro objetivos muy visibles en la empresa, ya que todos están orientados a la relación con los usuarios:

• proporcionar un canal privilegiado con los usuarios, para enviar y tratar sus peticiones a la informática,
• proporcionar la asistencia frente a los usuarios sobre la utilización de los servicios,
• realizar aprovisionamientos de los componentes estándares de los servicios, siguiendo las peticiones de los usuarios,
• proporcionar un canal para hacer llegar las quejas de los usuarios a la dirección informática.

2. La terminología de la práctica

a. La demanda de servicio

La demanda de servicio, en inglés request, es una petición de un usuario en un marco predefinido (catálogo de las peticiones de usuario). Esta solicitud de servicio afectará a la asistencia, asesoramiento, información, un cambio estándar sencillo, un aprovisionamiento de consumibles, un acceso a un servicio, incluso una queja. De hecho, detrás de la palabra solicitud de servicio, abarcaremos cualquier solicitud de usuario que no sea un incidente.

Una demanda de servicio o consulta va a realizar una acción limitada en el tiempo, de bajo riesgo, generalmente tratada por una sola persona y de bajo coste. Esta noción toma todo su sentido si hay una verdadera frecuencia en las solicitudes. Por lo tanto, formaremos un catálogo de peticiones de usuarios (ver más adelante). En muchas empresas, se llaman peticiones de pequeños trabajos.

b. El catálogo de las peticiones de usuario

Este catálogo es la base del correcto funcionamiento de esta práctica. Detalla las peticiones de servicio de los usuarios, con el coste de cada una de ellas (coste o jornada de trabajo) y el plazo de realización. El otro punto importante en este catálogo es el hecho de identificar claramente los perfiles de usuario que tienen permiso para hacer peticiones.

La difusión y la promoción de este catálogo frente a todos los usuarios, es un principal cometido.

3. La automatización de la práctica

El enfoque ITIL 4 recomienda una implementación de esta práctica lo más automatizada posible, para ser lo más eficiente posible. La utilización de un portal, con el catálogo de solicitudes en línea, es un buen ejemplo.

4. El mapa de calor de la práctica

El mapa de calor de la práctica Gestión de las peticiones de servicio, es el siguiente:

Planificar: no se pueden planificar las solicitudes de los usuarios.

Optimizar: esta práctica aporta comentarios de los usuarios, sobre todo a través de reclamaciones y quejas, incluso también de pleitos, para formular propuestas de mejora.

Compromiso: esta práctica aporta comentarios regulares de los usuarios, que permite tomar decisiones de compromiso.

Diseñar y Transformar: esta práctica diseñará las soluciones preautorizadas solicitadas por los usuarios.

Obtener y Construir: esta práctica va a adquirir y construir las soluciones preestablecidas solicitadas por los usuarios.

Suministrar y Dar soporte: por supuesto, esta práctica es clave para la actividad de oferta y de soporte frente a los usuarios.

Validación y pruebas de los servicios

1. Objetivo de la práctica

Esta práctica se basa en el proceso del enfoque ITIL V3 2011 titulado Validación y pruebas.

La práctica Validación y pruebas de los servicios tiene por misión garantizar que todos los cambios (nuevos productos y servicios, modificación de productos o de servicios existentes), están de acuerdo a las obligaciones solicitadas. Estas obligaciones, que representan el valor que va a proporcionar el producto o servicio, se ha elaborado por todas las partes integrantes (los usuarios, clientes, gestor del proyecto, el jefe del proyecto, los equipos de producción y de soporte, etc.).

Esta práctica va a ser la responsable de la buena gestión de los errores o de los funcionamientos incorrectos, que se pudieran descubrir durante las fases de pruebas, integración, preproducción y post entrada en producción.

Por lo tanto, su misión es definir, implementar y desarrollar el conjunto de campañas de pruebas, así como los procedimientos de validación del cambio que queremos poner en producción.

La fase de validación dará lugar a la elaboración de informes tanto funcionales como de rendimiento, explotabilidad, servicio habitual, etc.

2. Los tipos de pruebas

El enfoque ITIL 4 proporciona una lista de los diferentes tipos de pruebas a realizar. Están clasificadas en dos categorías, las pruebas funcionales que cubren "la utilidad" y las pruebas no funcionales que cubren la "garantía o el uso".

a. Las pruebas funcionales

Las pruebas unitarias

Tienen por objeto detectar los defectos de nivel de una unidad de programa durante el desarrollo o de nivel de un componente de infraestructura. Van a aislar el comportamiento de la parte de código o del componente a probar, de cualquier otro factor exterior y verificar que está conforme a lo esperado.

Las pruebas de sistema

Las pruebas de sistema permiten detectar funcionamientos incorrectos en la implementación conjunta de las plataformas de infraestructura y del software básico.

Las pruebas de integración

Las pruebas de integración de componentes permiten detectar funcionamientos incorrectos en la implementación conjunta de varias unidades de programa y/o de varios componentes de infraestructura, probadas de manera unitaria inicialmente.

Las pruebas de no regresión

Su objeto es detectar problemas de regresión introducidos por los efectos secundarios involuntarios, en las partes no modificadas, relacionadas con cambios funcionales o técnicas.

b. Las pruebas no funcionales

Las pruebas de rendimiento y capacidad

Su objeto es medir el rendimiento y los recursos aplicativos o de sistema (capacidad) que permiten detectar defectos introducidos, relacionados con los nuevos cambios.

Las pruebas de seguridad informática

Su objeto es detectar los defectos introducidos, relacionados con el incumplimiento de las características de seguridad definidas por la práctica Gestión de la seguridad informática.

Las pruebas de conformidad

Su objetivo es detectar los defectos introducidos, relacionados con el incumplimiento de las características legales y reglamentarias: por ejemplo en el sector bancario, las leyes sobre el blanqueo de capitales.

Las pruebas de explotabilidad

Su objetivo es detectar los defectos introducidos, relacionados con las copias de seguridad/restauración y procedimientos de explotación (copias de seguridad de contexto sistema y aplicativo, copias de seguridad y restauraciones de datos, limpiezas de datos, historización y archivo, etc.). Se encargan también de verificar el buen funcionamiento del tráfico de red y del establecimiento de los procedimientos de supervisión.

Las pruebas de mantenibilidad y soporte

Su objetivo es detectar los defectos introducidos, relacionados con las modificaciones de los documentos, con los nuevos cursos de formación, etc.

Las pruebas de aceptación de usuario

Su objeto es evaluar la versión observando directamente al usuario, en situación, utilizando el producto en un escenario real de uso con las tareas a realizar. Permite identificar de manera concreta los problemas que existen, las preguntas que se plantea y las funcionalidades que aprecia o no, con el objetivo de generar posibilidades de mejora, incluso de modificaciones.

3. El mapa de calor de la práctica

El mapa de calor de la práctica Validación y pruebas de los servicios, es el siguiente:

Planificar: no hay implicación en la actividad de planificación, ya que es una tarea dentro del resto de prácticas, como la gestión de proyecto.

Optimizar: esta práctica puede devolver propuestas de mejoras a la vista de los resultados de las diferentes pruebas.

Compromiso: esta práctica puede implicar el compromiso de determinadas partes integrantes para la validación de los nuevos servicios.

Diseñar y Transformar: esta práctica es parte integrante en las actividades de diseño y transformación.

Obtener y Construir: esta práctica está muy relacionada con todas las prácticas que intervienen en la actividad de aprovisionamiento y construcción.

Suministrar y Dar soporte: esta práctica es clave para la actividad de oferta y soporte, ya que garantiza un funcionamiento adecuado y es consciente de todos los errores conocidos durante las fases de prueba.