Por qué el software de construcción fracasa en campo, y qué sí funciona
El software de gestión de construcción promete centralizar avance, costos, documentos y comunicación en un solo sistema. La tecnología existe desde hace más de veinte años y las funciones sobran. Sin embargo, en una proporción muy alta de las obras, el residente sigue anotando en una libreta y capturando en la oficina por la tarde. No es un problema de funciones faltantes: es un problema de dónde ocurre la captura.
El patrón de fracaso
Se repite con una consistencia que ya no sorprende.
La dirección evalúa herramientas, compara funciones y elige. Se contrata, se capacita, se sube el catálogo de conceptos. Las primeras dos semanas todo el mundo lo usa. La tercera semana, alguien captura al día siguiente. La sexta, uno de los residentes lleva un mes sin entrar. Al trimestre, el sistema tiene datos de una obra de tres, incompletos, y la oficina técnica volvió a pedir el avance por correo.
La conclusión habitual dentro de la empresa es que «la gente de obra se resiste al cambio». Es una explicación cómoda y es falsa. Esa misma gente adoptó WhatsApp sin que nadie la capacitara.
Las cuatro causas reales
El costo de captura excede el beneficio percibido, para quien captura. Este es el problema central. El residente invierte tiempo en alimentar el sistema, y el beneficio lo recibe la oficina en forma de reportes. Desde su posición, es trabajo extra que le sirve a otro. Cualquier sistema que reparta así costos y beneficios va a fallar, sin importar qué tan bien esté diseñado.
La fricción física del contexto. Una obra tiene polvo, guantes, sol de frente, andamios y las dos manos ocupadas. Abrir una aplicación, navegar tres pantallas, buscar el concepto en una lista de 200 y teclear una cantidad es una operación de escritorio ejecutada en un lugar que no es un escritorio. La libreta gana porque tiene fricción casi cero, no porque sea mejor herramienta.
Conectividad intermitente. Muchas obras tienen mala señal, y un sistema que falla al guardar enseña en dos intentos que no se puede confiar en él. Después de eso, la gente escribe en la libreta «por si acaso», y ya no vuelve.
Diseño para el comprador, no para el usuario. Quien compra es el director; quien usa es el residente. Los ciclos de venta se optimizan para impresionar al primero —dashboards, integraciones, módulos— y eso rara vez coincide con lo que le sirve al segundo. El resultado es software que se ve muy bien en la demo y que nadie abre en obra.
Lo que sí adopta la gente
Observando qué herramientas sí sobreviven en obra, aparecen cuatro rasgos comunes.
Vive en un canal que ya usan. WhatsApp funciona en obra porque no hay nada que instalar, nada que aprender y nada que recordar. Cualquier propuesta que empiece con «descarga esta app» ya arranca con una desventaja considerable.
Captura en el formato en que la información nace. En obra la información nace hablada. El residente le dice al maestro lo que ve; no lo escribe en un formulario. Una nota de voz es la forma natural del dato. Convertirla en dato estructurado es trabajo del sistema, no del usuario.
Devuelve algo al que captura, rápido. Si el residente registra el avance y a los dos minutos recibe el rendimiento del día contra lo presupuestado, la captura dejó de ser burocracia. Si además elimina la captura de la tarde, se convirtió en algo que él quiere usar. El sentido de la dirección de los beneficios es lo que decide la adopción.
Tolera la mala señal por diseño. No con un mensaje de error amable, sino encolando y subiendo sola. El usuario no debería enterarse de que no había señal.
La prueba que vale la pena hacer
Antes de evaluar cualquier herramienta, hay una pregunta que revela más que cualquier demo:
¿Cuánto tiempo pasa entre que ocurre el hecho y que queda registrado en el sistema?
Si la respuesta se mide en horas o días, tienes un sistema de reportes, no un sistema de captura. Todo lo que produzca —avance, costos, evidencia— va a heredar la calidad de una reconstrucción de memoria hecha al final del día.
Si se mide en minutos, tienes un sistema de registro. Y ahí sí los datos sirven para decidir.
Un matiz honesto
No todo software de construcción fracasa, y sería deshonesto sugerirlo.
Los sistemas de oficina —presupuestos, control de costos, contabilidad de obra— funcionan bien y llevan décadas funcionando, porque su usuario está en un escritorio con teclado, café y señal. Ahí la fricción no existe y el software cumple.
El problema es específico de la captura en campo. Es la frontera donde el mundo físico entra al sistema, y es donde casi toda la cadena se rompe. Un sistema de costos excelente alimentado con datos capturados de memoria produce reportes excelentes sobre información mala.
Qué preguntar antes de comprar
Cinco preguntas que separan una demo de la realidad:
- ¿Qué tiene que hacer el residente, exactamente, para registrar un avance? Que te lo muestren paso a paso, no en diapositiva.
- ¿Qué pasa si no hay señal en ese momento?
- ¿Qué recibe el residente a cambio, y en cuánto tiempo?
- ¿Cuántos días toma cargar el catálogo de conceptos antes de poder empezar?
- ¿Qué porcentaje de sus clientes sigue registrando a diario después de seis meses?
La última es la única que importa de verdad, y es la que casi nadie contesta con un número.
Preguntas frecuentes
- ¿Entonces no vale la pena digitalizar la obra?
- Vale muchísimo la pena. Lo que no funciona es digitalizar pidiéndole al residente que trabaje como si estuviera en una oficina. La digitalización que funciona se adapta al contexto de campo en lugar de exigir que el campo se adapte a ella.
- ¿Por qué cuesta tanto adoptar las herramientas internacionales en Latinoamérica?
- Además del precio, por el vocabulario y el proceso. Los conceptos de obra, la estructura de precios unitarios, la mecánica de estimaciones y el rol de la supervisión son distintos en cada país. Una herramienta que no habla tu vocabulario obliga a traducir, y traducir es fricción.
- ¿Cuánto tarda una implementación realista?
- Depende del alcance. La señal de alarma es cualquier implementación que requiera más de dos o tres semanas antes de producir valor visible en obra. Cuanto más largo el periodo sin beneficio, más probable que el hábito no se instale.
- ¿Sirve obligar el uso desde la dirección?
- Sirve durante unas semanas. Después la gente encuentra la manera de cumplir formalmente sin usarlo de verdad: capturas al cierre del mes, datos redondeados, campos llenados por llenar. La obligación produce cumplimiento aparente; la utilidad produce uso.
- ¿Y si mi equipo de verdad se resiste al cambio?
- Vale la pena verificar la hipótesis antes de aceptarla. Si esas mismas personas usan WhatsApp, banca por celular y aplicaciones de transporte todos los días, el problema no es el cambio.
Chileno, diseñando para América Latina. Del research en campo saca lo que realmente importa para los clientes, y con eso arma productos que la gente no técnica adopta sola —legal, educación, contabilidad— y que se notan en la productividad desde la primera semana.
Ver todos sus artículos →
