Artículo técnico
Elegir software de obra: primero el proceso, luego el producto
Comparar listas de funciones es fácil y rara vez lleva a la decisión acertada. La pregunta buena es otra: ¿cuál de nuestros procesos podemos adaptar al software — y cuál no?
Artículo técnico de Open Experience GmbH. · Estado: septiembre de 2026
¿Cómo se elige el software de obra adecuado?
Separando primero los procesos propios en dos grupos. Los procesos primarios de creación de valor — aquello por lo que a una empresa se la conoce — no pueden adaptarse a un software: quien somete su proceso central a una solución estándar trabaja a partir de entonces igual que la competencia, que usa esa misma solución. Los procesos de apoyo, en cambio, están mejor servidos con software estándar, porque ahí cuentan el coste y la mantenibilidad y no se genera ninguna diferencia. Solo después de esa clasificación merece la pena comparar funciones.
Marco jurídico: Alemania (código civil BGB, condiciones de contratación de obra VOB/B, arancel HOAI). En otros países rigen normas distintas, y lo pactado en el contrato prevalece sobre los plazos ordinarios aquí citados.
Primario o de apoyo — la decisión previa
El mismo software puede ser la elección acertada para una empresa y la equivocada para otra. La diferencia no está en el producto, sino en el papel que cumple el proceso.
| Rasgo | Proceso primario de creación de valor | Proceso de apoyo |
|---|---|---|
| *Cómo se reconoce* | El cliente paga precisamente por eso | Necesario, pero intercambiable |
| *Sentido de la adaptación* | El software sigue al proceso | El proceso sigue al software |
| *Criterio de decisión* | El encaje, aunque cueste más tiempo | Coste, mantenibilidad, plazo de implantación |
| *Riesgo de elegir mal* | Perder el rasgo diferenciador | Recursos atados sin contrapartida |
La clasificación es propia de cada empresa: para un despacho la dirección de obra es el proceso central; para otro, una prestación accesoria.
Ejemplo 1 — cuando la eficiencia es el proceso central
Un despacho de proyectos es conocido por dirigir la obra con especial eficiencia. El reparto del trabajo está rodado: ingenieros con experiencia valoran en obra y dictan notas de voz, y la oficina las convierte en tareas. Si ahora se implanta un sistema de tickets que descarga a la oficina pero recarga a la dirección de obra, se viene abajo justo la ventaja que distingue a ese despacho.
- Las cuentas no salenAlivio donde la hora es barata y sobrecarga donde es cara: eso es un desplazamiento, no una mejora.
- Mejor esperar que forzarSi no existe una solución que encaje, esperar es mejor decisión que una que dañe el proceso central.
- Qué hace aquí un software adecuadoRegistrar tarea e imagen en un solo paso y dejar la observación como nota de voz — el análisis lo sigue haciendo la oficina como hasta ahora.
El ejemplo es una ilustración, no una referencia: describe un patrón que aparece una y otra vez en los proyectos de selección.
Ejemplo 2 — cuando el desarrollo a medida acaba en el sitio equivocado
Una ingeniería se ha labrado una ventaja real con una biblioteca propia de modelos de instalaciones, dependencias geométricas incluidas. De esa buena experiencia nace la idea de encargar también un sistema de registro de tareas. El error no está en la capacidad, sino en la clasificación: la ingeniería es conocida por el proyecto de instalaciones, no por la dirección de obra.
- Recursos en la palanca equivocadaLa capacidad de desarrollo que falta en el ámbito central genera retraso justo donde nace la ventaja.
- Pocos conocedores en casaQuien no vive el proceso a diario no puede ni especificarlo ni mantenerlo a largo plazo.
- Lo correcto seríaUn sistema estándar económico para el proceso secundario — y el desarrollo propio allí donde produce efecto.
La altura de vuelo correcta de los datos
La segunda pregunta de la elección no va de funciones, sino de datos: qué información hace falta a diario para trabajar y cuál está ahí como referencia. Los datos de trabajo tienen que estar donde se trabaja — móviles, sin conexión, localizables en segundos. Los datos de referencia pertenecen a un archivo ordenado del que se sacan cuando hacen falta. Quien fuerza ambas cosas en el mismo sistema obtiene o una aplicación de obra lenta o un archivo en el que nada se encuentra.
- En uso activoDefectos, comprobaciones, fotografías del tramo en curso, planos vigentes — cada día y al alcance de dos gestos.
- Guardado como referenciaContratos, versiones antiguas de planos, tramos ya cerrados — archivados de forma trazable, pero sin estorbar.
- Estándar más lo propio del proyectoUn expediente de obra con la misma estructura básica en todas partes y capaz aun así de recoger las particularidades de cada proyecto.
Preguntas que aclaran una elección más deprisa que cualquier demostración
¿Por qué nos paga el cliente?
La respuesta nombra los procesos que no se pueden adaptar.
¿Quién introduce los datos?
Los sistemas que empujan el registro hacia abajo fracasan por culpa de quienes tendrían que registrar.
¿Funciona sin cobertura?
En la estructura eso no es una cuestión de comodidad, sino la condición para que se use.
¿Podremos volver a salir?
Los formatos de exportación deciden si los datos son del proyecto o del proveedor.
¿Quién lo mantiene dentro de tres años?
En un desarrollo propio es la pregunta más cara y casi siempre la que queda sin respuesta.
¿Cuánto cuesta el décimo usuario?
Los modelos de precios que castigan el despliegue impiden justo aquello que aporta el provecho.
Especialista o generalista
Queda la cuestión de fondo: un proveedor global que evite los problemas de interfaz, o varias soluciones especializadas que hacen más dentro de su terreno. Ambas posturas son defendibles. Lo decisivo es dónde se necesita la profundidad: quien tiene la fase de obra como proceso central necesita profundidad ahí y puede prescindir de ella en otros sitios. Cómo se presenta esto frente a otros proveedores — incluida la pregunta de cuándo el competidor es la mejor opción — está en las páginas de comparativa.
Qué es Open Experience en este punto
Open Experience es el especialista de la fase de obra: defectos, fotografías, diario, listas de comprobación y registro 360° en una sola plataforma, con hardware propio y en el lenguaje de la fase 8 de prestaciones (HOAI). Del proyecto, del presupuesto o de las nóminas se ocupan otros — y eso no es un hueco, sino la decisión de tener profundidad en el proceso central.
Preguntas frecuentes
¿Estándar o desarrollo a medida — qué sale más barato?
El estándar casi siempre en la compra; el desarrollo a medida casi nunca en la explotación. La verdadera cuestión de coste no es la implantación, sino el mantenimiento a lo largo de cinco años.
¿Cómo reconozco un proceso primario?
En que los clientes lo mencionan cuando explican por qué trabajan con usted. Todo lo que es internamente necesario pero intercambiable pertenece al otro grupo.
¿Cuántos sistemas son demasiados?
No decide el número, sino los traspasos. Dos sistemas con una interfaz limpia son mejores que uno solo en el que la mitad del trabajo se pierde por el camino.
¿Qué es un entorno común de datos?
Un entorno ordenado en el que todos los intervinientes acceden a la misma versión — con una separación clara entre estado de trabajo, estado aprobado y archivo.
¿Cuánto dura de forma realista una implantación?
La instalación es cuestión de días. El cambio dura un proyecto, sobre todo porque hay que apagar los viejos caminos paralelos, no porque el software sea difícil.
¿En qué fracasan más a menudo los proyectos de selección?
En dos cosas: se eligió por listas de funciones en vez de por procesos — y quienes tendrían que registrar a diario no participaron en la decisión.
Fuentes y base jurídica
Las afirmaciones jurídicas de este artículo se apoyan en las fuentes primarias que figuran a continuación. El artículo no sustituye al asesoramiento jurídico en cada caso concreto.
Primero mirar sus procesos, después hablar de software.
45 minutos sin demostración de producto: ordenamos con usted qué proceso es su rasgo diferenciador — y cuál admite el estándar.