Diagrama de flujo del proceso de soporte TI (help desk)

¿Qué es diagrama de flujo del proceso de soporte ti (help desk)?

El proceso de soporte TI es la forma en que un servicio de soporte organiza su día: una única puerta de entrada para todos los contactos de usuario, llegue por el canal que llegue, y un único camino acordado desde ese contacto hasta el ticket cerrado. Lo que lo distingue de un procedimiento de un solo propósito es que transporta dos tipos de trabajo a la vez. Unos tickets son incidencias: algo que debería funcionar no funciona. Otros son solicitudes de servicio: no hay nada roto y el usuario pide un trabajo estándar ya acordado, como una licencia, un portátil nuevo o un software. Necesitan relojes distintos y a menudo aprobadores distintos, así que el proceso los separa pronto en vez de dejar que una sola cola trate todo como si fuera una caída de servicio.

Esta página cubre el flujo operativo del día a día, no las tripas de cada rama. Si necesitas declaración de incidencia grave, un gestor de incidencias con nombre, salas de crisis y escalado por incumplimiento de SLA, ese detalle pertenece al proceso de gestión de incidencias. Una sospecha de compromiso sigue el proceso de respuesta a incidentes de seguridad. Una solución que exige tocar un servicio en producción se traspasa a gestión de cambios, y una petición de acceso a un sistema sigue el proceso de solicitud de acceso, con su propia cadena de aprobación y su recertificación periódica. El análisis de causa raíz sale por completo de este proceso: la rama de problema recurrente abre un registro de problema en lugar de mantener abierto el ticket del usuario mientras alguien investiga.

El diagrama reparte cinco carriles (Usuario, Servicio de soporte, Soporte nivel 2, Activos y compras, y Gestión de problemas) en cinco fases, del contacto al cierre. Dibuja dos cosas que casi ningún equipo documenta: la consulta a la base de conocimiento que decide si el primer nivel aplica una solución documentada o diagnostica desde cero, y la rama de compras que decide si un artículo pedido sale de stock o hay que pedirlo. Y termina donde la mayoría de los procedimientos escritos se quedan cortos: con el usuario confirmando la solución y una rama de reapertura para cuando dice que sigue sin funcionar.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles con un responsable por paso (Usuario, Servicio de soporte, Soporte nivel 2, Activos y compras, y Gestión de problemas) repartidos en cinco fases: contacto, registro y clasificación, primer nivel, escalado y entrega, y resolución y cierre.
• Entrada multicanal: «El usuario contacta con soporte» alimenta «Recibir el contacto por cualquier canal», de modo que teléfono, correo, portal de autoservicio, chat y visita presencial caen en la misma cola antes de registrar nada.
• La bifurcación «¿Incidencia o solicitud de servicio?» justo después de «Registrar y clasificar el ticket», que envía las incidencias a «Asignar prioridad por impacto y urgencia» y las solicitudes por una rama de entrega aparte.
• Un intento de primer nivel construido en torno a «¿Solución en la base de conocimiento?»: el sí aplica la solución documentada y el no pasa a «Intentar resolver en primer nivel», y ambos se reencuentran en «¿Resuelto en primer nivel?», con una rama de escalado hacia «Investigar y resolver en nivel 2».
• La rama de solicitudes: «¿El responsable aprueba la solicitud?» con una salida denegada que termina en «Solicitud denegada y cerrada», y después «¿Hay stock disponible?», que deriva el pedido por «Emitir una orden de compra» antes de «Entregar y actualizar el inventario de activos».
• El cierre en la última columna: «Registrar la resolución y avisar al usuario», una decisión «¿El usuario confirma la solución?» con reapertura hacia el primer nivel, y «¿Problema recurrente o conocido?», que abre un registro de problema antes de «Ticket cerrado».

Cuándo usar esta plantilla

• Quieres documentar cómo funciona de verdad vuestro servicio de soporte, para que un agente nuevo vea a dónde va un ticket y quién es dueño de cada etapa sin preguntar a un compañero
• Necesitas separar incidencias de solicitudes de servicio cuando hoy conviven en una única cola indiferenciada y todo acaba tratándose como urgente
• Estás configurando una herramienta de tickets o ITSM, y las categorías, la matriz de prioridad, la regla de aprobación y la actualización del inventario del diagrama se corresponden con campos que tendrás que definir igualmente
• Quieres fijar dónde acaba el primer nivel y dónde empieza el nivel 2, algo que en la mayoría de los equipos es costumbre y no una regla escrita
• Vas a instruir a un servicio de soporte externalizado o recién contratado sobre los traspasos, las confirmaciones y los registros que esperas que respete

Cómo funciona

1. Renombra los carriles con vuestros roles reales

   Sustituye Usuario, Servicio de soporte, Soporte nivel 2, Activos y compras, y Gestión de problemas por los equipos que tenéis. Las organizaciones pequeñas suelen fundir activos y compras dentro del carril de soporte, y la gestión de problemas puede ser una persona con nombre en lugar de un equipo. Mantén un carril por quien decide, no por individuo, para que el diagrama sobreviva a un cambio de puesto.

2. Escribe el criterio para distinguir incidencia de solicitud

   La bifurcación «¿Incidencia o solicitud de servicio?» solo funciona si un agente puede aplicarla en segundos. Escribe la prueba junto a la decisión: ¿algo que debería funcionar está roto, o el usuario pide un trabajo estándar ya acordado? Enumera vuestros casos frontera reales, como un portátil lento frente a la petición de uno nuevo, e indica por dónde va cada uno.

3. Publica la matriz de prioridad

   Adjunta vuestras definiciones de impacto y urgencia a «Asignar prioridad por impacto y urgencia», indicando qué significa cada nivel en número de usuarios afectados y consecuencia para el negocio. Publicar la matriz donde los usuarios puedan leerla es lo que convierte la prioridad en algo que se deduce en lugar de discutirse ticket a ticket.

4. Fija el límite del primer nivel y qué debe llevar un escalado

   Define qué está autorizado y equipado a resolver el primer nivel, y qué tiene que contener un escalado para que el nivel 2 lo acepte: pasos ya probados, servicio afectado, evidencias y disponibilidad del usuario. Decide si además quieres un tope temporal que escale automáticamente un ticket sin avances, e indica quién es su dueño después del traspaso.

5. Decide qué necesita aprobación y qué está preaprobado

   Marca como preaprobados los artículos de catálogo de bajo coste y bajo riesgo para que se salten por completo «¿El responsable aprueba la solicitud?», y reserva la puerta para el gasto, las licencias y todo lo que cambie a qué puede acceder una persona. Cuando la petición sea de acceso a un sistema, traspásala a vuestro proceso de solicitud de acceso en lugar de aprobarla aquí.

6. Acuerda cierre, reapertura y derivación a problema, y publica una sola versión

   Indica qué cuenta como confirmación del usuario, cuánto espera un ticket resuelto antes de cerrarse automáticamente y con qué criterios «¿Problema recurrente o conocido?» abre un registro de problema. Después recorre el diagrama con cada carril, corrige los pasos que realmente ejecutan y publícalo como versión vigente con la aprobación registrada, para que todos lean la misma revisión.

Preguntas frecuentes

¿En qué se diferencia el proceso de soporte TI de la gestión de incidencias?

El proceso de soporte es el flujo operativo del propio servicio: todo contacto que llega, por cualquier canal, encaminado al tipo de tratamiento que le corresponde. La gestión de incidencias es solo una de sus ramas y se ocupa únicamente de las interrupciones no planificadas de un servicio. ITIL 4 trata service desk, gestión de incidencias, gestión de solicitudes y gestión de problemas como prácticas separadas justo por eso, aunque un equipo pequeño las ejecute todas desde una misma cola y con las mismas personas. Este diagrama es la vista de servicio que muestra cómo esas ramas comparten entrada y cierre, y deja el detalle profundo (incidencia grave, escalado por incumplimiento de SLA) al proceso de gestión de incidencias.

¿Cuál es la diferencia entre una incidencia y una solicitud de servicio?

Una incidencia es algo que debería funcionar y no funciona: un inicio de sesión fallido, una impresora caída, una aplicación que da errores. Una solicitud de servicio es un trabajo estándar ya acordado, sin avería de por medio: un software nuevo, una licencia, un equipo de sustitución, un buzón para alguien que se incorpora. La distinción importa porque cambia casi todo lo que viene después. Las incidencias reciben una prioridad por impacto y urgencia y se miden por el restablecimiento; las solicitudes reciben una aprobación y una vía de entrega y se miden por el plazo. Mezclarlas hace que las peticiones rutinarias corran con reloj de caída de servicio, o que las caídas reales esperen detrás de un pedido de portátiles.

¿Cuándo hay que escalar un ticket al nivel 2?

Cuando el trabajo supera el límite de conocimientos, herramientas o permisos del primer nivel: eso es un escalado funcional. Es distinto del escalado jerárquico, en el que se involucra a un responsable porque el impacto o el retraso se han convertido en un problema de negocio y no técnico. Muchos servicios añaden un tope temporal para que un ticket sin avances se escale automáticamente, algo útil como red de seguridad pero mala regla principal por sí sola. Sea cual sea el detonante, el traspaso tiene que llevar lo que ya se ha probado, o el nivel 2 dedicará su primera hora a repetir el trabajo del primero.

¿Se puede cerrar un ticket antes de que el usuario confirme la solución?

Resuelto y cerrado son dos estados distintos, y este diagrama los mantiene separados. El agente marca el ticket como resuelto cuando aplica la solución; se cierra solo cuando «¿El usuario confirma la solución?» devuelve un sí. Si el usuario dice que el problema sigue, el ticket se reabre hacia el primer nivel en lugar de abrirse uno nuevo, lo que mantiene juntos el historial y el reloj original. Como hay usuarios que nunca contestan, la mayoría de los servicios fijan un cierre automático de unos días laborables con un recordatorio previo, y publican ese plazo en la descripción del servicio para que el cierre no sorprenda a nadie.

¿Cómo encajan en el proceso las solicitudes que implican una compra?

Siguen la rama de entrega: aprobación cuando el catálogo la exige y después «¿Hay stock disponible?», que entrega desde el stock existente o emite una orden de compra antes de la entrega. El paso que la gente se salta es actualizar el inventario de activos, y por eso aquí vive en el mismo nodo que la entrega. Si el inventario no se actualiza en el momento de entregar, el recuento de licencias y la planificación de renovación de equipos se desactualizan en pocos meses. Para compras grandes o fuera de catálogo, el servicio plantea la necesidad y toma el relevo el proceso general de orden de compra, con su propio abastecimiento y su conciliación de facturas.