Un caso real
El puente que ya estaba bien planificado
Auditamos el cronograma del puente Tappan Zee, sobre el río Hudson, con los datos que facilitó su propio promotor. El plazo de su planificador es óptimo, se puede demostrar, y su plan cumple todo lo que pide su fichero. Lo que el fichero no dice es por qué el dragado se para tres veces.
Los bancos de pruebas académicos no enseñan la mitad de lo que hace falta saber. Un problema de laboratorio viene limpio. Un fichero de obra viene con dos relojes distintos, con esperas de diez meses que nadie explica y con una columna de duración que no dice lo mismo que las fechas de su propia fila. Todo lo que sigue lo aprendimos ahí.
El fichero
Diecinueve actividades no suena a mucho, y ese es justo el punto: la dificultad de un plan no está en cuántas filas tiene. Este viene de una ficha pública de la biblioteca DSLIB, el banco de proyectos empresariales reales que mantiene el grupo de Mario Vanhoucke en la Universidad de Gante, y sus datos los facilitó directamente el propietario de la obra. El nombre y el código de ficha son los que la propia biblioteca publica en su índice. El fichero es suyo y no lo redistribuimos, así que lo que sigue son medidas nuestras sobre un dato que cualquiera puede pedirles y comprobar.
Uno: su plazo es el mejor posible, y se puede demostrar
Con su misma fecha de arranque, su mismo calendario, sus mismos veinte topes de maquinaria, sus mismas precedencias contractuales y sus tres ventanas de dragado ancladas donde ellos las pusieron, el motor devuelve 1.289 días con cota inferior 1.289. Los dos números coinciden, y eso significa que no existe ningún plan que termine antes.
Su planificador acertó de lleno con el plazo, y su plan no se sale de ningún tope de maquinaria ni rompe ninguna precedencia. El informe dice las dos cosas.
Dos: el número que no publicamos
Si a un motor se le suelta este fichero tal cual, sin anclar nada, se come las tres esperas del dragado, que la lógica del fichero no explica. Si esas esperas son una veda del río, el plazo que devuelve no se puede ejecutar. Por eso no publicamos ningún ahorro sobre este fichero.
| Actividad | Espera | Arranca |
|---|---|---|
| Dragado I | 214 días | 4 de agosto de 2014 |
| Dragado II | 205 días | 3 de agosto de 2015 |
| Dragado III | 205 días | 1 de agosto de 2016 |
Las tres arrancan el primer día hábil de agosto. Eso tiene toda la pinta de una ventana medioambiental de dragado, que el Hudson tiene por la migración de los peces: una restricción legal que el fichero no contiene porque su planificador la metió a mano, con fechas, en vez de como regla.
La Autoridad de la Autopista del Estado de Nueva York, promotora de la obra, publica las medidas ambientales que se tomaron en el río durante la construcción, entre ellas las que protegen al esturión atlántico y los periodos en los que no se podía trabajar dentro del agua.
Si son una veda, un motor que se come esas esperas produce un plan ilegal. El nuestro las detecta, las mide y pregunta: su fichero dice que el dragado espera diez meses tres veces y no dice por qué. Si es la ventana de dragado, se respeta y su plazo es óptimo. Si no lo es, ahí hay medio año largo.
Esto no es un caso raro
La espera que aquí se llama ventana de dragado tiene nombre propio en el oficio y aparece en todas partes. Lo comprobamos en tres sitios que no se conocen entre sí:
- Un contrato de carretera del Departamento de Transporte de Virginia enumera ocho calendarios, cinco de ellos vedas con fechas exactas: parón invernal del aglomerado, capa de rodadura, tableros de puente, y dos paradas por fauna protegida (aves y murciélagos).
- Un expediente de Adif para la autopista ferroviaria Algeciras-Zaragoza usa la misma idea con otro nombre: la ventana de vía.
- Y en un corpus de setenta cronogramas reales de Primavera P6, treinta y siete usan más de un calendario en sus actividades, y uno llega a definir ciento ochenta y cuatro.
Lo que enseñan los ficheros reales y no enseña ningún banco de pruebas
Además de este puente hemos pasado por el lector setenta cronogramas reales de Primavera P6, con 147.165 actividades y 355.856 dependencias entre todos. Ese recuento sale de las tablas de los setenta ficheros, también de los cuatro que el lector no acepta. Las 120.679 tareas de nuestra medida de tiempos son otro conjunto: las de los ficheros que sí se leen, de este banco y de DSLIB. Esto es lo que salió, y ninguna de estas cosas aparece en un problema de laboratorio.
Los dos relojes
Una duración de ocho horas y un plazo de ocho horas no son lo mismo si la jornada dura ocho. Teníamos las duraciones contadas en horas de trabajo y el plan del cliente en horas de reloj, y nadie los comparaba. El resultado era un ahorro inflado, y siempre en el sentido que nos favorecía.
Había proyectos que, según el informe, terminaban mucho después de lo que sumaban todas sus duraciones juntas, y el informe salía tan tranquilo. Hoy hay un solo reloj.
La fecha de fin la pone el cliente
Reconstruíamos el fin de cada trabajo sumando su duración al inicio, así que cualquier desajuste entre su columna de duración y sus fechas se convertía en una acusación contra el cliente por algo que su propio fichero desmiente.
Ahora se lee el fin que él escribe, y solo se calcula cuando su fichero no lo trae.
Lo que no sabemos comprobar, se dice
En ficheros de grano fino, la duración escrita y las dos fechas de la misma fila no siempre cuentan lo mismo, y eso hace que el orden no se pueda comprobar sin acusar en falso. Lo intentamos de cuatro maneras distintas y todas seguían acusando en falso.
Así que en esos ficheros esa comprobación no se publica, y el informe lo dice. Las fechas obligatorias y la maquinaria se siguen comprobando igual. De los 228 proyectos de DSLIB que se leen, 206 tienen veredicto, en 22 decimos que no hemos podido mirar el orden y en ninguno acusamos de un orden que no hemos comprobado (medido el 9 de octubre de 2026 sobre DSLIB 3.4).
Por qué se usa la duración escrita y no el hueco entre fechas
Propusimos usar el intervalo entre las dos fechas en vez de la duración escrita. Quitaba falsos positivos, así que parecía buena idea.
Al medirla sobre los 126.609 trabajos sin empezar de los setenta cronogramas (medido otra vez el 3 de octubre de 2026) resultó que infla las duraciones: el intervalo mide más en el 57,8 % de los casos, con una razón media de 1,06 y una mediana de 1,08, o sea que habría alargado nuestros planes entre un 6 y un 8 %. Se cambiaba una distorsión por otra, y la nueva iba dentro del plan que le entregamos al cliente. Se descartó.
Navidad
Las últimas acusaciones falsas que quedaban eran festivos: un trabajo que iba del 17 al 30 de diciembre, con el 25 contado como un martes cualquiera.
Ahora el calendario laboral español viaja dentro del producto, congelado y comprobado contra el BOE: 19 territorios de 19 clavados, cero diferencias, 458 fechas de 2026 y 2027, y los 165 municipios de Madrid que publicaron sus fiestas locales.
Antes probamos dos bibliotecas conocidas. Una sirve para generar el dato fuera del producto, y lo que genera se congela y se compara con el BOE. La otra se descartó: no cubría Ceuta ni Melilla, ni pasaba al lunes los festivos que caen en domingo.
El caso del puente sale de un fichero de diecinueve líneas. Con el tuyo, comprobar mira el orden, la capacidad y las fechas obligatorias. Las esperas del dragado son periodos vedados, y esos los miramos por correo.