Páginas

11 de febrero de 2016

10 Debilidades de un sistema de gestión de Incidentes (OTRS)

Un sistema de seguimiento de incidentes (denominado en inglés como issue tracking system, trouble ticket system o incident ticket system) es un paquete de software que administra y mantiene listas de incidentes, conforme son requeridos por una institución.

Un ticket es un archivo contenido en el sistema de seguimiento que contiene información acerca de intervenciones de software hechas por personal de soporte técnico o terceros a pedido de un usuario final que ha reportado un incidente que está impidiéndoles trabajar en sus computadoras cuando ellos esperaban poder hacerlo.

Los Tickets se crean generalmente en un ambiente de help desk o call center. Típicamente el ticket tiene un número único de referencia, también conocido como un número de caso, incidente o reporte de llamada, el cual es usado para permitir al cliente o al personal de soporte localizar, añadir o comunicar el estado del incidente o requerimiento.

Cuando implementamos una solución de este tipo los usuarios se convierten en seres hostiles quienes desahogan en nosotros sus frustraciones laborales, necesitan inmediatez de respuesta y parece que dependiera su vida de eso. A continuación presentamos diez (10) debilidades de un sistema de gestión de incidentes, tickets OTRS

1.- Fuerte resistencia al cambio:
"Este informe tiene que salir para ya! y ustedes me ponen a perder tiempo!" , "El SIGESP no funciona, está malo, es una porquería", "De paso me dicen que tengo que hacer un ticket!!",  "Yo que tengo tanto trabajo necesito alguien que me atienda".
R: Amablemente le explicamos que necesitamos un ticket, Hacerle una lista de chequeo (Check-list) Preguntarle "¿Pero chequee antes si escribieron bien el monto?", "¿tienen saldo negativo?", "revise el cable de la impresora puede ser que esté apagada, etc."  luego nos dirigimos a la auditoría del programa a revisar, chequeamos que hizo el usuario, si hay algo extraño le explicamos que paso omitió. Por lo general los usuarios tienen la necesidad de ser escuchados, sin antes tratar de solucionarlo ellos mismos el problema.

2.-Llamadas antes, durante y después sin sentido:
"¿Está Juan pásamelo?", "Te llamo porque te creé un ticket hace dos minutos" ; "Te llamo para saber que pasó con mi ticket"; "Te llamo para ver si ya esta listo".
R. Le contestamos con la mayor cortesía  "Si ya lo sabemos, lo estoy viendo en el sistema de incidentes en este momento! "en la brevedad posible lo atenderemos" , "pero de ahora en adelante no llame, nosotros le llamaremos" ó "Estaba apunto de llamarlo pero me dilaté buscando su  número en el directorio de teléfono, le recomiendo para atenderlo más rápido coloque su extensión y la hora donde ubicarlo en el mismo ticket".

3.- Tickets de Emergencias que no son urgentes:
"Hay problemas con la nómina que se pagó hace quince días, es urgente!!!"
R. Explicarle "Un pago de nómina que ya se efectuó no es una emergencia ya se ejecutó", Existen verdaderas emergencias que si lo son: un mantenimiento de aire acondicionado que no se ha reparado y necesitan el anticipo, un proveedor que no se le ha pagado, una ayuda alimentaria, el ticket de alimentación". Pero su caso será atendido a la brevedad posible.

4.- El ticket la una excusa legal perfecta: 
De manera hostil expresan: "Yo no hago tickets eso no funciona eso es más burocracia, debe haber simplificación de trámites administrativos!!"
R. Explicarle:"Generar un ticket no es retrasar el proceso, es un control para asegurar que seas atendido", "Yo te entiendo y respeto tu posición pero debo justificar mi trabajo", ¿Con quien debo hablar para que me genere el ticket, quien es tu supervisor?. Evitar comentario  "pásamelo por escrito" esto es contraproducente.

5.- Ticket cerrado y el usuario ni se enteró:
"Que pasó con mi ticket de la semana pasada, no me llamaron, bueno no revisé el correo, tampoco no hubo interacción de llamada preguntándome si se solucionó la falla".
R. Explicamos "Usted debió recibir un correo explicándole todo; de ahora en adelante recibirá una llamada con una encuesta sobre la calidad del servicio".

6.- Tickets abiertos hace semanas:
Los tickets abiertos sin respuesta o seguimiento, son del tipo "No me lo cierres porque, si me vuelve ocurrir" o "si pasa algo extraño te llamo" luego se les olvida y no ocurre nada.
R. Se debe justificar cierre del ticket con una política: "Si transcurridas 24 horas de la atención y no se presenta nuevamente la falla se dará por cerrado automáticamente el ticket". Si usted hace caso omiso a esto deberá hacer un nuevo ticket

7.- Todos mienten y crean historias:
Nuevamente las llamadas  "Si, yo cree el ticket era una cosa loca que me pasó! fue hace como un año, pero como no vinieron a mi ya se me olvidó", "Yo he creado como diez tickets y no ha venido nadie!".
R. Se le dice "Espere un momento y chequeo en el sistema de ticket, pero aquí no veo nada, solamente veo uno, será este de la semana pasada el de impresora con el papel atascado, pero está cerrado", responden "si ese es, yo misma saque el papel!! si me pongo a esperar por ustedes!"

8.- Miedo de usar la aplicación:
"Yo no tengo clave", "no ha recibido el curso", "Yo no genero tickets", "Es muy complicado".  Por lo general no sabe funciona la aplicacion de incidentes o como operarla y cree que puede dañarla al poner un dato mal.
R.  Explicarle que eso de crear tickets no es ni engorroso ni complicado, vamos a crearlo juntos tendrá la clave". Probablemente la clave sea muy compleja y no le hemos dado el entrenamiento que el usuario necesita,etc., esto también aplica para los analistas que atienden los tickets.

9.- Listas de los usuarios más latosos:
Como si fueran un top ten de canciones de la radio vemos en los escritorios de los analistas listas de telefonos: Pedro ext. 9585, Julio: 9013, Andrés: 9901... de las personas quienes llaman a cada rato.
R: Al tener un sistema de tickets que controle el flujo tendremos estadísticas para la toma de decisiones, conocer quien necesita capacitación y encontrar los detalles del sistema.

10. Ticket asignado si control previo.
Se asigna un incidente analista sin haberlo chequeado antes y cuando lo contactamos ya estaba resuelto. "Como se tardaron tanto y no venían yo me puse a jorungar y lo resolví yo solita, era una estupidez".
R. Se le da las gracias y se le refuerza su iniciativa.