Hay una versión de esta historia en casi todas las funciones financieras en las que hemos entrado. Nunca es un fallo tecnológico. Es un fallo de traducción, y ocurre en un lugar previsible.
La controller conoce la regla. Pregúntele por qué la tolerancia del precio de compra es del 2 % y le dirá que el proveedor de acero factura por toneladas y la obra pide en kilos, así que siempre hay una diferencia de redondeo, y el 5 % dejaba pasar errores reales. Lo sabe desde hace cuatro años. No está escrito en ninguna parte.
El desarrollador puede construir cualquier cosa. Dele una especificación y la entregará a tiempo. Lo que no puede saber es que contabilizar en la cuenta de control equivocada rompe la eliminación intercompañía de marzo, porque nadie le ha explicado nunca qué es una eliminación y a nadie se le ocurriría mencionarlo.
Así que se define el alcance del proyecto. Finanzas escribe los requisitos en lenguaje contable. TI los lee como movimiento de datos. Ambas partes creen haberse puesto de acuerdo. Seis semanas después llega la demo, y la controller pronuncia las palabras que acaban con la mayoría de los proyectos de automatización:
«No es exactamente lo que quería decir.»
La especificación no es el problema
La respuesta habitual es escribir una especificación mejor. Más detalle, más aprobaciones, más talleres. Rara vez funciona, porque el conocimiento que falta no es del tipo que sobrevive a que quien lo tiene lo escriba para quien no lo tiene.
Pruébelo usted mismo. Escriba la regla de qué facturas de proveedores necesitan una orden de compra y cuáles no. Le saldrán tres líneas. Luego alguien preguntará por los suministros, el seguro anual, el abogado que factura por número de expediente en lugar de por orden de compra y el único proveedor que envía un extracto en vez de una factura porque lo hace así desde 2011. Sus tres líneas se convierten en dos páginas, y siguen incompletas, porque la regla real vive en un juicio que la controller aplica sin darse cuenta de que lo aplica.
Ese juicio es la parte valiosa. También es la parte que una especificación no puede transportar.
Lo que de verdad se transmite
Tres cosas transmiten ese conocimiento de forma fiable, y ninguna es un documento.
Observar el trabajo. Siéntese una mañana junto a la persona que lo hace. No un taller — el trabajo real, con las excepciones reales. Cada vez que dude, pregunte por qué. Las dudas son las reglas.
Partir del historial y no de la intención. No pregunte cómo deberían codificarse las facturas. Mire cómo se codificaron las doce últimas de ese proveedor. El libro mayor es un registro de la regla mucho más honesto que la descripción que haga cualquiera, incluida la controller.
Ejecutar en paralelo antes de que nada tenga autoridad. Deje que la automatización haga el trabajo junto al equipo, con datos reales, sin contabilizar nada. Cada diferencia entre su resultado y el del equipo es una regla que entendió mal, descubierta mientras todavía es barata. Es lo más valioso que puede hacer, y la mayoría de los proyectos se lo saltan porque parece hacer el trabajo dos veces. Es hacer el trabajo dos veces. De eso se trata.
La solución estructural
Las tres cosas son más fáciles cuando la persona que escribe la automatización sabe leer un balance de comprobación. No porque los Chartered Accountants sean mejores desarrolladores — por lo general no lo son —, sino porque el paso de traducción desaparece. No hay documento de traspaso porque no hay traspaso.
No es afirmar que todo equipo de automatización necesita un Chartered Accountant. Es una afirmación sobre dónde poner la junta. Si tiene que haber dos personas, ponga la junta donde equivocarse cueste poco — en la capa de integración, por ejemplo, no entre «para qué sirve el control» y «qué hace el código».
Ponga la junta en el lugar equivocado y tendrá la demo, la frase y las seis semanas.