Simplificar lo que pesa: la regla del post-it para reducir pasos y handoffs

Simplificar un flujo operativo es reducir dos cosas a la vez: el número de decisiones humanas triviales que el proceso requiere, y el número de handoffs entre personas o sistemas que rompen la continuidad del trabajo. La regla operativa cabe en una frase: si el criterio cabe en un post-it, no necesita un comité. Una aprobación de gasto por debajo de cierto umbral con proveedor recurrente no necesita un email a tres personas. Una incidencia rutinaria con respuesta conocida no necesita escalado. Un cierre mensual que pasa por dos hojas de Excel intermedias que solo trasladan datos de un sitio a otro no necesita esas dos hojas. Simplificar es distinto de eliminar — en el paso 1 se quita el paso entero, aquí el paso se queda pero se le quita la fricción. Y es distinto de automatizar — todavía no entra código, solo regla operativa escrita. Después de este paso, el flujo está lo bastante limpio para que un sistema determinista lo ejecute sin supervisión humana en cada caso.

Eso es el paso 3 del Zero Friction Method: simplificar. Llega después de eliminar lo que sobra y de estandarizar lo que queda, y antes de automatizar. El orden importa: simplificar lo que no se ha eliminado es trabajo en vano, y automatizar lo que no se ha simplificado es construir un sistema rápido haciendo cosas que no deberían pesar lo que pesan.

La regla del post-it

La señal más fiable para identificar un paso simplificable es la prueba del post-it. Si el criterio que un humano usa para decidir cabe en una nota de tres líneas — “compras de menos de 500 euros a proveedores con histórico de 12 meses se aprueban automáticamente”, “incidencias del tipo X se resuelven con la respuesta tipo Y”, “facturas con desviación menor al 2% respecto al pedido se concilian sin revisión” — entonces ese paso no necesita un humano cada vez. Necesita una regla escrita y la autoridad para aplicarla.

La prueba del post-it no es solo retórica. Es operativa. Cuando se le pide a la persona que ejecuta el flujo “escríbeme en tres líneas cómo decides este caso” y consigue hacerlo, eso es la regla. Cuando no consigue, eso es señal de que el paso requiere juicio real y se queda como decisión humana. La diferencia entre los dos casos es lo que separa el paso simplificable del paso que no lo es.

El error que mata la conversación es pedir el criterio al responsable, no al ejecutor. El responsable describe el criterio idealizado, que casi nunca es el real. El ejecutor describe el criterio que aplica en la práctica, que casi siempre es más simple y más binario de lo que la organización admite oficialmente.

Los dos vectores: decisiones y handoffs

Simplificar opera sobre dos dimensiones distintas que tienden a confundirse.

Decisiones triviales escaladas. El flujo contiene una decisión que en su definición formal requiere aprobación de tres personas, pero en la práctica el 90% de los casos siguen el mismo patrón. Una compra recurrente. Una incidencia conocida. Una desviación dentro de tolerancia. Cada uno de esos casos genera correos, esperas, recordatorios, y la decisión cuando llega es la misma de siempre. Simplificar aquí es escribir el criterio del 90% en una regla y reservar el comité para el 10% restante.

Handoffs entre personas o sistemas. El flujo pasa de la persona A a la persona B a la persona C, o del sistema X al Excel intermedio Z al sistema Y, y en cada handoff hay un coste: alguien copia, alguien pega, alguien valida que el dato no se ha corrompido en el trayecto. Esos handoffs son fricción pura. No son pasos que aporten valor, son pasos que existen porque la integración real entre los dos extremos nunca se hizo. Simplificar aquí es identificar dónde el dato cruza una frontera artificial y o bien eliminar la frontera, o bien aceptar que el handoff existe y reservarlo para casos donde sí aporte.

Los dos vectores suelen estar entrelazados en el mismo flujo. La aprobación de gasto que escala a tres personas pasa por dos sistemas distintos, con un Excel intermedio donde alguien transcribe. Simplificar resuelve los dos: el criterio binario para el 90% de los casos y la conexión directa entre los dos sistemas.

Cómo se hace, en concreto

El protocolo es directo. Se necesita el mapa de pasos que sobrevivió al ejercicio de eliminación y la lista de canónicos que salió de la estandarización. Sobre ese material, se hace una pasada con dos preguntas por paso:

1. ¿La decisión que se toma aquí cabe en un post-it? Si la respuesta es sí, se escribe la regla, se valida con el responsable funcional, y ese paso queda marcado como aprobación automática con umbral. Si la respuesta es no, el paso se queda como decisión humana real.
2. ¿Este paso existe porque el dato cruza una frontera artificial? Si la respuesta es sí, se documenta la frontera y se marca como candidato a integración directa en el paso 4. Si la respuesta es no, el paso aporta valor en sí mismo y se queda.

El entregable de esta sesión es una tabla con cuatro columnas: paso, tipo (decisión trivial / handoff / valor real), regla escrita (cuando aplica), responsable de la decisión final. No es un informe consultor. Son tres páginas como mucho, lenguaje plano, una entrada por paso.

Lo importante de esta tabla no es la tabla. Es que cuando un director de operaciones la firma, lo que está firmando es que el ejecutor del flujo puede aplicar las reglas de aprobación automática sin pedir permiso caso a caso. Esa autorización es el desbloqueo real. La tecnología viene después y es la parte fácil.

Tres ejemplos típicos

Aprobación de gasto. Una empresa con doscientos empleados procesa varios miles de facturas al año. El flujo formal requiere aprobación del responsable de departamento para cada factura. En la práctica, el 80% de las facturas son de proveedores con histórico de doce meses o más, importe por debajo de la media de ese proveedor, y conceptos repetidos. Simplificar aquí es: gasto por debajo de mil euros con proveedor recurrente y concepto recurrente se aprueba automáticamente; el responsable revisa solo el 20% restante. El responsable recupera horas a la semana. La aprobación deja de ser cuello de botella.

Gestión de incidencias rutinarias. Un equipo de soporte recibe cien tickets al mes. La mitad son de tres o cuatro tipos conocidos con respuesta tipo documentada. Hoy cada ticket pasa por triage humano antes de asignarse. Simplificar es: tickets que coinciden con uno de los patrones conocidos reciben la respuesta tipo y se cierran sin pasar por triage. El equipo de soporte deja de hacer triage de lo rutinario y se concentra en los tickets que sí requieren juicio.

Cierre mensual con Excel intermedios. El responsable financiero monta dos hojas de Excel cada mes para llevar datos del ERP a la herramienta de reporting. Esas dos hojas no transforman el dato, solo lo trasladan. Simplificar es identificar que esas dos hojas son un handoff puro entre dos sistemas y dejarlas marcadas para integración directa. Después del paso 4, esas dos hojas desaparecen y el dato pasa del ERP al reporting sin intermediarios humanos.

En los tres ejemplos, la simplificación no es código. Es decisión organizativa más regla escrita más permiso para aplicarla. El código del paso 4 ejecuta la regla, pero la regla ya estaba.

El error más frecuente: confundir simplificar con automatizar

La trampa que vemos repetida es saltar directamente al paso 4 sin pasar por este. Una empresa identifica que las aprobaciones de gasto son cuello de botella y compra una herramienta de workflow para automatizarlas. La herramienta se configura con el flujo actual: tres aprobadores, escalado en cada nivel, espera por email. La automatización mete velocidad encima del flujo viejo. La fricción sigue ahí, solo que ahora es fricción digital en lugar de fricción de papel.

El error es asumir que la herramienta resolverá la complejidad del flujo. No lo hace. Lo que la herramienta hace bien es ejecutar reglas claras. Si las reglas no están claras antes, lo que se automatiza es el caos.

Simplificar antes de automatizar significa que cuando entra la herramienta del paso 4, lo que tiene que hacer es lo más simple posible: aplicar una regla binaria, conectar dos sistemas directamente, ejecutar una respuesta tipo. Cuanto más simple es el flujo en el momento de la automatización, más barato y más mantenible es el sistema final.

El permiso, otra vez

Como en el paso 1, lo que falta para simplificar casi nunca es técnica. Es permiso. La regla del post-it para aprobación de gasto está escrita en la cabeza del responsable de departamento desde hace años. Lo que no había era la autorización formal para que esa regla sustituyera al proceso de tres firmas. Y la respuesta tipo para incidencias rutinarias está en el conocimiento del equipo de soporte. Lo que no había era la decisión de aceptar que esa respuesta tipo cierra el ticket sin necesidad de validación adicional.

Esas decisiones las toma siempre un director, no una herramienta. Y casi siempre están disponibles cuando se piden con la documentación correcta: tres páginas, tabla con cuatro columnas, criterios escritos, responsable final. El director firma o no firma cada regla. Cuando firma, se aplica esa misma semana sin código. Cuando no firma, se queda como decisión humana y se documenta el porqué.

Cuando el flujo está simplificado, el paso 4 funciona sobre reglas claras y conexiones directas. Y la IA del paso 5, cuando llega, opera sobre los pocos casos que requieren juicio real, no sobre el 80% rutinario que ya estaba resuelto desde la simplificación.

¿Cuántas decisiones del flujo más caro de tu operación caben hoy en un post-it y, aun así, siguen pasando por un comité?

---

Si vuestra empresa quiere identificar qué decisiones del flujo caben en un post-it y qué handoffs entre sistemas son fricción pura, el diagnóstico operativo de 2 semanas entrega la tabla de reglas escritas y la lista de integraciones directas priorizadas por impacto, firmada por el responsable funcional.