El procedimiento cabe en una frase: aprobar la compra y enviarla al proveedor. Después alguien pregunta qué ocurre si el proveedor todavía no está registrado. Otra persona recuerda una excepción y una tercera dice que siempre llama a administración. El proceso que parecía listo para automatizar aún depende de acuerdos que no están escritos.
Cartographer, presentado por UiPath, pone esa clase de conocimiento en el centro de su propuesta. Puedes aprovechar la pregunta sin adoptar una herramienta: ¿qué tendría que saber alguien que no estuvo en las conversaciones para atender un caso normal, uno incompleto y uno excepcional? La ficha de este artículo está pensada para empezar esa conversación.
UiPath presentó Cartographer el 23 de septiembre. El producto propone construir un Map of Work: una representación mantenida del proceso, sus reglas y el conocimiento operativo que suele estar disperso en documentos y conversaciones. El anuncio describe su uso para generar documentación y especificaciones de automatización. Son capacidades anunciadas por UiPath, no una prueba de que la herramienta pueda capturar correctamente cualquier proceso sin revisión.
Publicación de UiPath · 2026-09-23 (abre en otra pestaña)
Pensemos en una compra hipotética. El procedimiento dice que una solicitud aprobada se envía al proveedor. Pero el proveedor todavía no está registrado y la entrega no puede esperar. Una persona sabe a quién consultar y qué dato falta. Si el sistema futuro sólo reproduce el recorrido escrito, esa intervención seguirá ocurriendo fuera de él, quizá por mensajes que nadie relaciona con la solicitud.
Empieza por la última compra que se salió del guion
Pide un caso concreto, no una descripción ideal. ¿Qué información llegó? ¿Qué decisión hubo que tomar? ¿Quién podía tomarla? Así distingues una regla vigente de una costumbre personal y de una solución improvisada. Si dos áreas responden distinto, anota la diferencia antes de convertir una de las versiones en automatización.
También pueden aparecer versiones distintas del mismo recorrido. Compras considera aprobada una solicitud cuando recibe una respuesta; administración espera otro documento. Un mapa bonito no resuelve el desacuerdo. Sirve si hace visible la diferencia para que las áreas puedan decidir qué regla debe sostener el sistema.
Una conversación útil puede recorrer tres versiones de la misma compra: la que contiene todos los datos, la que requiere dar de alta al proveedor y la que necesita una autorización adicional. Al compararlas aparecen las condiciones que separan un paso de otro. El ejercicio no pretende documentar cada excepción imaginable, sino reconocer las que cambiarían el diseño y la responsabilidad de la decisión.
| Qué revisar | Cómo interpretarlo |
|---|---|
| Resultado esperado | ¿Qué recibe la siguiente persona cuando el paso está realmente terminado? |
| Entrada mínima | ¿Qué información permite avanzar y qué falta obliga a esperar? |
| Excepción | Describe una situación concreta que no sigue el camino normal, sin datos personales. |
| Decisión y responsable | ¿Quién puede autorizar la salida y dónde conserva la razón? |
| Pendiente | ¿Qué desacuerdo debe resolverse antes de convertirlo en una regla? |
| Aceptación | ¿Qué ejemplo permitiría comprobar que el software respeta lo acordado? |
Puedes trasladar esta ficha a un documento de trabajo. Es un recurso editorial de Acinsoft, no una función de Cartographer ni una especificación lista para desarrollar. Complétala con quienes realizan y autorizan la tarea. Si dos áreas responden distinto, registra ambas respuestas como una decisión pendiente; no elijas silenciosamente la más cómoda para automatizar. La ficha está terminada cuando la excepción tiene dueño, no cuando desaparecen los espacios vacíos.
Los huecos también forman parte del mapa
Lo que todavía no se acuerda puede quedar señalado como pendiente, con una persona responsable de resolverlo. Eso es más preciso que dibujar una flecha que oculta la duda. Una vez aclarada la regla, el equipo puede convertirla en un caso de aceptación y comprobar si el sistema futuro la representa, en lugar de descubrir el desacuerdo durante la entrega.
En el ejemplo, el avance podría consistir en reconocer un estado pendiente de alta del proveedor y asignarle un responsable. Eso no vuelve inmediato el trámite, pero evita que desaparezca entre conversaciones. La automatización tendría entonces algo más preciso que una flecha entre dos pasos: una decisión que las personas pueden revisar.
Usa la ficha como documento vivo: una persona describe el recorrido y otra intenta seguirlo con datos ficticios. Las preguntas que aparecen no son un fracaso de la documentación; son hallazgos del ejercicio. Conviene asignar quién resolverá cada desacuerdo y evitar llenar el hueco con una regla que nadie ha aprobado.
Esa definición puede convertirse en el punto de partida del perfilamiento de software con Acinsoft (servicio relacionado; abre en otra pestaña). Permite separar lo que ya se puede construir de lo que aún necesita una decisión del negocio. El desarrollo gana claridad cuando las excepciones conocidas llegan a la conversación antes de que estén escondidas en código.
No necesitas dibujar un mapa perfecto para empezar. Necesitas uno que no disfrace de certeza lo que todavía se discute. Si al terminar la ficha sabes qué decisión falta y quién puede tomarla, ya tienes un avance útil hacia una automatización que represente el trabajo real.
