Recommended resources
The freely available resources this lesson will direct you to.
Hola. En la lección anterior distinguimos entre poner una solución a disposición de las personas, conseguir una primera tarea útil, incorporarla al trabajo habitual y comprobar que aporta valor. Ahora retrocedemos un paso: ¿qué tarea concreta merece cambiar? Si no conocemos el trabajo tal como se hace hoy, es fácil desplegar una herramienta que nadie necesita en el momento adecuado.
En unos 40 minutos aprenderás a dibujar un flujo de trabajo real, detectar dónde se concentra la fricción y decidir si una tarea pide una mejora del proceso, una automatización convencional, asistencia con IA o automatización con IA. Usaremos consultas de soporte en formación como hilo conductor y veremos cómo contrastar nuestras impresiones con datos.
Primero, entender el trabajo que existe
Un flujo de trabajo no es una lista de funciones de una aplicación. Es el recorrido que sigue un caso —una consulta, una factura o una incidencia— desde que entra hasta que se considera resuelto. Incluye personas, información, decisiones, esperas y excepciones. Para analizarlo, conviene empezar por el estado actual, no por el flujo que querríamos implantar.
Lee «What Is a Workflow?», de IBM, para establecer qué estás delimitando cuando analizas un flujo y cómo validarlo con quienes realizan el trabajo.
En «What is a workflow?», lee la definición. Después, en «Workflow mapping and diagrams», sigue los seis pasos, desde la explicación inicial del mapeo hasta el último paso de la lista. Fíjate especialmente en la delimitación del proceso, los traspasos entre personas y la validación del dibujo con quienes conocen las excepciones.
Imagina que un equipo atiende preguntas de participantes sobre acceso a un curso. «Responder consultas» es demasiado amplio para localizar una oportunidad: mezcla preguntas sencillas, problemas técnicos y asuntos que exigen consultar datos personales. Delimitemos un caso: desde que llega una consulta de acceso hasta que se envía una respuesta o se deriva a soporte especializado.
Un mapa inicial, que habría que verificar con el equipo, podría ser este:
| Paso actual | Quién interviene | Información y resultado |
|---|---|---|
| Recibir la consulta | Sistema de tickets | Mensaje recibido y número de caso. |
| Identificar el problema | Agente de soporte | Categoría provisional: contraseña, enlace, permisos u otro. |
| Comprobar el contexto | Agente de soporte | Estado de acceso y documentación autorizada para ese caso. |
| Preparar una respuesta | Agente de soporte | Instrucciones ajustadas a lo que se ha comprobado. |
| Revisar y resolver | Agente de soporte o especialista | Respuesta enviada, o derivación si el problema continúa. |
| Registrar el resultado | Agente de soporte | Motivo y resolución documentados en el ticket. |
El orden visible no cuenta toda la historia. Una consulta incompleta puede requerir pedir más datos; un fallo de permisos puede necesitar intervención técnica; una explicación redactada puede volver atrás porque la información consultada era antigua. Esas variantes y vueltas suelen revelar más que el recorrido ideal.
Para que el mapa sirva en una conversación con el cliente, anota junto a cada paso cuatro cosas: qué entra y qué sale, quién puede actuar, con qué frecuencia aparece y qué impide avanzar. Distingue además el tiempo de trabajo efectivo del tiempo de espera. Si un ticket pasa dos días esperando una autorización, redactar más rápido la respuesta apenas modificará su tiempo total de resolución.
Localizar fricción sin confundirla con una oportunidad para IA
Con el flujo visible, buscamos síntomas: tareas frecuentes que consumen tiempo, cambios repetidos de aplicación, errores, retrabajo, esperas y pasos que se multiplican en ciertas variantes. Una persona puede señalar dónde le resulta más molesto trabajar; los registros, cuando existen, ayudan a comprobar cuánto ocurre y a quién afecta. Ambas fuentes son útiles, y ninguna sustituye a la otra.
La siguiente imagen muestra un análisis de envío de facturas con cinco grabaciones y tres variantes. Permite ver qué actividades se repiten y cuánto duran de media en esa muestra.
La introducción de datos de la factura aparece con una media de 53,6 segundos; descargar el adjunto del correo, con 48 segundos. Son pistas distintas. La primera podría incluir leer documentos de formatos variables y trasladar campos; la segunda quizá se resuelva mejor con una integración o una regla fija. Antes de proponer nada, preguntaríamos: ¿cuántos casos pasan realmente por cada actividad?, ¿qué errores se producen?, ¿qué ocurre cuando falta un dato?, ¿hay esperas que esta vista no captura? Cinco grabaciones no bastan para generalizar sobre todo el proceso. Tampoco un icono que sugiera automatización demuestra que sea necesaria la IA.
Cuando hay suficientes registros de actividad, la minería de procesos permite contrastar el mapa declarado con los recorridos observados. El siguiente vídeo, en inglés, muestra qué datos hacen falta y por qué mirar solo la duración media puede llevar a elegir mal.
Process Mining in Power Automate
Mira el fragmento de «Process Mining in Power Automate», del canal Henrik Marx on Dynamics 365 and Power Platform, como ejemplo de investigación de un flujo mediante registros; no necesitas aprender a configurar la herramienta.
En los datos necesarios, observa cómo se identifican el caso, la actividad y el momento de cada evento. En frecuencia y tiempo, compara el número de veces que aparece una actividad con el tiempo acumulado que consume. Termina con las excepciones: una actividad puede no ser la más lenta por caso y, aun así, merecer atención por su volumen o sus consecuencias.
La lección práctica es que un «cuello de botella» necesita una explicación. Si clasificar consultas lleva poco tiempo cada vez, pero ocurre cientos de veces, el esfuerzo total puede ser considerable. Si una derivación es rara pero retrasa casos urgentes, también importa. Y si la actividad lenta es una comprobación indispensable, acelerarla sin preservar su función puede empeorar el resultado.
Antes de añadir IA, preguntar qué problema resolvemos
Una vez identificada la fricción, todavía no hemos identificado la solución. Hay al menos tres posibilidades: quitar un paso innecesario, aplicar una regla o integración convencional, o utilizar IA donde la variación de los datos haga valiosa su capacidad de interpretar o generar contenido.
User Needs + Defining Success - People + AI Research
Lee «User Needs + Defining Success», de People + AI Research, para separar la detección de una necesidad de la decisión de emplear IA.
En «Map existing workflows», lee el enfoque de mapeo. Continúa en «Decide if AI adds unique value» con la pregunta clave. Por último, en las subsecciones «When AI is probably better» y «When AI is probably not better», recorre los ejemplos comparados. Busca razones para elegir una regla sencilla incluso cuando sería técnicamente posible usar IA.
Volvamos a las consultas de acceso. Si todas llegan por dos canales que crean tickets duplicados, eliminar el duplicado puede ser la mejor intervención. Si el formulario incluye un campo fiable llamado «tipo de incidencia», una regla convencional puede enviarlo a la cola correcta: es predecible y fácil de comprobar. En cambio, si las personas describen el problema en lenguaje libre —«entro, pero no veo el material»— y la información está dispersa en varios mensajes, una IA podría proponer una categoría y resumir lo relevante para el agente.
La diferencia no es «tarea repetitiva frente a tarea nueva». Una tarea repetitiva puede resolverse sin IA; una tarea poco frecuente puede requerir mucho juicio y no ser buena candidata a automatizar. Formula la oportunidad de manera específica: no «usar IA en soporte», sino «ayudar a identificar el motivo de una consulta redactada libremente y presentar al agente las instrucciones vigentes que podrían servir». Después comprueba si esas instrucciones existen, están actualizadas y pueden consultarse con los permisos adecuados. Si no, el problema quizá esté antes en la documentación que en la capacidad de generar texto.
Elegir cuánto control conservar
Asistir significa que la IA aporta algo al trabajo de una persona —una clasificación sugerida, un resumen o un borrador— y la persona decide cómo utilizarlo. Automatizar con IA significa que el sistema ejecuta una tarea definida sin que una persona tenga que completarla en cada caso, aunque debe poder supervisarse e intervenirse cuando corresponda. No son dos etiquetas permanentes para un proceso entero: distintos pasos del mismo flujo pueden necesitar grados de control diferentes.
User Needs + Defining Success - People + AI Research
Retoma la lectura de People + AI Research para decidir qué parte de una tarea conviene delegar y cuál debe permanecer bajo control humano.
En «Assess automation vs. augmentation», lee la distinción inicial. En «When to automate», continúa desde los criterios y controles. Finalmente, en «When to augment», lee los motivos para asistir. Atiende al valor que las personas atribuyen a la tarea, al coste de los errores y a las posibilidades de revisar o deshacer una acción.
En nuestro flujo, podríamos separar decisiones que a primera vista parecen una sola:
| Tarea delimitada | Tratamiento inicial razonable | Por qué |
|---|---|---|
| Asignar un ticket usando un campo de categoría fiable | Regla convencional | Entrada estructurada y resultado comprobable. |
| Resumir una descripción larga del problema | Asistencia con IA | El lenguaje varía; el agente puede cotejar el resumen con el mensaje original. |
| Proponer instrucciones basadas en documentación vigente | Asistencia con IA | La propuesta necesita comprobarse frente al caso y la fuente. |
| Confirmar un cambio de permisos o datos de acceso | Decisión y controles autorizados | Un error puede afectar a la seguridad; no basta un texto convincente. |
| Enviar una respuesta final | Según tipo de caso y controles | Una confirmación estándar puede seguir reglas; una respuesta personalizada requiere evaluar el riesgo antes de permitir envío automático. |
Esta tabla no es una receta universal. Señala las preguntas que deben resolverse en el proceso concreto: ¿qué daño produciría un error?, ¿puede detectarse antes de que afecte a alguien?, ¿hay una forma de corregirlo?, ¿quiere la persona responsable delegar esa acción? Un borrador que ahorra cuatro minutos de escritura pero exige seis de verificación no ha mejorado el flujo. Del mismo modo, enviar automáticamente mensajes incorrectos puede trasladar el trabajo al equipo que atiende reclamaciones.
Qué debe salir del análisis
Al terminar una primera investigación, el resultado útil no es una lista de herramientas. Es un mapa validado del flujo actual y una descripción breve de cada oportunidad candidata. Por ejemplo:
Oportunidad candidata: resumir consultas de acceso redactadas en lenguaje libre y sugerir su categoría al agente.
Paso afectado: identificación del problema, antes de consultar la documentación.
Fricción observada: hay que leer mensajes largos o dispersos para entender qué ha fallado; falta comprobar con qué frecuencia ocurre.
Modo propuesto: asistencia, no clasificación irreversible ni respuesta enviada automáticamente.
Información necesaria: texto del ticket y categorías autorizadas, con acceso limitado a lo necesario.
Comprobación pendiente: comparar los resúmenes y categorías sugeridos con casos reales; observar correcciones, tiempo total del agente y errores de derivación.
La última línea es importante: marca lo observado frente a lo que aún es una hipótesis. En esta fase puedes localizar tareas prometedoras y descartar soluciones innecesariamente complejas. Todavía no necesitas declarar ganadora una oportunidad ni prometer un ahorro; más adelante evaluarás formalmente valor, viabilidad y riesgo.
Para cerrar
Analizar un flujo consiste en seguir casos reales de principio a fin, incluidos traspasos, esperas y excepciones; contrastar la fricción percibida con evidencia; y delimitar la tarea antes de elegir tecnología. Recurre a IA cuando aporte algo que una simplificación o una regla no ofrecen, y decide por separado qué puede delegarse y qué necesita revisión humana.
En la próxima lección mirarás este mismo tipo de flujo desde otra perspectiva: las personas que lo recorren. Dos usuarios pueden intervenir en el mismo paso y tener necesidades, condiciones de trabajo y barreras de adopción muy distintas.