Secuenciar, dimensionar y asignar cuadrillas a 100–500 tareas de un proyecto de construcción — minimizar la duración bajo restricciones de precedencia y recursos (en la literatura: RCPSP).
En pocas palabras
¿Te suena?
- El jefe de obra llama a cada encargado a las 7 de la mañana para repartir tarea — la ronda dura 30–60 minutos al día
- Llevas 3–6 proyectos en paralelo y a fin de mes el reparto de cuadrillas se vuelve pelea — '¿en qué obra estoy esta semana?' es discusión habitual
- No puedes precisar por qué un proyecto se ha desviado 2–4 semanas; cada parte culpa a una causa distinta
- El reparto de grúa, bomba de hormigón o andamios provoca disputas 'espera que acabe' 1–2 veces por semana
- Cuando un proveedor se retrasa, no puedes mostrar numéricamente qué tareas posteriores se mueven — todo es intuición
- Una mala meteorología y el 'cómo rehago el plan de hoy' se come media jornada
- Le has dicho al cliente 'entregamos el día X' y vas con 2–3 meses de retraso; aparece penalización contractual o pérdida de cliente
Por qué importa
Cómo se resuelve
Profundidad técnica
Cómo se resuelve
Profundidad técnicaEn una frase: Céntrate en la ruta crítica — esas son las tareas cuyo retraso retrasa todo el proyecto. Las tareas fuera de la ruta crítica tienen holgura: pueden moverse uno o dos días sin afectar la fecha de fin. Asigna primero la única grúa o la única cuadrilla de ferralla a la ruta crítica.
Lo que el software realmente hace es esto: el reparto diario que tu jefe de obra dibuja a mano durante semanas, lo expone para 200–500 tareas en segundos y lo recalcula cada vez que algo se mueve o cambia. Tres etapas:
1. Describe el proyecto. Cada tarea — nombre, duración estimada, qué tareas debe seguir (precedencia), qué cuadrillas y máquinas usa, qué materiales necesita. Inventario de cuadrillas (cuántas de encofrado, ferralla, hormigón, dónde está cada una hoy), lista de máquinas (grúa, bomba, retro), calendario (festivos, previsión de meteorología). Los datos llegan del sistema de oferta/medición automáticamente o se introducen una vez en una tabla limpia.
2. Calcula el cronograma más corto factible. El software no prueba todas las secuencias posibles — para 200 tareas es matemáticamente imposible. Usa algoritmos de scheduling de investigación operativa (disciplina que usa matemáticas y computación para resolver decisiones de negocio) para tomar atajos inteligentes: qué tarea empieza qué día, con qué cuadrilla y máquina. El resultado llega en minutos — todas las precedencias respetadas, sin conflictos de recursos, duración mínima. La ruta crítica (la cadena que marca la fecha de fin) se muestra explícita; cualquier desplazamiento en ella mueve el proyecto entero.
3. Llega al campo. El plan aparece en la app del encargado como lista diaria de tareas: ‘07:30 encofrado de la 5ª planta, 10:00 hormigonado del Bloque A, 14:00 atado de ferralla del Bloque B’. Cuando un proveedor se retrasa o llega la lluvia, el software recalcula sólo la zona afectada y un nuevo cronograma llega en 15–30 segundos. Con varios proyectos, las asignaciones de cuadrilla y máquina se optimizan entre proyectos dinámicamente.
No sustituye al criterio del jefe de obra; piénsalo como una calculadora que escala el plan de 20 tareas que tiene en la cabeza hasta 500 y calcula la cadena de propagación de retrasos. La decisión sigue siendo tuya, pero el impacto numérico de cada retraso es visible.
Alternativas
Hoja de cálculo + cabeza del jefe de obra
GratisGratis
Para quién: 1–2 proyectos, 30–50 tareas, cuadrilla pequeña
- + Coste cero
- + Flexible — ajuste a pie de obra fácil
- + Sin decisión de inversión
- − Los conflictos de precedencia y recursos se escapan con 100+ tareas
- − La ruta crítica es invisible — no sabes qué desplazamiento mueve la entrega
- − El reparto de cuadrillas entre proyectos no se resuelve a ojo
- − La fecha prometida no tiene base matemática
Software local de gestión de proyectos de construcción
Empresarial1.500–6.000 EUR de implantación + 250–800 EUR/mes (precios pyme regional)
Para quién: 3–10 proyectos, 100–300 tareas por proyecto, estructura de cuadrillas estable
- + Interfaz y soporte en español
- + Certificaciones, mediciones y módulos financieros integrados
- + Foto de obra y parte diario en el flujo
- − El motor de scheduling suele quedarse en dibujo Gantt — sin verdadera optimización RCPSP
- − La ruta crítica existe pero la replanificación automática bajo restricciones de recursos es débil
- − El reparto de recursos entre proyectos está limitado
Software internacional especializado de gestión de proyectos
Empresarial30–100 EUR/usuario/mes en suscripción o 25.000–200.000 EUR/año de licencia
Para quién: Constructora grande, autopistas/ferroviario, 500+ tareas por proyecto complejo
- + Maduro: optimización RCPSP, gestión multiproyecto de recursos, análisis de riesgo totalmente soportados
- + Ruta crítica y Earned Value Management estándar
- + Algoritmos endurecidos en años
- − Coste alto de licencia y consultoría
- − Implantación 3–6 meses
- − Soporte en español limitado; curva de aprendizaje pronunciada
Desarrollo propio sobre solver de código abierto
Código abiertoLicencia gratis; 10–20 semanas de desarrollo interno o 60.000–250.000 EUR de consultoría
Para quién: Constructora grande o empresa que repite el mismo tipo de proyecto
- + Sin coste de licencia
- + Totalmente personalizable a tu estructura de partidas y estándares
- + Cloud o servidor propio
- − Capacidad técnica interna obligatoria
- − El mantenimiento es trabajo real
- − La experiencia en solvers RCPSP es escasa; montar el equipo es caro
Recomendación
Pregunta en la reunión
- ¿El motor de scheduling se basa en un verdadero algoritmo RCPSP o sólo en dibujo Gantt? ¿Qué tan cerca del óptimo para 200 tareas y 10 recursos?
- ¿Se soporta compartir cuadrillas y máquinas entre varios proyectos? ¿Con qué lógica decide el sistema a qué obra se mueve una cuadrilla?
- ¿La ruta crítica se calcula bajo restricciones de recursos (ruta crítica realmente resource-constrained) o sólo PERT-CPM clásico?
- Cuando una tarea se retrasa o llega meteorología adversa, ¿en cuánto se recalcula el plan? ¿Cómo llega al campo — app, SMS, teléfono?
- ¿Cómo se integra con certificaciones, mediciones y sistema financiero? ¿Las partidas entran automáticamente o de forma manual?
- ¿El análisis de riesgo (por ejemplo 'si el proveedor X se retrasa, cuánto se retrasa el proyecto') se hace con simulación Monte Carlo o con supuestos simples?
- ¿Cómo estructuráis el piloto — cuántos proyectos, cuántas semanas, qué umbral de éxito?
- Si dejamos de trabajar con vosotros, ¿cómo recuperamos el histórico de tareas, certificaciones y plan? ¿Hay export en formato estándar?
Detalles técnicos
Nota editorial
En obra, este problema se conoce como ’el plan de trabajo’, ’el plan de avance’ o ’el programa de obra’. El nombre académico es Resource-Constrained Project Scheduling Problem (RCPSP). Empezó con PERT/CPM en los años 60 y maduró en RCPSP cuando se añadieron restricciones de cuadrilla y máquina — uno de los campos más antiguos de la investigación operativa. Sin ese vocabulario, no podrás distinguir en una demo si el ‘módulo de gestión de proyecto’ que te venden es un verdadero motor de scheduling con restricciones de recursos o sólo un calendario que dibuja Gantts.
El punto que más se pasa por alto en este segmento: muchos productos anuncian ‘seguimiento de proyecto’ pero por debajo sólo hacen visualización Gantt + arrastrar y soltar — es decir, tú planificas y el software sólo dibuja. Un solver RCPSP real, cuando le dices ’esta tarea dura 3 días, hay una cuadrilla de encofrado, la grúa está libre tal día’, calcula matemáticamente la duración más corta del proyecto. En cualquier demo, pide al proveedor que recorra un ejemplo de 30 tareas con 4 cuadrillas y una restricción de grúa, y que explique cómo trabaja el solver y dónde está la ruta crítica.
Plan paso a paso para una pyme
Etapa 1 — Primero medir, después planificar. Durante al menos 2 proyectos registra cuatro cosas:
- Duración estimada vs. real por partida (lo que dijiste vs. lo que tardó)
- Causa del retraso (proveedor, meteorología, falta de cuadrilla, error de plan)
- Horas paradas de cuadrillas y máquinas
- Diferencia final de margen del proyecto respecto a presupuesto, en porcentaje
Sin esta línea base no puedes saber qué software entregará qué resultado.
Etapa 2 — Construye la tabla de partidas y duraciones. Un bloque residencial típico tiene 80–150 partidas distintas (encofrado m², ferralla toneladas, hormigón m³, instalaciones metros, acabados m²). Revisa la duración estimada y la varianza observada. Este catálogo es tu capital de conocimiento, y cualquier proveedor serio lo pedirá primero. Los datos de 3–5 proyectos previos valen oro.
Etapa 3 — Piloto. Arranca con un único proyecto de tamaño medio durante toda su duración (típicamente 6–12 meses). Define el criterio de éxito por escrito, antes del piloto: por ejemplo, ‘desviación de fecha de entrega menor a una semana y horas de cuadrilla paradas abajo 25 %’. Si no se alcanza, el piloto termina — guarda ese derecho de salida en el contrato.
Etapa 4 — Despliegue. Si el piloto sale bien, escala a todos los proyectos activos en 3–6 meses. La formación del jefe de obra y los encargados lleva 2–3 semanas; la integración con proveedores 4–8 semanas si se persigue.
Riesgos — qué puede salir mal
- Estimaciones de duración malas. Si las estimaciones están desviadas, ni el mejor plan se sostiene en la práctica. Antes del piloto, construye una tabla ’estimado-vs-real’ a partir de proyectos pasados; un buen solver RCPSP puede trabajar con duraciones probabilísticas.
- Resistencia en obra. ‘Que un ordenador no me diga qué hacer’ es una reacción común. En el piloto, repasa los resultados con el encargado; el software debe mostrar de forma transparente qué regla aplicó y por qué una tarea está en la ruta crítica.
- Dificultad de integración con proveedores. Cuando los materiales no llegan, el cronograma pierde sentido. El software debe poder absorber los compromisos del proveedor en tiempo real; si no, crece la carga de actualización manual.
- Dependencia de un único proveedor. Un software que guarda certificaciones, histórico de tareas y datos de plan en formato propio dificulta cambiar más adelante. Incluye una cláusula: ‘Podemos exportar nuestros datos en formatos abiertos estándar (CSV, XML o similar) cuando lo solicitemos.’
Lección relacionada (se enlazará al publicarse): ‘Una constructora residencial mediana abandonó su software de gestión de proyectos al mes 11 — qué pasaron por alto.’
Visión técnica del método de solución
Esta sección reúne lo que necesitarás al hablar con un equipo de software o un consultor. No es lo que el jefe de obra ve en su pantalla diaria — es el motor detrás del telón.
Enfoques principales para RCPSP:
| Enfoque | Tamaño típico | Tiempo de solución | ¿Garantiza el óptimo? |
|---|---|---|---|
| CPM (método de la ruta crítica) | 100–1.000 tareas, sin límite de recursos | Segundos | Sí (problema sin restricciones de recursos) |
| PERT | 100–500 tareas, duraciones inciertas | Segundos | Esperanza probabilística |
| MIP (programación lineal entera mixta) | 30–100 tareas, con restricciones de recursos | 1–30 minutos | Sí, con tiempo suficiente |
| Ramificación y acotación (especializada) | 50–200 tareas, con restricciones de recursos | 1–15 minutos | Sí (escala media) |
| Metaheurísticas (GA, SA, tabú) | 200–2.000 tareas | 30 segundos – 5 minutos | No (cuasi-óptimo) |
Regla práctica: con menos de 100 tareas puede bastar el CPM clásico; pero con restricciones de recursos fuertes, una metaheurística da una respuesta más realista. Con 200+ tareas, donde MIP se vuelve intratable, metaheurística más simulación es la combinación estándar.
La elección de la función objetivo cambia la forma de la solución:
- Duración total del proyecto (makespan): ‘Termina antes’ — encaja con contratos con cláusulas penales
- Equilibrio de uso de recursos: ‘Mis cuadrillas trabajan’ — encaja con empresas con coste de mano de obra alto
- Flujo de caja (optimización de Earned Value): ‘Pagos del cliente a tiempo’ — encaja con empresas con tesorería ajustada
- Mezcla penalización por retraso + bonus por adelanto: ‘Beneficio neto máximo’ — encaja con proyectos con cláusula de bonus
La mayoría de despliegues reales usan una mezcla ponderada de los cuatro.
Referencias académicas
Listadas en el bloque sources de esta página. RCPSP ha sido uno de los campos más activos de la investigación operativa desde los años 60; el trabajo actual se centra en planificación multiproyecto, planificación bajo incertidumbre y recálculo en tiempo real. INFORMS Interfaces y el archivo de la European Journal of Operational Research recogen casos de despliegues en construcción real.
Fuentes
- Brucker, P., Drexl, A., Möhring, R., Neumann, K. y Pesch, E. (1999). Resource-constrained project scheduling: Notation, classification, models, and methods. European Journal of Operational Research, vol. 112 — el artículo de clasificación canónica del campo RCPSP.
- Hartmann, S. y Briskorn, D. (2010). A survey of variants and extensions of the resource-constrained project scheduling problem. European Journal of Operational Research, vol. 207 — la revisión moderna exhaustiva.
- Demeulemeester, E. L. y Herroelen, W. S. (2002). Project Scheduling: A Research Handbook. Kluwer Academic Publishers. Manual académico de referencia.
- INFORMS Interfaces — casos de aplicaciones de investigación operativa en construcción y gestión de proyectos. informs.org/Publications/Interfaces
Glosario
- RCPSP
- Secuenciar cientos de tareas de proyecto, dimensionar duraciones y asignar cuadrillas bajo restricciones de precedencia y recursos.
- Ruta Crítica
- La cadena más larga de tareas dependientes del inicio al final del proyecto — la cadena que fija la fecha de entrega.
- MIP
- Modelo de optimización donde parte de las variables de decisión deben ser números enteros (p. ej. número de camiones o de turnos).