alexa

红牛棋牌线路

icorp | Blog

icorp | Blog

Autopsia a un Ticket Vencido – Guía para Optimización de Tickets en Service Desk

La actividad central dentro de un Service Desk es la atención de las solicitudes que realizan los usuarios para el área de TI. Para ello y siguiendo una práctica que se ha implementado en la mayoría de las organizaciones, dichas actividades se vinculan directamente con un número de atención que dentro del ambiente interno se denomina número de “ticket”.

El manejo de estas atenciones por medio de tickets facilita su correcta administración y organización en distintas formas; sea por área de atención, sea por el personal que atenderá un grupo en particular de solicitudes, entre otras opciones. Pero más allá de esto, su importancia radica en que nos brindan una serie de estadísticas que nos dan la oportunidad de medir y cuantificar el trabajo que se realiza en el área de sistemas y de esta forma medir el impacto que ésta área tiene en toda la organización.

La generación de tickets es una actividad que se realiza de manera tan rutinaria que a veces se descuidan detalles que pueden afectar en determinado momento a que una solicitud realizada por alguno de los usuarios de la empresa no se atienda en el tiempo o las formas adecuadas. Esto conlleva repercusiones que en el ámbito laboral pueden ir desde un impacto casi nulo hasta un impacto crítico para la entidad de manera global.

Imaginemos por un instante que somos médicos y que estamos a punto de realizar una autopsia.

Cualquier disciplina o ciencia a pesar de las obvias diferencias que presenta en función al área a la cual está enfocada tiene como base fundamental el método científico, en el cual los procesos de observación y análisis tienen una importancia fundamental para aprender de fallas pasadas y evitarlas en el futuro, garantizando así la creación de hábitos correctos.

Hagamos entonces a partir de este paso, un ejercicio de discernimiento que nos ayudará a encontrar puntos que siendo muy comunes pueden generar en nosotros hábitos correctos al momento de trabajar con las solicitudes que se reciben en el día a día.

红牛棋牌线路En este ejercicio el supuesto “cadáver “estará representado por medio de un ticket, un ticket que se “venció”, es decir, que no fue atendido dentro de los parámetros previamente establecidos para una situación específica. Dicho ejercicio consistirá en que se nos encomendará revisar el ticket, dividirlo y analizarlo con la intención de conocer las causas que originaron su vencimiento.

Desde luego existen muchas situaciones que podrían analizarse, algunas más complejas que otras, pero en esta ocasión nos encontramos con un ticket que a simple vista nos parece muy común y que seguramente todas aquellas personas que hemos trabajado brindando servicio dentro del área de TI hemos visto; un reporte indicando que un usuario no puede ingresar a internet.

红牛棋牌线路En nuestra hoja de análisis tomamos nota del nombre o título del ticket;

“Sin acceso a internet

Es un título simple, común, cotidiano y que pesar de que en un primer momento nos brinda una clara idea de la situación que se nos presenta (no se tiene acceso a internet) después de unos instantes el panorama deja de ser tan claro y surgen algunas cuestiones básicas relativas a este primer punto; ¿En este equipo ya se había ingresado con anterioridad a internet o sería la primera vez que se está intentando ingresar? ¿Al intentar ingresar a internet le aparece un mensaje de error? ¿No se tiene acceso a ninguna página o solo es a alguna página en específico?

红牛棋牌线路En realidad, éstas son solo tres preguntas dentro de una amplia gama de cuestionamientos que cualquier analista de ServiceDesk se podría hacer cuando un usuario reporta esta situación. La idea principal consiste en mostrar que el “nombre” bajo el cual se mostró a nuestro “paciente” no es lo suficientemente claro y descriptivo.

红牛棋牌线路Después de este primer punto de reflexión, centramos nuestra atención en el “cuerpo” del ticket. El cuerpo del ticket correspondería con la descripción de la falla o situación que se presenta con la finalidad de que se pueda ahondar en la información colocada en el título (que como ya vimos, no brinda demasiada información al respecto).

红牛棋牌线路Dentro del cuerpo del título encontramos la siguiente información;

Usuario reporta vía telefónica que no puede acceder a internet en su laptop. Solicita que se revise su equipo por la tarde ya que necesita entrar a internet

Service Desk 24/7

红牛棋牌线路El equipo de Service Desk de icorp analiza cada Ticket a fondo. Haz click en la imagen para agrandar el modelo.

Para este punto, la esperanza que teníamos de obtener de primera mano una pieza de información más precisa de lo acontecido se desvanece. Parece ser que este “cadáver” no nos facilitará nuestra labor.

Como primer detalle detectamos que la descripción en realidad es casi una repetición del título sin brindar un aporte sustancial, aunque sí permite obtener dos datos adicionales que podemos destacar; se trata de una laptop y la atención se brindó a través del teléfono. Sin embargo, al contar con estos datos, se agregan más preguntas que respuestas al análisis que estamos realizando; algunas de las cuales serían: ¿La laptop se conecta a la red a través de un cable, de señal inalámbrica (Wireless) o a través de algún dispositivo de internet móvil como sería una BAM? ¿Si se conecta a través de una señal inalámbrica, ya se verificó que el adaptador de red estuviera encendido? En estricto sentido, estoy seguro que cualquiera persona involucrada en el ámbito de sistemas podría notar que hace falta una descripción más clara y precisa de la situación, así como una mayor información relativa a la solicitud que se nos está presentando.

En este momento esa falta de información parece algo muy evidente, que de inmediato salta a la vista y que sin embargo, la gran mayoría de los analistas de ServiceDesk hemos omitido colocar en alguna ocasión. Y no es solo eso, después de leer nuevamente la descripción notamos un pequeño pero importante detalle; no se le pidió al usuario que nos indicara un número telefónico de contacto. ¿Alguna vez nos hemos encontrado con alguna situación similar?

Una vez que se terminaron de revisar los puntos anteriores ha llegado el momento de adentrarnos en las entrañas del ticket para saber la razón de su vencimiento. Sin duda, pueden ser muchas las causas de que esto haya sucedido, por lo cual trataremos de hacer un análisis imparcial y obtener conclusiones positivas al respecto.

红牛棋牌线路Al dividir el ticket, llegamos al historial de seguimiento. Aquí cabe aclarar que los procesos establecidos para dar seguimiento a una solicitud pueden variar mucho entre cada uno de ellos pero para este caso en particular nos encontramos con la siguiente información;

“No se pudo contactar al usuario vía telefónica debido a que no se tenía su número de extensión, se marcó al área de recepción solicitando información de contacto. Se marcó a la extensión proporcionada varias veces sin éxito alguno

“Al día siguiente se intenta contactar a usuario nuevamente vía telefónica sin éxito alguno. Por la tarde se logra contactar a usuario quien comenta que ha tenido varias reuniones por lo cual no se encontraba disponible y que debido a su carga de trabajo no puede facilitar su equipo para revisión en este momento por lo cual solicita que se revise al otro día por la mañana

“Se contacta a usuario en el tiempo indicado el día anterior, se conecta vía remota al equipo de cómputo y se verifica si cuenta con acceso a internet. Se detecta que el usuario necesita ingresar a una página de transferencia de archivos, ya que necesita enviar un documento a un colaborador. No se puede ingresar a dicha página debido a que está bloqueada desde el firewall de la organización por motivos de seguridad. Se revisa el archivo a enviar y se detecta que debido a su tamaño no puede enviarse por correo electrónico. Se informa a usuario que dicho acceso a la página debe validarse con el área correspondiente y que dicha solicitud será canalizada a dicha área.

Se escala ticket al área correspondiente para que se permita el acceso a la página solicitada

红牛棋牌线路En este punto del análisis, cada quien puede opinar si lo descrito en el historial es lo suficientemente preciso o no. Lo que sí resulta más evidente es que ahora ya tenemos una idea clara de la solicitud inicial realizada por el usuario; no podía ingresar a una página de internet en particular y además, esto no era resultado de un error, sino que para ingresar a dicha página se necesitaba de una configuración realizada por otro nivel dentro del área de sistemas. Desafortunadamente, para el momento en que la situación se clarificó ya habían pasado dos días de que la solicitud había sido creada y por lo tanto, ya había sobrepasado el tiempo en el cual este tipo de solicitudes se deben atender, es decir, en síntesis, ahora ya sabíamos porque el ticket que teníamos ante nuestros ojos se había “vencido”.

En nuestra hoja de anotaciones y para finalizar el ejercicio, colocamos la siguiente descripción;

Causa principal que originó el vencimiento; definición inadecuada de la solicitud originalmente recibida.

红牛棋牌线路En estricto sentido, sabemos que un ticket que se “venció” continúa en proceso de atención y de ninguna manera significa que se abandone o que no se siga revisando por el área correspondiente. Sin embargo, esto no es lo primordial, ya que debemos tener presente que muchas veces una atención brindada fuera de tiempo es equivalente a una atención que no se brindó y la razón es que el tiempo de respuesta es un factor clave tanto en la percepción del usuario como en los estándares de calidad que existen para los servicios de TI. En el ejemplo anterior, queda de manifiesto que una correcta definición inicial de la solicitud del usuario nos hubiera evitado perder un factor que no se puede recuperar; el tiempo.

Pero más allá de buscar culpables, el área de TI como una entidad que evoluciona de manera constante debe ser capaz de retroalimentarse a sí misma y de esta forma aprender de lo sucedido para evitar en la medida de lo posible que se vuelva a presentar en el futuro.

Precisamente por eso, he elaborado una  [ninja-popup ID=188]guía para generar tickets[/ninja-popup]  que puedes descargar en segundos. En ella, se describen algunos elementos que son básicos para que un ticket o número de servicio tenga una base sólida a partir de la cual los diversos especialistas de TI puedan desarrollar su trabajo.

Esta percepción, puede hacer toda la diferencia entre el éxito y el fracaso de un departamento de sistemas. Finalmente, si miramos a través de un cristal claro, el principal objetivo que todo departamento de sistemas debería tener es la satisfacción del cliente.

Como suele decir Jeff Bezos, CEO de Amazon;

“Nosotros vemos a nuestros clientes como los invitados de una fiesta en la que nosotros somos los anfitriones. Nuestro trabajo es hacer que la experiencia del cliente sea un poco mejor cada día”.

. . .

Sobre el autor

Jorge Luis Lopez
Jorge Luis Lopez

红牛棋牌线路Es ingeniero en sistemas, certificado como Analista de Service Desk y dotado con los conocimientos, tanto en el uso como en la aplicación, de herramientas administrativo-financieras. Desde hace tres años, Jorge brinda soporte y asesoría para usuarios de TI en icorp bajo el mantra que lo ha convertido en experto: “La motivación es lo que te ayuda a empezar. El hábito te mantiene firme en tu camino”.

2 Comments

  1. Omar Salinas Omar Salinas Ledesma Reply

    Muy buena información de mucha utilidad para los que estamos en el área de service desk para seguir poniendo atención a nuestras actividades y evitar caer en ese tipo de errores que se describen ya que nos hace ver la importancia de el llenado del ticket y su asignación.

  2. Gregorio Hernández Reply

    Excelente analogía del ciclo de vida del reporte, muy buen aporte, sin duda en muchos HD-SD de varías empresas es muy común que se tenga ese tipo de problemas en la documentación, Yo como Coordinador del área la forma en la que empece a disminuir la mala redacción de los ingenieros que atendían el primer nivel fue: llevándolos conmigo a mi lugar y pidiéndoles que lean las descripciones de sus compañeros, después de ello les preguntaba que entendiste, como lo resolverías y lo primero que me decían es: no entendí de bien a bien que problema tiene el usuario, con esto logre minimizar de manera significativa estos vicios que se tienen en la mala documentación, del igual modo les mande esto que es muy similar a lo que expones en tu guía:

    Información mínima a solicitar a un usuario en atención telefónica
    1. Nombre completo del usuario
    2. Tel. o ext. Donde se localiza
    3. Ubicación física (en caso de que haya un corporativo con varios edificios)
    4. Tiempo que se tiene con el problema
    5. Emulación de lo reportado (es por conexión alámbrica, inalámbrica o bam)?
    6. Descripción con santo y seña de lo reportado
    7. Documentar santo y seña lo que se realizó a modo de evitar re trabajos para el siguiente nivel
    8. Anteriormente si lo podía hacer?
    9. Que error le aparece, Impresión de pantalla en caso de que no se tenga una conexión remota
    10. Cuantos usuarios son los del problema?
    11. Ayer podía hacerlo? Podía trabajar con esto?
    12. En caso de que sea un problema con el contacto de energía eléctrica checar conectando otro aparato
    13. Redacción clara, a modo de que quien lo lea entienda lo que estas tratando de transmitir
    红牛棋牌线路 Gracias, espero que les sirva esto también, Saludos.

Agrega tus comentarios