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 obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse 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. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...

Houston, tenemos un problema

¿Qué pasaría si la NASA hubiese externalizado el servicio de soporte a sus misiones Apollo? ¿Cuál podría haber sido la respuesta a la famosa frase ...