El Control Presupuestal en Tiempo Real Es un Problema de Latencia

Todo reporte de presupuesto de obra está desactualizado. La única pregunta es por cuánto. Un costo existe en el momento en que se adquiere un compromiso, y aparece en un reporte cierto número de días después; todo lo que pasa entre esos dos momentos es latencia, y la latencia está hecha de demoras específicas y nombrables, no de lentitud organizacional en general. “Tiempo real” como promesa de producto no es interesante. El rezago, medido contra la ventana en la que alguien todavía podía actuar, sí.

Resumen rápido

• La utilidad de un reporte de costos la define la brecha entre cuándo existe un costo y cuándo se ve, no cada cuánto se refresca la pantalla.
• La mayor fuente individual de rezago es registrar los costos en la factura y no en el compromiso. Cerrarla no exige ninguna disciplina nueva en campo.
• Decisiones distintas tienen ventanas distintas. Un sistema solo necesita ser más rápido que la ventana de la decisión que soporta.
• La captura en campo es donde fracasan la mayoría de las implementaciones, y la solución es derivar las entradas en vez de pedirlas.
• Actualidad sin trazabilidad no cambia nada: un número que no se puede rastrear hasta sus transacciones se discute en vez de accionarse.

Esta es la mitad operativa del problema descrito en qué construyen las empresas de construcción cuando su plataforma se queda corta. El presupuesto existe y los códigos de costo existen; lo que falta es la velocidad a la que la realidad llega a quienes todavía pueden cambiarla.

¿De Dónde Sale Realmente el Rezago?

Seis pasos, cada uno con su propia demora, y se suman en vez de solaparse.

1. El costo se incurre. Se emite una orden de compra, se programa una cuadrilla, se reserva una máquina.
2. El costo se captura. Alguien lo registra en un sistema. Para una orden de compra esto puede ser inmediato; para el consumo de material en obra depende de si alguien lo pregunta.
3. El costo se aprueba. Un paso de flujo, muchas veces el más largo y el menos visible, y con frecuencia esperando a una sola persona.
4. El costo se valoriza. El monto comprometido se conoce desde el paso uno; el monto real a veces no se conoce hasta que el proveedor factura.
5. El costo se contabiliza. Llega al sistema de registro, muchas veces en lote o con cadencia de período.
6. El costo se lee. Alguien abre el reporte, lo que ocurre con el ritmo que tenga la organización, y ese ritmo suele ser el mensual que impone la facturación.

Ese último punto merece nombrarse, porque es estructural y no accidental. La cadencia contractual de un proyecto de construcción es mensual: el cliente revisa las actas de pago contra el schedule of values una vez al mes, y ese es el ritmo alrededor del cual todo el mundo en la obra ya está organizado. La reportería de costos lo hereda por defecto, aunque nada de las decisiones que realmente toma un director de obra sea mensual.

El ejercicio útil no es comprimir los seis pasos. Es encontrar cuál paso individual se queda con la mayor parte de la demora, y en la mayoría de los contratistas es el paso cuatro.

¿Qué Tiene que Significar “Tiempo Real” para Ser Útil?

Más rápido que la decisión que informa, y no más.

Lea la columna de la derecha y el brief de diseño se escribe solo. Ninguna de esas filas exige un flujo en vivo. Dos de ellas exigen que un costo se vea dentro del día siguiente a haberse comprometido, cosa que ningún sistema puede hacer si espera una factura.

Este replanteamiento también mata una categoría de trabajo costoso. Los tableros de respuesta sub-segundo, los pipelines de streaming y la agregación en vivo son ingeniería genuinamente difícil, y para un proyecto cuya decisión accionable más rápida tiene una ventana de tres días, no compran nada. CodeBranch dimensiona esto durante la fase de Product Definition preguntando qué decisión soporta cada número, porque la respuesta normalmente hace la arquitectura más simple y no más elaborada.

¿Por Qué el Costo Comprometido Cierra Casi Toda la Brecha?

Porque mueve el momento de registro del final del ciclo al principio, y lo hace sin pedirle a nadie que cambie su forma de trabajar.

Una orden de compra ya es un documento que alguien crea deliberadamente, en una oficina, frente a un computador. Capturarla en ese momento no cuesta nada operativamente y elimina semanas de rezago. Lo mismo vale para un subcontrato adjudicado, un alquiler reservado, una cuadrilla programada para el mes entrante. Todas son decisiones que se toman en un escritorio, y un escritorio es donde la captura sale barata.

CodeBranch construyó esto en una plataforma de control presupuestal para una empresa de construcción eléctrica de 201 empleados, donde el presupuesto del proyecto carga techos de consumo de material — un tope explícito de cuánto de cada material puede consumir el proyecto — y cada orden de compra y cada salida de almacén se valida contra ese techo al registrarse. La mano de obra se planea mes a mes por nivel de destreza contra la bolsa que permite el presupuesto, de modo que un mes con exceso de personal se ve mientras se está asignando.

La diferencia entre eso y un reporte de desviación es la diferencia entre un control y una medición. Un reporte le dice que el cable se acabó. Un techo validado en la orden de compra se lo dice antes de que se coloque la orden, que es el único momento en el que la información podía haber cambiado algo. La imputación tiene que estar en pie para que cualquiera de los dos funcione, y por eso la estructura de códigos de costo va primero.

¿Qué Se Rompe Cuando el Cuello de Botella Es el Campo?

El consumo, y solo el consumo — pero es la mitad que más pesa en la exactitud.

Los compromisos se pueden capturar en un escritorio. Lo que realmente se instaló, realmente se consumió y realmente se desperdició solo se puede capturar donde ocurrió la obra, por gente cuyo oficio es la obra. Todo sistema que además les pide ser digitadores se degrada al contacto con un frente de trabajo.

Dos respuestas de diseño aguantan:

• Derivar en vez de preguntar. Si el modelo sabe que una unidad de obra consume 1.05 unidades de material, el campo solo tiene que reportar unidades de obra terminadas, no material consumido. El segundo número se desprende del primero y es más confiable que el que alguien habría estimado.
• Hacer la captura un subproducto. El dato debería caer de algo que la persona ya estaba haciendo — cerrar una orden de trabajo, dar por recibido un frente, pedir una salida de almacén — en vez de ser una tarea aparte que compite con su trabajo real.

CodeBranch aplicó el principio de derivación en una app móvil de presupuesto para un cliente de construcción que produce un presupuesto completo a partir de cinco a diez preguntas. Las preguntas cubren solo lo que un no experto puede observar; los rendimientos, las composiciones de cuadrilla y el consumo de material se aplican por debajo. El modelo no está simplificado para el celular, está menos expuesto.

La restricción detrás de todo esto es la rotación y el tiempo de entrenamiento, que es el tema de diseñar software de construcción para una rotación de 90 días en campo. Una interfaz de captura que exige un usuario entrenado es una interfaz que funciona el primer trimestre y después deja de funcionar.

¿Por Qué Nadie Le Cree al Tablero?

Porque estar actualizado no es lo mismo que ser creíble, y la industria tiene evidencia sobre esto.

En el estudio de 2020 de Autodesk y FMI sobre datos en construcción, solo el 12% de los encuestados dijo que siempre incorpora los datos del proyecto en su toma de decisiones, y el 30% reportó que más de la mitad de sus datos de proyecto son problemáticos — produciendo malas decisiones más de la mitad de las veces. Un camino más rápido hacia un número que nadie acciona no es una mejora.

Lo que convierte un número en una decisión es la trazabilidad. Un director de obra mirando un sobrecosto del 9% en un paquete de obra tiene que poder abrirlo y ver las órdenes de compra, las salidas de almacén y las horas que produjeron la cifra. Sin eso, la primera reacción ante cualquier número incómodo es ponerlo en duda, y la duda es legítima, porque el número no es verificable.

Esto tiene consecuencias arquitectónicas concretas:

• Los agregados se calculan a partir de transacciones que siguen siendo direccionables una por una, no de resúmenes precalculados.
• Cada cifra carga su fecha de corte, de modo que un número viejo se ve viejo en vez de estar silenciosamente equivocado.
• Las correcciones se registran como asientos nuevos en vez de sobrescribir la historia, de modo que un número que cambió se puede explicar.

Nada de eso es exótico. Es una decisión que se toma temprano, y es difícil de agregar después a un sistema que se construyó para pintar un tablero.

¿Dónde Deja de Ayudar Reportar Más Rápido?

En el punto en que la restricción es el tiempo de respuesta de la organización y no su información.

Un reporte de costos semanal que se lee y se acciona le gana a un tablero en vivo que nadie es dueño. Si la desviación le llega al director de obra el lunes y la decisión necesita tres aprobaciones que toman hasta el viernes siguiente, bajar el rezago de reportería de cinco días a cinco minutos no cambia nada medible. La cadena de latencia incluye los pasos humanos, y esos suelen ser los eslabones más largos.

También vale la pena ser honestos sobre el techo de este tipo de trabajo. El análisis de McKinsey de 2017 sobre productividad en construcción encontró que el crecimiento global de la productividad laboral en el sector promedió 1% anual durante dos décadas, contra 2.8% de la economía mundial y 3.6% de manufactura. La visibilidad de costos es un insumo de esa brecha, no la explicación. Un contratista que hace seguimiento de costos casi en tiempo real y sigue construyendo como hace diez años mejoró su reportería, no su productividad.

Lo que el control de costos sí compra es específico y vale la inversión por sí solo: poder saber, durante la ejecución, cuáles proyectos están perdiendo plata y por qué, mientras todavía hay proyecto que proteger. Construir eso normalmente se reduce a dos decisiones — cuándo entra un costo al sistema, y quién tiene que digitar para que llegue. Esas son las preguntas con las que arranca CodeBranch cuando dimensiona software para empresas de construcción, porque el resto de la arquitectura se desprende de las respuestas.