Elegir un software de gestión de obras consiste en encontrar la herramienta que resuelve los problemas concretos de tu constructora y que tu equipo de oficina y de obra va a usar de verdad, no la que acumula más funciones. Para acertar, conviene partir de tus procesos, separar lo imprescindible de lo deseable y probar las candidatas en una obra real antes de firmar.

Torre de viviendas en construcción con una grúa torre

Antes de ver demos: procesos y problemas concretos

El error más común al buscar un programa de gestión de obras es empezar por los catálogos. En una presentación comercial todas las herramientas parecen capaces de todo, y la comparación acaba siendo una lista de casillas marcadas que dice poco sobre cómo se trabajará en tu obra.

Resulta más útil anotar antes, con el jefe de obra y la oficina técnica, unos pocos problemas concretos: las fotos se quedan en los móviles personales, nadie encuentra qué respondió la dirección facultativa a una consulta antigua o los repasos se acumulan hasta la entrega.

Para cada problema, describe el proceso que hay detrás. Esas respuestas serán después el guion de las demos:

  • Quién genera la información y en qué momento: en el tajo, en la caseta o en la oficina.
  • Quién la revisa o la aprueba, y qué ocurre cuando no lo hace.
  • Qué resultado sale al final: un parte, un informe, un acta, una relación valorada.
  • Con qué otras herramientas o personas tiene que cruzarse esa información.

Quién lo va a usar: oficina, obra y empresas externas

Un software para constructoras tiene usuarios muy distintos, y lo que convence a la oficina puede fracasar en el tajo. Piensa en cada perfil y en las condiciones reales en las que va a trabajar:

  • Oficina técnica y gerencia: ordenan documentación, revisan varias obras a la vez y preparan informes, casi siempre desde el ordenador.
  • Jefe de obra: reparte su jornada entre la caseta, el tajo y las reuniones, y necesita ver de un vistazo lo pendiente sin escribir las cosas dos veces.
  • Encargado: registra desde el móvil, a veces con guantes, con sol directo o en un sótano sin cobertura. Para él cuentan los pocos toques y que la aplicación guarde los datos sin conexión y los sincronice después sin perder nada.
  • Subcontratas: entran de vez en cuando y apenas reciben formación. Si ver una tarea o un plano les exige instalar varias cosas o pedir ayuda, volverán al teléfono.
  • Dirección facultativa y promotora: suelen consultar y, en ocasiones, comentar o aprobar, así que interesa saber cómo se cobra un acceso limitado.

Lo imprescindible y lo que puede esperar

Con los problemas y los usuarios claros, divide los requisitos en dos listas. En la de imprescindibles solo entra aquello sin lo cual la herramienta no resuelve tus problemas prioritarios; lo demás es deseable, por atractivo que parezca en la demo. Así evitas descartar una buena opción por una función secundaria o pagar módulos que nadie abrirá. Como orientación:

  • Casi siempre imprescindibles: registro desde el móvil con trabajo sin conexión, acceso sencillo para subcontratas, permisos por obra y por perfil, y exportación completa de los datos.
  • Imprescindibles según el caso: control de revisiones de planos si cambian a menudo, gestión de repasos si entregas viviendas, inspecciones documentadas si tu cliente las pide.
  • Normalmente deseables: paneles a medida, visor de modelos BIM, firma de documentos dentro de la herramienta o automatismos avanzados.
  • Deseables que pueden volverse imprescindibles: la conexión con tu ERP o tu contabilidad, cuando hoy se copian a mano muchos datos.

Integraciones, datos, seguridad y soporte

Hay criterios que no se aprecian en una demo corta y que pesan mucho a medio plazo. Pide que te los enseñen en la propia herramienta, no en una diapositiva.

Si la herramienta guarda datos personales, como teléfonos de trabajadores o fotos en las que aparecen personas, el proveedor suele actuar como encargado del tratamiento, y el Reglamento General de Protección de Datos exige regular esa relación por contrato. Y aunque la Ley de Datos de la Unión Europea establece un marco para facilitar el cambio entre proveedores de servicios en la nube, lo práctico es comprobar tú mismo cómo se exporta todo.

Criterios técnicos: qué comprobar y qué debería hacerte dudar
CriterioQué comprobarSeñal de alerta
Uso en obra sin conexiónQue se creen registros con fotos sin cobertura y se sincronicen solos al recuperarlaLa aplicación pide conexión en cada paso
Acceso de subcontratasCómo se invita a una empresa externa, qué ve y cómo se le retira el accesoCada usuario externo necesita una licencia completa o una configuración larga
Integración con lo que ya usasConexión con tu ERP, tu contabilidad o tu planificación, o al menos importación y exportación en formatos abiertosTodo depende de un desarrollo a medida sin plazo ni coste cerrados
Propiedad y exportación de datosQue el contrato reconozca que los datos son tuyos y que se exporten completos, con fotos y documentosSolo se exporta en un formato propio del proveedor o se cobra aparte
Seguridad y permisosPermisos por obra, empresa y perfil, registro de cambios, copias de seguridad y lugar de alojamientoTodos ven todas las obras o nadie aclara dónde se guardan los datos
Soporte y formación en españolCanales, horario e idioma del soporte y ayuda durante la puesta en marchaEl soporte atiende en otro idioma o depende de un único comercial

Modelos de precio: cómo comparar sin sorpresas

Comparar solo la cuota mensual suele llevar a error, porque cada proveedor cobra por conceptos distintos. Pide el coste de un escenario realista, con tus obras y tus usuarios, y revisa la duración mínima del contrato, la renovación y las condiciones de baja. Los modelos más frecuentes, solos o combinados, son estos:

  • Por usuario: pagas por cada persona con acceso. Aclara si los usuarios externos o de solo consulta cuentan igual que los internos.
  • Por proyecto u obra: pagas por cada obra activa. Pregunta qué ocurre con la consulta del archivo cuando la obra se cierra.
  • Por módulos: contratas una base y añades funciones. Comprueba qué módulos hacen falta de verdad para tus imprescindibles.
  • Costes fuera de la cuota: implantación, migración de datos, formación, almacenamiento adicional, integraciones y soporte prioritario.

Cómo hacer una prueba piloto en una obra real

Ninguna herramienta encaja igual en todas las constructoras, y los cálculos de ahorro presentados en abstracto dicen poco de tu caso. Antes de decidir, prueba las candidatas finalistas en una obra real durante unas semanas: es la forma de saber si la herramienta se adapta a tu manera de trabajar y si tu equipo la adopta.

  1. Elige una obra representativa, ni la más sencilla ni la más complicada, con un jefe de obra dispuesto a probar.
  2. Define antes de empezar qué procesos se prueban, quién participa y qué tiene que pasar para considerar que funciona.
  3. Incluye a quien tendrá más dificultades: el encargado y al menos una subcontrata, no solo la oficina técnica.
  4. Carga tus datos reales, con tus planos y tus plantillas, en lugar de los ejemplos del proveedor.
  5. Haz que la prueba abarque un ciclo completo de trabajo, con visitas de la dirección facultativa, cambios de planos y un cierre de mes.
  6. Al terminar, repasa con los usuarios qué se ha registrado de verdad, qué se ha seguido haciendo por fuera y qué ha fallado, y decide con esos hechos.

Ejemplo práctico (ilustrativo)

Una constructora dedicada a rehabilitar edificios residenciales, con varias obras abiertas en distintas ciudades, busca una herramienta común. Antes de pedir demos, el jefe de producción y la oficina técnica anotan tres problemas: fotos perdidas en móviles personales, respuestas de la dirección facultativa enterradas entre correos y repasos acumulados hasta la última semana.

Fijan como imprescindibles el registro de fotos sin conexión, porque muchas obras tienen sótanos y patios sin cobertura, un acceso sencillo para subcontratas y la exportación completa de los datos. La conexión con la contabilidad queda como deseable.

Prueban dos herramientas en una rehabilitación de fachada y cubierta, con el jefe de obra, el encargado y las subcontratas de andamios y de cubierta. Una pierde registros al sincronizar tras trabajar sin cobertura; la otra resulta más sencilla para el encargado, aunque su panel para la gerencia es más limitado. Eligen la segunda, porque el problema estaba en el tajo y no en la oficina.

Preguntas que conviene hacer en una demo

  • ¿Cómo se registra una observación con fotos sin cobertura y cómo se sincroniza después?
  • ¿Cómo se invita a una subcontrata, qué ve exactamente y cómo se le retira el acceso?
  • ¿Qué pasa con una obra cerrada: sigue consultable, se archiva o tiene coste?
  • ¿Cómo se exportan todos los datos, incluidas fotos y documentos, y en qué formatos?
  • ¿Dónde se alojan los datos y cómo se hacen las copias de seguridad?
  • ¿Qué conexión hay con el ERP, la contabilidad o la planificación de la empresa, y quién la mantiene?
  • ¿Qué incluye la puesta en marcha y qué formación recibe el equipo de obra?
  • ¿Se puede hacer una prueba en una obra real, con datos propios, antes de firmar?

Preguntas frecuentes

¿Es mejor una herramienta que lo haga todo o varias especializadas?

Depende de tus problemas prioritarios. Una herramienta única evita duplicar datos y reúne a todo el equipo en el mismo sitio, pero puede quedarse corta en alguna función. Varias especializadas cubren mejor cada proceso a cambio de más accesos, más contratos y más riesgo de que la información quede repartida. Si las combinas, comprueba cómo se conectan y quién mantiene esas conexiones.

¿Conviene un software pensado para construcción o uno genérico de gestión de proyectos?

Las herramientas genéricas son flexibles, pero no suelen traer de serie lo que distingue a una obra: planos con revisiones, trabajo sin conexión, acceso de subcontratas o registros vinculados a una ubicación. Un software específico para constructoras lo incorpora, aunque puede ser más rígido. Si tus problemas son de coordinación en la oficina, una genérica puede bastar; si están en el tajo, suele encajar mejor una específica.

¿Cuánto debe durar una prueba piloto?

No hay una duración fija. Lo razonable es que cubra un ciclo completo de la obra: varias visitas de la dirección facultativa, algún cambio de planos, la gestión de repasos o incidencias y un cierre de mes. Si es demasiado corta, el equipo apenas habrá superado la curva de aprendizaje y las conclusiones hablarán más de la novedad que de la herramienta.

¿Qué ocurre con los datos si dejas de usar el software?

Depende del contrato, por eso conviene leerlo antes de firmar. Revisa durante cuánto tiempo puedes descargar la información tras la baja, en qué formatos y con qué coste, y cuándo borra los datos el proveedor. Lo prudente es hacer una exportación de prueba durante el piloto y comprobar que las fotos y los documentos conservan su relación con cada obra.

Fuentes