Definición y origen
El camino crítico (Critical Path Method, CPM) es la secuencia más larga de tareas dependientes dentro de un proyecto. Su duración fija el plazo mínimo posible: cualquier retraso en una tarea perteneciente a esa secuencia retrasa la fecha final del proyecto en la misma magnitud. Las tareas fuera del camino crítico disponen de holgura (float) y pueden retrasarse, dentro de ese margen, sin afectar al plazo total.
El método fue desarrollado en 1957 por Morgan R. Walker (DuPont) y James E. Kelley (Remington Rand) para planificar paradas de mantenimiento de plantas químicas. Casi en paralelo, la US Navy desarrollaba PERT para el programa Polaris. Diferencias entre los tres enfoques habituales:
- CPM: duraciones determinísticas. Un valor por tarea. Apropiado con histórico fiable.
- PERT: duraciones probabilísticas (optimista, más probable, pesimista, ponderadas). Para proyectos sin precedentes.
- Critical Chain Method (CCM): variante de Goldratt con buffers compartidos y recursos limitados como restricción. CPM clásico asume recursos ilimitados, su mayor debilidad.
Conceptos clave: cuatro fechas por tarea — ES (Early Start), EF (Early Finish), LS (Late Start), LF (Late Finish) — y dos holguras: total float (retraso admisible sin afectar al proyecto) y free float (sin afectar a la siguiente tarea). Una tarea es crítica cuando slack = 0 (ES=LS, EF=LF).
Cálculo paso a paso
El cálculo se hace en dos pasadas sobre la red de actividades:
- Pasada hacia adelante (forward pass): se recorre la red desde el inicio. Para cada tarea, ES = máximo de los EF de sus predecesoras, y EF = ES + duración. Esto da la fecha más temprana en la que cada tarea puede empezar y acabar.
- Pasada hacia atrás (backward pass): se recorre la red desde el final, fijando LF de la última tarea = EF de la última tarea. Para cada tarea, LF = mínimo de los LS de sus sucesoras, y LS = LF − duración.
- Slack = LS − ES = LF − EF. Las tareas con slack = 0 forman el camino crítico.
Ejemplo. Proyecto con cinco tareas:
| Tarea | Duración (días) | Predecesoras |
|---|---|---|
| A | 3 | — |
| B | 5 | A |
| C | 2 | A |
| D | 4 | B |
| E | 3 | C, D |
Pasada adelante: A (0-3), B (3-8), C (3-5), D (8-12), E (12-15). Duración total = 15 días.
Pasada atrás desde E (LF=15): E LS=12, D LS=8, C LS=10, B LS=3, A LS=0.
Slack: A=0, B=0, C=5, D=0, E=0. Camino crítico = A-B-D-E (15 días). La tarea C tiene 5 días de holgura: puede retrasarse hasta 5 días sin afectar al plazo. Si C ocupa el mismo recurso que B y obligas a secuenciarlas, el camino crítico cambia y aparece restricción de recurso — territorio CCM.
Cómo se aplica en Business Central
Business Central nativo no calcula camino crítico. El módulo Jobs estándar maneja tareas, presupuesto y registro de horas, pero no modela dependencias ni holguras. Es contable, no operativo. Para proyectos con secuencia compleja (implantaciones, ingeniería, obras a medida) eso obliga a planificar en MS Project o Excel y reconciliar manualmente — fuente conocida de divergencia entre lo planificado y lo facturado.
dvplanner y dvproject cubren esa carencia sobre BC:
- Dependencias entre tareas (FS, SS, FF, SF) con lag/lead en días u horas.
- Cálculo automático del camino crítico al guardar. ES/EF/LS/LF se recalculan en cada cambio y las tareas críticas se resaltan en el Gantt.
- Recálculo automático ante cambios de scope sin intervención manual.
- Alertas operativas cuando una tarea crítica acumula desviación (partes de horas o fecha de inicio real sobre LS).
- Integración con recursos (capacidad, calendarios, festivos): avisa cuando una tarea crítica está sobre un recurso saturado, corrigiendo el supuesto de “recursos ilimitados”.
- Trazabilidad presupuesto/real vinculada a la red. Si una tarea crítica se desvía, ves el impacto en margen del proyecto en la misma vista.
Errores frecuentes
- Ignorar dependencias indirectas. La ruta real puede depender también de hardware, permisos o un proveedor externo. Si no están modeladas, la red miente.
- Tratar los recursos como ilimitados. Si dos tareas críticas comparten al mismo ingeniero, el plazo real es mayor que el calculado. Hay que activar nivelación de recursos o pasar a CCM.
- No recalcular tras cambios de scope. Una tarea nueva o un cambio de duración puede mover el camino crítico a otra rama. Seguir vigilando la rama antigua es ceguera estructural.
- Confundir tarea larga con tarea crítica. Una tarea de 30 días con 20 de holgura no es crítica. Una de 2 días con holgura cero, sí. La criticidad es relacional, no absoluta.
- No actualizar duraciones con avance real. Sin partes de horas o porcentaje de avance, el camino crítico calculado deja de reflejar la realidad a las dos semanas.
- Olvidar la integración con la WBS. El camino crítico se calcula sobre las tareas hoja del WBS. Si la descomposición es gruesa, hay dependencias internas que el CPM no ve y aparecen como retrasos “sorpresa”.