Llega un aviso: un usuario no puede iniciar sesión, una impresora no funciona, un servidor da errores. Alguien del servicedesk lo convierte en un ticket, elige una categoría y determina la urgencia. ¿Puede la IA hacerse cargo de esto? En gran medida sí, con una excepción importante que varía según la empresa.
Tres ejes son decisivos: volumen, margen de criterio y contacto con el cliente.
El volumen es alto. Un servicedesk procesa diariamente decenas o cientos de avisos, y muchos de ellos son variaciones de un pequeño número de problemas conocidos: contraseña olvidada, sin acceso a una unidad compartida, el portátil no arranca. Con volúmenes altos y repetición, una tarea es por definición adecuada para automatizar, porque un modelo aprende de patrones que se repiten con frecuencia.
El margen de criterio es limitado. La urgencia y la categoría suelen derivarse de un árbol de decisión: cuántos usuarios se ven afectados, hay una solución provisional, de qué sistema se trata. Es exactamente el tipo de trabajo en el que los modelos de texto son buenos: leer un aviso, extraer las características y compararlas con un modelo de categorización. Lo que la IA puede manejar hoy en día es el texto — los avisos mismos, a menudo escritos en términos libres por el usuario, y la traducción de eso a un ticket estructurado.
El contacto con el cliente es funcional, no relacional. Un usuario que informa de una avería sobre todo quiere que se atienda, no que se genere una conversación. Esto cambia en cuanto algo sale mal o se vuelve delicado — véase para ello también cómo se comunica una avería hacia los usuarios, pues se trata de otra tarea con otro perfil.
El componente físico no juega ningún papel: se trata de trabajo administrativo frente a una pantalla, no de una acción sobre equipos. Los costes de error son medios. Un aviso mal priorizado rara vez provoca daños directos, pero en sistemas sujetos a cumplimiento normativo — un sistema financiero, un historial de paciente — la situación es distinta, y por ello el eje de cumplimiento normativo puntúa aquí por encima de la media. Una avería en un entorno con obligación legal de notificación requiere un motivo documentado para la clasificación, no solo una etiqueta.
El punto débil es la creatividad, y precisamente por eso no se trata de una sustitución total. Un aviso que no encaja en el patrón conocido — una combinación nueva de síntomas, un sistema que falla por primera vez, un usuario que describe el problema de forma confusa — requiere alguien que piense en lugar de clasificar. Ahí entra en juego la supervisión: la IA propone una categoría y una urgencia, una persona aprueba o corrige, con motivo. Esa es una configuración distinta de la sustitución total, y también es la práctica más habitual entre las empresas que ya trabajan con esto.
En una empresa con un panorama de aplicaciones pequeño y manejable y unos pocos cientos de usuarios, el noventa por ciento de los avisos es una repetición de algo que ya ha ocurrido cien veces. Ahí, un modelo con un buen modelo de categorización puede gestionar de forma autónoma la mayor parte de la recepción, con una persona que solo ve las excepciones.
En una empresa con muchos sistemas heredados, software a medida y un historial de fusiones, el patrón es menos predecible. Los avisos son más diversos, las categorías están menos claramente definidas, y la probabilidad de que un aviso quede fuera del patrón conocido es mayor. Ahí una parte mayor del trabajo sigue recayendo en una persona, no porque la IA no quiera hacerlo, sino porque la entrada es demasiado poco estructurada para convertirla automáticamente en algo fiable.
La condición previa, por tanto, no es la tecnología sino la recepción: formularios de recepción estructurados y un modelo de categorización de incidentes bien desarrollado determinan en gran medida cuánto de este trabajo ya se puede transferir hoy. Sin esos dos elementos, la mayor parte sigue siendo trabajo manual, con la IA como herramienta de apoyo en lugar de ejecutora.
Esto no es un consejo de personal ni una justificación para reducir un equipo de servicedesk. Si una organización extrae o no consecuencias de personal a partir de un trabajo que cambia, y cómo lo hace, es decisión del empleador, y para ello se aplican requisitos legales propios; véase para el cuidado que corresponde en ese proceso los puntos de atención al suprimir puestos de trabajo. Esta página describe únicamente lo que sucede con la tarea en sí.
También es útil no ver esta tarea de forma aislada del resto de la operación de TI. El registro de incidentes está relacionado con trabajo como la monitorización del rendimiento de sistemas, que a menudo da las señales tempranas antes de que exista un aviso, y con tareas de gestión como la ejecución y el control de copias de seguridad o el mantenimiento actualizado de los datos maestros, que comparten la misma combinación de volumen alto y margen de criterio limitado. Quien quiera saber, para todo el departamento de TI, dónde ya se está produciendo el cambio, hace mejor en observar todas las tareas en conjunto, no un solo proceso de tickets.
El resultado para su propio servicedesk depende de cuántos de sus avisos encajan en patrones reconocibles y de lo bien estructurada que ya esté su recepción. Esto varía según la empresa y no se puede determinar con una regla fija.
El análisis rápido gratuito de FTE TO AI ofrece una primera indicación al respecto: doce preguntas, sin necesidad de cuenta, con una indicación de qué parte de las horas de su perfil se puede transferir hoy a la IA. El análisis de trabajo completo, que calcula el trabajo de toda una empresa tarea por tarea en capacidad de FTE, todavía está en construcción.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.