Skip to content
Construction

Análisis de Precios Unitarios y los Límites del Presupuesto Genérico

CT

CodeBranch Team

Unit Price Analysis and the Limits of Generic Estimating

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éricaAnálisis de precios unitarios
GuardaEl precio de una unidad de obraLos componentes y rendimientos que lo producen
Cuando cambia el precio de un materialActualizar cada línea afectadaRecalcula en todo donde se consume
Mano de obraUn costo por hora o por unidadComposición de cuadrilla y rendimiento por turno
Conocimiento de la empresaNo queda representadoLos rendimientos son el conocimiento
Volver a costear un proyectoPasada manualRecálculo
Alimenta comprasNo — las cantidades se derivan aparteSí — 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?
Es la práctica de construir el precio de una unidad de obra — un metro cuadrado de muro, un metro lineal de ducto — a partir de sus componentes: los materiales que consume, las horas de cuadrilla que requiere, el tiempo de equipo y los costos indirectos que se le asignan. El resultado es un precio, pero el valor está en la descomposición, porque es lo que le permite volver a costear cuando cambia el precio de un material o la composición de una cuadrilla. CodeBranch construyó este motor para un contratista eléctrico, y modelar los rendimientos fue la parte que determinó si los números se sostenían.
¿Por qué una hoja de cálculo no puede hacer bien el análisis de precios unitarios?
Una hoja de cálculo lo puede hacer una vez, y muy bien. Lo que no puede es mantener las relaciones: cuando cambia el precio de un material, todo precio unitario que lo consume debería moverse, y toda cotización construida sobre esos precios unitarios debería reflejarlo. En una hoja de cálculo esas conexiones existen solo en la cabeza de quien armó el archivo. CodeBranch trata ese grafo de dependencias como el núcleo del sistema y no como una funcionalidad, porque es justamente lo que una hoja de cálculo no puede sostener por estructura.
¿Cuál es la diferencia entre una base de datos de costos y un motor de análisis de precios unitarios?
Una base de datos de costos guarda cuánto cuestan las cosas. Un motor de análisis de precios unitarios guarda cómo la obra las consume: los rendimientos. Medio día de una cuadrilla de dos personas por unidad, 1.05 unidades de material para cubrir el desperdicio, un tercio de un turno de equipo. Los rendimientos son la parte propia de cada empresa y la que carga la ventaja competitiva. CodeBranch construye alrededor de los rendimientos porque ahí es donde el presupuesto de un contratista se diferencia de un tarifario publicado.
¿Cómo se conecta el análisis de precios unitarios con compras y control presupuestal?
Por la misma descomposición. Si una línea de presupuesto sabe que necesita 1.05 unidades de un material, la requisición de compra se puede generar desde ahí, y el consumo real se puede comparar contra el rendimiento que se supuso. Sin la descomposición, una línea de presupuesto es un número y la comparación hay que reconstruirla a mano. CodeBranch construye esto como un solo modelo y no como tres sistemas, que es la razón por la que la cotización, las compras y el control presupuestal del cliente leen de la misma estructura.
¿Tenemos que rehacer nuestro proceso de presupuesto para usar esto?
Normalmente no rehacerlo: formalizarlo. La mayoría de los contratistas ya hace análisis de precios unitarios; vive en hojas de cálculo y en la cabeza de los presupuestadores con más experiencia. El trabajo es volver los rendimientos explícitos y consistentes al punto de poder guardarlos y reutilizarlos. CodeBranch levanta este tema durante la fase de Product Definition, porque una organización que no logra ponerse de acuerdo sobre sus propios rendimientos no está lista para un software que depende de ellos.
¿Cómo evaluamos a un socio para software de presupuesto a medida?
Pregúntele cómo modelaría un rendimiento que varía según la condición: la misma obra costando distinto en el tercer piso que a nivel de piso. Un socio que responde con una tabla de consulta no lo ha pensado; uno que pregunta qué genera esa variación en su negocio sí está entrando al problema real. CodeBranch arranca con una fase de Product Definition donde salen exactamente estas preguntas, porque las decisiones de modelo de datos que se toman en la primera semana determinan qué puede representar el sistema durante toda su vida.
construction estimating unit price analysis custom software

Artículos Relacionados