Gestionar la voz del cliente es la base del Valor de los servicios de TI
Esa reflexión me gusta mucho porque nos habla sobre la necesidad de interiorizar una idea, un objetivo, hacerlo propio en cada acción y tarea. No un objetivo difuso, sino uno concreto. Es importante preguntarnos siempre para qué sirve el trabajo que hacemos, y porque lo hacemos y cómo lo hacemos.
Como dijo Ford: "No es el empresario el que paga tu salario, son los clientes"
También considero importante mencionar que para obtener el valor, es necesario examinar la competencia. Y no hablo de la competencia de otra empresa que ofrece productos o servicios parecidos, hablo también de las otras formas en que nuestro cliente está satisfaciendo la necesidad del servicio que le ofrecemos. Sino somos capaces de pensar como el cliente, ponernos en sus zapatos, identificar el momento y el valor que le dá nuestro servicio, no estamos listos para abordar un proceso de transformación. Al menos no sin amargarnos la vida antes.
En ITIL el valor es un término que se incorporó a la gestión de los servicios, un término que se suele dejar de lado por considerarse "palabrería" "romancerismo" etc y que paradogicamente resulta a mi entender, el quid la la cuestión!!!. Gracias a la definición que da ITIL no tenemos que indagar mucho en el cliente para obtener el valor de nuestros servicios.
ITIL nos dice que Valor es la suma de las funcionalidades y la garantía.
Esto me lleva al tema del servicio. ¿Cual es el servicio de TI que estamos ofreciendo para nuestro cliente u organización? rápidamente pensamos en "gestión de incidencias"......error. Ese no es un servicio!! Una incidencia, es una interrupción no planificada o degradación de un servicio acordado con el cliente. Con lo cual tenemos que el servicio de TI según ITIL es otra cosa. Es aquello que ofrecemos a nuestro cliente u organización y que debe abarcar los aspectos de funcionalidad: Son las cosas que hacemos por el cliente o la organización sin que estos asuman los costos de hacerlos y la garantía: todo servicio incluso hecho por el mismo cliente lleva intrínceco un riesgo de no poder hacerse o simplemente de fallar, y en ese momento donde se produce la característica del valor asociada a la garantía la cual pretende reducir, controlar, mitigar la no disponibilidad o algún error producido en la prestación del servicio.
Este es un error frecuente que se comete al diseñar el catálogo de servicios de TI, y que nos lleva a procesos sin sentido, y comprometidos(riesgo) al meterles ITIL con calzador. Me he topado con grandes profesionales quemados de buenas metodologías, frustrados de pensar que todo lo de ITIL y las buenas prácticas son todo menos buenas y mucho menos prácticas y de sentirse atados para hacerlo de otra manera. Honestamente yo creo que me sentiría igual sino fuera porque he intentado leer ITIL desde la optica de cliente preguntandome el sentido que tiene para mi.
No en valde te diré:
Muestrame tu catálogo de servicios de IT y te diré cómo has entendido ITIL.
Esto me trae a otra pregunta existencial....¿existe un catálogo de servicios perfecto? Yo creo que la respuesta tiene matices y no es un sí ni un no rotundo. Todo está en que el cliente entienda para qué le sirve nuestro servicio y sin teorizar mucho, pueda verse con el servicio en su realidad a un costo adecuado y con un servicio post-venta (o ccompra según se mire) adecuado.
Las telefónicas y los proveedores de web hosting los tienen muy maduros. ¿Cómo es posible que nos regalen el movil, el ruter y hasta una tv y si mañana sale un chisme moderno también el chisme moderno?!!! Bueno, esque no nos lo regalan, simplemente han entendido el valor que tiene su servicio para el cliente. Sin donde utilizarlo, no necesitamos servicio. Podrían seguir mejorando su proceso y reducir costos operativos, o pueden invertir en un echo y lanzarlo en la siguiente campaña de 5G a la vez que optimizan los procesos de la compra yyyyyy por favor de la BAJA!!!!!!!!!!
En fin. Quiero terminar aquí ⇰ y terminaré con tres consejos para confeccionar el catálogo de servicios de TI:
1⇒.- El catálogo de servicios no es una gestión de incidentes o peticiones de servicio. Se debe delimitar lel servicio en base a las funcionalidades que se brindan. Cada cliente puede requerir acuerdos de nivel de servicio personalizados. Y pueden existir ANS estándar.
2⇒. Todas las funcionalidades deben tener un proceso o procedimiento asociado, que nos diga como se gestiona, requisitos, datos de entrada, tiempo de ciclo, y las salidas que el cliente o peticionario del servicio recibirá.
3⇒. Las incidencias del servicio. como lo es un CI a la CMDB, asi son las Incidenias a los servicios. Debe existir una forma de asociar una incidencia a un servicio, y de hacer un registro de los tipos de incidencia que nuestro servicio ha presentado. Esto es porque el valor de la gestión de incidencias es que no existan errores conocidos. La gestión de una incidencia reiterada sobre un servicio es un indicador de dejadez, de no tomarse en serio que una incidencia implica que nuestro cliente ha dejado de recibir el servicio en los términos adecuados. El valor en la gestión de incidencias es la garantía sobre un trabajo que debío realizarse de la forma correcta. Con lo cual, registrar demasiadas y no darles seguimiento, no digo ipso facto, sino a mediano plazo, resolviendo de raiz, es un mal indicador, pero lo es peor, no disponer de una línea en la plataforma de ticketing para registrar las incidencias, y peor todavía que se premie la volumetría de gestión de incidencias sin tomar en cuenta cuántas de ellas son errores conocidos de hace mucho tiempo, porque entonces, no estamos ante gestión de incidencias, estamos ante peticiones de servicio, y esas son otra cosa. Parecidas pero diferentes.
Resumo: gestión de peticiones para brindar funcionalidad sobre un grupo de CIs y en la medida de lo posible, alineados con los procesos de la organización para facilitar los ANS, y la gestión de incidencias para cubrir la garantía. Una vez se ha documentado la incidencia se vuelve error conocido. El error conocido va a una BD de errores, asociados a un CI que en cuanto el CI cambie, éste podría dejar de estar vigente y deshabilitar los "workarrounds" respectivos.
Esto último también importante por el tema de la gestión del conocimiento, la KWDB del Service Desk. Porque las peticiones tienen "instrucciones técnicas" o "procesos".y las incidencias tienen un "error conocido" y uno o varios "workarrounds" que es información más volatil en cuanto que si desaparece la causa del error, estos documentos deben desclasificarse correspondientemente de la búsqueda activa, no de la histórica.
En fin, es un tema muy lindo y apacionante.
Os deseo buenas noches y feliz verano desde ya a todos,
M.
