Análisis de Precios Unitarios y los Límites del Presupuesto Genérico
CodeBranch Team
Un precio unitario no es un precio. Es el resultado de un cálculo, y el cálculo es el activo. Un metro cuadrado de formaleta es cierta cantidad de material, cierta fracción de un día de cuadrilla, cierta porción de tiempo de equipo y cierta asignación de costo indirecto — y cuando se mueve el precio de la madera, todo precio unitario que consume madera debería moverse con él. Las herramientas genéricas de presupuesto guardan el resultado. El análisis de precios unitarios guarda la estructura que lo produjo.
Resumen rápido
- Un precio unitario se descompone en materiales, mano de obra, equipos e indirectos, cada uno con un rendimiento: cuánto consume de él una unidad de obra.
- Los rendimientos son la parte propia de cada empresa. Son lo que hace que el presupuesto de un contratista sea distinto al de un tarifario publicado, y casi nunca están escritos en ninguna parte.
- Una hoja de cálculo puede calcular bien un precio unitario, pero no puede mantener las dependencias, y por eso volver a costear un proyecto es un ejercicio manual.
- La misma descomposición que produce una cotización puede manejar compras y control presupuestal, si se guarda como un modelo en vez de recalcularse en cada sistema.
- El 62% de las empresas todavía presupuesta en hojas de cálculo, lo que es menos una falla de adopción tecnológica que una señal de que las herramientas disponibles no modelan rendimientos.
Este es uno de los casos más claros del patrón descrito en qué construyen las empresas de construcción cuando su plataforma se queda corta: el proceso es específico de cómo la empresa gana dinero, y la plataforma modela una versión más simple de él.
¿Qué Contiene Realmente un Precio Unitario?
Cuatro componentes, y el cuarto es el que se pierde.
Materiales directos, con un factor de consumo y no con una cantidad. Un metro cuadrado de muro no consume un metro cuadrado de material; consume cierta cantidad más el desperdicio, y el factor de desperdicio es en sí mismo un juicio de la empresa basado en la destreza de la cuadrilla y las condiciones del sitio.
Asignaciones de mano de obra, expresadas como composición de cuadrilla y rendimiento. No “dos horas de mano de obra” sino “una cuadrilla de un oficial y un ayudante, con un rendimiento de X unidades por turno”. La distinción importa porque cuando las tarifas cambian por oficio, el precio unitario tiene que recalcularse por oficio.
Equipos y herramienta, asignados por tiempo y no como propiedad completa. Una bomba de concreto no la consume una unidad de obra: la consume una fracción de turno, y esa fracción depende de la secuencia de vaciado.
Transporte y logística, que es el componente que más se omite y el que pega en obras con acceso difícil. Material que hay que izar hasta el piso ocho cuesta más colocarlo que el mismo material a nivel de piso, y si el modelo no tiene dónde poner esa diferencia, el presupuestador la entierra en un factor de ajuste que después nadie puede auditar.
Vale la pena señalar qué cubren y qué no cubren los marcos estándar de la industria. El sistema CSI MasterFormat organiza especificaciones y códigos de costo en divisiones, lo que le da a todo el mundo un vocabulario común sobre qué obra es. No dice nada sobre qué consume una unidad de esa obra. La descomposición es la parte que cada contratista tiene que apropiarse.
CodeBranch construyó un motor de análisis de precios unitarios para un contratista eléctrico como parte de una plataforma de control presupuestal, y estructurar estos cuatro componentes — en vez de guardar un precio por ítem — es lo que permitió que el mismo modelo alimentara cotización, compras y seguimiento de presupuesto.
¿Por Qué Es Más Difícil Modelar un Rendimiento que un Precio?
Porque un precio es un número y un rendimiento es un juicio con condiciones encima.
El precio de un bulto de cemento es el precio de un bulto de cemento. Cuántos metros cuadrados de muro termina una cuadrilla en un turno depende del muro, la altura, el acceso, el clima, la cuadrilla y si lo están haciendo por primera vez en ese proyecto. Todo presupuestador con experiencia sabe esto y ajusta. Casi ningún sistema guarda el ajuste.
Hay una forma más afilada de poner la asimetría: los datos de precio se pueden comprar, los datos de rendimiento no. La Oficina de Estadísticas Laborales de Estados Unidos publica índices de precios al productor que cubren insumos de construcción, y las bases comerciales venden precios unitarios por región. Nadie publica cuántos metros cuadrados de muro terminan sus cuadrillas en un turno, porque ese número es suyo.
Este es el meollo de por qué las herramientas genéricas se quedan cortas. Están hechas para guardar precios, que son estables y externos, y tratan los rendimientos como un número único que se digita una vez. Los rendimientos reales de un contratista varían según la condición, y la variación no es ruido: es el conocimiento acumulado que hace que sus presupuestos sean mejores que los de un competidor.
La pregunta de diseño es cuánta de esa variación modelar de forma explícita. Muy poca y el sistema es un tarifario con pasos de más. Demasiada y nadie puede mantenerlo. El punto medio útil suele ser un rendimiento base con un número pequeño de modificadores nombrados que el presupuestador aplica conscientemente, de modo que el ajuste quede registrado en vez de absorbido.
| Tarifario / herramienta genérica | Análisis de precios unitarios | |
|---|---|---|
| Guarda | El precio de una unidad de obra | Los componentes y rendimientos que lo producen |
| Cuando cambia el precio de un material | Actualizar cada línea afectada | Recalcula en todo donde se consume |
| Mano de obra | Un costo por hora o por unidad | Composición de cuadrilla y rendimiento por turno |
| Conocimiento de la empresa | No queda representado | Los rendimientos son el conocimiento |
| Volver a costear un proyecto | Pasada manual | Recálculo |
| Alimenta compras | No — las cantidades se derivan aparte | Sí — el consumo ya está en el modelo |
¿Qué Gana con Esto Más Allá del Presupuesto?
La descomposición es reutilizable, y esa es la parte que justifica construirla.
Las compras salen del mismo modelo. Si una línea de presupuesto sabe que consume 1.05 unidades de un material por unidad de obra, la requisición se puede generar desde la cantidad de obra programada, en vez de reconstruirse con alguien leyendo los planos por segunda vez.
Los reales se comparan contra los supuestos. Cuando la obra está hecha, lo que realmente se consumió se puede poner contra el rendimiento que se supuso. Esa comparación es el ciclo de retroalimentación que mejora el siguiente presupuesto, y existe solo si el supuesto se guardó en una forma que sobrevive.
Los cambios de alcance se vuelven a costear en vez de volver a presupuestar. Un cambio de diseño que suma veinte metros cuadrados de un ensamble conocido es un cambio de cantidad contra un precio unitario existente, no un ejercicio nuevo de presupuesto.
Ninguna de esas tres está disponible si el precio unitario está guardado como un número. Las tres salen solas si está guardado como una estructura.
¿Por Qué el 62% de las Empresas Sigue Presupuestando en Hojas de Cálculo?
Porque la hoja de cálculo hace lo único que importa — modela el cálculo — y las alternativas muchas veces no.
En la última encuesta sistemática de tecnología en construcción, el 62% de las empresas dependía de hojas de cálculo para presupuestar. Eso normalmente se lee como una falla de adopción tecnológica. Es por lo menos en igual medida un veredicto sobre la tecnología: un presupuestador que puede expresar una relación de rendimiento en una hoja de cálculo y no puede expresarla en la plataforma de presupuesto está tomando una decisión racional.
Lo que la hoja de cálculo no puede hacer es sostener las relaciones en el tiempo. Las fórmulas están, pero el razonamiento detrás de ellas no, y cuando se va la persona que armó el archivo lo que queda es una calculadora que funciona y que nadie se atreve a modificar. La misma encuesta encontró que el 49% de las empresas mueve datos entre aplicaciones a mano, que es el síntoma aguas abajo: el presupuesto vive en un lado y todo lo que debería fluir desde él vive en otro.
Reemplazar las hojas de cálculo por algo peor es un error común y caro. Reemplazarlas por algo que modele las mismas relaciones y además las persista es el objetivo real.
¿Cómo Sobrevive el Modelo al Uso en Campo?
Exponiendo menos de lo que contiene.
La misma lógica de precio unitario que un presupuestador usa en la oficina tiene que producir un número cuando un comercial está parado frente a un cliente sin computador. CodeBranch construyó los dos extremos para el mismo contratista: una plataforma web de cotización con diseño de planta y detalle a nivel de componente, y una aplicación móvil que produce un presupuesto a partir de un formulario de cinco a diez preguntas.
La versión móvil no usa un modelo de precios simplificado. Usa el mismo modelo con la mayoría de las entradas derivadas en vez de preguntadas. Las preguntas cubren lo que un no experto puede observar — cuántas zonas de iluminación, cuántas cortinas motorizadas — y los rendimientos, cuadrillas y consumos de material se aplican por debajo.
Ese es el principio general y vale la pena decirlo sin rodeos: la complejidad va en el modelo, no en el formulario. Un sistema que exige un operador experto para producir un número correcto movió el conocimiento al operador, que es donde estaba antes de que existiera el software.
¿Qué Tiene que Ser Cierto Antes de Construir Esto?
La organización tiene que ponerse de acuerdo sobre sus propios rendimientos.
Esto suena administrativo y es la parte que descarrila estos proyectos. En la mayoría de los contratistas, los rendimientos están repartidos entre varios presupuestadores senior que no usan todos los mismos números y que tienen buenas razones para sus diferencias. Escribirlos en un sistema fuerza una decisión que antes era implícita, y esa decisión no es una decisión de software.
CodeBranch saca esto a la superficie durante el Product Definition en vez de descubrirlo en desarrollo, porque una empresa que no logra resolver sus rendimientos no está lista para un sistema cuyo valor entero descansa en ellos. A veces el resultado correcto es formalizar primero la práctica de presupuesto y construir el software después.
Cuando los rendimientos están resueltos, lo demás es manejable. Cuando no lo están, ninguna cantidad de software mejora el presupuesto: solo hace que el desacuerdo se produzca más rápido. Ese orden — resolver el modelo y después construir encima — es la forma en que CodeBranch estructura el software para empresas de construcción, y el presupuesto es el caso más claro de por qué el orden importa.
Preguntas Frecuentes
¿Qué es el análisis de precios unitarios en construcción?
¿Por qué una hoja de cálculo no puede hacer bien el análisis de precios unitarios?
¿Cuál es la diferencia entre una base de datos de costos y un motor de análisis de precios unitarios?
¿Cómo se conecta el análisis de precios unitarios con compras y control presupuestal?
¿Tenemos que rehacer nuestro proceso de presupuesto para usar esto?
¿Cómo evaluamos a un socio para software de presupuesto a medida?
Artículos Relacionados
El Costeo de Obra Empieza en el Código de Costo
El costeo de obra es un problema de imputación, no de reportería. La estructura de códigos de costo decide qué podrán decirle los reportes.
Cuándo NO Construir Software de Construcción a Medida
Todas las guías de construir o comprar en construcción las publica alguien que vende una plataforma. Este es el caso en contra de construir, de una empresa que construye.
Por Qué la IA en Construcción se Atasca en la Capa de Datos
El 87% de los contratistas espera que la IA transforme su negocio. El 26% califica bien la calidad de sus datos. La distancia entre esas cifras es todo el problema.