Mapa de procesos antes de automatizar con IA: ejemplo práctico

Antes de añadir un agente de IA, mapea una tarea desde el hecho que la inicia hasta un resultado observable. Anota la entrada, decisión, responsable, traspaso y excepción de cada paso. La pregunta útil es: ¿otra persona podría seguir esta ficha sin adivinar a quién le toca actuar?

Una lista de herramientas no responde a esa pregunta. Empieza por cómo se trabaja hoy, incluidos los mensajes, las esperas y las correcciones. Dibuja aparte la propuesta futura para no confundir una mejora deseada con el proceso actual.

Delimita el proceso antes de elegir software

Tomemos una solicitud interna de equipo. En este ejercicio, el mapa empieza cuando llega la petición y termina cuando quien la solicita confirma que ha recibido las instrucciones de recogida aprobadas, o cuando el responsable registra una denegación. La recogida física, la devolución y las compras quedan fuera de este mapa.

Es un ejercicio ficticio de planificación: no es un caso de cliente, una aplicación operativa de IliciLabs ni una automatización probada. Sus reglas y estados son propuestas que debes adaptar con las personas que hacen el trabajo.

La introducción de IBM al mapeo de procesos explica cómo identificar las personas implicadas, el inicio y el final del proceso, y validar el mapa con sus participantes. Usa ese enfoque para reconstruir un caso reciente de tu organización antes de proponer cambios. Conserva los registros confidenciales en los sistemas aprobados; utiliza ejemplos anonimizados al hablar de un proyecto con terceros.

Un mapa completo: de la petición al acuse de recibo

Supongamos que la solicitud EQ-17 pide un proyector para un taller, pero no indica la fecha de recogida. Este es un mapa propuesto; cada salida deja algo que el siguiente responsable puede comprobar.

Paso y responsable	Entrada y decisión	Salida o excepción
Operaciones recibe la petición	Referencia, equipo y fecha de recogida. ¿Falta un dato obligatorio?	EQ-17 queda pendiente de información. Operaciones pide la fecha; no la inventa.
Operaciones comprueba disponibilidad	La persona aporta la fecha. Operaciones consulta el registro de equipos para ese día.	Anota la referencia del registro y la hora de consulta. Un conflicto pasa al responsable del equipo; no equivale a una asignación confirmada.
El responsable del equipo decide	Tiene la solicitud y la comprobación de disponibilidad. ¿Aprueba esa petición?	Registra decisión, hora y condiciones. Una denegación lleva motivo; una aprobación todavía no es una instrucción enviada.
Operaciones prepara el traspaso	Usa la decisión aprobada para preparar las instrucciones de recogida.	Registra versión de las instrucciones y resultado del envío. Si falla, sigue en Operaciones; no pasa a recepción confirmada.
La persona solicitante acusa recibo	Confirma que ha recibido las instrucciones vigentes.	Registra la referencia del acuse y cierra este mapa como recepción de instrucciones confirmada. Sin acuse, el traspaso sigue abierto.

En este diseño, Operaciones conserva la responsabilidad del traspaso hasta el acuse de recibo. El responsable del equipo decide la asignación. Acordad cuándo hacer seguimiento y quién sustituye a la persona responsable, en lugar de pasar una tarea sin respuesta de un equipo a otro.

Un diagrama por carriles puede hacer visibles esos cambios de responsable. La guía de carriles de Lucidchart explica cómo situar cada tarea en el carril de su responsable y usar flechas para el flujo entre roles. Puedes dibujar esas mismas divisiones en papel; la ficha siguiente es un registro inicial, no un requisito de comprar una herramienta.

Copia esta ficha para un paso de tu proceso

Complétala para cada paso y conecta sus salidas con las entradas siguientes. Un campo vacío señala una pregunta que resolver con el equipo.

• Alcance: empieza cuando ___; termina cuando ___; excluye ___.
• Disparador y referencia: ocurre ___; este caso se identifica por ___.
• Entrada y fuente: datos obligatorios ___; registro de referencia ___; consultado a las ___.
• Acción y decisión: ___ hace ___; la regla o aprobación necesaria es ___.
• Salida: la siguiente persona recibe ___, con evidencia en ___.
• Traspaso: responsable actual ___; rol receptor ___; aceptación registrada mediante ___.
• Excepción: si ocurre ___, queda en ___; lo resuelve ___; se retoma después de ___.
• Seguimiento: revisar lo pendiente tras ___; rol suplente ___.
• Medición: tiempo de trabajo ___ y de espera ___ por separado; correcciones contadas mediante ___.

Distingue quién ejecuta una tarea de quién responde por su resultado. La guía de roles de Microsoft explica esa diferencia en su ejemplo RACI. Para un mapa pequeño, escribe los roles con claridad y acuerda quién responde por el resultado; una matriz completa es opcional.

Recorre las excepciones antes de construir

Pide a las personas implicadas que apliquen la ficha propuesta a estos casos. Anota el resultado esperado y las dudas. Son comprobaciones sugeridas, no pruebas ya realizadas.

• Falta la fecha: EQ-17 espera información. No se deduce disponibilidad ni aprobación.
• El registro contradice la petición: ya consta una asignación. El responsable del equipo resuelve el conflicto antes de aprobar.
• Llega la misma petición otra vez: compara su referencia con el caso existente antes de crear otra asignación; una coincidencia ambigua necesita revisión.
• El traspaso no se acepta: las instrucciones se entregaron, pero no llega acuse. El caso sigue abierto con su responsable de seguimiento.
• Falla el envío: conserva decisión y versión de las instrucciones. Comprueba el registro de entrega antes de reintentar; un resultado incierto no equivale a fallo confirmado ni a recepción.

Si los participantes discrepan sobre el resultado, aclara primero la regla o la responsabilidad. Pregunta también si la propuesta puede eliminar una copia redundante de datos en lugar de automatizarla.

Elige la siguiente intervención a partir del mapa

En este ejemplo, comprobar si falta la fecha puede resolverse con una regla fija. Resumir una petición en texto libre podría ser un borrador asistido por IA, con el original disponible para quien lo revise. La aprobación y el acuse siguen siendo acciones humanas explícitas en el diseño propuesto. No hace falta añadir IA solo para mover un estado bien definido.

Usa la matriz para decidir qué automatizar para examinar esas opciones. Para el problema más específico de llevar documentos extraídos a revisión y exportación, consulta la guía de flujo documental: cubre otra capa del proceso.

Para hablar de un proyecto acotado, lleva el mapa actual, un caso normal anonimizado, una excepción, los sistemas implicados y las decisiones abiertas al Laboratorio de automatización con IA. Acordad primero qué significa terminar y cómo se comprobará. Cualquier ahorro de tiempo esperado seguirá siendo una hipótesis hasta medir trabajo real comparable.