Programa de obra: cuánto tarda construir una nave industrial

La pregunta llega casi siempre en la misma junta y con la misma redacción: ¿en cuánto tiempo la tenemos lista? Lo que se espera es un número, y casi siempre alguien lo dice. El problema es que un plazo comprometido antes de saber qué se va a construir no es una estimación: es una promesa hecha sobre información que todavía no existe, y suele convertirse en el primer compromiso que el proyecto incumple.

La fecha de una nave industrial rara vez la define la velocidad de la obra. La definen las cadenas que la anteceden y la rodean: cuánto falta para cerrar la definición técnica, cuándo se liberan las compras de fabricación larga, cuándo caen las autorizaciones, de qué depende la acometida eléctrica y qué debe probarse antes de operar. El programa de obra sirve exactamente para eso: hacer visibles esas cadenas mientras todavía se puede decidir sobre ellas.

El plazo se estima con la misma madurez que el costo

AACE International, en su práctica recomendada 27R-03, clasifica los programas de proyecto en cinco clases y establece que la característica primaria para ubicar un programa en una clase es el grado de definición del proyecto. El uso previsto del programa y el método de programación empleado son características secundarias: acompañan a la definición, no la sustituyen.

La escala va de la Clase 5, con la definición más baja, a la Clase 1, que corresponde a un proyecto plenamente definido. Y a cada clase le corresponde un uso legítimo distinto: los programas de menor definición sirven para tamizar conceptos y estudiar factibilidad, y se arman de arriba hacia abajo con hitos y eventos clave; los de definición avanzada se construyen de abajo hacia arriba, con detalle suficiente para controlar la obra o para licitarla.

Esa distinción se pierde en la práctica más de lo que parece. Una barra de doce meses dibujada sobre un croquis de implantación no es un programa de control: es un tamizado de concepto que alguien empezó a tratar como compromiso. Y un cronograma con setecientas actividades sobre un anteproyecto tampoco resuelve nada, porque el detalle no compensa la falta de definición: solo la esconde mejor. Es el mismo razonamiento que aplica al esquema de contratación, donde pedir un precio cerrado sobre un alcance abierto produce supuestos ocultos en lugar de certeza.

Lo que gobierna la fecha no siempre está en la obra

Cuando un proyecto se atrasa, la conversación se concentra en el frente visible: cuántas cuadrillas hay, cuántos metros se colaron esta semana. Pero los desplazamientos grandes casi siempre se originaron meses antes, en frentes que ni siquiera dependen del contratista.

Frentes que gobiernan la fecha de una nave industrial
Frente	Qué lo hace avanzar	Quién lo controla	Qué lo detiene
Definición y proyecto ejecutivo	Decisiones de operación sobre proceso, layout, cargas y crecimiento	El propietario, con sus diseñadores	Requerimientos que se siguen discutiendo mientras se dibuja
Autorizaciones	Documentación completa y responsivas cuando corresponden	Autoridades y dependencias, con la gestión de las partes	Reingresos por información incompleta o por cambios de proyecto
Compras de fabricación larga	Especificación liberada y condiciones comerciales cerradas	El proveedor, una vez liberada la ingeniería	Ingeniería que no cierra, o cambios posteriores a la orden
Infraestructura del sitio y acometidas	Solicitudes, factibilidad y obras del desarrollador o la empresa suministradora	Terceros ajenos al contratista	Capacidad no confirmada o gestiones iniciadas tarde
Obra física	Frentes liberados, material en sitio y cuadrillas	El contratista	Interferencias, retrabajo y frentes sin liberar
Pruebas, entrega y arranque	Criterios de aceptación acordados y sistemas terminados	Propietario, contratista y especialistas	Pendientes que impiden probar y documentación incompleta

Leer la tabla por columnas es más útil que leerla por filas. La tercera columna dice quién puede realmente mover cada fecha, y en la mayoría de los renglones la respuesta no es el constructor. Un programa que solo detalla la obra física deja fuera justamente los frentes donde el propietario todavía tiene capacidad de actuar: la definición, los trámites y las gestiones con terceros. Los permisos y trámites y la capacidad disponible en el parque industrial pertenecen al programa desde el primer día, no a una lista aparte de pendientes administrativos.

La ruta crítica es una consecuencia de la lógica, no una lista de fechas

La práctica recomendada 37R-06 de AACE International describe los niveles de detalle de un programa y señala un punto que conviene tener presente: el nivel 3 es el primero en el que puede mostrarse una red de ruta crítica con significado y usarse el método de la ruta crítica para monitorear y administrar el trabajo. Los niveles anteriores, del 0 al 2, son de resumen: sirven para comunicar y reportar, no para calcular.

Esto tiene una consecuencia incómoda para muchas juntas de arranque: la barra de colores que se proyecta en la pantalla suele ser un nivel de reporte, y no el programa con el que se administra la obra. Si nadie puede mostrar la red que hay debajo —qué actividad depende de cuál y por qué—, entonces no existe una ruta crítica: existe una intención dibujada en forma de barras.

Los síntomas de un programa que no calcula son reconocibles sin ser especialista. Actividades sin predecesora ni sucesora, que flotan sueltas. Fechas fijadas a mano con restricciones duras, que impiden que el programa reaccione cuando algo se mueve. Duraciones desproporcionadamente largas que en realidad esconden varias actividades sin desagregar. Holguras negativas que nadie explica. Y traslapes generosos entre actividades que en obra no pueden ocurrir al mismo tiempo. Ninguno de esos síntomas requiere auditoría formal para detectarse: basta con preguntar qué pasa con la fecha final si una actividad concreta se atrasa dos semanas. Si el programa no responde, no es un modelo.

La fecha que importa en las compras no es la de la orden

En una nave industrial, varios componentes tienen plazos de fabricación y entrega que no se acortan por más presión que se les ponga: la estructura metálica, la lámina de cubierta y fachada, los transformadores y tableros, los equipos de bombeo contra incendio, las puertas seccionales y los equipos de andén. Cuando alguno de ellos entra tarde, el programa no se recupera con más gente en obra.

Lo que conviene entender es que la fecha determinante no es la de colocación del pedido, sino la de liberación de la ingeniería que permite fabricar. Un proveedor no arranca con una intención de compra: arranca con planos de taller aprobados, especificaciones cerradas y decisiones que muchas veces dependen de operación, no del constructor. La carga colgada bajo cubierta, la posición de un equipo de proceso o la demanda eléctrica confirmada son datos del propietario, y cada semana que tardan en confirmarse se traslada íntegra al final del proyecto.

Por eso los hitos de liberación deben aparecer en el programa con nombre, responsable y fecha, igual que cualquier actividad de obra. Un proyecto coordinado en BIM ayuda a llegar a esas liberaciones con menos interferencias pendientes, pero no reemplaza la decisión que operación tiene que tomar.

Traslapar no es acelerar

Cuando la fecha objetivo es más corta que el plazo calculado, existen dos caminos y conviene no confundirlos. Uno es traslapar etapas que originalmente iban en secuencia: empezar cimentaciones con la ingeniería de instalaciones todavía en desarrollo, o liberar la fabricación de estructura antes de cerrar por completo la arquitectura. El otro es aumentar recursos sobre actividades que ya están en la ruta crítica: más cuadrillas, más turnos, más frentes simultáneos.

El primero no cuesta más dinero de entrada, pero compra tiempo a cambio de riesgo de retrabajo: si una decisión posterior contradice algo ya fabricado o ya construido, el ahorro desaparece y suele llevarse consigo más plazo del que ganó. El segundo cuesta desde el primer día y tiene rendimientos decrecientes: llega un punto en el que meter más gente al mismo frente reduce la productividad en lugar de aumentarla, y multiplica las interferencias entre cuadrillas.

Ninguna de las dos opciones es indebida. Lo indebido es aplicarlas sin decir en voz alta qué se está comprando y con qué se está pagando. Traslapar sin reconocer el riesgo de retrabajo es la forma más común de convertir un atraso de programa en un sobrecosto que aparece meses después como orden de cambio.

Estacionalidad y calendario: lo que sí es previsible

En el Bajío, las lluvias se concentran en los meses de verano, y ese periodo afecta de forma desigual a los distintos frentes de obra. Terracerías, excavaciones, cimentaciones y pavimentos son sensibles a la humedad y al acceso de maquinaria; el montaje de estructura y la instalación de cubierta pierden jornadas por viento y tormenta; el trabajo bajo techo, una vez cerrada la envolvente, es mucho más estable.

Esto no se administra con optimismo, sino con secuencia: cuando el calendario lo permite, conviene programar los trabajos más expuestos fuera del periodo más lluvioso y buscar el cierre de la envolvente antes de que llegue. También conviene reflejar en el programa los periodos vacacionales, los cierres de fin de año y los tiempos reales de respuesta de proveedores y dependencias en esas fechas. Un programa que asume productividad constante durante todo el año está mal desde antes de arrancar.

La holgura tiene dueño

Casi todos los programas incluyen algún colchón. El problema es que muchas veces está repartido en silencio: cada contratista infla un poco sus duraciones, el propietario agrega unas semanas al final y nadie sabe cuánta reserva real existe ni quién puede usarla.

Es preferible hacerlo explícito, con la misma lógica que separa contingencia y reserva en el presupuesto. La holgura dentro de una cadena de actividades pertenece al proyecto y se consume conforme aparecen desviaciones normales de ejecución. Una reserva de programa administrada por el propietario cubre lo que sí cambia el alcance: una decisión de negocio, un requisito nuevo, un cambio del usuario final. Mezclarlas produce el efecto conocido: el colchón se agota en los primeros meses y cualquier evento posterior se convierte en discusión de responsabilidad en vez de decisión de inversión.

Conviene también acordar desde el contrato cómo se documenta el uso de esa reserva y qué evidencia se requiere, porque el momento de discutirlo no es cuando ya se consumió.

Un programa se controla con cortes, no con opiniones

Un programa que no se actualiza deja de ser una herramienta y se convierte en un documento histórico. La actualización necesita fecha de corte, avance registrado por actividad, lógica revisada y una comparación explícita contra la línea base aprobada. Reportar un porcentaje global de avance sin decir qué actividades de la ruta crítica se movieron no informa nada útil.

La práctica recomendada 37R-06 describe el uso de programas de tipo continuo, que combinan una ventana de anticipación —del orden de treinta a ciento ochenta días, según el proyecto— con una revisión de los periodos recién terminados. Esa ventana corta es la que realmente coordina la obra: define qué frentes deben quedar liberados, qué material debe estar en sitio y qué decisiones deben cerrarse antes de la siguiente junta.

Tres preguntas ordenan cualquier revisión mensual. ¿Cambió la ruta crítica desde el corte anterior, y por qué? ¿Qué actividades consumieron holgura sin haberse atrasado formalmente? ¿Qué liberación de ingeniería, permiso o suministro está a punto de convertirse en el nuevo cuello de botella? Un reporte que responde eso vale más que cien páginas de barras.

El impacto en tiempo de un cambio se analiza antes de autorizarlo

La práctica recomendada 52R-06 de AACE International describe el análisis prospectivo de impacto en tiempo: un método para evaluar, antes de ejecutar un cambio, cómo afectaría al programa vigente. La lógica es directa: se toma el programa actualizado a la fecha, se inserta la actividad o el conjunto de actividades que introduce el cambio, se recalcula la red y se observa el efecto sobre la fecha de terminación.

La utilidad práctica es que convierte una discusión de percepciones en una decisión con base técnica. Un cambio puede resultar caro en dinero y neutro en tiempo, o barato y devastador para el programa, y esas dos cosas no se intuyen: se calculan. Autorizar cambios sin ese análisis es la forma más segura de acumular desplazamientos que nadie asignó a ninguna causa y que al final se discuten como responsabilidad general del contratista.

La fecha también decide entre construir y rentar

Para muchas empresas, el plazo no es una variable de ejecución sino el criterio central de la decisión inmobiliaria. Una nave existente puede ocuparse antes, pero obliga a adaptar la operación al edificio y suele requerir adecuaciones cuyo alcance solo se conoce después de una due diligence técnica seria. Una nave construida a la medida bajo el esquema Build-to-Suit responde al proceso real, pero el reloj empieza en la definición y no en la firma.

La comparación honesta no es entre "rentar ya" y "construir después". Es entre la fecha en la que cada opción permite producir de forma estable, con el layout validado y los sistemas probados. Una nave ocupada antes de tiempo, con adecuaciones pendientes y sin capacidad confirmada, puede costar más plazo del que ahorró.

Ruta práctica para armar el programa

Definir la fecha objetivo del negocio y qué significa exactamente: ocupación, primer producto o producción estable.
Evaluar con honestidad la madurez de la definición técnica y elegir la clase de programa que corresponde a ese nivel.
Identificar los frentes que no controla el constructor: definición, autorizaciones, acometidas y obras del parque.
Listar los suministros de fabricación larga y fijar el hito de liberación de ingeniería de cada uno.
Construir la red con lógica explícita, sin restricciones duras que impidan recalcular.
Reflejar estacionalidad, calendario laboral y rendimientos realistas por frente.
Hacer explícita la holgura, decidir a quién pertenece y cómo se documenta su uso.
Aprobar la línea base y establecer periodicidad de corte, formato de reporte y ventana de anticipación.
Analizar el impacto en tiempo de cada cambio antes de autorizarlo.
Programar desde el inicio las pruebas y la entrega técnica, no como un remanente al final.

Errores comunes

Comprometer fecha antes de cerrar la definición. El plazo se estima con la misma madurez que el costo.
Programar solo la obra física. Deja fuera los frentes donde el propietario sí puede actuar.
Confundir el reporte con el programa. Una barra resumen no calcula ruta crítica.
Fijar fechas a mano. Un programa con restricciones duras deja de reaccionar y de avisar.
Tratar las compras como trámite administrativo. La liberación de ingeniería es una actividad del programa.
Traslapar sin nombrar el riesgo. El tiempo ganado reaparece como retrabajo y orden de cambio.
Dejar las pruebas para el final. La etapa de arranque necesita programa propio.

Un programa de obra no sirve para prometer una fecha: sirve para saber, en cada momento, qué decisión pendiente la está moviendo. Cuando el propietario entiende cuáles cadenas dependen de él, la conversación deja de ser un reclamo mensual sobre el avance y se convierte en una lista corta de decisiones que todavía puede tomar a tiempo. Esa disciplina condiciona el costo real del proyecto y determina si una futura ampliación se planea con información confiable o se improvisa.

Si estás definiendo la fecha objetivo de un proyecto, puedes revisar el programa preliminar con el equipo de Grupo COB. Compartir la madurez actual de la definición, los suministros críticos y las restricciones del sitio permite ubicar el plazo en un rango sostenible en lugar de un número aislado.

Referencias técnicas consultadas

AACE International: práctica recomendada 27R-03, Schedule Classification System (rev. 12 de noviembre de 2010).
AACE International: práctica recomendada 37R-06, Schedule Levels of Detail – As Applied in Engineering, Procurement, and Construction (rev. 20 de marzo de 2010).
AACE International: práctica recomendada 52R-06, Prospective Time Impact Analysis – As Applied in Construction (rev. 4 de mayo de 2017).

Estas referencias se consultaron como guías de proceso y no sustituyen los criterios contractuales de cada obra. Los plazos, secuencias y requisitos aplicables a un proyecto concreto deben definirse con los especialistas, proveedores y autoridades correspondientes.