Incidente, problema, solicitud y cambio no son sinónimos. El incidente restaura un servicio; el problema busca eliminar causas recurrentes; la solicitud entrega algo predefinido; y el cambio controla modificaciones con riesgo. Clasificarlos correctamente evita colas equivocadas, SLAs distorsionados, reincidencias y cambios sin gobierno, y permite automatizar el soporte con mayor precisión.
Definiciones taxonómicas
1. Incidente
Es una interrupción o degradación no prevista de un servicio que requiere recuperar la operación. La prioridad no debería depender únicamente de quién reporta, sino del impacto sobre el negocio y la urgencia de restauración.
PeopleCert señala que Incident Management busca minimizar el impacto negativo restaurando la operación normal del servicio tan pronto como sea posible.
Pregunta para identificarlo: ¿Algo que debería funcionar dejó de funcionar o funciona peor de lo esperado?
Ejemplos:
- Un usuario no puede ingresar al ERP.
- Un POS dejó de procesar ventas.
- La VPN corporativa presenta una caída.
- Una impresora crítica de producción dejó de operar.
- Una aplicación responde con una degradación significativa.
2. Problema
Es la investigación de la causa real o potencial de uno o varios incidentes. Su objetivo no es simplemente restaurar; es disminuir la probabilidad y el impacto de que la falla vuelva a presentarse.
PeopleCert describe Problem Management como la práctica que identifica causas reales o potenciales, administra workarounds y errores conocidos y busca reducir la recurrencia y el impacto de los incidentes.
Pregunta para identificarlo: ¿Estamos resolviendo nuevamente el mismo síntoma sin entender por qué ocurre?
Ejemplos:
- La VPN falla todos los lunes después de una actualización.
- Ciertas cajas POS pierden conectividad repetidamente.
- Usuarios de una misma sede experimentan bloqueos recurrentes.
- Un servicio se recupera reiniciándolo, pero vuelve a caer días después.
3. Solicitud de servicio
Es una petición iniciada por el usuario para obtener una prestación predefinida y normalmente catalogada, no para corregir una falla.
PeopleCert define Service Request Management alrededor de solicitudes predefinidas iniciadas por usuarios y entregadas de forma controlada y amigable.
Pregunta para identificarla: ¿El usuario está pidiendo algo nuevo o previamente definido, en lugar de reportar algo que dejó de funcionar?
Ejemplos:
- Alta de un usuario.
- Instalación autorizada de software.
- Solicitud de acceso a una aplicación.
- Cambio de equipo.
- Restablecimiento rutinario de credenciales.
- Solicitud de información.
¿Y el cambio?
Conviene hacer una distinción importante: un cambio no es simplemente una cuarta variante de ticket. Es una actividad gobernada para modificar un producto, servicio, configuración o componente que puede afectar la operación.
Change Enablement busca incrementar la proporción de cambios exitosos mediante evaluación de riesgos, autorización y administración del calendario de cambios.
Un incidente, problema o solicitud puede originar un cambio sin dejar de ser lo que originalmente era.
Ese pequeño matiz evita bastantes dolores de cabeza —y unos cuantos CAB eternos.
Incidente, problema, solicitud o cambio: cómo distinguirlos
| Clasificación | Pregunta principal | Objetivo operativo | ¿Cómo se prioriza? | Ejemplo | KPI principal |
| Incidente | ¿Algo dejó de funcionar? | Restaurar el servicio | Impacto × urgencia | ERP inaccesible | MTTR / tiempo a productividad |
| Problema | ¿Por qué ocurre o se repite? | Eliminar o controlar la causa | Frecuencia × impacto × riesgo | Caídas recurrentes del ERP | Recurrencia / problemas eliminados |
| Solicitud | ¿El usuario está pidiendo algo previsto? | Entregar un servicio estándar | Catálogo, perfil y SLA | Alta de acceso | Tiempo de cumplimiento / % automatizado |
| Cambio | ¿Debemos modificar producción o configuración? | Ejecutar una modificación con riesgo controlado | Riesgo × impacto × ventana | Modificar una política de acceso | Tasa de éxito / fallas por cambio |
La separación es consistente con la estructura actual de ITIL: Incident Management, Problem Management y Service Request Management se agrupan dentro de las prácticas de soporte y cumplimiento, mientras que Change Enablement forma parte del bloque orientado a planear, implementar y controlar modificaciones.
¿Por qué clasificar correctamente los tickets impacta al negocio?
Una clasificación incorrecta parece un detalle administrativo hasta que se analiza qué ocurre después.
Si una interrupción crítica entra como solicitud, puede quedar atrapada en un SLA que no corresponde a su impacto. Si un problema recurrente continúa registrándose únicamente como incidentes independientes, el equipo seguirá restaurando el servicio sin eliminar la causa. Y si una modificación productiva se ejecuta sin Change Enablement, TI pierde trazabilidad sobre riesgo, autorización y resultado.
En Kenos by Scanda partimos de una idea sencilla: cerrar el ticket no equivale necesariamente a devolver productividad. Nuestro marco operativo prioriza disponibilidad, tiempo a productividad, recurrencia, resolución sin intervención humana y costo por punto operando, en lugar de limitar la lectura del soporte al volumen de tickets cerrados.
La clasificación afecta directamente:
- CIO: calidad de los SLAs, backlog, capacidad y MTTR.
- COO: tiempo durante el cual una tienda, planta, sucursal o área permanece detenida.
- CFO: costo real por interacción, productividad perdida y retorno de automatización.
- CISO: trazabilidad de accesos, cambios, configuraciones y evidencia.
- Dirección: capacidad de distinguir actividad operativa de mejora real.
¿Cómo clasificar un ticket paso a paso?
Paso 1. Pregunta si existe una interrupción o degradación
La primera pregunta debería ser: ¿El usuario podía realizar esta actividad antes y ahora no puede hacerlo?
Si la respuesta es sí, probablemente existe un incidente. Ejemplo: “No puedo entrar a SAP y hace una hora sí podía.”
Incidente.
Pero:
“Necesito que me den acceso a SAP porque me incorporé al área de Finanzas.”
Solicitud.
Las dos frases contienen “acceso a SAP”, pero operativamente son completamente distintas.
Paso 2. Determina el impacto sobre el negocio
No todos los incidentes deberían competir en la misma cola.
Clasificar correctamente implica agregar contexto:
- Número de usuarios afectados.
- Sede o ubicación.
- Proceso de negocio.
- Aplicación o servicio.
- Horario crítico.
- Ingreso o productividad afectada.
- Existencia de workaround.
- Dependencias.
- Riesgo regulatorio o contractual.
En nuestro modelo de Service Desk, la priorización se realiza por impacto y criticidad, no simplemente por orden de llegada. Integramos incidentes, solicitudes, problem management, RCA, major incident management, catálogo, automatización y escalamiento L1-L3 dentro del mismo gobierno operativo.
Paso 3. Busca recurrencia antes de cerrar
Resolver un incidente no significa necesariamente haber resuelto el problema.
Antes del cierre conviene preguntar:
- ¿Ha ocurrido antes?
- ¿Afectó al mismo servicio?
- ¿Existe un patrón por sede, equipo, versión o horario?
- ¿Se utilizó nuevamente el mismo workaround?
- ¿Tenemos causa raíz identificada?
- ¿Existe un known error relacionado?
Cuando el patrón existe, además del incidente debe abrirse o vincularse un registro de problema.
Esto cambia la conversación:
Incidente: “Volvimos a ponerlo en línea.”
Problema: “¿Qué tenemos que cambiar para que no vuelva a caer?”
PeopleCert también vincula Problem Management con el análisis de incidentes recurrentes y sus causas como mecanismo para reducir futuras interrupciones.
Paso 4. Separa solicitudes de fallas
Las solicitudes tienen una ventaja operativa enorme: normalmente son predecibles.
Precisamente por eso son candidatas naturales para:
- Catálogos.
- Formularios estructurados.
- Aprobaciones.
- Knowledge.
- Workflows.
- Runbooks.
- Automatización.
- Autoservicio.
- Agentes de IA.
Un password reset estándar no debería consumir el mismo modelo operativo que la caída de un sistema financiero crítico.
En Kenos by Scanda utilizamos esta separación para dirigir la automatización hacia las interacciones repetitivas mientras mantenemos capacidad humana para situaciones donde el contexto y el impacto justifican intervención especializada. Nuestro modelo contempla bots, runbooks, knowledge, autoservicio cognitivo y automatización de solicitudes repetitivas.
Paso 5. Pregunta si la resolución requiere modificar el entorno
Aquí aparece el cambio. Supongamos que una aplicación falla. El flujo puede ser:
Incidente
↓
se restaura temporalmente
↓
el análisis encuentra una configuración incorrecta
↓
se abre un problema
↓
la solución definitiva requiere modificar producción
↓
se genera un cambio
Son registros relacionados, no cuatro nombres diferentes para el mismo ticket. Change Enablement debe aportar, de acuerdo con el nivel de riesgo:
- Evaluación del impacto.
- Riesgo de implementación.
- Autorización.
- Ventana.
- Responsables.
- Plan de implementación.
- Validación.
- Plan de reversa.
- Evidencia posterior.
PeopleCert señala que los cambios estándar pueden ser preautorizados y repetibles, mientras que los normales requieren evaluación y aprobación y los de emergencia responden a situaciones que exigen intervención inmediata.
Los casos que más se confunden en una mesa de servicio
| Situación | Clasificación correcta | Razón |
| “Olvidé mi contraseña y necesito restablecerla” | Solicitud | Es una prestación estándar iniciada por el usuario |
| “Mi contraseña correcta dejó de funcionar para todos los usuarios” | Incidente | Existe una interrupción no prevista |
| “Cada lunes se bloquean las cuentas de la misma área” | Incidente + problema | Hay que restaurar hoy e investigar la recurrencia |
| “Necesito acceso a una nueva aplicación” | Solicitud | El usuario solicita una nueva prestación |
| “La solución definitiva requiere modificar una política en producción” | Cambio vinculado | La modificación debe evaluar riesgo y autorización |
| “El último despliegue provocó una caída” | Incidente + cambio relacionado | Hay que restaurar el servicio y conservar trazabilidad del cambio que lo originó |
| “Hay que aplicar un hotfix urgente para recuperar producción” | Incidente + cambio de emergencia | Recuperación y modificación requieren controles distintos |
Regla práctica
No clasifiques por la acción técnica; clasifica primero por lo que ocurrió al negocio. “Reiniciar servidor” no es una clasificación. Puede ser:
- La acción de recuperación de un incidente.
- Un workaround de un problema.
- Una tarea dentro de un cambio.
- Una actividad automatizada de un runbook.
¿Cuándo un incidente debe generar un problema?
No todos los incidentes justifican problem management. Conviene escalar cuando existe alguno de estos patrones:
- Alta frecuencia.
- Alto impacto económico.
- Major incident.
- Workaround utilizado repetidamente.
- Causa desconocida con riesgo relevante.
- Mismo síntoma en múltiples sedes.
- Patrón asociado a una versión, dispositivo o configuración.
- Incidente originado por cambios fallidos.
- Riesgo de incumplimiento.
En Kenos by Scanda llamamos Mejorar al movimiento en el que cada incidente alimenta conocimiento, analítica y automatización. Una señal clara de baja madurez es que el mismo incidente continúe apareciendo trimestre tras trimestre sin RCA, cambio correctivo o automatización asociada.
¿Cómo medir el costo de una mala clasificación?
La clasificación debe terminar conectándose con unit economics.
Para incidentes: costo del incidente = minutos de indisponibilidad × valor económico por minuto + productividad perdida + costo de recuperación + penalizaciones o impacto contractual. Una medición particularmente útil es el tiempo a productividad: cuánto tarda el usuario o punto de servicio en volver a operar, en lugar de cuánto tarda TI en cerrar administrativamente el ticket.
Ese indicador forma parte del tablero operativo que utilizamos en Kenos by Scanda.
Para problemas: puede medirse: Incidentes recurrentes evitables × costo promedio de cada incidente. Además de:
- Frecuencia de reincidencia.
- Tiempo hasta causa raíz.
- Número de known errors.
- Incidentes asociados por problema.
- Reducción posterior a la remediación.
Para solicitudes: las métricas relevantes cambian:
- Tiempo medio de fulfillment.
- Costo por solicitud.
- % automatizado.
- % autoservicio.
- Tasa de abandono.
- Reaperturas.
- Intervención humana requerida.
Para cambios: la conversación debe enfocarse en:
- Tasa de cambios exitosos.
- Cambios que generan incidentes.
- Rollbacks.
- Cambios de emergencia.
- Tiempo de implementación.
- Costo del cambio fallido.
Esto permite llegar a algo que dirección sí puede discutir: costo, capacidad liberada, riesgo y productividad, no simplemente “tickets verdes”.
Qué datos debe ver dirección
Un dashboard ejecutivo no necesita todas las métricas del ITSM. Necesita aquellas que indiquen si la operación está mejorando.
Recomendamos observar conjuntamente:
| Métrica | Qué responde |
| Tiempo a productividad | ¿Cuánto tarda realmente el usuario en volver a trabajar? |
| MTTR | ¿Estamos restaurando más rápido? |
| FCR | ¿Qué tanto resolvemos sin escalar? |
| Reincidencia | ¿Estamos eliminando causas o repitiendo trabajo? |
| % de solicitudes automatizadas | ¿La automatización está liberando capacidad? |
| % sin intervención humana | ¿Cómo está evolucionando la economía del soporte? |
| Change failure rate | ¿Los cambios están introduciendo nueva fricción? |
| Incidentes provocados por cambios | ¿Existe control real del cambio? |
| Costo por tipo de interacción | ¿Dónde está consumiéndose el presupuesto? |
Nuestro documento maestro de Kenos incluso propone medir incidentes evitados, visitas evitadas por diagnóstico remoto, porcentaje de resolución sin intervención humana y costo por punto operando, métricas que trasladan el Service Desk desde actividad hacia resultados.
¿Cómo automatizar la clasificación con IA sin perder gobierno?
La IA aporta valor cuando existe una taxonomía sólida. Si la clasificación de origen está mal diseñada, automatizarla solo permite equivocarse con admirable velocidad.
Una arquitectura práctica debería hacer lo siguiente:
1. Clasificar la intención
Identificar si el texto representa:
- Interrupción.
- Solicitud.
- Recurrencia.
- Consulta.
- Acceso.
- Evento de seguridad.
- Posible cambio.
2. Enriquecer el registro
Cruzar automáticamente contexto:
- Usuario.
- Aplicación.
- Dispositivo.
- CMDB.
- Ubicación.
- Servicio de negocio.
- Historial.
- Incidentes similares.
- Cambios recientes.
3. Asignar impacto
“No abre SAP” cambia por completo si afecta:
- a una persona,
- a Finanzas,
- a toda una planta,
- o al cierre mensual.
4. Recomendar resolución o ruta
La IA puede decidir entre:
- Autoservicio.
- Knowledge.
- Runbook.
- L1.
- L2.
- L3.
- Problem Management.
- Major Incident.
- Change Enablement.
5. Conservar intervención humana donde agrega valor
En nuestro enfoque de mesa de servicio AI-native utilizamos IA para clasificación, enriquecimiento y resolución guiada, de forma que la intervención humana entre donde realmente aporta contexto o capacidad técnica.
El mercado también se está moviendo en esa dirección. El reporte de PeopleCert sobre IA en herramientas ITSM señala que incidentes, problemas y request fulfillment concentran especial interés por su volumen y potencial de automatización y ahorro de tiempo.
¿Qué impacto puede tener en TCO y ROI?
Clasificar correctamente no genera ROI por arte de magia. Lo que hace es crear la estructura necesaria para identificar qué se puede estandarizar, automatizar, prevenir y eliminar. Tenemos evidencia interna que ayuda a dimensionar ese efecto.
En un caso de Service Desk para retail documentado por Kenos by Scanda, 30% de las interacciones fueron automatizadas y se obtuvo una reducción de 20% en TCO. Nuestro Documento Maestro también registra un caso anonimizado de $2.5 millones de pesos de ahorro anual mediante automatización de soporte, identificado internamente como un proof point apto para comunicación anonimizada.
Estos resultados no significan que clasificar tickets por sí solo produzca esos porcentajes. Sí muestran por qué una operación que separa solicitudes repetitivas, incidentes, recurrencias y cambios puede detectar mucho mejor dónde automatizar y dónde atacar costo estructural.
Conclusión predictiva
La siguiente evolución del Service Desk no será tener más categorías: será usar mejor las relaciones entre ellas. A medida que los agentes de IA absorban más interacciones repetitivas, la taxonomía se convertirá en una capa de gobierno. Las organizaciones que sigan metiendo incidentes, solicitudes, causas recurrentes y modificaciones bajo el mismo concepto de “ticket” automatizarán volumen; las que relacionen incidente → problema → cambio y solicitud → fulfillment automatizado podrán automatizar resultados.
En Kenos by Scanda consideramos que la métrica decisiva dejará de ser cuántos tickets cerró la mesa y será cada vez más: qué porcentaje del trabajo evitó, automatizó o devolvió productividad al negocio.
Por eso nuestra operación conecta Service Desk, IA, knowledge, RCA, automatización, SLAs/XLAs y métricas ejecutivas. El objetivo no es administrar tickets: es reducir la fricción que impide cobrar, producir, atender o trabajar.
Deja de medir tickets. Empieza a medir productividad recuperada. En Kenos by Scanda ayudamos a convertir la mesa de servicio en una operación orientada a continuidad y resultados: clasificamos y priorizamos por impacto, automatizamos interacciones repetitivas, conectamos incidentes con RCA y Problem Management, y usamos analítica e IA para reducir recurrencias y tiempos muertos.
Si hoy tu mesa no puede decir con precisión cuánto atiende, cuánto evita, cuánto automatiza y cuánto tiempo productivo devuelve al negocio, el primer paso es construir esa línea base. Agenda una sesión con nosotros para identificar las principales fricciones de tu Service Desk y definir los indicadores que realmente deberían llegar al CIO, COO y CFO.
FAQ
1. ¿Un incidente puede convertirse en un problema? Sí, pero técnicamente es mejor mantener registros relacionados. El incidente gestiona la recuperación del servicio; el problema investiga y controla la causa. Un incidente recurrente o de alto impacto puede justificar la apertura de un problema sin perder el historial del incidente original.
2. ¿Toda solicitud de servicio requiere un cambio? No. Muchas solicitudes pueden resolverse mediante un workflow, automatización o procedimiento estándar. Si para cumplirla es necesario modificar un componente o configuración del entorno con impacto potencial sobre servicios, entonces puede generarse un cambio vinculado y aplicarse el nivel de control correspondiente.
3. ¿Qué métricas debería presentar un CIO o CFO para saber si la clasificación funciona? Más que contar tickets, recomendamos monitorear tiempo a productividad, MTTR, FCR, reincidencia, porcentaje de solicitudes automatizadas, resolución sin intervención humana, incidentes asociados a cambios y costo por tipo de interacción. Una buena clasificación hace visibles estos unit economics y permite justificar automatización y mejora continua.
