Presupuestador

Un presupuesto que dependía de una sola cabeza, convertido en un criterio que se puede escribir, discutir y mejorar.

Presupuestador es un sistema de apoyo a la decisión para un taller de fabricación metálica en Montevideo. El objetivo no fue construir una app de presupuestos genérica, sino hacer explícito el criterio de precios que hasta ahora vivía en la cabeza de una sola persona y ponerlo a disposición del resto del equipo sin perder el juicio experto que lo sostiene.

1. Diagnóstico operativo
2. Criterios documentados
3. MVP en Google Sheets
4. Calibración contra el presupuestador
5. V1 usable
6. Adopción en todo el equipo

Dónde está hoy el proyecto: V1 usable está construida y responde presupuestos reales; el paso siguiente, que todo el equipo presupueste de forma independiente, es el objetivo, todavía no un resultado medido (más en Resultados y Limitaciones, más abajo).

Un taller que presupuesta bien, pero despacio y desde la cabeza de una sola persona.

Guzmán Villalba es un taller de fabricación metálica en Montevideo. Cada trabajo, desde una baranda a medida hasta una tanda completa de piezas, arranca con un presupuesto. Durante años, ese presupuesto salió del criterio de un solo presupuestador: material, mano de obra, tiempo de máquina y margen, calculados desde la memoria y la experiencia, no desde un sistema escrito.

Eso funcionó mientras el volumen fue manejable. Pero los pedidos empezaron a hacer cola detrás de una sola persona. Alguien nuevo en el equipo no podía presupuestar sin acompañar el proceso durante meses. Y como el criterio vivía solo en su cabeza, no se podía cuestionar, versionar ni mejorar; solo se podía repetir.

Un presupuesto lento puede perder el trabajo antes de cortar el primer caño.

Un cliente que llama pidiendo un número aproximado necesita una respuesta rápida y defendible. Si la única vía es un presupuesto formal completo, y ese presupuesto depende de que una persona puntual tenga tiempo libre esa semana, la respuesta llega tarde, o no llega.

• El criterio de precios no estaba escrito en ningún lado: vivía en la experiencia de una persona.
• No había una forma rápida de dar un rango orientativo sin armar el presupuesto completo.
• Sumar gente al equipo de presupuestos significaba, en la práctica, que esa persona los acompañara caso por caso.

La precisión y el impacto todavía se describen de forma cualitativa. No se publican cifras hasta contar con una muestra suficiente y verificable.

Mirar cómo se arma un presupuesto, no solo preguntar cómo se arma.

Un solo modelo de precios, varias superficies.

La hipótesis de partida: si el criterio del presupuestador se podía volver explícito, no hacía falta reemplazar su juicio. Hacía falta darle una forma que otra persona pudiera usar, cuestionar y mejorar. En vez de construir una aplicación única desde el principio, el sistema separa la lógica de precios (versionada, inspeccionable, propiedad del taller) de las superficies que la consultan, así el presupuestador podía seguir trabajando desde el primer día, y la interfaz podía evolucionar sin tocar la lógica de fondo.

Las mismas variables que aparecieron en el descubrimiento, material y espesor, complejidad de corte, terminaciones y tiempo de máquina definen costo y mano de obra; la relación con el cliente y la urgencia ajustan desde ahí.

Estos tres números describen decisiones de diseño del sistema (cuántos modelos, cuántas superficies, cuántos tipos de salida), no métricas de negocio del taller.

Publicar la lógica antes que la interfaz.

La primera versión del modelo de precios vivió enteramente en Google Sheets con Apps Script, a propósito, para que el presupuestador pudiera corregir y extender el criterio él mismo, sin depender de un ciclo de desarrollo, y para poder validar el sistema contra presupuestos reales antes de construir cualquier interfaz.

Cada presupuesto que pasaba por la planilla quedaba registrado. Esa base de presupuestos, no un número de negocio, sino el propio material de trabajo del sistema, es lo que después permitió comparar el modelo contra el criterio del presupuestador y ajustar la ponderación antes de pasar a una interfaz dedicada.

El presupuestador como referencia, no como usuario de prueba.

La validación no fue una tanda de usability testing con usuarios externos; consistió en comparar, presupuesto por presupuesto, lo que proponía el modelo contra lo que decía el propio presupuestador. Cuando coincidían, eso confirmaba una regla. Cuando no coincidían, esa diferencia era la señal para revisar el modelo, no para descartar el desacuerdo.

1. Correr un presupuesto real por el modelo
   Mismo caso, dos criterios: el del modelo y el del presupuestador, uno al lado del otro.
2. Marcar coincidencias y desvíos
   Los desvíos no se promediaban ni se ignoraban; cada uno se revisaba para entender qué variable faltaba o estaba mal ponderada.
3. Ajustar el modelo, no el criterio
   El objetivo era que el modelo aprendiera a explicar el criterio del presupuestador, no al revés.

La precisión y el impacto todavía se describen de forma cualitativa. No se publican cifras hasta contar con una muestra suficiente y verificable.

De una planilla difícil de transferir a una herramienta guiada, trazable y configurable.

1. Entrada guiada por familia y subcategoría
   El flujo organiza producto, dimensiones, opciones constructivas, terminación y colocación. Cada familia habilita las variables que corresponden.
2. Resultado en vivo y criterio visible
   La V1 muestra precio recomendado, rango, referencia histórica, jornales orientativos y revisión técnica. También permite definir un precio elegido sin ocultar el cálculo original.
3. Operación y calibración en un mismo sistema
   Historial, catálogos, parámetros y QA permiten revisar la lógica y ajustar el motor sin convertir la calculadora en una caja negra.

Prueba de la V1 con una escalera en L: el sistema adaptó las medidas a dos avances, incorporó descanso y baranda, y devolvió rango, jornales y revisión de inclinación. Los valores son demostrativos; la calibración exacta sigue en curso.

La IA aceleró la construcción del producto, no reemplaza el criterio del taller.

La IA se utilizó como apoyo para ordenar requisitos, explorar flujos, revisar consistencia y acelerar iteraciones de diseño y desarrollo. En la V1 observable, el precio surge del motor de reglas y parámetros del sistema, con revisión humana y posibilidad de ajuste.

Una V1 usable, todavía en calibración.

El producto ya permite recorrer un presupuesto completo y obtener una salida consistente. Todavía no corresponde presentarlo como un sistema cerrado ni como un resultado de negocio validado.

Lo que la V1 todavía no resuelve.

• Los valores requieren calibración exacta antes de usarse como referencia definitiva.
• Los trabajos atípicos siguen necesitando revisión directa del presupuestador.
• La persistencia actual no sustituye una base de datos online preparada para operación multiusuario.
• Todavía no hay autenticación, roles ni evidencia suficiente de uso independiente por parte del equipo.

Lo difícil nunca fue la pantalla.

El trabajo de diseño real fue volver explícito un criterio que una persona nunca había tenido que poner en palabras, hacerlo lo bastante claro como para escribirlo, discutirlo y corregirlo. La aplicación fue, en comparación, el paso más simple una vez que eso estaba resuelto.

También aprendí a desconfiar de la tentación de reemplazar el criterio experto por una fórmula prolija: un modelo que ignora las condiciones reales del taller, la relación con el cliente, la urgencia, la disponibilidad de máquina esa semana, hubiera sido más simple de construir, y peor. El sistema tenía que aprender del presupuestador, no corregirlo desde afuera.

Cerrar la V1 antes de ampliar el alcance.