«Shift-left» es probablemente uno de los términos más utilizados —y también más manidos— en ITSM. Hace referencia a la tendencia a resolver los problemas lo antes posible dentro de la cadena de soporte, con el objetivo de contener costes. La idea resulta convincente y, sobre el papel, difícil de rebatir. El problema es que muchas organizaciones tratan el shift-left como un fin en sí mismo —un proyecto que poner en marcha o una herramienta que implementar— en lugar de entenderlo como el resultado de unos prerrequisitos operativos ya consolidados.
Desplazar los tickets hacia los niveles menos costosos de la cadena de soporte —el movimiento «hacia la izquierda» del que toma su nombre esta práctica— no genera ningún ahorro si no se dan al mismo tiempo tres condiciones: una base de conocimiento de calidad, un autoservicio bien diseñado y una automatización madura del service desk.
El análisis que sigue pretende situar el shift-left en el lugar que realmente le corresponde. Para las organizaciones ITSM, debe ser un punto de llegada sustentado en unos cimientos operativos sólidos, y no una solución tecnológica que implantar al principio del camino.
La matemática que hace imprescindible el shift-left
El interés por el shift-left se basa en una realidad muy concreta en términos de costes: el coste por ticket aumenta de forma considerable a medida que se avanza hacia niveles de soporte más especializados, desde el service desk de primer nivel hasta el soporte prestado por proveedores externos.
Según los benchmarks de MetricNet, en Norteamérica un ticket atendido por un service desk de Nivel 1 cuesta aproximadamente 22 dólares, mientras que el mismo problema, resuelto mediante autoservicio en el Nivel 0, cuesta alrededor de 2 dólares. A medida que se asciende en la cadena de soporte, el soporte de escritorio (Nivel 2) cuesta unos 70 dólares, el soporte de TI de Nivel 3 alrededor de 100, el soporte de campo unos 220 y el soporte del proveedor puede alcanzar los 600 dólares por ticket. MetricNet identifica también un «Nivel -1» —el punto más a la izquierda de todos—: la prevención de incidentes mediante la gestión de problemas, que evita que lleguen a generarse tickets que, de otro modo, acabarían entrando en el sistema.
En la práctica, cuantos más tickets consigamos desplazar hacia la izquierda —por ejemplo, de un restablecimiento de contraseña atendido por un agente, con un coste de 22 dólares, a uno automatizado que cuesta 2—, mayor será la reducción del coste total. En esta diferencia de costes se basa la promesa de ahorro asociada al shift-left: cada solicitud resuelta en un nivel inferior cuesta menos. Sin embargo, esta lógica solo se cumple con una condición: que la solicitud se resuelva realmente en ese nivel y no se limite a ser transferida.
Cuando el shift-left aumenta los costes en lugar de reducirlos
El ahorro por ticket presupone una resolución real, no un simple redireccionamiento. Una solicitud enviada al autoservicio que después regresa al Nivel 1 —porque el artículo de la base de conocimiento era impreciso, el portal resultaba poco intuitivo o la automatización estaba mal diseñada— no cuesta 2 dólares, sino 2 dólares más los 22 dólares del Nivel 1, a los que puede sumarse además el coste de una posible escalada. Un shift-left prematuro puede, por tanto, incrementar el coste total del problema: reduce la proporción de solicitudes resueltas en el primer contacto y aumenta los contactos repetidos por la misma consulta.
Precisamente por eso, una iniciativa de shift-left impulsada únicamente por el objetivo de reducir costes suele producir el efecto contrario. Un canal de autoservicio diseñado solo para contener el gasto suele registrar una baja adopción y no ofrecer los beneficios esperados. Cuando los usuarios no encuentran una respuesta, terminan recurriendo a soluciones fuera de los canales oficiales.
Así lo confirma el estudio de TeamViewer sobre fricción digital: el 54 % de los empleados afirma no sentirse capaz de resolver por sí solo los problemas técnicos. Es una señal de que un autoservicio mal mantenido acaba infrautilizado y obliga a los usuarios a recurrir igualmente al soporte. El resultado es la paradoja que cualquier responsable de ITSM debería querer evitar: mejoran las métricas de volumen, mientras empeoran la experiencia real de los usuarios y el coste efectivo por problema resuelto.
Checklist de prerrequisitos
Para que la redistribución de tickets entre los distintos niveles de soporte sea realmente viable, deben cumplirse de antemano tres condiciones: los verdaderos factores que hacen posible el shift-left.
1. Conocimiento preciso y accesible
La base de conocimiento es uno de los activos más importantes de la cadena de valor de ITSM. Sin embargo, no basta con «capturar» conocimiento: su valor está en utilizarlo, no simplemente en almacenarlo. Metodologías consolidadas como Knowledge-Centered Service (KCS) existen precisamente para mantener los artículos actualizados, relevantes y realmente útiles para resolver problemas. Esta es la condición necesaria para que un problema pueda considerarse «Level Zero Solvable», es decir, resolverse de forma autónoma en el Nivel 0.
2. Gestión eficaz en el Tier 0 y el Tier 1
El Nivel 0 (autoservicio) y el Nivel 1 deben diseñarse en función de las necesidades reales de los usuarios, no de las funcionalidades del software. Un portal fácil de utilizar, con una búsqueda eficaz y preguntas frecuentes bien planteadas, y un primer nivel que disponga de las herramientas y la autonomía necesarias para resolver y cerrar tickets sin tener que escalarlos: aquí es donde se decide, en gran medida, el éxito o el fracaso del shift-left.
3. Ciclos de feedback cerrados entre niveles
Cada vez que un nivel superior resuelve un problema nuevo, la solución encontrada debe documentarse y ponerse a disposición de los niveles inferiores, para que pueda reutilizarse de forma autónoma en el futuro. El proceso se desarrolla en cuatro etapas: documentar, buscar, corregir y resolver. Sin este flujo continuo de transmisión del conocimiento, la base de conocimiento va quedando progresivamente desactualizada, lo que acaba reduciendo la eficacia del shift-left.
Gestión del cambio organizativo
A estos tres prerrequisitos se suma un cuarto, a menudo pasado por alto: la gestión del cambio organizativo. El shift-left implica un cambio en la forma de trabajar y exige revisar también los criterios de evaluación y los incentivos de los equipos. Sin este cambio, la gestión del conocimiento, el autoservicio y la automatización siguen siendo simples herramientas que nunca llegan a adoptarse de verdad.
Es precisamente en estos prerrequisitos donde los responsables de TI deberían medir primero su rendimiento, antes incluso de fijarse en el volumen de tickets. La tasa de resolución en el primer contacto, el porcentaje de problemas «Level Zero Solvable» y la tasa de reapertura de tickets indican, mejor que cualquier recuento de tickets redirigidos, si el shift-left está funcionando realmente.
IA y shift-left: beneficios reales y costes ocultos
La inteligencia artificial y, en particular, los grandes modelos de lenguaje (LLM) están cambiando la economía del shift-left, aunque no necesariamente de la forma en que muchos esperan. Utilizada correctamente, la IA puede aumentar de forma significativa la capacidad de resolución del Nivel 1. Gartner identifica el apoyo al agente (agent enablement) como uno de los casos de uso más eficaces: resúmenes automáticos de tickets, respuestas rápidas y sugerencias de siguiente mejor acción (next-best action) que ahorran tiempo al agente sin sacrificar la precisión.
Del mismo modo, un LLM puede generar borradores de artículos para la base de conocimiento a partir de tickets resueltos, ampliando rápidamente el conocimiento disponible para el Tier 0 y el Tier 1 y acelerando la automatización del service desk.
Los costes invisibles de una automatización sin bases sólidas
La otra cara de la moneda es una automatización mal diseñada que genera costes adicionales en etapas posteriores. Un asistente conversacional basado en una base de conocimiento de baja calidad no resuelve el problema: se limita a redirigir la solicitud —a menudo de forma incorrecta— y puede ofrecer respuestas imprecisas con una seguridad engañosa, erosionando la confianza de los usuarios y aumentando los contactos repetidos. No es casualidad que, en el informe de TeamViewer mencionado anteriormente, el 32 % de los encuestados afirme que las soluciones de IA que probaron no funcionaron.
Aun así, el potencial sigue siendo enorme: Gartner estima que, para 2029, la IA agéntica podrá resolver de forma autónoma el 80 % de los problemas de servicio más comunes, con una reducción aproximada del 30 % de los costes operativos. Sin embargo, estos resultados solo son alcanzables cuando el Nivel 0 y el Nivel 1 ya se apoyan en unos fundamentos sólidos. De lo contrario, la automatización del service desk se limita a reproducir a gran escala los errores que ya existen.
El shift-left como indicador de madurez
Para los responsables de TI que deben demostrar el impacto de la tecnología en los resultados de negocio —y no limitarse al cumplimiento de los SLA—, el shift-left debe entenderse como el resultado de unos prerrequisitos consolidados, no como un punto de partida. Hay que cuestionar la idea de que basta con redistribuir la carga de soporte y confiar en que la calidad aparecerá por sí sola.
La secuencia debe ser otra: primero, construir los prerrequisitos —conocimiento, autoservicio, automatización y procesos de transmisión y feedback del conocimiento—; después, como consecuencia natural, redistribuir progresivamente los tickets hacia niveles inferiores; y, por último, lograr una reducción sostenible de costes, basada en resoluciones reales y no en simples transferencias.
Entendido de esta forma, el shift-left se convierte realmente en un indicador valioso de la madurez operativa de una organización ITSM.
FAQs
- ¿Qué es el shift-left en ITSM?
Es la práctica de resolver problemas y solicitudes lo más cerca posible del usuario y del momento en que se producen, trasladando tickets desde niveles de soporte más costosos hacia otros de menor coste, hasta llegar al autoservicio de Nivel 0. - ¿Por qué el shift-left puede aumentar los costes en lugar de reducirlos?
El ahorro presupone que el problema se resuelva realmente y no se limite a ser redirigido. Un ticket que vuelve a niveles superiores acumula los costes de las distintas etapas, reduce la tasa de resolución en el primer contacto y aumenta el número de contactos repetidos. - ¿Qué prerrequisitos son necesarios antes de redistribuir los tickets hacia niveles inferiores?
Se necesitan tres: una base de conocimiento precisa y accesible; una gestión eficaz del Tier 0 y del Tier 1 diseñada en función de las necesidades reales de los usuarios; y procesos estructurados que permitan trasladar a los niveles inferiores las soluciones encontradas en los niveles superiores. - ¿Permite la IA prescindir de los prerrequisitos del shift-left?
No. La IA amplifica las condiciones existentes: con una base de conocimiento sólida, puede acelerar la automatización del service desk; con una base de baja calidad, puede generar respuestas erróneas, aumentar los contactos repetidos y erosionar la confianza de los usuarios.
