Stanton: dábamos por hecho que las facturas no cambian. Las facturas cambian

El equipo reenvía las facturas a un chat de Telegram, que hace de buzón. No hay ninguna herramienta nueva que aprender, ni una pantalla más en la que entrar cada mañana.

La elección tiene una parte que conviene decir en voz alta. Telegram no es el canal al que la gente está acostumbrada. Esa es la razón por la que casi nadie lo usa para esto.

Lo elegimos igualmente porque para este trabajo es el más factible de todos. Su interfaz de programación es sencilla y gratuita, así que el buzón se monta en horas en lugar de en semanas y no añade una cuota mensual al proyecto antes de que nadie haya demostrado que funciona.

Y la parte que sí importa al equipo se cumple. Reenviar un documento a un chat es algo que cualquiera sabe hacer desde el móvil, esté donde esté.

La primera versión leía cada factura, extraía los campos y los dejaba en la hoja de cálculo con la que el equipo ya trabajaba. Funcionaba. Ese no era el problema.

¿Qué se nos escapó, entonces? Una suposición que no habíamos escrito en ninguna parte. Dábamos por hecho que una comercializadora emite siempre sus facturas igual.

No es así. Una comercializadora rediseña su factura cuando le conviene, sin avisar a nadie y desde luego sin avisar a la gestora que las recibe. El día que eso pasa, el sistema sigue leyendo, sigue extrayendo y sigue escribiendo filas. Solo que algunas ya no dicen lo que parecen decir.

Ese es el fallo caro de esta clase de sistemas. No el que se rompe con estrépito, sino el que sigue funcionando y va llenando una hoja de cálculo de datos que nadie va a volver a comprobar.

Lo que añadimos no fue más inteligencia, fue una comprobación. Antes de dar por buena la lectura, el flujo verifica que la factura tiene la forma que se espera de ella.

Cuando esa comprobación falla, el flujo no continúa. No intenta adivinar dónde ha quedado el total ahora, no lo aproxima y no escribe una fila con lo que ha podido sacar. Se detiene y avisa a una persona, con el documento delante para que decida.

La factura que llega distinta deja de ser un dato silencioso y pasa a ser un aviso. Es más trabajo el día que ocurre y es mucho menos trabajo los meses siguientes, cuando ya nadie tiene que auditar una hoja hacia atrás buscando desde cuándo cuadran mal las cifras.

La verificación del formato es una de tres. Las otras dos son igual de aburridas y hacen el mismo trabajo.

Que estén todos los datos, porque un campo que falta no puede quedarse vacío en la hoja como si el dato no existiera. Que cuadren entre sí, porque un total que no suma sus conceptos es un total en el que no se puede confiar. Y que el formato sea el previsto, que es la que aprendimos por el camino difícil.

Las tres se ejecutan en medio del flujo, antes de que nada llegue a la hoja de cálculo. Validar al final, cuando el dato ya está escrito, convierte cada error en una corrección que hay que rastrear.

Hoy el 98 % de las facturas se convierte en filas sin que nadie las toque. El equipo ya no teclea importes ni fechas.

El 2 % restante no desaparece, escala. Sale del flujo con el documento al lado y el motivo señalado, así que quien lo revisa ve en qué se atascó en lugar de tener que buscarlo.

¿Y por qué no aspirar al cien por cien? Porque ese reparto es lo que hace que el número valga algo. Un sistema que pasara el cien por cien estaría inventando en el 2 % que no entendió. Ese 2 % iría a la hoja de cálculo con el mismo aspecto que el resto.

Son dos agentes en producción, no una plataforma. Y la palabra agente está elegida, porque debajo de cada uno hay flujos, que son secuencias de pasos que corren siempre igual.

El agente es quien decide qué flujo activar con lo que acaba de llegar. Es el mismo reparto de siempre, el modelo elige el camino y el código lo recorre, con la diferencia de que aquí el camino es un flujo entero en vez de una consulta.

Empezaron por las facturas de suministros, que era el proceso que más horas se llevaba. Desde entonces el cliente ha ido ampliando la automatización a otros procesos administrativos.

Ese es el patrón que recomendamos y el que vemos sobrevivir. El primer proceso paga el montaje, la conexión, el registro y las comprobaciones. Los siguientes lo reutilizan y se deciden con los números del que ya está funcionando.

Sobre cuánto tarda el primero, la respuesta honrada depende de lo que haya al empezar. Con los datos disponibles, los accesos concedidos y la tarea bien definida, un piloto en dos semanas es realista.