Presupuestador

Un presupuesto que dependía de una sola cabeza, convertido en un sistema que creció junto con el problema.

Restimator (nombre interno: Presupuestador) es un sistema de apoyo a la decisión para un taller de fabricación metálica en Montevideo. No nació como un producto. Surgió de un problema sistémico: presupuestar dependía por completo de una planilla armada a mano y del criterio de una sola persona. Ese problema era demasiado grande para atacarlo de una sola vez, así que se fue descomponiendo en soluciones más chicas y verificables. Entre ellas, un estimador rápido y, en paralelo, una base de materiales y precios que con el tiempo se convirtió en un sistema más completo. No fue un roadmap planeado de antemano, sino respuestas que fueron apareciendo a medida que el problema se entendía mejor. Este caso cuenta esa evolución completa, incluyendo lo que todavía está en desarrollo.

1. Diagnóstico y criterios documentados
2. MVP en Google Sheets
3. Restimator rápido V1
4. Presupuesto y producción V2
5. Cierre estimado vs. real

Dónde está hoy el proyecto: el estimador rápido V1 está implementado y en uso; la V2 (presupuesto completo, aprobaciones y producción) tiene partes implementadas en desarrollo activo y partes todavía en diseño. Ningún tramo de este caso presenta un prototipo como si ya estuviera funcionando (más en Validación y estado actual, 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 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 armarlo depende de la disponibilidad de una sola persona 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, acompañarlas caso por caso hasta que pudieran presupuestar solas.
• La información de cada pedido quedaba repartida entre planillas, carpetas físicas, WhatsApp y mail, sin un lugar único.

El número anterior no describe diez herramientas simultáneas: reúne superficies físicas, canales digitales, cálculos y conocimiento personal que podían intervenir según cada caso. Hoy Restimator ya centraliza la estimación rápida y concentra en V2, en desarrollo activo, solicitudes, clientes y proyectos, materiales y costos, presupuestos, estados, seguimiento y producción. Aprobaciones, documentación de taller, compras y cierre estimado contra real todavía no forman un circuito completo.

Antes de Restimator, cada presupuesto era un recorrido artesanal por varios sistemas desconectados.

Entender este flujo no salió solo de preguntarle al presupuestador cómo trabajaba. Al propio presupuestador le costaba poner en palabras sus reglas. Acompañar varios presupuestos reales de punta a punta fue lo que mostró el recorrido completo, y confirmó algo importante: el criterio no era arbitrario, era consistente pero no estaba documentado. Eso significaba que se podía capturar como un modelo explícito, en vez de reemplazarlo por una fórmula genérica que hubiera ignorado las condiciones reales del taller.

Ningún paso de este flujo estaba mal hecho: el taller presupuestaba bien. El problema era estructural: el conocimiento vivía en una sola cabeza, la información no quedaba centralizada, y cada ajuste se resolvía de nuevo en vez de convertirse en una regla reutilizable. Esos tres problemas (concentración de conocimiento, información dispersa y repetición de trabajo) son los que las distintas soluciones que fueron apareciendo después encararon, cada una desde un ángulo distinto.

Explorar el proceso original ↓

La estimación no vivía en una sola herramienta. La planilla concentraba reglas, materiales y cálculos, mientras Trello ayudaba a seguir presupuestos y trabajos como una pieza más de un ecosistema distribuido.

Del conocimiento tácito a una estructura visible

El relevamiento no se limitó al flujo de presupuestación. Empecé a mapear las familias de productos del taller, sus variantes, materiales y variables de complejidad para entender qué parte del criterio podía documentarse y reutilizarse.

El objetivo fue convertir el criterio del presupuestador en un modelo explícito, sin reemplazar su juicio.

La hipótesis de partida: capturar el criterio de precios como un modelo explícito, versionado e inspeccionable, y separarlo de las superficies que lo consultan. Así el presupuestador podía seguir trabajando desde el primer día sin cambiar su forma de operar, mientras el modelo se iba validando. La interfaz podía evolucionar después, sin tener que rehacer la lógica de precios cada vez.

Esta hipótesis no se tradujo en un plan de dos etapas prolijas decidido de antemano. El problema era demasiado grande para atacarlo de una sola vez, así que se fue descomponiendo en soluciones más chicas y verificables a medida que se entendía mejor. El estimador rápido fue una de esas soluciones, no la primera de dos fases planeadas desde el inicio.

Publicar la lógica antes que la interfaz.

La primera respuesta de producto no fue chica: fue atacar el problema completo: tener una base de materiales y precios propia, poder elegir desde un catálogo en vez de copiar y pegar cada vez, y que los precios se actualizaran solos en lugar de revisarse a mano. Esa dirección arrancó en Google Sheets con Apps Script, a propósito, para poder construir y corregir la lógica sin depender de un ciclo de desarrollo, y para validar el sistema contra presupuestos reales antes de construir cualquier interfaz dedicada.

Cada presupuesto que pasaba por la planilla quedaba registrado, y la propia planilla fue creciendo hacia una base de materiales y precios reutilizable. Ese fue el germen de lo que más adelante sería la biblioteca de productos tipo de la V2. 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, corrida tras corrida: mismo caso, dos criterios uno al lado del otro; los desvíos no se promediaban ni se ignoraban, se revisaban para entender qué variable faltaba o estaba mal ponderada. El objetivo siempre fue que el modelo aprendiera a explicar el criterio del presupuestador, no al revés.

Ver primeras iteraciones ↓

La primera iteración funcional tomó la forma de una planilla con automatizaciones en Apps Script. Fue un esqueleto útil para empezar a convertir criterios y antecedentes en una herramienta reutilizable, aunque todavía era lento, limitado y difícil de sostener como experiencia de producto.

Un problema específico, encontrado mientras se exploraba el problema grande.

Mientras la base de materiales y precios se seguía construyendo, apareció en paralelo un problema distinto: muchos pedidos no necesitaban todavía un presupuesto formal completo; alcanzaba con un rango rápido para decidir si valía la pena seguir. Restimator nació como una respuesta chica y específica a ese problema puntual, no como la segunda etapa de un plan de dos fases: clasificar el pedido, pedir lo mínimo indispensable y devolver un rango. La pregunta que resuelve no es «¿cuánto sale?» en detalle, sino «¿vale la pena seguir?».

Estas cifras no comparan tareas equivalentes. Restimator agrega una etapa temprana: primero devuelve un rango orientativo y recién después se decide si conviene invertir tiempo en el presupuesto formal. El tiempo del presupuesto formal varía según complejidad.

Restimator V1 arrancó como fórmulas dentro de esa misma planilla y de ahí pasó a una interfaz web propia. Se usó y se sigue usando como herramienta real, no como un piloto descartado. Su objetivo explícito era reducir trabajo innecesario antes del presupuesto formal, no reemplazarlo.

El mayor desafío fue explicitar el criterio.

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 ignorara la relación con el cliente, la urgencia o la disponibilidad de máquina habría sido más simple de construir, pero peor para el taller. El sistema tenía que aprender del presupuestador, no corregirlo desde afuera.

Las decisiones de usabilidad se probaron en el trabajo cotidiano, especialmente con Irene y otras personas del equipo. El ciclo fue simple y repetido: usar un caso real, observar dónde se trababa el flujo, recoger feedback, ajustar y volver a probar. No fue un laboratorio formal, sino iteración situada en la operación del taller.

Restimator resolvía bien una pregunta puntual: «¿sigo o no?». Sin embargo, dejaba a la vista el problema más grande que ya se venía explorando en paralelo desde la propia planilla del MVP: presupuestar, aprobar, producir y hacer seguimiento de un trabajo real es un problema de operación completo, no solo de estimación. Ese problema mayor es el que la V2 fue encarando.

De responder «más o menos cuánto» a sostener todo el ciclo del trabajo.

La base de materiales y precios que arrancó en la planilla del MVP nunca dejó de crecer en paralelo a Restimator. Un taller no vive solo de estimaciones rápidas: un presupuesto aprobado tiene que convertirse en documentación de producción, en compras, en trabajo ejecutado. Además, alguien necesita poder comparar después lo que se calculó contra lo que costó en realidad. Esa dirección más amplia, que ya venía tomando forma desde el principio, es lo que la V2 fue ampliando.

El motor de precios que hoy usa Restimator no se reescribió para la V2. Se desacopló de su interfaz para poder alimentar un presupuesto más completo (productos, materiales, jornales, terminaciones, servicios) sin perder la lógica ya validada. Es la misma decisión de arquitectura del MVP original (lógica separada de superficie) aplicada un nivel más arriba, sobre la misma base que se venía construyendo desde el principio.

Distribuir la complejidad en vez de amontonarla en una sola pantalla.

La V1 resolvía bien el cálculo principal, pero concentraba demasiada información y decisiones en una sola superficie. El diseño de la V2 se apoyó en tres criterios explícitos: trazabilidad de cada decisión, captura del conocimiento del taller en configuraciones reutilizables, y menor carga cognitiva sin perder velocidad.

Dos decisiones de systems design sostienen el resto del producto: una biblioteca de productos tipo, que convierte el conocimiento recurrente del taller en configuraciones reutilizables y editables en vez de partir de cero cada vez; y un lector de planos conceptual, que explora acelerar la extracción de medidas sin sacarle a la persona la revisión y la trazabilidad final. Ambas piezas son prototipos: decisiones de diseño exploradas y documentadas, no funcionalidad entregada.

A medida que Restimator creció hacia múltiples módulos, estados y dispositivos, mantener la consistencia dejó de ser solo una cuestión visual y pasó a formar parte del problema de producto.

El Design System documenta foundations, tokens, componentes y patrones responsive para escalar la experiencia con coherencia. Su núcleo está implementado y en uso; las extensiones todavía especificadas se presentan como tales.

Dentro del Design System

Foundations

IMPLEMENTED. Tokens de color, contraste y acento convierten decisiones visuales en reglas reutilizables.

Components

IMPLEMENTED. Estados y validaciones se expresan con componentes consistentes, sin depender únicamente del color.

Product Patterns

DOCUMENTED. Una regla de negocio se convierte en un patrón legible y repetible dentro del producto.

Screen Examples

UI KIT · DOCUMENTED. La calculadora aplica el sistema completo a una superficie de trabajo densa.

Responsive System

SPECIFIED FOR IMPLEMENTATION. Mobile conserva el mismo vocabulario, pero adapta navegación, densidad y acceso al resultado.

Design → Implementation

DOCUMENTED. Foundation → token → component → pattern → screen: la misma decisión se propaga sin volver a definirse en cada superficie.

Ver Design System completo →

La V2 ya existe como producto funcional, aunque su circuito completo todavía no está cerrado.

Estas capturas corresponden a funcionalidades implementadas y ejecutadas localmente durante pruebas. La URL localhost identifica el entorno de desarrollo, no un prototipo. El circuito completo todavía seguía en desarrollo activo.

De estimador a sistema operativo.

La arquitectura conserva la misma idea del MVP, un modelo de precios, varias superficies, pero ahora el modelo alimenta un ciclo completo: presupuesto, revisión, aprobación, producción y cierre. Algunas partes de este ciclo ya están implementadas y en desarrollo activo; otras todavía son prototipos o quedan como trabajo futuro. El diagrama marca cada tramo con su estado real, no con la intención.

Cómo leer los estados: verde = implementado (en desarrollo activo); sin color = en desarrollo; gris/atenuado = diseñado, prototipo o futuro. El estado exacto de cada paso y su evidencia están en «Ver detalle».

Dos piezas de este ciclo están confirmadas como implementadas y en uso: el dashboard V2 (prioridades, presupuestos y seguimiento en un mismo lugar) y la vista de producción conectada a presupuestos y tareas. El resto del ciclo (aprobación interna, respuesta del cliente, documentación de taller, compras y cierre estimado contra real) está en distintos grados de desarrollo, diseño o todavía sin construir. La secuencia completa de punta a punta, con datos de demostración, es la pieza de evidencia más importante que falta producir (ver Validación y estado actual).

Una solución que fue creciendo con el problema.

Este recorrido no siguió un plan de dos fases prolijas decidido desde el primer día. El problema era demasiado grande para atacarlo de una sola vez: se fue descomponiendo en piezas más chicas y verificables, algunas exploradas en paralelo, y cada una fue tomando forma real en un momento distinto, no necesariamente en el orden en que se les ocurrieron a las personas, sino en el orden en que se pudieron construir y probar.

El punto donde un presupuesto aprobado se convierte en trabajo real.

Presupuestar bien no alcanza si lo aprobado no se traduce en instrucciones claras para el taller. La V2 empezó a construir ese puente: una vista de producción que conecta presupuestos, prioridades y tareas ya está implementada y en uso; la documentación técnica (despiece, lista de corte) y el módulo de compras y abastecimiento existen como propuestas de diseño, todavía no como funcionalidad entregada.

La orden de producción diseñada reorganiza costos y decisiones comerciales en instrucciones accionables para el taller, y la exploración de compras conecta las necesidades de producción con el abastecimiento. Ambas están documentadas como decisiones de Product Design, no presentadas acá como módulos ya en uso.

Qué está implementado hoy y qué todavía necesita evidencia.

Restimator/Presupuestador es un sistema en uso real y en evolución activa, no un producto terminado. Esto es lo que se puede afirmar hoy con confianza, y lo que todavía necesita más evidencia antes de poder afirmarse como resultado.

Sobre el uso de IA en este proyecto: se usó como apoyo de desarrollo y documentación: ayudó a estructurar criterios a partir del diagnóstico, asistir el desarrollo del código de V1 y organizar la documentación del proyecto. No hay funcionalidad de IA embebida en el producto (lectura de fotos, sugerencia de rango o marcado de anomalías) confirmada como implementada. Una versión anterior de este caso describía esas tres capacidades como si ya existieran, y esa afirmación no estaba respaldada por evidencia verificable; se retira acá.

• Los trabajos atípicos o a medida siguen resolviéndose con criterio manual; el sistema cubre bien el patrón común, no el caso excepcional.
• El motor de estimación necesita más historial de presupuestos para mantenerse preciso a medida que cambian los costos de material.
• El sistema depende de que el presupuestador siga revisando y corrigiendo el modelo; no es un criterio que se mantenga solo.

Hacia dónde va esto.