Que yo sepa ITIL no aclara esta cuestión y antes o después suele surgir en el trabajo diario de las organizaciones de soporte. La teoría dice que una incidencia siempre es mucho más urgente que una petición de servicio debido a que estas últimas se suelen relacionar con acciones panificables. Como siempre digo la teoría lo soporta todo, pero en ocasiones la cruda realidad nos dice lo contrario.
Ante una incidencia de máxima prioridad y una petición de servicio también de máxima prioridad, ¿que hay que atender primero? Hace unos días abrí un debate en Linkedin sobre si una solicitud de reseteo de password debería registrarse como una incidencia o como una petición, la respuesta fue unánime: petición. Ahora bien si un usuario necesita que su password sea reseteada, ¿puede esperar a la "cola" de la planificación?
Cierto es que en este caso lo importante no es el concepto sino darle una solución rápida al usuario. Por lo general el flujo de trabajo de las incidencias es el más "ágil" de todos los procesos y esto puede llevar a pensar que en un ejemplo como el anterior lo más aconsejable es saltarse la teoría. Cada organización debe tomar su propia decisión al respecto (adopt & adapt) pero... ¿hay alguna forma de seguir la teoría al pie de la letra sin perjudicar al usuario?
Lo habitual es que los técnicos que se encargan de tratar las incidencias sean los mismos que los que se dedican a las peticiones de servicio. Si el dimensionamiento lo permite, lo ideal sería tener a un recurso dedicado a realizar labores de "dispatcher". Esta persona debe tener unas directrices claras para poder tomar una decisión y repartir la carga de trabajo al equipo de técnicos correspondiente. Si no es posible disponer del "dispatcher" y la organización no es lo suficientemente madura existe el riesgo de que peticiones que no pueden esperar sean encoladas y retrasadas en el tiempo.
No hay comentarios:
Publicar un comentario