Operamos con la misma arquitectura que vendemos
Enunciado de forma cualitativa. No hicimos un estudio medido de antes y después, así que no se afirma ningún porcentaje.
Contexto
La operación comercial y de entrega de BoRo: leads entrantes, definición de alcance, propuestas, proyectos, comunicación con clientes, facturación y contabilidad. La misma clase de problema que trabajamos con clientes, a nuestra escala.
Restricción operacional
El estado comercial, el de entrega y el contable vivían en lugares distintos. Decidir si un proyecto estaba económicamente sano implicaba que una persona reconciliara tres fuentes a mano, que es el patrón de middleware humano aplicado a nosotros mismos.
Arquitectura
- Límites explícitos de sistema de registro: el ERP es dueño de los hechos contables, la plataforma del estado comercial y de entrega, y ninguno vuelve a enunciar lo del otro.
- Estados de ciclo de vida para un scope, desde la entrada hasta la aprobación, la entrega y el cierre, con las condiciones necesarias para salir de cada uno.
- Un snapshot comercial aprobado e inmutable, para que la economía acordada de un proyecto no se pueda editar después.
- Un modelo de lectura que compara esperado contra real leyendo contabilidad y partes de horas en vivo, en lugar de mantener un segundo libro.
Implementación
- Portal de clientes y panel interno sobre una sola aplicación Next.js, separados por host.
- Entrada de leads idempotente con outbox de eventos y manejo de dead-letter, para que una falla aguas abajo no pueda perder un lead en silencio.
- La contabilidad corre sobre Odoo con guardas de servidor que exigen atribución de proyecto sobre el ingreso al momento de publicar, igual desde la UI, por RPC o por API.
- Identidad analítica por proyecto, para poder atribuir costo, ingreso y horas sin reconciliación manual.
Resultado observado
- El estado comercial y el de entrega tienen un dueño cada uno, y la frontera contable es explícita en vez de supuesta.
- La economía aprobada de un proyecto es inmutable del lado del servidor: una vez aprobada, las cifras no se pueden cambiar sin un change request aprobado que cree una versión nueva.
- Lo esperado contra lo real se deriva de la contabilidad publicada y los partes de horas a demanda, así que no hay un segundo juego de números que reconciliar.
- La atribución de proyecto sobre el ingreso la exige el sistema, no la memoria de una persona.
Enunciado de forma cualitativa. No hicimos un estudio medido de antes y después, así que no se afirma ningún porcentaje.