En esta página
Un plan de sincronización tiene veinte cajas. La caja siete copia un estado a una hoja de cálculo. La caja ocho reformatea esa hoja para una plataforma de correo electrónico. La caja nueve envía un mensaje a una persona responsable para que apruebe la importación. El plan pregunta qué agente debería encargarse de las cajas siete a nueve.
La primera pregunta es por qué existen esas cajas. El ejemplo es ilustrativo, no una auditoría de un equipo real.
Una conversación sobre diseño de flujos de trabajo propone cuatro categorías para el trabajo: eliminar el paso, usar código normal, usar un agente o dejar la decisión en manos de una persona. El movimiento útil precede a la selección del modelo. Eliminar un paso puede hacer innecesaria toda la maquinaria que lo rodea.
Empieza por el resultado visible para el cliente
Nombra el resultado que el flujo debe producir. Para una conexión entre una tienda y un sistema de correo electrónico, podría ser: «Un cliente que haya comprado deja de recibir el recordatorio del carrito». Ese resultado requiere estado, tiempo y una regla de supresión. No requiere una hoja de cálculo, una exportación nocturna completa ni el correo de aprobación de alguien responsable.
La ilustración de Tajo centra la revisión en la asignación propuesta y en el límite previo a la activación. No implementa la supresión de recordatorios de carrito. Para lograrla, primero hay que definir la señal de compra y la regla de supresión. Añadir otro campo asignado no sustituye ninguna de esas decisiones.
Revisa la sincronización antes de ejecutarla
Sincroniza las actualizaciones de clientes con mi plataforma de correo.
Sincronización de clientes
| Campo de origen | Campo de destino | Regla |
|---|---|---|
email | EMAIL | Directa |
first_name | FIRSTNAME | Directa |
last_name | LASTNAME | Directa |
Vista previa sintética superada
3 campos asignados · Sin escrituras en el destino
Diseño ilustrativo basado en las herramientas de asignación de Tajo. Una vista previa sintética y un borrador guardado no activan la sincronización.
Recorre el flujo actual hacia atrás, desde el resultado. Para cada paso, pregunta qué fallaría si desapareciera. Un control real tiene una respuesta: se perdería el consentimiento, se ignoraría una disputa de pago o podría enviarse algo sin autorización. Un traspaso habitual puede tener solo una explicación histórica: el sistema antiguo necesitaba un archivo.
La categoría de eliminación no autoriza a borrar salvaguardas. Antes de elegir una categoría, averigua para qué sirve cada paso.
- Resultado necesarioresultado para el clienterecorrer hacia atrás
- Examinar los pasospropósito y controleliminar pasos obsoletos
- Trabajo que permaneceresponsable y comprobable
La auditoría identifica el resultado y las dependencias que realmente lo protegen. Si una hoja de cálculo contiene un criterio de negocio que no está en ningún otro sitio, hay que conservar ese criterio aunque desaparezca el archivo.
| Tipo de paso | Pregunta | Ejemplo en un flujo ilustrativo de carrito |
|---|---|---|
| Eliminar | ¿Protege o produce el resultado necesario? | Una exportación duplicada que nadie lee |
| Código normal | ¿La regla es exacta y estable? | Suprimir un recordatorio cuando hay una compra verificada |
| Criterio de modelo | ¿El paso exige una interpretación acotada? | Clasificar una solicitud en texto libre para enviarla al equipo adecuado |
| Persona o política aprobada | ¿La decisión concede autoridad o conlleva consecuencias materiales? | Aprobar el acceso a datos de clientes |
La tabla es una herramienta de diseño. No informa de cómo se clasificaron los pasos reales de ninguna empresa.
Pon las reglas exactas en el código
Una llamada a una API, una validación de campo, una comparación de marcas de tiempo o una comprobación de permisos no mejora porque un modelo improvise. El código puede expresar una invariante, ejecutarse igual dos veces y producir un fallo que se pueda examinar. Úsalo cuando la regla se pueda formular.
En el ejemplo del carrito, un evento de compra puede llegar tarde o dos veces. El programa debe identificar el pedido, comparar el estado actual y evitar un recordatorio cuando ya se conoce la compra. Si el sistema no puede averiguar si hubo una compra, necesita un estado de incertidumbre. Un modelo no puede concederse permiso para adivinar que el cliente no compró.
Parte del trabajo resiste las reglas exactas. Una solicitud de soporte podría decir: «Compré esto ayer, pero el recibo muestra mi dirección anterior». Para dirigir el mensaje quizá sirva un criterio semántico acotado. El resultado debería ser un equipo conocido o «no se puede determinar», no una instrucción abierta para modificar el pedido. Mantén separada la decisión del modelo del código que aplica los permisos y modifica el estado.
Un agente puede ocultar los pasos
«Un agente podría leer el flujo y hacerlo todo». Una demostración puede dar esa impresión de sencillez. En producción sigue haciendo falta que alguien explique por qué el agente puede consultar un registro, qué acciones tiene permitidas y cómo revertir una acción equivocada. Un agente general oculta los mismos pasos dentro de un prompt y borra las etiquetas que facilitaban auditarlos.
Hay otra objeción: la propia auditoría de cuatro categorías lleva tiempo. Es cierto. Hazla breve. Elige un resultado para el cliente, enumera los pasos necesarios para conseguirlo y pregunta qué aporta cada uno. El ejercicio solo resulta útil si reduce el trabajo o aclara la responsabilidad. Auditar en detalle todos los sistemas cercanos se convierte en otra caja más.
Prueba la clasificación con un caso normal y uno de fallo. Si un paso eliminado era en realidad un control, la prueba debería revelarlo. Si no puedes evaluar el criterio del modelo con ejemplos, acótalo o devuelve la decisión a una persona. Si hay que cambiar el código con cada excepción de un cliente, separa los mecanismos estables de las reglas locales del negocio.
La auditoría también necesita una condición para detenerse. Un equipo podría descomponer cada tarea hasta que clasificarla cueste más que el trabajo ahorrado. Detente cuando cada paso que permanece tenga una persona responsable, un activador y un motivo comprobable. Registra la única incertidumbre que podría cambiar el diseño y pruébala en el fragmento real más pequeño. En una sincronización, podría ser si un evento de compra llega lo bastante pronto como para suprimir un recordatorio en cola. La guía de integración ofrece una secuencia de planificación más amplia; las cuatro categorías evitan que esa secuencia conserve pasos innecesarios. Revisa la clasificación cuando cambien el flujo o sus permisos.
El paso más barato es el que el resultado nunca necesitó.
Preguntas frecuentes
¿Qué debería eliminarse antes de automatizar?
Un paso que solo exista para compensar un traspaso eliminable, un registro duplicado o un informe que nadie usa puede ser candidato. Comprueba quién usa sus resultados y los controles asociados antes de eliminarlo.
¿Cuándo necesita un paso un modelo?
Usa un modelo para un criterio semántico acotado que no pueda expresarse mediante una regla exacta y estable, con entradas observables, resultados tipados y una vía para gestionar la incertidumbre.
¿Qué decisiones deben seguir en manos de una persona?
Mantén con una persona responsable o una política aprobada explícitamente las decisiones que requieren consentimiento, conceden permisos o tienen consecuencias que superan el alcance autorizado del sistema.