Una oficina técnica de treinta personas cierra su quinto proyecto en dieciocho meses con la misma plataforma técnica prescribida en los cinco. El director técnico revisa la asignación de horas y espera encontrar el patrón habitual de compresión: el primer proyecto siempre lleva más tiempo, el quinto debería llevar aproximadamente la mitad. La realidad del informe le contradice. El primer proyecto llevó seis semanas de configuración de la plataforma; el quinto llevó cinco semanas y media. La curva de aprendizaje que la oficina asumía como activo intangible no aparece por ningún sitio. Un vistazo rápido a los expedientes de los cinco proyectos revela la razón: cada proyecto se ha configurado manualmente desde la interfaz de administración de la plataforma. Tipos de entidad redefinidos uno a uno. Roles reconfigurados uno a uno. Flujos de trabajo reimplementados uno a uno. Campos personalizados recreados uno a uno. Nada de lo hecho en el proyecto anterior se ha trasladado al siguiente porque no había forma técnica de hacerlo.
La ventaja compuesta que debería acumularse en una cartera de proyectos similares no se materializa cuando la configuración vive dentro de la plataforma y no fuera. Lo que no se puede exportar, versionar, probar y reaplicar es lo que fuerza a la oficina técnica a repetir el mismo trabajo una y otra vez, sin que la senioridad del equipo se traduzca en aceleración de proyecto. Ese fenómeno no es un problema de gestión de la ingeniería: es una propiedad técnica de la plataforma prescribida.
Lo que la oficina técnica está pagando en realidad
El tiempo del arranque en blanco lo paga el senior técnico. Es el perfil que domina la arquitectura de la plataforma, entiende las implicaciones de cada decisión de configuración y garantiza que el flujo funcione en producción. Es también el perfil más caro y el más escaso. Cinco proyectos multiplicados por seis semanas de configuración con dedicación mayoritaria de senior técnico equivale a treinta semanas de un perfil que, si la plataforma soportara configuración exportable, habría estado en dos o tres semanas del quinto proyecto y el resto disponible para nuevos proyectos, para propuestas o para el desarrollo de metodología interna. La pérdida no aparece en ningún expediente porque no está facturada como pérdida: está diluida en la línea de horas técnicas de cada uno de los cinco proyectos, y solo se hace visible cuando alguien mira el conjunto.
El segundo efecto es la exclusividad. Cuando un senior técnico está configurando el arranque de un proyecto, no puede estar en la revisión técnica de otro proyecto ni en la reunión de propuesta del siguiente. La oficina técnica escala con perfil senior o no escala; y con configuración por proyecto no escalable, cada nuevo proyecto ocupa el mismo cuello de botella que el anterior.
Configuración como código: lo que cambia cuando existe
La solución técnica se conoce en otros ámbitos —infraestructura, despliegue de software, gobierno de datos— con el nombre de configuración como código. Aplicada a una plataforma GMAO+GIS, significa que toda la configuración del sistema —tipos de entidad, atributos, roles, permisos, flujos de trabajo, plantillas de plan preventivo, matrices de criticidad, capas cartográficas base— se puede exportar como fichero estructurado y legible fuera de la plataforma, versionar en el sistema de control de versiones habitual de la oficina técnica, probar en un entorno separado y reaplicar a un cliente nuevo con una llamada a la API.
Cuando la configuración vive fuera de la plataforma, cada nuevo cliente arranca desde una plantilla que agrupa el conocimiento acumulado en los proyectos anteriores. El senior técnico revisa el fichero de plantilla, lo adapta a las particularidades del cliente actual —dos tipos nuevos de activo, un flujo específico, tres roles distintos—, lo prueba en el entorno de piloto y lo publica en producción. El tiempo total del arranque de configuración pasa de seis semanas de trabajo manual a dos semanas de trabajo dirigido, y la seniority del equipo se traduce por primera vez en aceleración medible.
Tres criterios para verificar antes de prescribir
Una ingeniería técnica que quiera acumular ventaja compuesta a lo largo de una cartera de proyectos debería verificar tres criterios en la fase de selección de plataforma. El primero es la exportabilidad completa de la configuración. No basta con que la plataforma permita exportar el maestro de activos: tienen que ser exportables los tipos de entidad, los flujos, los roles, las plantillas de plan preventivo y toda estructura configurable. Cualquier elemento que se configure desde la interfaz y no aparezca en el export es un elemento que se reconfigura manualmente en el proyecto siguiente.
El segundo es la granularidad de la reimportación. Un buen sistema permite importar solo una parte del fichero —los flujos, sin tocar los roles— y controlar qué se sobreescribe y qué se preserva. Sin granularidad, la reutilización se convierte en un reemplazo total que suele romper la configuración específica del cliente actual.
El tercero es la versionabilidad de las plantillas. La oficina técnica debería poder mantener un repositorio interno de plantillas con historial de cambios, comentarios y capacidad de retroceder a versiones anteriores. Sin control de versiones, las plantillas envejecen sin trazabilidad y se convierten en el mismo problema que resolvían.
La API como decisor del margen del segundo proyecto
En Maptainer estos tres criterios se cumplen por diseño: la configuración de la plataforma es enteramente accesible por la especificación OpenAPI 3.0, la importación es granular por tipo de elemento y las plantillas de configuración se pueden mantener en el sistema de control de versiones que la oficina técnica ya usa para el resto de su código y documentación. La consecuencia práctica es que una ingeniería que arranca su tercer o cuarto proyecto con la misma plataforma comprime el tiempo de configuración de forma medible respecto al primero, y esa compresión se convierte directamente en margen del proyecto y en capacidad de la oficina para tomar más encargos con el mismo equipo.
Lo que decide la selección de plataforma para una ingeniería
La conversación clásica alrededor de la selección de una plataforma técnica gira en torno a funcionalidad y precio de licencia. La conversación que verdaderamente decide el margen a tres años es distinta: qué parte del trabajo de configuración se puede empaquetar como plantilla reutilizable y qué parte queda fuera de esa posibilidad. Las plataformas que dan una respuesta clara y verificable a esa pregunta son las que sostienen la escala de una oficina técnica pequeña. Las que se refugian en el argumento de que la configuración por proyecto es inevitable son, con frecuencia, las que convierten la ganancia comercial de la oficina en una acumulación de horas técnicas no facturables.