The Zero Friction Method: por qué eliminamos antes de automatizar

The Zero Friction Method es el orden operativo con el que entramos en una empresa: cinco verbos en secuencia estricta. Uno, eliminar lo que sobra — los pasos que ningún miembro del equipo defiende cuando se les pregunta directamente. Dos, estandarizar lo que queda — definir el canónico para cada variación que la operación llevaba años posponiendo. Tres, simplificar lo que pesa — reducir las decisiones humanas triviales que no requieren comité. Cuatro, automatizar lo determinista — código real, OCR, integraciones, no Excel-pegamento. Cinco, aumentar con IA — solo para lo que necesita juicio a escala. La IA es el paso 5, no el 1, y saltarse pasos es la causa estructural de que un proyecto con seis cifras de presupuesto termine, dieciocho meses después, como una demo bonita parada en una nube. El verdadero entregable del método no es el sistema final: es que el equipo del cliente sepa aplicar la misma secuencia sin nosotros, seis meses después de irnos.

Hay una pregunta que casi nadie hace en una primera reunión y que cambia todo lo que viene después: ¿este paso necesita existir?

No “¿cómo lo automatizamos?”. No “¿qué herramienta de IA encaja aquí?”. La pregunta es anterior y es más incómoda, porque obliga a admitir algo que la mayoría de operaciones llevan años posponiendo: una parte del proceso existe por costumbre, no por necesidad.

Trabajamos en empresas industriales medianas donde el flujo de pedido tiene catorce pasos, el cierre mensual ocupa dos sábados de la misma persona, y la integración entre el ERP y el TMS la hace un Excel que solo entiende María. Cuando nos llaman, casi siempre la frase es la misma: “queremos meter IA en esto”. Y casi siempre nuestra respuesta es la misma: la IA viene después. Mucho después.

Esto no es eslogan. Es un orden operativo, con cinco verbos, que aplicamos siempre igual. Lo llamamos The Zero Friction Method.

Los cinco verbos

El orden importa más que cualquier herramienta concreta. Saltarse un paso es la razón por la que un proyecto de IA con seis cifras de presupuesto termina, dieciocho meses después, como una demo bonita parada en una nube.

Vamos uno por uno.

1. Eliminar lo que sobra

Es el paso gratis, y por eso casi nadie lo hace.

Cuando entramos en una operación, lo primero que pedimos es sentarnos con las personas que ejecutan el proceso, no con las que lo describen en una diapositiva. Pedimos que nos enseñen el flujo paso a paso, sobre la pantalla real, con un caso real. En menos de una hora aparecen, sin excepción, varios pasos que ningún miembro del equipo defiende cuando se les pregunta directamente: “¿este paso por qué existe?”

Las respuestas más frecuentes son tres. “Porque siempre se ha hecho así.” “Porque lo pedía un cliente que ya no es cliente.” “Porque el sistema antiguo lo necesitaba y nunca lo quitamos.”

Eliminar esos pasos no requiere tecnología, ni código, ni presupuesto. Requiere permiso para hacerlo. Y ese permiso, casi siempre, está disponible: el director de operaciones lleva meses sospechando que sobran, lo que no había era el espacio para auditarlos.

Cuando se eliminan, el flujo pesa la mitad antes de tocar nada técnico. Esa es la base sobre la que se monta todo lo demás. Si esto no se hace, lo que automatices después tendrá la misma deuda operativa, solo que más rápida. La sesión completa, con el protocolo paso a paso y los tres errores que lo arruinan, la dejamos escrita en cómo identificar los pasos del flujo que sobran.

2. Estandarizar lo que queda

Después de eliminar, lo que sobrevive sigue siendo heterogéneo. Cada cliente tiene su excepción. Cada proveedor tiene su formato. Cada delegación tiene su pequeña variación que “siempre se ha hecho así por respeto a su forma de trabajar”.

Estandarizar no es imponer rigidez. Es definir el canónico, escribir cuál es la versión por defecto del proceso, y aceptar que las excepciones son excepciones, no la norma escrita de cinco maneras distintas.

Cuando un catálogo lleva la misma marca escrita de cuatro maneras distintas, el problema no es de datos. Es la decisión que llevan años posponiendo: aceptar que la limpieza es parte del trabajo, no un proyecto aparte. Cuando la facturación de un proveedor llega en PDF y la de otro en Excel y la de un tercero en email, lo difícil no es leerlas, lo difícil es decidir cuál es el formato canónico al que todas deben aterrizar.

La estandarización es trabajo poco glamuroso, no se vende en pitches y nadie hace presentaciones de casos de éxito sobre un canónico de proveedor. Pero sin ella, el paso 4 no funciona y el paso 5 amplifica el caos en lugar de resolverlo. Cómo se hace en la práctica, con el ejemplo concreto de un catálogo, lo desarrollamos en estandarizar antes de automatizar.

3. Simplificar lo que pesa

Lo que ha sobrevivido a la eliminación y se ha estandarizado, ahora se simplifica.

Simplificar significa reducir el número de decisiones humanas que el flujo requiere. No reducir las decisiones importantes, reducir las decisiones triviales que hoy se toman a mano y que nadie disfruta tomando. La regla operativa es directa: si el criterio cabe en un post-it, no necesita un comité.

En un flujo de aprobación de gasto, simplificar puede ser definir que cualquier compra por debajo de cierto umbral con proveedor recurrente se aprueba directamente, sin pasar por un email a tres personas. En un flujo de incidencia, simplificar es decidir que las incidencias rutinarias tienen una respuesta tipo y que solo las atípicas se escalan. En un flujo de cierre, es eliminar las dos hojas de Excel intermedias que no cambian el resultado, solo lo trasladan de un sitio a otro.

Después de este paso, el flujo es lo bastante limpio para que un sistema determinista lo ejecute sin que nadie lo supervise. Cómo se identifican las decisiones simplificables y los handoffs entre sistemas, con el protocolo concreto y tres ejemplos, lo desarrollamos en simplificar lo que pesa.

4. Automatizar lo determinista

Aquí, y no antes, entra el código.

Automatización no significa IA. Significa que un sistema con reglas claras hace lo que antes hacía una persona escribiendo lo mismo veinte veces al día. Un sistema que extrae datos de una factura con un OCR convencional. Una integración entre el ERP y el TMS que pasa de Excel-pegamento a una conexión real. Un dashboard que se actualiza cuando el dato cambia, no cuando alguien recuerda exportarlo.

La automatización en este punto funciona porque el proceso ya está limpio. Si automatizas el flujo del paso 1 sin haber eliminado nada, terminas con un sistema rápido haciendo cosas que no deberían existir. La eficiencia aparente sube, la deuda operativa también.

Casi todo el valor de un proyecto operativo se libera en este paso, no en el siguiente. La IA cierra. La automatización determinista carga.

5. Aumentar con IA

La IA entra cuando se la gana, no antes. Y cuando entra, hace lo que ningún sistema determinista puede hacer: tomar decisiones que requieren juicio a escala.

Detectar la anomalía que el ojo humano se salta porque está cansado un viernes por la tarde. Categorizar variantes de la misma marca cuando entra una grafía nueva que las reglas no contemplan. Responder en castellano a una pregunta del ERP sin que nadie tenga que escribir SQL. Sugerir el cargo más probable para una factura nueva basándose en el patrón histórico del proveedor.

Para todo esto, la IA es la herramienta correcta. Para los cuatro pasos anteriores, no.

Cuando se sigue este orden, lo que el cliente vive no es “metimos IA”. Es “dejé de tener que mirar facturas en mi día”, “sé cuánto vendí el trimestre pasado por delegación en cinco segundos”, “el dashboard cuenta la historia sin que nadie lo monte cada lunes”. La IA es invisible. Lo visible es el resultado operativo.

Por qué saltar pasos rompe todo

El error más caro que vemos en el mercado es exactamente este: empresas que contratan un proyecto de IA para automatizar un proceso que nadie ha revisado. Se salta el paso 1, se salta el paso 2, se salta el paso 3, y se intenta entrar directamente por el paso 4 o el 5.

El resultado es predecible. La IA aprende los patrones del proceso roto. Las excepciones siguen siendo excepciones, ahora más caras de gestionar. Las cinco maneras de escribir la misma marca siguen ahí, ahora con un modelo encima que las trata como cinco entidades distintas. Los catorce pasos del flujo siguen siendo catorce, ahora ejecutados por un agente que confunde a la persona del equipo que tenía que operarlo.

Y lo peor: el equipo del cliente se queda con la sensación de que la IA “no funciona”. Cuando lo que no ha funcionado es el orden.

Lo hemos visto suficientes veces para saber que el patrón es estructural, no accidental.

El verdadero entregable

The Zero Friction Method tiene una propiedad que rara vez aparece en presentaciones: el verdadero entregable no es el sistema construido al final. Es que el equipo que lo opera, seis meses después de que nos hayamos ido, identifique un problema nuevo y lo resuelva con la misma secuencia de cinco verbos, sin nosotros.

Eso es lo que medimos. Si el equipo del cliente ha aprendido a preguntarse “¿este paso necesita existir?” antes de pedirnos que automaticemos algo, hemos cumplido. Si el equipo solo sabe operar el sistema concreto que entregamos, hemos hecho algo más cercano a un piloto eterno con final feliz, que es mejor que nada pero no es lo que prometimos.

Construimos para irnos, no para quedarnos. El método es la herramienta que hace eso posible.

Si tu operación está pensando en IA

Una sola pregunta antes de elegir herramienta o proveedor: ¿alguien ha mirado el flujo paso a paso, en pantalla real, con un caso real, en los últimos seis meses?

Si la respuesta es no, ese es el primer paso. No la IA. No el sistema. La pregunta de si todos esos pasos del flujo necesitan existir.

Cuando esa pregunta se ha hecho honestamente y se ha actuado sobre la respuesta, la IA encaja como un guante. Antes, ni eso.

¿Cuántos pasos tiene hoy tu flujo más caro, y cuándo fue la última vez que alguien los miró uno a uno?

---

Si vuestra empresa está pensando en meter IA en un proceso operativo y queréis recorrer estos cinco verbos sobre vuestro flujo real antes de elegir herramienta, el diagnóstico operativo de 2 semanas es la primera puerta. Salimos con el flujo mapeado, los pasos que sobran identificados, y un plan priorizado por impacto.