Gestión de Servicios TI: Caso Práctico

Se refieren a una compañía (ficticia) dedicada al catering, "Cater Matters", que ha optado por introducir la metodología ITIL para la gestión de sus servicios.

"Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que incluye:

• Servicios de comedor de grandes empresas.
• Servicios de catering para colegios.
• Servicios de catering para eventos (congresos, actos institucionales, ...).
• Servicios de restauración para hoteles.
  La logística del servicio es compleja y los niveles de servicio muy exigentes en lo que respecta a la calidad y los plazos de entrega.
  Para mejorar sus estándares de servicio "Cater Matters" ha implementado un sofisticado sistema informático que le permite gestionar de una manera más ágil y eficiente sus relaciones con los clientes así como sus procesos de producción y distribución.
  La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar la metodología ITIL como la base de todos sus procesos y servicios. Entre las decisiones adoptadas consecuentemente caben destacar:

• Creación de un Service Desk o Centro de Servicios que centralice todas las relaciones con los clientes y el resto de la infraestructura TI.
• Organización de sus actividades en torno a los procesos.
• Designación de responsables o gestores para cada uno de los procesos críticos.
• Establecimiento de estrictos protocolos de monitorización de la calidad del servicio.
  El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio.
  La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el modelo de Kepner y Tregoe:

• Identificación del problema.
• Clasificación del problema.
• Establecimiento de las posibles causas.
• Comprobación de la causa más probable.
• Verificación de la causa verdadera.
  Identificación: En nuestro caso el problema es sencillo de definir:

• La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos, sin que este error parezca tener correlación con otros componentes de hardware / software.
  Clasificación: La clasificación se adaptaría a los siguientes parámetros:

• Identificación: Problemas en el registro de pedidos.
• Origen: Módulo de pedidos online.
• Frecuencia: el problema no es recurrente, es la primera vez que se detecta.
• Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio.
  Posibles causas: Entre las causas más probables figuran:

• Errores en la programación del lado cliente de la aplicación.
• Errores en los módulos de registro del servidor web.
• Errores de configuración de la base de datos.
  Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación.
  Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes:

• Se intenta reproducir el problema.
• Se comprueba que el error sólo se reproduce con una determinada marca de helados.
• Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas.
  Verificación:

• Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción.
• Se introducen las modificaciones necesarias en la programación.
• Se comprueba el correcto registro del pedido.
  El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:

• Elevar una RFC con la solución propuesta.
• Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.