En resumen: Un system of action es la capa del stack que lee de tus sistemas de registro (ERP, eCommerce, CRM), cruza la información, decide con las reglas de tu negocio y ejecuta la acción dentro de esos mismos sistemas. Por ejemplo, genera la guía de cada orden, concilia los pagos con sus facturas y avisa al cliente, con traza de cada acción.
Un system of action (sistema de acción, en software) es el software que ejecuta el trabajo operativo que vive entre tus sistemas: toma los datos de los sistemas de registro, los cruza, aplica las reglas del negocio y escribe de vuelta cada acción, con traza completa y con tu aprobación donde hace falta.
Soy Cris Ugarte, CEO y cofundador de Puente OS, la plataforma que construye los sistemas que operan tu negocio. Trabajamos con empresas de retail, eCommerce y logística de Latinoamérica, en Chile, Perú y México, y en la mayoría vemos el mismo hueco en el stack.
¿Qué es un system of action?
Un system of action es el tercer piso del stack. Sobre el system of record, que guarda cada transacción, y el BI, que te la muestra, está la capa que ejecuta el siguiente paso dentro de esos mismos sistemas: lee, cruza, decide y actúa. Cada acción queda registrada y es explicable.
Piensa en tu stack como un edificio de tres pisos.
Primer piso: el system of record
Tu ERP, tu eCommerce, tu CRM y tus marketplaces registran cada transacción: la venta, el despacho, la factura, el pago. Son tu system of record, la fuente de verdad, y su trabajo es guardar bien lo que pasó.
Segundo piso: el BI
Tu BI toma lo que registró el primer piso y lo convierte en dashboards: cuánto vendiste, qué se atrasó, dónde se fue el margen. Te muestra lo que pasó.
Tercer piso: el que ejecuta
El tercer piso ve que una orden quedó sin guía y la genera. Detecta una comisión descuadrada y la corrige. Lee que un cliente preguntó por su pedido y le responde con el tracking. En la mayoría de las empresas, ese piso es tu equipo: personas con cinco pestañas abiertas, un Excel madre y un grupo de WhatsApp donde alguien escribe "oye, ¿salió la guía de la orden de ayer?".
Ese tercer piso tiene nombre: system of action. El marco From Systems of Record to Systems of Action lo define como software que lee de los sistemas de registro, razona sobre esos datos y ejecuta acciones gobernadas. En Puente le sumamos el piso del BI y lo llevamos a la operación de comercio y logística.
¿Qué diferencia hay entre system of record y system of action (y dónde entra el BI)?
El system of record, el BI y el system of action se complementan. El system of record guarda cada transacción y es la fuente de verdad. El BI ordena esos datos para que entiendas el negocio. El system of action toma las señales de ambos, decide con tus reglas y ejecuta el siguiente paso dentro de tus sistemas.
System of record vs system of action, con el BI al medio, en cuatro dimensiones:
- La pregunta que responde. System of record: ¿qué pasó? BI: ¿cómo vamos y por qué? System of action: ¿qué toca hacer ahora y quién lo hace?
- Lo que produce. System of record: transacciones y datos maestros. BI: reportes y alertas. System of action: acciones ejecutadas (guías, estados, comisiones, respuestas) y excepciones con dueño.
- Cuándo trabaja. System of record: cuando se registra una transacción. BI: cuando alguien abre el reporte. System of action: cuando cambia un dato, llega un evento o vence un plazo.
- Quién ejecuta el siguiente paso. System of record y BI: una persona. System of action: el sistema en lo que tiene reglas claras, y una persona con contexto en lo que requiere criterio.
¿En qué se diferencia un system of action de un RPA, un iPaaS o un agente de IA?
Un system of action orquesta un proceso completo, y el RPA, el iPaaS y los agentes de IA resuelven partes de ese proceso. El RPA repite clics en una pantalla, el iPaaS sincroniza datos y el agente interpreta textos y documentos. El system of action junta el contexto, las reglas, las excepciones con dueño y la escritura de vuelta.
- RPA. Imita los clics de una persona. Sirve para tareas fijas y funciona mientras la pantalla se mantiene igual.
- iPaaS o integración. Mueve datos entre sistemas con reglas de mapeo. La decisión y la excepción quedan en el equipo.
- Agente de IA. Lee, interpreta y redacta. Rinde mejor dentro de un proceso con reglas y aprobaciones.
- System of action. Lleva la automatización de procesos de punta a punta: lee de todos tus sistemas, aplica reglas explícitas a lo repetible, usa agentes donde hay que interpretar y escribe de vuelta en cada sistema.
¿Qué significa que una acción sea gobernada?
Una acción gobernada es una acción que el sistema ejecuta dentro de las reglas y aprobaciones que definió tu empresa, y que queda registrada con la razón que la gatilló. En Puente OS, cada cambio al sistema tiene vuelta atrás a la versión anterior, y todo entra a producción con la aprobación de tu equipo.
En la práctica, cumple cuatro condiciones:
- Es explicable. Deja escrito qué dato la gatilló y qué regla aplicó.
- Queda registrada. Cualquier persona puede reconstruir qué pasó con una orden o un pago.
- Respeta tus aprobaciones. Tu empresa define montos, umbrales y quién aprueba: una nota de crédito sobre cierto monto espera en una App hasta que finanzas la firma.
- Corre sobre versiones con vuelta atrás. Si una regla cambia o un paso sale mal, el sistema vuelve a la versión anterior, y lo que ya se ejecutó queda en el registro para corregirlo.
Varios de nuestros clientes exigen reglas explícitas y auditables para su lógica crítica: una regla escrita se revisa, se prueba y se mejora.
¿Por qué el trabajo entre sistemas termina en manos de tu equipo?
El trabajo entre sistemas termina en tu equipo porque cada sistema resuelve bien su parte y lo que queda entre ellos (el traspaso, la validación, el "alguien tiene que mover esto") lo absorbe una persona. Con cada herramienta nueva aparece un traspaso nuevo, y el equipo termina haciendo de middleware humano, conectando sistemas a mano.
Según el Anatomy of Work Index de Asana, que encuestó a más de 10.000 trabajadores del conocimiento, el 60% del tiempo de trabajo se va en "trabajo sobre el trabajo": comunicar sobre las tareas, buscar información, saltar entre aplicaciones y perseguir el estado de lo pendiente. Un estudio publicado en Harvard Business Review siguió a 137 personas en tres empresas Fortune 500: cambiaban de aplicación o sitio web unas 1.200 veces al día, y reorientarse les tomaba poco menos de cuatro horas a la semana, cerca del 9% de su tiempo de trabajo.
A ese costo lo llamamos el impuesto de coordinación: reuniones, aprobaciones y traspasos manuales que crecen con cada venta.
Lo vi de cerca antes de Puente. Con Octavio, mi socio, trabajamos juntos en Walmart Chile, y el tercer piso lo ocupábamos nosotros. Dijimos: si al retailer más grande del mundo le pasa, le pasa a todos. Ese piso se puede construir.
¿Cómo se ve un system of action en una operación real?
Un system of action en una operación real se ve como procesos que corren de punta a punta y le llevan a tu equipo solo lo que requiere criterio. Tres ejemplos de system of action en retail, eCommerce y logística: la orden que sale con su guía, la conciliación de pagos y la operación que vive en planillas.
Ejemplo 1: de la orden al cliente
Un viernes a las 23:40 entra una orden en el eCommerce:
- El workflow lee la orden apenas se crea.
- Confirma el stock en el ERP y elige la bodega según la zona de despacho del cliente.
- Elige el courier según peso, costo y nivel de servicio comprometido.
- Genera la guía en el portal del courier.
- Actualiza el estado en el ERP y en el canal de venta.
- Le avisa al cliente con su número de seguimiento.
Si falta un dato, como una dirección incompleta, la excepción llega a la persona correcta con la orden y la acción sugerida, lista para resolver en un clic.
Una versión de este flujo ya corre en producción. En uno de nuestros clientes, un vendedor multicanal de electrónica en México que operaba con planillas, el sistema valida la dirección, elige la paquetería por zona, costo y seguro, y genera la guía: el 97,9% de las órdenes sale con su guía sin intervención humana.
Ejemplo 2: la conciliación y los pagos
El pago llega al banco con una referencia incompleta, y alguien lo cruza a mano con la factura del ERP.
Con un system of action, el workflow lee los movimientos, busca la factura que calza por monto, fecha e identificador del cliente, aplica la tolerancia que definió finanzas y registra la conciliación. Lo que queda fuera de regla llega a finanzas con las facturas candidatas ya sugeridas.
Ejemplo 3: donde la operación vive en planillas
En muchas operaciones, las devoluciones viven en un Excel y un grupo de WhatsApp. Con un system of action:
- El cliente pide la devolución por WhatsApp y adjunta una foto.
- Un agente lee el mensaje y la foto, e identifica la orden y el motivo.
- El workflow valida la fecha de compra contra tu política.
- Crea el registro en las Bases de datos de Puente, genera la guía de retiro y avisa a bodega.
- Cuando el producto llega, deja lista la nota de crédito para que finanzas la apruebe.
Puente actúa sobre tus sistemas, y donde la operación vive en planillas, también guarda el registro. Es el caso del vendedor de electrónica del primer ejemplo, que opera sin ERP: sus 38.628 órdenes procesadas de punta a punta entre noviembre de 2025 y agosto de 2026 viven en las Bases de datos de Puente.
¿Con qué piezas se construye un system of action?
Un system of action se construye con integraciones a tus sistemas, una capa de datos que cruza la información, reglas que deciden, algo que interprete lo ambiguo y una interfaz donde tu equipo aprueba. En Puente OS eso toma la forma de cuatro piezas: Apps, Agentes, Workflows y Bases de datos.
- Bases de datos, junto con las integraciones, para el contexto que cruza sistemas: órdenes, stock, guías y pagos en un mismo lugar.
- Workflows con reglas explícitas y auditables para lo repetible. Se gatillan cuando cambia un dato o a una hora fija, y ejecutan dentro de tus sistemas.
- Agentes para lo que requiere interpretar: el mensaje de un cliente, un documento escaneado, una excepción ambigua.
- Apps donde tu equipo ve, decide y aprueba lo que requiere su criterio.
Un system of action con IA, en Puente OS, significa que la IA está en cómo se construye: describes en lenguaje natural lo que tu operación necesita y obtienes software corriendo. Y la escritura de vuelta es concreta: en un retailer de mascotas en Chile con eCommerce multicanal, Puente ya ejecutó 8.362 cambios de precio en Shopify.
¿Cómo se implementa un system of action, paso a paso?
Un system of action se implementa proceso por proceso: eliges el que más duele, levantas cómo funciona hoy, escribes sus reglas y lo pones en producción conectado a tus sistemas. Con Puente OS, cada proceso llega a producción en 2 a 4 semanas.
- Elige un proceso que duela. Con volumen, traspasos manuales y un costo visible cuando falla. Mientras más peludo, mejor.
- Toma la línea base. Con datos de las últimas semanas: casos que entran, tiempo por caso y horas del equipo.
- Levanta el gatillo, las decisiones y las excepciones. Qué evento lo inicia, qué decide hoy una persona, qué casos se salen de la regla y dónde vive cada dato.
- Escribe las reglas en explícito. Por ejemplo: "si el paquete supera cierto peso y la dirección está fuera de cobertura, va con el segundo courier".
- Define el destino de cada excepción. La resuelve el sistema o llega a una persona con nombre, con todo el contexto.
- Configura la escritura de vuelta y los permisos. Qué ejecuta el sistema por su cuenta y qué necesita aprobación.
- Pon el proceso en producción y compáralo con la línea base desde la primera semana.
Los pasos 3 y 5 son el centro del Diseño Autónomo de operaciones: diseñar cada proceso para que lo repetible corra solo, con tus reglas, y tu equipo decida lo que requiere criterio.
¿Cómo se mide si un system of action funciona?
Un system of action se mide por proceso, con indicadores operativos: qué porcentaje de casos completa el sistema de punta a punta, cuánto tarda el ciclo completo, cuántas excepciones aparecen por tipo y cuánto tardan en resolverse, y cuánto volumen maneja el mismo equipo mes a mes.
- Tasa de resolución de punta a punta. Casos que el sistema completa sin intervención, divididos por los casos totales del período. Es el indicador principal.
- Tiempo de ciclo. De la orden a la guía, del pago a la conciliación.
- Excepciones por tipo y tiempo de resolución. Una excepción que se repite es una regla por escribir.
- Volumen por persona. Cuántas órdenes, guías o pagos maneja el mismo equipo.
- Horas de coordinación. Reuniones de seguimiento y mensajes de "¿en qué va esto?".
Compara cada indicador con la línea base del paso 2. En el vendedor de electrónica en México, el volumen mensual subió 40% con el mismo equipo de operaciones (de 3.742 a 5.247 órdenes al mes), y la generación de guías pasó de 5 a 7 horas por corte a 15 minutos.
Imagina un lunes distinto: la operación del fin de semana ya está cerrada y tu equipo toca una de cada cien órdenes. Esa imagen es nuestra meta de diseño, y avanzamos hacia ella proceso por proceso. El dato medido más cercano es el de la generación de guías de ese cliente: el 97,9% de las órdenes sale con su guía sin intervención humana.
¿Qué cambia para el equipo de operaciones con un system of action?
Con un system of action, el equipo de operaciones se queda con el trabajo que requiere criterio: resolver excepciones, negociar con proveedores, cuidar al cliente y mejorar el proceso. El sistema absorbe el volumen repetible, así que la operación puede crecer 2 a 5 veces sin multiplicar el headcount.
Para el primer proceso buscamos uno cuyo retorno llegue en menos de 90 días, así el siguiente paso se decide con datos propios.
Tu ERP registra lo que pasó. Tu BI te muestra lo que pasó. Puente hace que pase.
Puntos clave
- Un system of action lee de tus sistemas de registro, cruza la información, decide con tus reglas y ejecuta.
- Orquesta el proceso completo; el RPA, el iPaaS y los agentes de IA resuelven partes de él.
- Cada acción es gobernada: explicable, registrada y dentro de tus aprobaciones, y cada cambio al sistema tiene vuelta atrás.
- En Puente OS se construye con Apps, Agentes, Workflows y Bases de datos; lo repetible corre con reglas explícitas.
- Se implementa proceso por proceso, en 2 a 4 semanas cada uno, y se mide por casos resueltos de punta a punta.
¿Quieres ver cómo se vería el tercer piso en tu operación? Partimos con un piloto de un mes: en ese mes tu primer proceso queda vivo en producción, y si decides seguir, el valor del piloto se descuenta completo de la implementación. Agenda una demo con nuestro equipo.
