Informe técnico: Mejora del proceso de atención de incidencias de TI
Gestión Estratégica de Proceso y Agilidad Empresarial (PSISP08066) · Universidad Autónoma del Perú · Ingeniería de Sistemas
Propuesta estratégica para reducir el tiempo de resolución de incidencias en la mesa de ayuda de una pyme de servicios informáticos, con Kanban como metodología ágil principal.
1. Contexto y organización
El proyecto mejora el proceso de atención de incidencias de la mesa de ayuda de Servicios Informáticos Andes S.A.C., una pyme limeña de soporte y mantenimiento de TI, porque hoy las incidencias se pierden entre canales y se resuelven tarde. La empresa es un caso ficticio construido para este curso; las cifras son supuestos.
| Dato | Valor (supuesto) |
|---|---|
| Rubro | Soporte, mantenimiento y consultoría de TI para empresas |
| Tamaño | 45 colaboradores; mesa de ayuda con 1 coordinador y 6 técnicos |
| Clientes | 60 empresas con contrato de soporte mensual |
| Volumen | 450 incidencias al mes |
| Canales de entrada | Correo, WhatsApp y llamada telefónica |
| Registro actual | Hoja de cálculo compartida, llenada a mano |
| Tiempo medio de resolución | 18 horas hábiles |
| Incidencias fuera de plazo (SLA) | 30 % |
| Incidencias reabiertas | 20 % |
Proceso elegido: atención de incidencias, desde que el cliente reporta el problema hasta que confirma su cierre. Es un proceso misional: de él depende la renovación de los contratos.
Alcance: incluye recepción, registro, clasificación, asignación, resolución, escalamiento y cierre. Excluye la facturación y la gestión de proyectos de consultoría.
2. Mapa de procesos
La atención de incidencias es el proceso misional que más pesa en la renovación de los contratos, por eso es el objeto del proyecto.
Los procesos estratégicos fijan las metas y los acuerdos de nivel de servicio (SLA); los de apoyo proveen personal, repuestos e infraestructura. El proceso resaltado es el que se modela y mejora en las secciones siguientes.
3. Modelado BPMN del proceso actual (AS-IS)
Toda incidencia pasa por dos tareas manuales del coordinador antes de llegar a un técnico, y una de cada cinco regresa al inicio porque el problema persiste.
El modelo usa la notación BPMN (evento de inicio, tareas, compuertas y evento de fin) y puede reproducirse en Bizagi Modeler. Las tareas resaltadas son los puntos de espera; el escalamiento por WhatsApp no deja registro en ningún sistema.
4. Diagnóstico del proceso actual
Tres de cada diez incidencias vencen su plazo porque esperan en dos puntos: el registro manual y la asignación por el coordinador. Los problemas se priorizan por impacto y frecuencia (supuestos, escala de 1 a 5).
| N.º | Problema detectado | Tipo | Impacto | Frecuencia | Prioridad |
|---|---|---|---|---|---|
| 1 | Asignación manual: toda incidencia espera al coordinador | Cuello de botella | 5 | 5 | 25 |
| 2 | Registro manual en hoja de cálculo; hay incidencias sin registrar | Actividad sin valor agregado | 4 | 5 | 20 |
| 3 | Sin clasificación por urgencia; todo se atiende por orden de llegada | Falla de diseño | 5 | 4 | 20 |
| 4 | Escalamiento informal por WhatsApp, sin seguimiento | Falla de control | 4 | 4 | 16 |
| 5 | El cliente no confirma el cierre; 20 % se reabre | Re-trabajo | 4 | 4 | 16 |
| 6 | Sin base de conocimiento; se repite el diagnóstico de problemas conocidos | Desperdicio | 3 | 4 | 12 |
Prioridad = impacto × frecuencia. Los problemas 1 a 3 concentran la mayor parte de la demora y son el foco del rediseño.
5. Herramientas estratégicas: SIPOC y FODA
El SIPOC delimita el proceso y el FODA indica que la oportunidad principal es automatizar el ruteo con herramientas que la empresa ya domina.
| Proveedor (S) | Entrada (I) | Proceso (P) | Salida (O) | Cliente (C) |
|---|---|---|---|---|
| Cliente corporativo | Reporte del problema por correo, WhatsApp o llamada | Atención de incidencias: registrar, clasificar, asignar, resolver, cerrar | Incidencia resuelta y confirmada | Usuario del cliente |
| Fabricantes y proveedores de software | Parches, garantías, soporte de segundo nivel | Registro histórico del caso | Gerencia de cuentas | |
| Coordinador de la mesa | Contrato y acuerdos de nivel de servicio | Reporte mensual de cumplimiento | Dirección de la empresa |
| Positivo | Negativo | |
|---|---|---|
| Interno | Fortalezas: técnicos con experiencia; relación cercana con los clientes; equipo pequeño que cambia rápido | Debilidades: registro manual; dependencia del coordinador; sin indicadores ni base de conocimiento |
| Externo | Oportunidades: herramientas de tickets gratuitas o de bajo costo; clientes que piden reportes de servicio; demanda creciente de soporte | Amenazas: competidores con portal de tickets; penalidades por incumplir SLA; pérdida de clientes por demora |
La estrategia que se desprende es FO/DO: aprovechar las herramientas de tickets (oportunidad) para eliminar el registro manual y la dependencia del coordinador (debilidades).
6. Rediseño del proceso (TO-BE)
El proceso propuesto elimina las dos tareas manuales del coordinador: el sistema crea el ticket, lo clasifica y lo asigna por reglas, y el cierre lo confirma el cliente.
Si el cliente no responde en 48 horas, el ticket se cierra solo; si responde que el problema persiste, se reabre con todo su historial. El coordinador deja de ser un paso del flujo y supervisa el tablero y los reportes.
| Aspecto | AS-IS (actual) | TO-BE (propuesto) |
|---|---|---|
| Registro | Manual en hoja de cálculo | Automático, venga por el canal que venga |
| Clasificación | Sin urgencia; orden de llegada | Por categoría y urgencia |
| Asignación | El coordinador, a mano | Reglas por tipo de incidencia y carga |
| Escalamiento | WhatsApp, sin registro | Dentro del ticket, con seguimiento |
| Cierre | El cliente no confirma | Confirmación o cierre automático a las 48 horas |
| Rol del coordinador | Cuello de botella | Supervisa el tablero y los reportes de SLA |
7. Propuesta estratégica
La propuesta busca bajar el tiempo medio de resolución de 18 a 8 horas hábiles en seis meses, alineada con la estrategia de la empresa de ser el proveedor de soporte más confiable para pymes de Lima.
Objetivo general: rediseñar el proceso de atención de incidencias con un sistema de tickets y gestión visual Kanban para cumplir los acuerdos de nivel de servicio.
Objetivos específicos:
- Centralizar los tres canales de entrada en un único registro de tickets.
- Clasificar cada incidencia por urgencia y asignarla por reglas, sin pasar por el coordinador.
- Formalizar el escalamiento y la confirmación de cierre por parte del cliente.
- Crear una base de conocimiento con las 20 incidencias más frecuentes.
| Indicador | Fórmula | Línea base | Meta a 6 meses |
|---|---|---|---|
| Tiempo medio de resolución | Suma de horas hábiles de resolución ÷ incidencias cerradas | 18 h | 8 h |
| Cumplimiento de SLA | Incidencias a tiempo ÷ incidencias totales | 70 % | 90 % |
| Tasa de reapertura | Incidencias reabiertas ÷ incidencias cerradas | 20 % | 8 % |
| Incidencias registradas | Tickets creados ÷ incidencias reportadas | 85 % | 100 % |
Alcance de la propuesta: la mesa de ayuda y sus siete integrantes. No incluye cambios en contratos ni en las áreas comercial y de facturación.
8. Agilidad y selección de metodología
Kanban es la metodología principal porque las incidencias llegan todos los días sin poder planificarse, y obtiene 4,25 de 5 frente a 3,10 de Lean y 3,00 de Scrum.
Nivel de agilidad actual (supuesto):
| Principio ágil | Situación en la mesa de ayuda | Nivel |
|---|---|---|
| Entregar valor de forma continua | Se resuelve por orden de llegada, sin priorizar por urgencia | Bajo |
| Adaptarse al cambio | El equipo es pequeño y cambia de prioridad con rapidez | Medio |
| Colaboración con el cliente | Relación cercana, pero sin confirmación formal de cierre | Medio |
| Reflexión y mejora periódica | No existen reuniones de revisión | Bajo |
Criterios de selección (puntaje de 1 a 5):
| Criterio | Peso | Scrum | Kanban | Lean |
|---|---|---|---|---|
| Flujo continuo de trabajo no planificable | 30 % | 2 | 5 | 3 |
| Facilidad de adopción en un equipo de 7 personas | 20 % | 3 | 5 | 3 |
| Visibilidad del trabajo y límite de trabajo en curso | 20 % | 3 | 5 | 2 |
| Reducción de desperdicios | 15 % | 3 | 3 | 5 |
| Cadencia de mejora planificada | 15 % | 5 | 2 | 3 |
| Puntaje ponderado | 100 % | 3,00 | 4,25 | 3,10 |
Decisión: Kanban para gestionar el flujo diario, principios Lean para eliminar los desperdicios del diagnóstico y una retrospectiva cada dos semanas tomada de Scrum para cubrir la mejora periódica.
9. Aplicación de metodologías ágiles
Scrum organiza la construcción de las mejoras en cuatro sprints, y Kanban y Lean rigen la operación diaria de la mesa de ayuda una vez implementadas.
Backlog de mejoras (Scrum). Velocidad supuesta: 12 puntos por sprint de dos semanas.
| ID | Historia de mejora | Prioridad | Puntos | Sprint |
|---|---|---|---|---|
| H1 | Como cliente, quiero reportar por cualquier canal y que se cree un ticket automático, para que mi solicitud no se pierda | Alta | 8 | 1 |
| H3 | Como técnico, quiero ver la urgencia y el plazo de cada ticket, para atender primero lo crítico | Alta | 3 | 1 |
| H2 | Como coordinador, quiero reglas de asignación por tipo y carga, para no asignar a mano | Alta | 5 | 2 |
| H5 | Como cliente, quiero confirmar el cierre, para evitar que el caso se reabra | Media | 3 | 2 |
| H4 | Como técnico, quiero escalar un ticket a segundo nivel dentro del sistema, para tener seguimiento | Media | 5 | 3 |
| H7 | Como gerente, quiero un reporte mensual de cumplimiento de SLA, para decidir con datos | Baja | 3 | 3 |
| H6 | Como técnico, quiero consultar una base de conocimiento, para no repetir diagnósticos | Media | 8 | 4 |
Roles: el coordinador es Product Owner, un técnico senior es Scrum Master y los otros cinco técnicos forman el equipo de desarrollo. Eventos: planificación al inicio de cada sprint, revisión y retrospectiva al final.
Tablero Kanban de la operación.
| Columna | Límite de trabajo en curso | Regla de salida |
|---|---|---|
| Nuevo | Sin límite | El ticket tiene cliente, canal y descripción |
| Clasificado | 10 | Tiene categoría y urgencia; el sistema lo asigna |
| En atención | 6 (uno por técnico) | El técnico aplicó una solución |
| Esperando cliente o 2.º nivel | 4 | Llegó la respuesta o el repuesto |
| Resuelto, por confirmar | 8 | El cliente confirma o pasan 48 horas |
| Cerrado | Sin límite | Queda registrado en el historial |
Los tickets urgentes usan un carril expreso: se atienden antes que el resto y pueden superar el límite de «En atención» en una unidad.
Desperdicios Lean (muda) y acciones.
| Desperdicio | Dónde ocurre | Acción |
|---|---|---|
| Espera | El ticket espera al coordinador para ser asignado | Asignación por reglas |
| Re-trabajo | 20 % de incidencias reabiertas | Confirmación de cierre y lista de verificación de solución |
| Sobreprocesamiento | Se anota la incidencia en la hoja y en el correo | Registro único en el sistema de tickets |
| Movimiento | Se busca el historial entre correos y chats | Historial completo dentro del ticket |
| Conocimiento sin uso | Se repite el diagnóstico de problemas conocidos | Base de conocimiento con las 20 incidencias más frecuentes |
| Defectos | Clasificación errónea que envía el caso al técnico equivocado | Catálogo cerrado de categorías |
10. Plan de implementación
La implementación dura seis meses en cuatro fases, y cada fase avanza solo si cumple su criterio de salida.
| Fase | Duración | Entregable | Criterio de salida |
|---|---|---|---|
| 1. Preparación | Semanas 1 a 2 | Sistema de tickets elegido y categorías definidas | Catálogo de categorías aprobado por el coordinador |
| 2. Construcción | Semanas 3 a 10 | Mejoras H1 a H6 entregadas en cuatro sprints | Los cuatro sprints revisados con el equipo |
| 3. Piloto | Semanas 11 a 14 | Cinco clientes atendidos con el proceso nuevo | Tiempo medio de resolución menor a 12 h en el piloto |
| 4. Despliegue y mejora | Semanas 15 a 26 | Los 60 clientes en el sistema; retrospectiva cada dos semanas | Metas de los cuatro indicadores alcanzadas |
Riesgos y respuesta.
| Riesgo | Probabilidad | Impacto | Respuesta |
|---|---|---|---|
| Los técnicos siguen usando WhatsApp y la hoja de cálculo | Alta | Alto | Capacitación de medio día y regla: lo que no está en el ticket no existe |
| El coordinador siente que pierde control | Media | Medio | Nuevo rol de dueño del producto, con reportes de SLA |
| Los clientes no adoptan el aviso de cierre | Media | Medio | Cierre automático a las 48 horas sin respuesta |
| El presupuesto de la herramienta es insuficiente | Baja | Alto | Empezar con una herramienta gratuita o de bajo costo y migrar si se justifica |
Gestión del cambio. Se comunica el motivo del cambio antes de la capacitación, se nombra a dos técnicos como líderes del cambio y se mide la adopción con el porcentaje de incidencias registradas (meta: 100 %).
11. Conclusiones y referencias
El rediseño ataca los tres problemas de mayor prioridad (asignación manual, registro manual y falta de clasificación) y, si se cumplen las metas, reduce el tiempo de resolución de 18 a 8 horas hábiles. Kanban resulta la metodología más adecuada porque el trabajo llega a diario y no se puede planificar por sprints; Scrum sirve para construir las mejoras y Lean para eliminar los desperdicios. Todas las cifras de la empresa son supuestos del caso.
Referencias del sílabo utilizadas como base:
- Pérez Fernández de Velasco, J. A. (2010). Gestión por procesos (4.ª ed.). ESIC.
- Cruelles Ruiz, J. A. (2013). Stock, procesos y dirección de operaciones. Marcombo.
- Villajuana, C. Gestión estratégica integral. Texto en línea.