Explicando el chiste

0

Recientemente publiqué el chiste “Cinco gestores se fueron de Safari“. Este chiste lo suelo utilizar para explicar los objetivos de cada gestor y por extensión de cada proceso. Es una manera de ver como se complementan.

Normalmente lo que hago es contar el chiste y luego lo analizo, mostrando por qué cada uno hace lo que hace. Me parece que es una manera muy amena de explicarlo. Así que ya conté el chiste, ahora me toca explicarlo (y que pierda toda la gracia, como cada vez que se explica un chiste).

Gestor de incidencias

Bueno, los gestores tienen un pinchazo. Está claro que estamos delante de una incidencia, ya que el servicio que da el coche ya no es operativo. El gestor de incidencias sale en ese momento corriendo y su único objetivo es restaurar el servicio lo antes posible. No le importa si el apaño durará poco, lo que necesita es resolverlo lo antes posible. Esta claro que el poner un chicle es una exageración, pero demuestra cual debe ser la máxima prioridad cuando tenemos una incidencia: tardar lo mínimo posible.

Esta claro que la solución debe ser mínimamente aceptable y que en el mundo real el chicle no bastaría. Tampoco habría que correr riesgos. Pero bueno, lo que siempre prevalece es restaurar el servicio lo antes posible.

Gestor de problemas

El gestor de problemas no está preocupado con el tiempo en el que se tarde en resolver la incidencia. No es su problema. El sólo debe fijarse en una cosa: que no se repita. Para ello las buenas prácticas le dicen que primero tiene que encontrar una causa raíz (rueda no diseñada para desiertos) y una solución temporal (poner un chicle). Con eso ya tiene un error conocido. Aquí hemos demostrado la diferencia entre problema y error conocido. Además hemos ilustrado el caso en el que la gestión de incidencias proporciona la solución temporal, y el gestor de problemas la confirma. Una vez tenemos un error conocido el gestor de problemas trabaja en elaborar el cambio que solucione la causa raíz por completo (cambiar la rueda) pero no lo hace él, esto queda para la gestión de cambios.

Gestor de cambios

Un cambio nunca se hace a la ligera. Hay que pasar por un CAB o un ECAB para realizarlo. El gestor de cambios no puede decidir, por muy crítica que sea la situación que un cambio debe hacerse. Precisamente su rol principal es asegurar que los cambios se hacen con la seguridad adecuada, lo cual necesita la aprobación. En este caso el gestor está bloqueado porque no contacta con el dueño del todoterreno. Esta claro que esto pone de manifiesto que hacía falta un ECAB que pudiese tomar la decisión de forma urgente (con alguno de los que están en el coche) si no se puede contacar con el CAB.

Gestor de versiones

El gestor de versiones está y debe estar completamente alejado de la operación de servicio. La gestión de versiones pertenece a la fase de transición y si me apuras casi más a la de diseño. El gestor de versiones debe crear la nueva versión y ya la pondrá en producción el gestor de cambios. Así vemos como el gestor de versiones está diseñando nuevos modelos de ruedas, algo totalmente paradójico.

Gestor del nivel de servicio

Y este es quizás el más “zumbado” de los cinco. Primero está dando por saco a los demás gritando tiempos. Debe medir continuamente el nivel de servicio para saber si se cumple. Por otro lado demuestro el problema principal de la gestión de nivel de servicio actual, las compensaciones de SLA ridículas. El gestor soluciona todo el problema pagando un café. Está claro que el impacto que ha tenido la incidencia no se compensa con un café. Pues esto pasa mucha veces cuando por dejarte un día sin correo te bajan un 5% el coste del servicio del siguiente mes.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y Master in Advanced Studies, pero se ha metido de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable de desarrollo y soporte del área de proyectos web e integraciones.

No comments

Te puede interesar...

Priorizando incidencias

Cuando se diseña un proceso de gestión de incidencias, especialmente cuando se combina con el despliegue de una herramienta ITSM, uno de los aspectos más ...