flowchart LR
A[Recibir] --> B[Revisar]
B --> C[Aprobar]
C --> D[Registrar]
De acciones aisladas a procesos
Cómo pasar de disponer de capacidades técnicas aisladas a organizar tareas, secuencias y estados dentro de un proceso de trabajo controlable.
Hasta ahora hemos ido agregando capacidades.
Podemos formular instrucciones más precisas, convertirlas en templates, encapsular metodologías como skills, recuperar conocimiento pertinente y permitir que una aplicación lea documentos, consulte sistemas o ejecute determinadas acciones mediante tools, APIs, connectors o MCP.
Eso resuelve una pregunta importante:
¿Qué puede hacer el sistema?
Pero cuando el trabajo deja de ser una acción puntual aparece un problema diferente.
Supongamos que llega un contrato de un proveedor tecnológico. El sistema puede buscar el documento, extraer cláusulas, recuperar la política interna, comparar una redacción, crear una matriz y registrar un resultado. Todas esas capacidades pueden funcionar correctamente y, aun así, el proceso completo salir mal.
Podemos revisar la versión equivocada. Podemos analizar antes de recibir un anexo decisivo. Podemos negociar una cláusula que todavía necesitaba aprobación. Podemos duplicar una revisión. Podemos cerrar el asunto sin registrar una excepción. Podemos tener un excelente análisis jurídico que nunca llega a la persona que debe decidir.
El problema ya no está necesariamente dentro de cada capacidad.
Puede estar entre las capacidades.
Éste es el punto de entrada a una nueva capa del recorrido: organizar el trabajo.
Idea central
Tener capacidades no basta.
Cuando una tarea profesional requiere varias acciones relacionadas, debemos hacer explícito qué se hace, en qué relación ocurre, dónde se encuentra el asunto y qué debe ocurrir para avanzar.
En esta página construiremos esa idea mediante tres conceptos básicos:
tareas → secuencias → estados.
De “puede hacerlo” a “cómo debe ocurrir”
La diferencia puede verse con un ejemplo muy sencillo.
Imaginemos cuatro capacidades disponibles:
buscar documentos
analizar cláusulas
crear registros
enviar notificacionesLa lista nos dice qué operaciones son posibles.
No nos dice:
- cuál debe ejecutarse primero;
- qué información necesita cada una;
- qué resultado debe producir;
- quién puede ejecutarla;
- cuándo debe detenerse el proceso;
- qué ocurre si falta un documento;
- qué acción requiere aprobación;
- qué significa haber terminado.
Ahora añadamos una primera organización:
recibir contrato
↓
buscar antecedentes
↓
analizar
↓
pedir aprobación
↓
registrar decisiónYa no tenemos solamente operaciones disponibles. Tenemos una relación entre ellas.
La pregunta cambia de:
“¿Puede buscar, analizar o registrar?”
hacia:
“¿Cuándo debe buscar, qué debe ocurrir antes de analizar y bajo qué condición puede registrar?”
El material del curso formula precisamente este cambio: un conjunto de tools sin procedimiento puede aumentar ruido, riesgo y trabajo de supervisión. El valor aparece cuando las capacidades se insertan en una secuencia con condiciones de avance, responsables, aprobadores, evidencia y cierre.
La literatura de gestión de procesos parte de una intuición compatible. Mathias Weske describe un proceso como un conjunto de actividades realizadas coordinadamente dentro de un entorno organizacional y técnico para alcanzar un objetivo. Lo decisivo para nosotros es la palabra coordinadamente: el trabajo no se reduce a la suma de sus actividades.
La nueva unidad de análisis: el asunto completo
Cuando trabajamos con prompts o skills, nuestra atención suele concentrarse en una tarea delimitada.
Por ejemplo:
Extrae las cláusulas de terminación.O:
Compara esta cláusula con nuestro estándar interno.Esas operaciones pueden evaluarse individualmente.
Pero una revisión contractual completa tiene otra unidad de análisis:
el asunto desde que ingresa hasta que queda resuelto.
Eso obliga a mirar conexiones.
Un contrato puede estar técnicamente bien analizado y organizacionalmente mal tramitado.
Una matriz puede ser correcta y haberse construido sobre una versión obsoleta.
Una recomendación puede ser razonable y carecer de la aprobación necesaria.
Una decisión puede ser correcta y no haber dejado evidencia suficiente.
Pensar en procesos significa dejar de mirar únicamente la calidad de cada pieza y comenzar a mirar la trayectoria del trabajo.
1. Tareas: qué debe hacerse
Una tarea es una unidad de trabajo que debe realizarse dentro del proceso.
En nuestro caso podrían existir tareas como:
recibir solicitud
clasificar proveedor
verificar documentación
revisar contrato
analizar privacidad
consultar seguridad
preparar matriz
negociar desviaciones
obtener aprobación
registrar decisiónLa tarea no determina por sí sola quién la ejecuta.
Puede ser realizada por:
- una persona;
- software convencional;
- una aplicación de IA;
- una combinación de ellos.
Por ejemplo, “extraer las fechas principales del contrato” podría automatizarse. “Aceptar una excepción material al límite de responsabilidad” puede reservarse a una persona con autoridad suficiente. Ambas son tareas dentro del proceso, pero no tienen la misma naturaleza ni requieren el mismo control.
Acción, tarea y objetivo no son exactamente lo mismo
Conviene hacer una pequeña distinción.
Una acción puede ser una operación técnica concreta:
abrir archivo
buscar registro
enviar correo
crear ticketUna tarea suele tener significado dentro del trabajo:
comprobar que el expediente contiene todos los documentos necesariosY un objetivo describe el resultado más amplio que buscamos:
preparar una decisión informada sobre si la contratación puede aprobarseUna tarea puede necesitar varias acciones.
Por ejemplo:
Tarea: verificar documentación.
Puede requerir:
consultar expediente
↓
listar archivos
↓
comparar contra requisitos
↓
identificar faltantes
↓
actualizar estadoEsta distinción evita un error importante: confundir la existencia de una tool con la existencia de una tarea bien diseñada.
Una tool puede permitir buscar_documento.
Eso no significa que el sistema ya sepa qué documentos necesita encontrar, para qué etapa, con qué criterio de suficiencia y qué debe ocurrir si no aparecen.
Una tarea necesita entrada y produce algún resultado
Incluso antes de estudiar formalmente los workflows, conviene acostumbrarnos a pensar las tareas como pequeñas transformaciones.
Por ejemplo:
ENTRADA
contrato + datos básicos del proveedor
TAREA
clasificar tipo de contratación
RESULTADO
tipo contractual + criticidad preliminarOtro:
ENTRADA
contrato + estándar interno
TAREA
comparar cláusula de responsabilidad
RESULTADO
desviación identificada + evidenciaEsta estructura ayuda porque hace visible algo que una instrucción vaga puede ocultar: una tarea depende de información y genera información que será utilizada después.
Cuando varias tareas se encadenan, el resultado de una puede convertirse en la entrada de la siguiente.
Ahí aparece la secuencia.
2. Secuencias: qué debe ocurrir antes y después
Una secuencia establece una relación de orden entre tareas.
La forma más simple es lineal:
La idea parece evidente, pero tiene consecuencias importantes.
Si “aprobar” sólo puede ocurrir después de “revisar”, la secuencia expresa una restricción.
No está diciendo simplemente qué suele pasar.
Está diciendo qué debería poder pasar.
Weske utiliza precisamente este tipo de relación al explicar que un proceso explícito contiene actividades y restricciones de ejecución entre ellas. En una secuencia, una actividad posterior sólo queda habilitada cuando la anterior ha terminado.
Para nuestro propósito no necesitamos aprender una notación formal. Necesitamos captar la lógica:
ordenar trabajo significa definir dependencias entre actividades.
No todas las secuencias son una línea recta
Los procesos reales rara vez consisten en:
A → B → C → D → finPueden contener tareas en paralelo.
Por ejemplo, después de clasificar un proveedor podrían iniciarse simultáneamente revisiones de privacidad y seguridad:
flowchart TD
A[Clasificar proveedor] --> B[Revisión jurídica]
A --> C[Revisión de privacidad]
A --> D[Revisión de seguridad]
B --> E[Consolidar]
C --> E
D --> E
También pueden contener bifurcaciones.
flowchart TD
A[Verificar documentación] --> B{¿Está completa?}
B -- Sí --> C[Analizar]
B -- No --> D[Solicitar antecedentes]
D --> E[Esperar respuesta]
E --> A
O retornos.
negociar
↓
recibir nueva versión
↓
revisar cambios
↓
si quedan problemas → negociar nuevamentePor eso “secuencia” no debe entenderse únicamente como una fila de pasos.
Es más útil pensarla como la estructura de relaciones de avance entre tareas.
Dependencia temporal y dependencia lógica
Dos tareas pueden estar relacionadas porque una ocurre después de otra, pero eso no siempre significa que la primera sea una condición material de la segunda.
Comparemos:
revisar cláusula
↓
preparar comentarioAquí existe una dependencia lógica clara: no podemos preparar un comentario fundado sobre una cláusula que todavía no hemos revisado.
En cambio:
crear carpeta
↓
revisar cláusulapuede existir una regla organizacional que exige ese orden, aunque técnicamente el análisis pudiera realizarse antes.
Ambos tipos de relación importan.
Un proceso profesional contiene tanto restricciones derivadas de la lógica del trabajo como restricciones creadas deliberadamente para gobernarlo.
La secuencia también distribuye control
Supongamos que una aplicación puede enviar automáticamente una propuesta de redacción al proveedor.
Tenemos dos posibles secuencias.
Primera:
generar propuesta
↓
enviar al proveedor
↓
revisión humanaSegunda:
generar propuesta
↓
revisión humana
↓
aprobación
↓
enviar al proveedorLas mismas capacidades están presentes.
Lo que cambia es su organización.
Y con ella cambia el nivel de control.
Esto muestra por qué el diseño de procesos no es una cuestión meramente administrativa. El orden de los pasos puede determinar si un control ocurre antes o después de una acción relevante.
3. Estados: dónde se encuentra el asunto
Hasta aquí sabemos qué tareas existen y cómo pueden relacionarse.
Todavía falta una pregunta esencial:
¿Dónde se encuentra el asunto ahora?
Para responderla necesitamos el concepto de estado.
Un estado representa una condición relevante de una instancia del proceso en un momento determinado.
Por ejemplo:
RECIBIDO
EN ADMISIÓN
PENDIENTE DE DOCUMENTACIÓN
EN REVISIÓN
EN NEGOCIACIÓN
PENDIENTE DE APROBACIÓN
APROBADO
RECHAZADO
CERRADOTarea y estado no son lo mismo
Comparemos:
solicitar DPAcon:
PENDIENTE DE DPALa primera expresión describe algo que hacemos.
La segunda describe la situación en la que queda el expediente.
Podemos representarlo así:
stateDiagram-v2
[*] --> DocumentacionIncompleta
DocumentacionIncompleta --> PendienteProveedor: solicitar DPA
PendienteProveedor --> DocumentacionCompleta: recibir DPA
DocumentacionCompleta --> EnRevision
La tarea puede provocar una transición.
El estado permite saber el resultado operacional de esa transición.
Por qué los estados importan cuando el trabajo dura
En una conversación breve puede parecernos innecesario representar estados.
Pero pensemos en una organización con cien asuntos abiertos.
Un correo enviado ayer no nos dice si el expediente está:
- esperando antecedentes del proveedor;
- esperando revisión de privacidad;
- listo para aprobación;
- detenido por una excepción;
- ya cerrado.
El historial de acciones responde:
¿Qué ocurrió?
El estado responde:
¿Cuál es la situación actual?
Ambas preguntas son distintas.
Weske destaca que la información de estado permite monitorear instancias de procesos y conocer qué está ocurriendo en cada caso. Esta observabilidad es una de las razones por las que los procesos explícitos pueden administrarse mejor que los flujos que viven solamente en correos y memoria informal.
Estado del proceso y estado de una tarea
También conviene distinguir dos niveles.
Una tarea individual puede estar:
no iniciada
en ejecución
terminada
fallida
suspendidaMientras el expediente completo puede estar:
EN REVISIÓNPor ejemplo, dentro de EN REVISIÓN puede ocurrir que:
- la revisión contractual ya terminó;
- la revisión de seguridad sigue en ejecución;
- privacidad está pendiente;
- ninguna de ellas haya producido todavía una condición suficiente para pasar a aprobación.
Eso muestra que un proceso puede contener varios estados relacionados.
No necesitamos modelarlos todos desde el primer día. Sí debemos entender que “estado” no significa una única etiqueta universal pegada al expediente.
De estados a transiciones
Un estado se vuelve realmente útil cuando podemos responder:
¿Qué debe ocurrir para cambiarlo?
Por ejemplo:
ESTADO ACTUAL
PENDIENTE DE DOCUMENTACIÓN
EVENTO
el proveedor entrega el DPA
COMPROBACIÓN
el DPA corresponde al servicio y está vigente
NUEVO ESTADO
EN REVISIÓNO:
ESTADO ACTUAL
EN REVISIÓN
EVENTO
terminan las revisiones obligatorias
COMPROBACIÓN
no quedan hallazgos críticos sin tratamiento
NUEVO ESTADO
PENDIENTE DE APROBACIÓNTodavía no necesitamos convertir esta estructura en una especificación técnica completa. Basta comprender que los estados hacen visible una propiedad que las listas de tareas no muestran: la situación actual y las condiciones de cambio.
Modelo del proceso e instancia concreta
Existe una distinción adicional que resulta muy útil.
El proceso general podría decir:
recibir
→ clasificar
→ revisar
→ aprobar
→ registrarÉse es el modelo del proceso.
Cada contrato concreto es una instancia que recorre ese modelo.
Por ejemplo:
Contrato A → EN REVISIÓN
Contrato B → PENDIENTE DE PROVEEDOR
Contrato C → PENDIENTE DE APROBACIÓN
Contrato D → CERRADOLa analogía con una ruta ayuda.
El mapa describe caminos posibles.
Cada expediente ocupa una posición concreta dentro de ellos.
La analogía deja de servir si imaginamos que todos los asuntos deben seguir exactamente el mismo camino. Los procesos pueden contener ramas, retornos, excepciones y rutas distintas según el caso.
Del trabajo por etapas al proceso
En la sección sobre prompts ya aprendimos a dividir una tarea compleja en etapas:
extraer
↓
clasificar
↓
evaluar
↓
revisarCuando la persona controla manualmente cada paso dentro de una conversación, tenemos una forma básica de coordinación.
Ahora estamos agregando algo diferente.
No preguntamos solamente:
“¿Qué paso viene después?”
También preguntamos:
- ¿qué estado tiene el asunto?;
- ¿qué condiciones habilitan el siguiente paso?;
- ¿qué tareas pueden ejecutarse en paralelo?;
- ¿qué ocurre si una tarea falla?;
- ¿qué evidencia deja cada transición?;
- ¿quién es responsable de que el proceso avance?
Esa diferencia marca el paso desde trabajar por etapas hacia organizar un proceso.
Un caso completo: el contrato del proveedor de IA
Retomemos el caso conductor.
Llega una solicitud para contratar una plataforma de IA.
Tareas
Podemos identificar inicialmente:
1. recibir solicitud
2. clasificar servicio
3. verificar documentación
4. revisar contrato
5. revisar privacidad y seguridad cuando corresponda
6. consolidar hallazgos
7. negociar desviaciones
8. obtener aprobación
9. registrar resultadoSecuencia
No todas las tareas pueden realizarse en cualquier orden.
Por ejemplo:
flowchart TD
A[Recibir solicitud] --> B[Clasificar]
B --> C[Verificar documentación]
C --> D{¿Suficiente?}
D -- No --> E[Solicitar antecedentes]
E --> C
D -- Sí --> F[Revisiones]
F --> G[Consolidar]
G --> H{¿Hay desviaciones?}
H -- Sí --> I[Negociar]
I --> G
H -- No --> J[Pedir aprobación]
J --> K[Registrar]
Estados
Mientras tanto, cada asunto puede encontrarse en:
RECIBIDO
PENDIENTE DE INFORMACIÓN
EN REVISIÓN
EN NEGOCIACIÓN
PENDIENTE DE APROBACIÓN
CERRADOAhora tenemos una representación mucho más útil que una lista de tools.
Podemos preguntar:
¿qué asuntos están detenidos por falta de información?
¿cuáles están listos para aprobación?
¿qué tarea debe ocurrir antes de que un expediente cambie de estado?
¿qué casos llevan demasiado tiempo en una etapa?
Ésa es la utilidad de pensar en procesos.
El proceso no tiene por qué estar automatizado
Nada de lo explicado hasta ahora exige inteligencia artificial.
Un proceso puede ejecutarse completamente mediante personas y correos.
También puede apoyarse en software convencional.
O puede incorporar IA en determinadas tareas.
La organización del trabajo y el grado de automatización son preguntas diferentes.
Esto es importante porque evita una tendencia frecuente: creer que diseñar el proceso equivale a decidir dónde colocar IA.
El orden correcto suele ser el contrario:
comprender el trabajo
↓
definir tareas y relaciones
↓
identificar controles
↓
recién entonces decidir qué conviene apoyar o automatizarLo que ganamos al pensar en procesos
La primera ganancia es visibilidad.
Podemos ver dónde comienza y dónde termina el trabajo.
La segunda es coordinación.
Podemos identificar dependencias y responsables.
La tercera es control.
Podemos ubicar revisiones y aprobaciones antes de las acciones que requieren autorización.
La cuarta es trazabilidad.
Podemos registrar no sólo el resultado final, sino la trayectoria que llevó hasta él.
La quinta es capacidad de mejora.
Si sabemos dónde se acumulan esperas, duplicaciones o errores, podemos intervenir sobre el proceso correcto.
Qué puede salir mal al mapear procesos
Convertir toda actividad en una microtarea
Un modelo demasiado detallado puede volverse imposible de mantener.
No necesitamos representar cada clic.
La granularidad debe permitir comprender y controlar el trabajo.
Confundir el proceso ideal con el proceso real
Una organización puede declarar:
Legal revisa antes de Comprasmientras en la práctica Compras negocia antes de recibir comentarios jurídicos.
Mapear sólo el procedimiento formal puede ocultar el problema que queríamos descubrir.
Usar estados vagos
Estados como:
EN PROCESOpueden decir muy poco.
Si necesitamos distinguir espera de proveedor, revisión interna y aprobación, conviene representarlos separadamente.
Diseñar únicamente el camino feliz
Un proceso que supone que siempre existen todos los documentos, nunca falla una integración y nadie rechaza una propuesta describe sólo el caso más fácil.
La calidad del diseño se prueba también cuando falta información, aparece una excepción o una tarea no puede ejecutarse.
Automatizar antes de comprender
Si automatizamos inmediatamente un proceso mal diseñado, podemos obtener errores más rápidos y más difíciles de supervisar.
La tecnología no elimina la necesidad de pensar la secuencia.
Qué debes recordar
Podemos condensar esta página en tres preguntas.
Tarea
¿Qué debe hacerse?
Secuencia
¿Cómo se relacionan esas tareas?
Estado
¿Dónde se encuentra el asunto y qué debe ocurrir para avanzar?
Estas tres ideas transforman una colección de capacidades en el inicio de un proceso organizado.
No hemos definido todavía una arquitectura completa de workflow.
Sólo hemos construido sus fundamentos.
El problema que todavía queda abierto
Ya podemos identificar tareas, ordenarlas y representar estados.
Pero todavía necesitamos una forma más completa de describir el proceso.
¿Qué pone en marcha el trabajo?
¿Qué entra en cada etapa?
¿Qué condiciones permiten continuar?
¿Quién es responsable?
¿Qué salida debe producir cada paso?
¿Cuándo puede considerarse cerrado el asunto?
El siguiente nodo reúne esas preguntas en una abstracción específica: el workflow.