El Costeo de Obra Empieza en el Código de Costo

El costeo de obra falla mucho antes de que corra el primer reporte. Un costo queda imputado a una pieza de obra en el momento en que se incurre — una orden de compra emitida, material retirado de almacén, horas firmadas en un parte — y quien hace la imputación tiene unos segundos y una lista desplegable. Si la estructura detrás de esa lista no coincide con cómo está organizada realmente la obra, la imputación se vuelve una suposición, y ningún reporte construido sobre suposiciones se puede corregir después. La estructura de códigos de costo es la que decide si ese momento sale bien.

Resumen rápido

• El costeo de obra es un problema de imputación. El reporte es una agregación; la exactitud se define en el punto de captura.
• La estructura de códigos de costo es el esquema del sistema. Define la pregunta más fina que cualquier reporte futuro va a poder responder.
• Los contratistas necesitan dos desgloses: contra el que facturan y contra el que ejecutan. Rara vez tienen la misma forma.
• Los cuatro flujos de costo — mano de obra, material, equipo, subcontrato — entran por eventos distintos, y cada uno necesita su propia ruta de captura.
• El software contable general se organiza por período y cuenta. El costeo de obra se organiza por obra, y por eso la dimensión de proyecto hay que diseñarla desde adentro.

Este es el problema de control que viene inmediatamente después del descrito en qué construyen las empresas de construcción cuando su plataforma se queda corta: el presupuesto existe, la obra arrancó, y la pregunta ya no es cuánto debería costar sino a dónde se está yendo la plata.

¿Qué Exige Realmente el Costeo de Obra?

Cuatro flujos de costo, cada uno entrando al sistema por un evento distinto.

La mano de obra llega por captura de tiempo. Alguien registra horas contra un código, normalmente al final del turno, normalmente en un celular, muchas veces por cuadrilla y no por persona. La calidad de la imputación depende por completo de qué tan rápida y qué tan obvia sea esa interacción.

El material llega dos veces: una cuando se compromete en una orden de compra, y otra cuando se consume. Son fechas distintas y montos distintos, y un sistema que solo registra la segunda está ciego al costo comprometido — la plata ya se gastó y el reporte todavía no lo sabe.

El equipo llega como tiempo asignado y no como factura. Una máquina en obra le cuesta al proyecto haya trabajado ese día o no, y la regla de asignación es una decisión de la empresa que tiene que quedar codificada en algún lado explícito.

El subcontrato llega como avance contra un compromiso. El desglose propio del subcontratista casi nunca coincide con el del contratista general, así que este flujo carga un paso de traducción que a nadie le gusta mantener.

Cada uno de esos cuatro es una ruta de captura diferente, y tratarlos como uno solo — “los costos entran al sistema” — es el error de diseño que produce un módulo de costeo que técnicamente funciona y operativamente no.

¿Por Qué la Estructura de Códigos Decide lo que Usted Puede Aprender?

Porque un reporte solo puede agregar; nunca puede subdividir.

Si la mano de obra se captura contra un solo código para instalación eléctrica en todo un piso, entonces la pregunta “cuál de estas tres líneas de apartamentos se está comiendo las horas” no tiene respuesta, ni hoy ni nunca. El dato para responderla nunca se creó. Agregar un reporte no ayuda. Agregar la distinción a la estructura sí ayuda, pero solo para la obra registrada después del cambio, lo que significa que la comparación contra el trimestre pasado se perdió.

Esto es lo que hace que la estructura sea una decisión de modelo de datos y no una configuración. La mayoría de los contratistas la anclan a un marco publicado — el sistema de divisiones CSI MasterFormat es el punto de partida común en Estados Unidos — y después la extienden con códigos propios que reflejan cómo organizan cuadrillas y facturan obra de verdad. El marco le da un vocabulario compartido con arquitectos y clientes. Las extensiones son donde vive la información de gestión que sí sirve.

El trade-off es real en las dos direcciones:

• Muy pocos códigos y los reportes son ciertos pero inútiles. Todo entra en presupuesto o cerca, porque los cajones son lo bastante anchos para absorber la desviación.
• Demasiados códigos y el campo deja de cooperar. Un maestro eligiendo entre doscientas opciones al final del turno escoge la que está más arriba, y ahora el dato engaña activamente en vez de ser simplemente grueso.

La resolución práctica no es un número de códigos. Es decidir sobre cuáles distinciones el negocio va a actuar de verdad, y negarse a codificar el resto. Un código que nunca ha cambiado una decisión es un impuesto para todos los que tienen que seleccionarlo.

¿Qué Pasa Cuando Facturación y Ejecución Usan Desgloses Distintos?

Siempre los usan, y fingir lo contrario es la forma más común en que el costeo de obra deja de funcionar sin que nadie se dé cuenta.

El desglose de facturación es el schedule of values, un documento contractual que, según el American Institute of Architects, asigna la totalidad del valor del contrato a las distintas porciones de la obra del contratista y sirve de base para revisar las actas de pago mensuales. Se negocia con el cliente, es deliberadamente grueso, y muchas veces está moldeado por consideraciones de flujo de caja que no tienen nada que ver con cómo se ejecuta la obra.

El desglose de ejecución existe por la razón opuesta. Tiene que ser lo bastante fino para decirle a un director de obra qué frente, qué cuadrilla y qué material está perdiendo plata mientras todavía hay tiempo de actuar. Su granularidad natural es uno o dos órdenes de magnitud más fina que la del schedule of values.

Los dos son necesarios. La pregunta de diseño es cómo se relacionan, y solo hay tres respuestas: usar una sola estructura y perder aquello para lo que servía la otra, mantener ambas por separado y dejar que se desalineen, o mantener un mapeo explícito entre ellas. La tercera es más trabajo al principio y la única que sobrevive a un segundo proyecto.

¿Dónde Entran Realmente los Costos al Sistema?

En el compromiso, no en la factura — y esa distinción es casi todo el valor.

Una orden de compra emitida hoy por ducto que llega en tres semanas y se factura en seis es plata gastada hoy. Un sistema de costeo que la registra cuando se contabiliza la factura está reportando un pasado que el proyecto ya dejó atrás. Lo mismo aplica a un subcontrato adjudicado, un alquiler reservado, una cuadrilla programada para el mes entrante.

CodeBranch construyó esta lógica en una plataforma de control presupuestal para una empresa de construcción eléctrica de 201 empleados, donde el presupuesto carga techos explícitos de consumo de material — el proyecto puede consumir como máximo cierta cantidad de un material dado — y cada orden de compra y cada salida de almacén se valida contra ese techo en el momento. La mano de obra se modela por nivel de destreza, con su propia bolsa planeada, de modo que un mes con más personal del previsto se ve en el mes en que se asigna y no en la nómina que viene después.

Ese diseño tiene una propiedad que vale la pena nombrar: el control ocurre en el momento de la transacción, que es el único momento en que alguien todavía puede decidir no hacerla. Un reporte de desviación entregado después informa; un techo validado en la orden de compra previene. El segundo es más difícil de construir y es la razón por la que el sistema cambió cómo operaba esa empresa y no solo cómo reportaba.

El lado de la captura en campo es donde se ganan o se pierden la mayoría de las implementaciones, y el modo de falla es el reingreso manual. Pasar un costo de un sistema a otro a mano no es solo un costo de personal; es donde se degrada la imputación, porque quien hace el reingreso no estaba ahí cuando el costo se incurrió y está reconstruyendo la intención a partir de un documento. Cada salto entre sistemas es una oportunidad de que un costo caiga en el cajón equivocado, y la persona que podría haberlo detectado ya no está en el circuito.

¿Por Qué Contabilidad Es el Lugar Equivocado para Correr el Costeo de Obra?

Porque el libro mayor está organizado por período y por cuenta, y el costeo de obra está organizado por obra.

La contabilidad responde una pregunta que se hace mensualmente gente de afuera de la empresa: cuánto ganó y cuánto gastó esta entidad en este período. El costeo de obra responde una pregunta que se hace continuamente gente de adentro: esta pieza de obra está costando lo que dijimos que iba a costar. Las dos necesitan las mismas transacciones de base y casi nada más en común — distinta granularidad, distinto momento, distinta definición de cuándo existe un costo.

La mayoría de los productos contables generales pueden cargar una dimensión de proyecto, y para un contratista con un puñado de obras simultáneas eso suele alcanzar. Deja de alcanzar en el punto en que la dimensión de proyecto necesita estructura propia: un desglose de obra, comprometido contra real, cantidades además de pesos, y un mapeo a un cronograma de facturación del que el libro mayor no sabe nada.

CodeBranch desarrolló software de contabilidad y facturación a medida para una empresa de construcción en una relación de dos años por una razón emparentada: la facturación por proyecto y los reportes financieros específicos de construcción no estaban disponibles en las herramientas de mercado que esa empresa había evaluado. La dimensión de proyecto tenía que ser parte del modelo de datos y no un campo añadido.

La secuencia práctica se desprende de esto. El costeo de obra pertenece donde se registra la obra, y el sistema contable recibe el resultado. Construirlo al revés — hacer del libro mayor la fuente de verdad del proyecto — es lo que produce un reporte de costos conciliado, autoritativo y con treinta días de atraso.

¿Dónde Se Acaba Este Argumento?

En dos lugares, y vale la pena decir los dos sin rodeos.

Se acaba en la escala. Un contratista con tres obras y ocho personas no necesita una estructura de códigos de costo; necesita una hoja de cálculo y alguien que conozca cada obra. El problema de imputación descrito acá aparece cuando ninguna persona sola puede sostener el proyecto en la cabeza, que es función del número de obras simultáneas y del tamaño de las cuadrillas, no de la ambición.

Se acaba en el presupuesto. El costeo de obra compara real contra presupuestado. Si el presupuesto estaba mal, un costeo excelente le dice exactamente qué tan mal, en detalle, cada semana, y no cambia nada del resultado. El presupuesto tiene que estar construido sobre una estructura contra la cual se pueda comparar — que es el tema de análisis de precios unitarios y los límites del presupuesto genérico — antes de que el control de costos tenga algo que controlar.

Esas dos advertencias son también la prueba de si esto es un proyecto de software del todo. Cuando las obras son lo bastante numerosas como para que la imputación tenga que ser sistemática, y los presupuestos lo bastante estructurados como para ser comparables, la brecha entre lo que un contratista puede ver y lo que necesita ver suele ser un problema de modelo de datos. Esa es la clase de brecha que CodeBranch dimensiona como software para empresas de construcción, empezando por la estructura de códigos de costo, porque cada reporte que viene después es una agregación sobre ella.