Captulo 10

Gestin de Cadena Crtica / Buffer

Resumen de la programacin de proyectos con recursos limitados es a menudo una

tarea compleja debido a la presencia de las dependencias entre las actividades y la
limitada disponibilidad de recursos renovables. Los dos captulos anteriores se haba
dado una amplia visin general de las diferentes tcnicas para la construccin de una
agenda tan, teniendo diversos objetivos de programacin en cuenta. En este captulo
se extiende este enfoque de planificacin de recursos limitados a un horario ms
flexible lnea de base con el fin de protegerse contra eventos inesperados. La Cadena
Crtica / Enfoque de gestin Buffer asume la construccin de una agenda viable de
recursos como se discute en los captulos anteriores, pero incorpora un cierto grado
de flexibilidad en los tiempos de actividad de inicio con el fin de controlar de forma
sencilla fechas divergentes y responder rpidamente mediante la adopcin de
medidas correctivas para mantener todo el proyecto a tiempo.

10.1 Introduccin
Ha habido un nmero significativo de proyectos internacionales de alto perfil en su
defecto para ser entregados a tiempo y dentro del presupuesto. El proyecto de tnel
del canal para proporcionar una conexin submarina entre Francia y el Reino Unido
es probablemente el ejemplo ms conocido, pero, sin duda, la mayora de los
lectores tambin se puede pensar en volver de proyectos de menor escala ms cerca
de su ambiente de trabajo que fracas estrepitosamente. Una serie de caractersticas
indeseables estn asociados con muchos proyectos en su defecto: excesos de
presupuesto, especificaciones del proyecto Mised compro-, y se perdi hitos. En
consecuencia, las tres dimensiones bsicas del xito del proyecto (tiempo, costo y
calidad) son a menudo en peligro. En su exitosa novela de negocios, "Cadena
Crtica", razon Goldratt ese momento era ms importante que el costo de los
directores de proyectos (Goldratt 1997). El apoyo a esta idea se puede encontrar en
numerosos artculos. A modo de ejemplo, un estudio de McKinsey inform en
Business Week (Port et al., 1990) que un proyecto que est en el tiempo pero con el
presupuesto en un 50% ganar 4% menos que un proyecto dentro del presupuesto.
Por el contrario, el estudio predijo que un proyecto que est en el presupuesto, pero
6 meses de retraso ganarn 33% menos que un proyecto en el tiempo. Ambas
fuentes apoyan la importancia estratgica de reducir el tiempo del proyecto.

La calidad o el alcance del producto del proyecto (que cumple con las
especificaciones requeridas) es en gran medida del sector y del entorno y no sern
estudiados por separado en este captulo. Como es habitual, la atencin se centra en
la perspectiva de la planificacin dinmica y ms precisamente en la incapacidad de
gestin de proyectos que se adhieren a la programacin inicialmente propuesto.
excesos de presupuesto son claramente visibles y se puede atribuir. A menudo son
una eleccin explcita de gestin para acelerar el proyecto (horas extras, adquisicin
de recursos adicionales,...) O ms bien las consecuencias implcitas del proyecto
tomando ms tiempo de lo previsto inicialmente, lo que refleja las consecuencias

financieras de los recursos que ocupan ms largos que los previstos . Existen varias
otras fuentes para excesos de presupuesto,
p.ej. la necesidad de adquirir nuevos equipos porque el presente resulta ser
insuficiente para las necesidades del proyecto, pero estos riesgos son o bien
completamente imprevisible, o que son predecibles y por lo tanto deben ser incluidos
en el desarrollo del presupuesto inicial. Tales caractersticas del proyecto son a
menudo fuera del control de la gestin, o de lo contrario slo necesitan una atencin
cuidadosa, pero no un montn de accin de gestin.
A diferencia de estos acontecimientos imprevisibles, el tema principal de este
captulo trata de la presencia de variabilidad en el cronograma del proyecto que se
podra anticipar en cierta medida. En este captulo se realiza una vista similar a la
variacin del proyecto en que se tome en el Cap. 5, sino que tambin lleva los
recursos renovables en cuenta. En consecuencia, los proyectos necesitan ser
programado bajo alta complejidad y en la presencia de incertidumbre y, por tanto,
pueden clasificarse en el cuarto cuadrante de la figura. 1.4. A lo largo del captulo, se
asume implcitamente que los osos lector en mente en todo momento que las
acciones para influyen en el rendimiento del cronograma del proyecto a menudo
arriesgarse a tener una repercusin directa en el presupuesto, as como en la calidad
del proyecto. Es sorprendente ver que, dada la gran cantidad de proyectos que han
terminado la tarde durante las ltimas dcadas, la gestin sigue sin citar los plazos
del proyecto precisos. Esto es problemtico, debido a que prcticamente todas las
organizaciones utilizan sus planes de proyecto no slo como herramientas para
gestionar los proyectos, sino tambin como una base sobre la cual hacer
compromisos de entrega a los clientes. Por lo tanto, un objetivo de vital importancia
en los planes del proyecto y los mtodos de programacin eficaces es permitir a las
organizaciones para estimar las fechas de realizacin de los proyectos
correspondientes. Esto es particularmente cierto para las organizaciones que prestan
servicios a clientes industriales, debido a este tipo de clientes con regularidad tienen
sus propios proyectos, que requieren las salidas que las organizaciones de
proveedores se comprometen a entregar.
El contorno de este captulo se puede resumir como sigue. Seccin 10.2 da una
visin general de las diferentes fuentes de incertidumbre en la gestin de proyectos
y la programacin. En la Seccin. 10.3, los principales componentes de la Cadena
Crtica / Buffer Management (CC / BM) tcnica de programacin est resaltada en
detalle. Seccin 10.4 da un ejemplo ilustrativo ficticio usando un enfoque / BM de
seis pasos CC. Seccin 10.5 ilustra cmo una llamada programacin del proyecto
tamponada CC / BM se puede utilizar durante la fase de ejecucin del proyecto para
monitorear y controlar el desempeo del proyecto y para activar acciones correctivas
en caso de que la fecha lmite del proyecto est en peligro. Seccin 10.6 ofrece un
resumen de las principales crticas sobre el enfoque CC / BM, destacando los mritos
claros y mostrando debilidades y peligros potenciales. Seccin 10.7 extrae
conclusiones generales de los captulos.

10.2 Fuentes de Incertidumbre

En un entorno de fabricacin, mquinas rompen regularmente hacia abajo y
necesitan ser reparados. Este es un proceso aleatorio que se pueden observar y para
los cuales se pueden estimar los parmetros, de tal manera que una imagen

bastante precisa de la disponibilidad de esta mquina se puede obtener. En la

mayora de los lugares de fabricacin, tales como entornos de talleres de trabajo,
rutas de trabajo y utilizaciones de la mquina son bastante predecible. Puesto que la
operacin diaria es una en la que un cierto grado de reina de rutina, el gerente a
cargo puede invocar la lgica y el clculo para estimar los tiempos promedio de
plomo y la carga media del sistema. Un proyecto de rutina no es como un trabajo
enviado a un taller de trabajo, pero uno que es lo suficientemente importante como
para merecer ser administrados por separado. Como consecuencia, los promedios no
son tanto importante para un gerente de proyecto como es la variabilidad. Por
desgracia, debido a la naturaleza nica de cada proyecto, las estimaciones basadas
en la experiencia previa son a menudo poco fiables, si la experiencia cada vez
anterior ya se ha acumulado (comparar las actividades ms rutinarias implicadas en
la construccin de un edificio con el esfuerzo de programacin requerido para un
proyecto de I + D ). Adems de eso, las personas a planificar y ejecutar proyectos, no
las mquinas o programas informticos. Por lo tanto, una idea de la naturaleza
humana es crucial en la gestin de proyectos. Cada buen gestor de proyectos est
equipado con un conjunto de herramientas de habilidades de gestin de recursos
humanos.
La entrada necesaria para obtener un horario determinista es una sola estimacin de
la duracin de cada actividad del proyecto. Sin embargo, esta duracin es una
variable estocstica, que se supone que es independiente de las otras actividades.
Muy a menudo, estas duraciones tienen una funcin de densidad de probabilidad que
es sesgada a la derecha, por ejemplo, como se muestra en la Fig. 10.1.1

Si uno pregunta a un programador en un proyecto de desarrollo de software cunto

tiempo el desarrollo del componente de l / ella est trabajando en tomar, l / ella
nunca va a seleccionar el valor esperado E (di) o la mediana (50% -percentile). Ms
bien, l / ella va a mencionar algo en la vecindad de la -percentile 90%, de manera
que la estimacin de la duracin se puede hacer con una cierta cantidad de la
seguridad. De lo contrario, en aproximadamente 1 de cada 2 casos, su / su
programacin terminar tarde (ver Fig. 10.2), y esto no es del todo beneficioso para
su / su evaluacin de desempeo. Por supuesto, la curva de densidad real nunca se
conoce de antemano, para protegerse a s mismo / ella misma an ms, la

almohadilla programador voluntad la estimacin de tiempo an ms. Como

resultado, en muchos ambientes del proyecto, la duracin de la actividad
estimaciones individuales incluyen toda una cantidad razonable de seguridad.

Por otra parte, el establecimiento de fechas de terminacin es a menudo visto como

un proceso de negociacin. En la negociacin es una prctica comn para hacer una
oferta de apertura que permite cortes ms adelante. Planificadores deben prever un
recorte global horario, que se podra esperar para agregar reserva adicional con el fin
de proteger a sus horarios desde ese recorte. Adems, los gerentes en cada nivel de
la jerarqua de la organizacin tienden a aadir sus propias medidas de precaucin
en la parte superior de las estimaciones de los administradores o coordinadores de
informacin a los mismos. En un sistema de cortes de insercin seguridad y horarios
arbitrarios a lo largo de los diferentes niveles de la jerarqua de la organizacin tal,
duraciones de las actividades proyectadas finales tendrn muy poco, en su caso, el
valor real.

La ley de Parkinson 10.2.1

Cuando un programa del proyecto se va a desarrollar en funcin de las duraciones
estimadas solo momento, algn algoritmo de planificacin determinista se puede
invocar, por ejemplo, mediante el uso de las opciones de ruta y la nivelacin de
recursos crticos de software estndar de gestin de proyectos como se discute en
los captulos anteriores. Pero lo que suceder cuando el componente de software que
el programador est desarrollando est acabado en un 70% del tiempo estimado? La
mayora de los programas del proyecto tienen hitos asociados con tiempos de
actividad de acabado, lo que significa que un pronto final no ser recompensado en
especial, pero un acabado final no es deseable. El trabajador probablemente no
pasar a la salida de su / su programacin de los recursos asignados a las
actividades sucesoras, sino comenzar a modernizar su / su cdigo, la adicin de
caractersticas adicionales agradables grficas ms o menos (chapado en oro o la
adicin de campanas y silbatos innecesarios). Este es un ejemplo de lo que se llama
"ley de Parkinson".

El trabajo se expande para llenar el tiempo asignado (la ley de Parkinson)

El programador no es recompensado por los primeros acabados, sino que l / ella
corre el riesgo de ver a las futuras estimaciones de tiempo reducido por un factor

determinado, porque l / ella parece ser una sobreestimacin de su / sus necesidades

de tiempo. Adems, si l / ella las manos en sus / sus salidas temprano, l / ella
probablemente se le asignar un nuevo trabajo de inmediato, y es ms agradable y
menos estresante para permanecer en la actividad inicial durante un tiempo ms
largo. En otros casos, la gente slo tiene que ajustar el nivel de esfuerzo para
mantener ocupado durante todo el horario de actividades. Como ya se ha
mencionado, tradicional estrs ambientes del proyecto no llegar tarde, pero no
promueven ser temprano. Este entorno favorece la ley de Parkinson. En muchos
entornos, todava hay otros desincentivos para informar de una actividad pronta
conclusin: el trabajo realizado en los contratos a tiempo y materiales para los
resultados de instancia en menos ingresos si el trabajo se haya completado antes de
tiempo. Si la organizacin funcional completa el trabajo en menos tiempo de lo
estimado, no pueden seguir cobrando el proyecto.

10.2.2 El Sndrome del Estudiante

Un segundo tipo de efectos indeseables que pueden entrar en juego en entornos de
gestin de proyectos estndar, puede ser muy bien descrito en un entorno
acadmico. Considere un curso para el cual los estudiantes matriculados tienen que
escribir un documento y tienen un plazo de 3 meses a partir de ahora. El documento
en s no obstante sera, si trabaj en pleno esfuerzo y con un grado razonable de
seguridad que se incluye, no requieren ms de 4 semanas. Cul sera la
planificacin del trabajo de cualquier estudiante "regular"? l o ella sobre todo
posponer el inicio real de la investigacin y la preparacin de slo algunas 4 semanas
antes de la fecha lmite. Sin lugar a dudas, un comportamiento similar se observa en
la prctica la gestin de proyectos. Este efecto es conocido como el "sndrome del
estudiante": muchas personas tienen una tendencia a esperar a que las actividades
se ponen realmente urgente antes de trabajar en ellos.
Espere hasta que consiguen actividades (sndrome del estudiante) muy urgente
Ambos escenarios, la ley de Parkinson y el sndrome del estudiante, se producirn en
proyectos con horarios deterministas con tiempo suficiente seguridad y construidas
en los que se utilizan para evaluar los hitos trabajadores. Que har que las
estimaciones iniciales de duracin para convertirse en profecas que se cumplen, al
menos cuando las actividades hipotticamente podran ser muy rpido. Esto implica
que, aunque las interrupciones imprevistas inducen retrasos, no habr variaciones de
horario positivas para compensar los negativos. Tales retrasos tambin con
frecuencia se producen exactamente debido al sndrome del estudiante: cuando se
encuentra un problema inesperado cuando el trabajo se realiza a mitad de camino,
toda la seguridad ya se ha ido y ser invadido la estimacin. Esto lo hace sentir como
la actividad fue subestimado, para empezar, que puede dar lugar a an ms altas
estimaciones futuras.

10.2.3 Caminos paralelos mltiples

Si la red del proyecto no se limita a consistir en una sencilla ruta de actividades, sino
que tiene mltiples caminos paralelos que divergen y se unen en diferentes lugares
de la red, no es otra razn por los acabados de actividad favorables no siempre
pueden ser explotadas, mientras que los retrasos a menudo tienen inmediata

repercusiones en todo el proyecto. Esto es causado por el uso predominante de las

relaciones de precedencia acabado de inicio para modelar redes de actividades, que
implican que una actividad sucesora slo puede iniciarse cuando el ltimo de sus
predecesores acabados. Este efecto es inevitable, como el tipo de relacin de
precedencia es la eleccin y modelos ms lgica la realidad de la manera ms
natural. Por lo general, el camino se funde tienden a concentrarse cerca del final del
proyecto: en efecto, "montaje", "integracin" o las operaciones de "prueba" en su
mayora se producen cerca de la finalizacin del proyecto, que requiere muchos
elementos a reunirse. Esta es una razn por qu los gerentes de proyecto afirman
que "muchos proyectos completos 90% el primer ao, y completan el 10% final en el
segundo ao".
Considere la Fig. 10.3, en el que la actividad A tiene un nmero indeterminado de m
predecesores inmediatos Pi; i D 1; :::; metro.
Fig. 10.3 An assembly activity can only start when multiple predecessors are finished

Si cada uno de los caminos que se fusionen tiene una probabilidad del 50% de los
que est realizando la hora prevista, la probabilidad de al menos un ser tarde ya es
casi un 88% cuando tres actividades se funden. Incluso si cada actividad individual
tena una probabilidad de 85% de la terminacin del tiempo de funcionamiento, la
probabilidad de que al menos uno es tarde todava enfoques 40%. Estas
observaciones estn relacionadas con las desventajas de la aplicacin del modelo
PERT clsico y justificar la necesidad de simulacin ms sofisticado o herramientas
analticas en las que las duraciones de las actividades de hecho pueden ser
modelados como variables aleatorias independientes. La aparicin de mltiples
caminos paralelos y la influencia sobre sus actividades sucesoras tambin se discute
en la Seccin. 5.5.2 como el "sesgo fusionar".

10.2.4 La multitarea
Una ltima prctica de gestin de proyectos que requiere atencin en esta seccin es
la de realizar mltiples tareas, que no es que gran parte relacionada con el propio
comportamiento humano, ya que es la organizacin del trabajo. La multitarea es la
realizacin de mltiples actividades de los proyectos al mismo tiempo. En realidad, el
tiempo se divide entre varias actividades, por ejemplo, trabajando en un proyecto en
la maana y otra por la tarde. La mayora de la gente piensa en la multitarea como
una buena manera de mejorar la eficiencia, porque garantiza a todo el mundo est
ocupado todo el tiempo.

Sin embargo, tiene un efecto perjudicial sobre duraciones de las actividades, que se
ilustra en la Fig. 10.4. Supongamos que dos actividades que tienen que ser realizado
por un solo recurso. La imagen superior de la figura. 10.4 muestra un diagrama de
Gantt que representa el caso de la multitarea: ambas actividades slo se terminan al
final del horizonte de programacin. La parte inferior de la figura. 10.4 ilustra los
beneficios que se pueden lograr mediante la eliminacin de la multitarea: no hay
ningn cambio en la hora de finalizacin de la actividad 2, pero la actividad 1 estar
terminado en la mitad del tiempo si se trabaja a pleno esfuerzo. Sin embargo, hacia
la gestin, el trabajador tendr al menos ser capaz de presentar los avances en todas
las actividades. En este ejemplo, la influencia de los tiempos de preparacin se pasa
por alto: cada vez que un trabajador pasa de una actividad a otra, l / ella tendr una
cierta cantidad de tiempo para manejar este cambio en off, tanto en el caso de la
fsica y de la propiedad intelectual trabajo.

las estimaciones de tiempo momento individuales en un entorno de multitarea se

vuelven muy dependientes tanto del grado de multitarea que tenerse en cuenta
durante la ejecucin de la actividad. Si la experiencia del pasado se usa para
desarrollar estimaciones, esas estimaciones son slo tiene sentido si el mismo grado
de multitarea estaba presente en el momento de referencia. En la mayora de los
casos, las duraciones de la actividad efectivamente son posibles (al esfuerzo total)
permanece oculto. Este razonamiento es muy similar a la estimacin de los plazos de
entrega de lotes de productos en una empresa de fabricacin: si uno mira a los
plazos de entrega logrados en el pasado para producir un valor, l / ella debe
considerar slo aquellas observaciones en las que la compaa estaba trabajando
bajo una carga del sistema comparable.

La multitarea no slo necesita ocurrir dentro de un proyecto: la mayor parte del

trabajo del proyecto se ejecuta sobre una base comn a varios proyectos (en
oposicin a la utilizacin de los recursos dedicados por completo). Multitarea o saltar
entre los proyectos podra resultar en un nmero de efectos negativos,
especialmente en el caso de los recursos de cuello de botella. Un entorno multiproyecto plantear dificultades particulares, debido a que los trabajadores
probablemente reportar a varios jefes de proyecto y tendrn que cumplir con los
deseos de cada uno de ellos. Existe claramente una necesidad de priorizacin de
proyectos y la reduccin de la multitarea a un nivel aceptable. De lo contrario, se
crear una considerable competencia por los recursos entre los proyectos.

10.3 Gestin de Cadena Crtica / Buffer

En esta seccin se presenta una metodologa de gestin de proyectos integrada que
se centra especialmente en el control de la incertidumbre durante la ejecucin del

proyecto y sus efectos indeseables se discuti en la seccin anterior. La Cadena

Crtica / Buffer Management (CC / BM) metodologa es una aplicacin de la Teora de
Restricciones (TOC). Al final de la dcada de 1970, el dr. Eli Goldratt ha desarrollado
una metodologa de planificacin y el software correspondiente bajo el nombre de
OPT (Produccin optimizado la tecnologa). En medio de la dcada de 1980, el
trmino fue sustituido por OPT TOC. TOC ofrece un enfoque estructurado para la
lgica de resolucin de problemas y aplica sus esfuerzos de intercambio de ideas
sobre todo al entorno de fabricacin. El TOC tiene un enfoque de gestin de los
cuellos de botella, o restricciones, que mantienen el proceso de produccin desde el
aumento de su produccin. Una vez que los gerentes a identificar los cuellos de
botella, la operacin general se ha previsto enteramente como una funcin de la
programacin de cuello de botella. Cuando el todo es tan efectivo como lo puede ser
en una determinada capacidad, los administradores pueden elevar la restriccin al
invertir una capacidad adicional en los cuellos de botella. Una vez que una restriccin
ha sido levantada, estos pasos deben ser repetidos para identificar otras limitaciones
emergentes. Todo a la vista de la tabla de contenido est fuera del alcance de este
libro. Se remite al lector a una breve introduccin en la Seccin. 2.3.2.

10.3.1 Teora de las Restricciones en Gestin de Proyectos

Por supuesto, los textos de gestin de proyectos han contado muchos
administradores para centrarse en las limitaciones. Para los proyectos, la restriccin
se percibe como la ruta crtica, que es el conjunto de actividades que determina el
tiempo mnimo necesario para que el proyecto completo (vase la Parte I de este
libro). Goldratt agrega un importante segundo ingrediente de este marco que la
gestin menuda pasa por alto: los escasos recursos necesarios para las actividades
tanto dentro como fuera de la ruta crtica y posiblemente tambin por otros
proyectos. En el caso del desarrollo de un nuevo producto, por ejemplo, un
administrador puede programar las diferentes actividades de acuerdo con el ritmo de
la ruta crtica, pero todava se enfrentan a retrasos debido a la consola de diseo
asistido por ordenador es soportado por los otros puestos de trabajo. La cadena
crtica (CC) se define como el conjunto de actividades que determina la duracin
total del proyecto, teniendo en cuenta tanto las dependencias de recursos y de
precedencia. Para evitar esta cadena crtica de demoras, CC / BM aconseja a los
administradores para construir varios tipos de tampones de seguridad (tiempo) en el
horario, similar a las memorias intermedias de almacenamiento utilizados en lneas
de produccin para asegurarse de que las mquinas de cuello de botella siempre
tienen material a trabajar.

10.3.2 hacia atrs en el Tiempo de Trabajo

Un horario / BM CC se desarrolla hacia atrs en el tiempo a partir de una fecha de
finalizacin objetivo para el proyecto. En los captulos anteriores de este libro, se han
programado actividades AS-pronto-como-posible (ASAP) a partir de la fecha de inicio
del proyecto, tal como se procede en la programacin de proyectos tradicional. Esto
lugares programacin de trabajo lo ms cerca posible a la parte delantera de la
programacin. En CC / BM planificacin, el trabajo se coloca lo ms cerca posible a la
finalizacin del programa, como en una tarde-como-posible-moda (ALAP). Este
enfoque ofrece ventajas similares a las que ofrece el enfoque justo a tiempo (JIT) en

un entorno de produccin. Estos beneficios incluyen minimizar el trabajo en curso

(WIP), y no incurrir en costos antes de lo necesario, lo que mejora el flujo de caja del
proyecto (bajo el supuesto de que slo las salidas de efectivo estn asociadas con las
actividades del proyecto intermedios). Adems, los posibles cambios en el alcance de
la actividad (alteraron las especificaciones del cliente o los cambios en los
subsistemas de interfaz con la actividad), implicara un mayor riesgo de reanudacin
de las actividades que se inician lo antes posible. Menos trabajo tambin dar como
resultado del hecho de que los trabajadores simplemente tienen una mejor
informacin acerca de sus tareas. El principal inconveniente directamente
relacionada con la programacin de una manera ALAP es que, en la terminologa
tradicional ruta crtica, todas las actividades se harn crticos. Cualquier aumento en
la duracin de cualquier actividad dar lugar a un aumento igual en la fecha de
finalizacin del proyecto. Como se explicar en detalle ms adelante, los tampones
se insertan en los puntos clave en el plan de proyecto que va a actuar como
amortiguadores para proteger a la fecha de finalizacin del proyecto frente a las
variaciones en la duracin de la actividad. De esta manera, los beneficios de la ALAP
programacin estn totalmente explotadas con una proteccin adecuada contra la
incertidumbre.
Considere un proyecto que consta de seis actividades en serie, como se muestra en
la Fig. 10.5. La duracin de cada actividad puede ser modelado como una variable
estocstica, por ejemplo con una funcin de densidad univariado como se muestra
en la Fig. 10,1 (donde la varianza variar entre las actividades).

Claramente, la reputacin de una organizacin como un proveedor confiable que est

en juego cuando se cita a plazos poco fiables a los clientes, por lo que sus programas
de proyectos deben proteger a los clientes frente a la variabilidad inherente en las
duraciones de las actividades. Sin embargo, una gran proteccin excesivamente por
el contrario dar lugar a propuestas no competitivas y la prdida de oportunidades
de negocio. Con el fin de hacer frente a esta compleja tarea de estimacin plazo del
proyecto, un mtodo de proteger a sus clientes de los efectos de la variabilidad
duracin podra ser la de garantizar la terminacin oportuna de cada actividad
individual. De hecho, el mtodo ampliamente aceptado de seguimiento del progreso
en relacin con un cronograma de hitos es un ejemplo de este enfoque. La eleccin
de una estimacin de tiempo de seguridad para cada actividad por separado tendr
como resultado la eleccin de una aproximacin de la estimacin -percentile 90% de
cada duracin de la actividad por separado, lo que resulta en el diagrama de Gantt
se muestra en la parte inferior de la figura. 10.5. Como se seal anteriormente,
estos hitos son profecas que se cumplen, por lo que el proyecto es muy probable
que tan pronto extremo que en el plazo citado.

10.3.3 El amortiguador del proyecto

Es muy dudoso que cualquier organizacin podra ser competitivos en el entorno
empresarial de hoy en da si los gerentes de la organizacin intentaron manejar la
variabilidad de esta manera. La mayora de los gerentes saben esto, por supuesto. Es
por eso que luchan con un conflicto, entre ser capaz de presentar una propuesta
competitiva a un cliente y proteger el mismo cliente de los efectos adversos de la
inevitable variabilidad en la duracin del proyecto. El problema bsico es que, como
ya se ha mencionado, los primeros acabados son desperdiciados, mientras que los
acabados finales de los aos se acumulan mientras el proyecto avanza. En el
enfoque de TOC para la gestin del proyecto, la proteccin aparentemente lgica de
la finalizacin prevista de las actividades individuales no es el objetivo. Por el
contrario, en el espritu del desempeo del proyecto impulsado por la velocidad de
salida al mercado, la gestin slo se desea la conclusin rpida y exitosa del
proyecto en su conjunto. Por lo tanto, CC / BM elimina tiempo de seguridad en las
actividades individuales y agregados esta proteccin al final del proyecto bajo la
forma de un amortiguador del proyecto (PB). Esto implica una revisin de todas las
estimaciones de la duracin de la actividad, de tal manera que se excluye la
proteccin contra la variabilidad. Se podra citar la duracin media de las actividades
comparables, cuando se trabajan a pleno esfuerzo, o alternativamente, elegir una
duracin que slo ser superado aproximadamente una de cada dos veces (la
mediana). El enfoque / BM CC construye un cronograma del proyecto basado en los
llamados estimaciones de duracin agresivos (media, mediana, o cualquier otro
valor) que no son (al menos de forma individual) rellena con seguridad. La reduccin
en el tiempo de la actividad estima que las estimaciones de tiempo agresivos
tambin implica que es esencial para la ejecucin del proyecto de acuerdo a la
mentalidad correcaminos o el enfoque de la carrera de relevos. Este enfoque obliga a
una actividad para comenzar tan pronto como las actividades predecesoras han
terminado. Exactamente como en una carrera de relevos, el objetivo es sacar
provecho de la dcada de los acabados de las actividades anteriores. El cronograma
del proyecto resultante sobre la base de las estimaciones de tiempo agresivos slo es
una ayuda para llegar a una fecha lmite del proyecto, y no para comprobar el
rendimiento individual calendario de actividades (o en otras palabras: no hay hitos
para las actividades individuales).

La eliminacin de la proteccin de las actividades individuales debe ser agregada en

un tampn PB proyecto con un tamao adecuado. Sin embargo, ya que ambos
acabados de actividad positivos y negativos se alcanzarn (por ejemplo 50%)
estimaciones, estas fluctuaciones se (parcialmente) compensar el uno al otro a lo
largo de la cadena. En consecuencia, la proteccin agregada que debe
proporcionarse al final de la programacin no tiene que ser tan grande como la suma
del tiempo de seguridad retirado de las actividades individuales. Este es un resultado
intuitivo, pero tambin puede ser fcilmente demostrado matemticamente.
Suponga que todas las actividades en una cadena de n tienen igual varianza - 2. Si el
tiempo de seguridad de cada actividad individual se supone que es igual a dos
desviaciones estndar, el tiempo de seguridad acumulativa ser / n.2-. La varianza
de la suma de las duraciones en el otro lado es la suma de las diferencias, por lo que,
para proteger la cadena ejecutado segn la mentalidad roadrunner, el tiempo de
seguridad requerido es 2- pn. La suma de un nmero de variables aleatorias
independientes tiende a una distribucin normal (de acuerdo con el teorema del

lmite central), que implica que el porcentaje de proteccin proporcionada por el

individuo distribuciones fuertemente sesgadas es incluso menor que la de la cadena
ms normal de las actividades seleccionando el mismo nmero de desviaciones
estndar. El lector menos inclinados estadsticamente no tiene de que preocuparse
por estos detalles: un enfoque de corte en bruto sera vlida para pegar el 50% del
tiempo de seguridad quitada de cada actividad en el PB, que es tambin el mtodo
Goldratt propuso en su novela. Este 50% resultados regla del en el tamao PBreducido que se representa en la fig. 10.6. Una segunda regla de oro es la suma de
los cuadrados de error o mtodo de raz cuadrada: el tamao requerido PB se hace
igual a la raz cuadrada de la suma de los cuadrados de la seguridad eliminado en las
actividades individuales. Esta segunda regla es preferible que los proyectos con un
gran nmero de actividades, ya que la regla del 50% tiende a sobreestimar la
proteccin requerida en tal caso. Esto se debe a que se trata de un procedimiento
puramente lineal: un proyecto de 12 meses podra terminar con una mejor marca de
6 meses, un proyecto de 2 aos podra terminar con una mejor marca de un ao.

10.3.4 amortiguadores de alimentacin

La seccin anterior explica cmo manejar adecuadamente las actividades y cadenas
de actividades individuales. Sin embargo, ningn proyecto consta de una sola cadena
de actividades. Todos los proyectos tienen mltiples cadenas en paralelo, aunque en
su mayora, slo uno ser el ms largo. Los efectos de estas cadenas paralelas sobre
la variabilidad en la duracin total de un proyecto se han discutido en la Fig. 10.3 y
deben ser incorporados en el enfoque de CC / BM. La figura 10.7 muestra una red de
proyectos ficticios con nueve actividades. El segundo, pero la ltima actividad de la
cadena ms larga (cadena crtica) con ID = 5 es una actividad de montaje: su
comienzo exige la salida generada por las cuatro primeras actividades de la cadena
ms larga, y tambin las salidas generadas por la llamada cadena de alimentacin .
La ausencia de cualquiera de estas salidas se opone a la de inicio de la actividad de
montaje. Por el momento, se supone que no hay conflictos de recursos se producen
entre las diferentes cadenas, de tal manera que de hecho pueden ser ejecutadas en
paralelo, independientemente uno de otro. La parte inferior de la figura. 10.7
muestra un diagrama de Gantt en la cadena de alimentacin se ha programado
ALAP, como la teora / BM CC prescribe.

De la discusin de la Fig. 10.3, se sabe que el establecimiento de sus proyectos

proyecciones de duracin de la lnea de base sobre la base de la cadena crtica solo
dar resultados fuertemente sesgados a la baja, y este efecto se incrementa
solamente por nuestra programacin ALAP. Supongamos que la cadena 1-4 tiene una
probabilidad de 50% de llegada en la previsin de duracin programa agresivo, y de
manera similar para la cadena de alimentacin, a continuacin, la actividad 5 no
comenzarn a tiempo en una de cada 4 (= 0: 502) de los casos. Una forma
matemticamente correcta para manejar la complicacin de cadenas paralelas sera
el uso de cualquiera de simulacin o clculos estadsticos para adaptar el tamao de
la PB en consecuencia, como se explica en el anlisis de riesgos Chap horario. 5 sin
la presencia de los recursos. Sin embargo, aqu es donde la elegancia y la simplicidad
de CC / BM entra en accin. El PB slo sirve para proteger la CC en s y el CC est
desacoplada de todos los externos (cadena no crtica) las cadenas de alimentacin
por medio de los llamados amortiguadores de alimentacin (FB) . Ms precisamente,
un FB se inserta siempre que sea una actividad nonCC alimenta en una actividad de
CC. Si la regla del 50% se utiliza para dimensionar el PB y un poco ms pequea (del
50%) FB se inserta, el horario amortiguada de la figura. se obtendr 10,8. La prctica
habitual cuando hay varias cadenas que estn interconectadas, es proteger slo para
el ms largo de todas esas cadenas de alimentacin, haciendo caso omiso de los
dems.

10.3.5 La Cadena Crtica

Hasta ahora, la limitada disponibilidad de recursos renovables se ha ignorado en
gran medida. Sin embargo, la presencia de los recursos conduce a menudo a
situaciones en las que los conflictos de recursos estn involucrados, como se
muestra en los captulos. 7 y 8. Considerar la red del proyecto sencillo de la figura.
10.9. Actividades 1 y 3 y las actividades 2 y 4 se deben realizar en serie debido a la
relacin de precedencia acabado de inicio definida para mantener entre ellos.
Actividad 1 y 2 la actividad debe ser realizada por el mismo recurso X (renovable), de
los cuales slo 1 unidad disponible. Las duraciones de las actividades se supone que
son agresivos 50% estimaciones. CC / BM se inicia mediante la derivacin de un

calendario factible de recursos en la que todas las actividades comienzan ALAP (esto
se puede lograr mediante la funcin de "redistribucin de recursos" en herramientas
de software de gestin de proyectos estndar o mediante el uso revs de las tcnicas
de programacin basados en reglas de prioridad de la secta. 7.4.1). una (sin bfer)
horario de este tipo se representa en la Fig. 10.9. Sobre la base de un programa de
este tipo, es fcil identificar el CC, definido como la cadena ms larga de actividades
que considera tanto dependencias tecnolgicas y de recursos: ser una cadena de
actividades para las que el final de cada actividad es igual al comienzo de la
siguiente.

En el ejemplo, el CC es la "puesta en 1-2-4-end" de la cadena. El conflicto de recursos

se resuelve forzando las actividades 1 y 2 para llevar a cabo en serie, como se indica
por el arco de puntos en la red en la Fig. 10.10. El horario tamponada se muestra en
la misma figura. La RB tampn de recursos se discute a continuacin.

10.3.6 Los tampones de recursos

Una de las causas principales de los proyectos finales de los aos es que los recursos
no estn disponibles o no disponibles en cantidad suficiente cuando se necesitan.
CC / BM requiere un mecanismo para evitar que las actividades de CC a partir de
finales o tomar ms tiempo debido a los recursos indisponibilidades (otras
actividades son menos importantes). El mtodo elegido es el uso de un tampn de
recursos (RB) para proporcionar informacin a los recursos de CC sobre cundo van a
ser necesarios. Este RB es diferente de la PB y FBs en que normalmente no ocupar el
tiempo en el horario de referencia del proyecto. Es una herramienta de informacin
para alertar al administrador de proyectos y recursos que realizan de la inminente
necesidad de trabajar en una actividad de CC. RB se colocan cada vez que un recurso
tiene una actividad en el CC, y la actividad CC anterior se lleva a cabo por un medio
distinto. tampones de recursos deben asegurarse de que los recursos estarn
disponibles cuando se necesitan y las actividades de CC pueden comenzar a tiempo
o (si es posible) antes de tiempo. RB suele tomar la forma de una advertencia

anticipada, es decir, una llamada de atencin para cada nueva instancia de un

recurso en la CC. Por otra parte, el espacio (tiempo de inactividad) se puede crear en
el recurso de proporcionar una especie de capacidad protectora. Un ejemplo de la
colocacin de un RB se proporciona en la Fig. 10.10: se advierte recurso Y algn
tiempo antes de que sea para empezar a trabajar en el CC, que debera estar listo.

10.4 Ejemplo ilustrativo

Despus de haber cubierto todos los aspectos bsicos de programacin de CC / BM,
un breve resumen de la metodologa de programacin de CC / BM para derivar la
lnea base del cronograma tamponada puede describirse de la siguiente manera:

1. Vamos con estimaciones agresivas.

2. Construir un calendario de ALAP.
3. Identificar la cadena crtica.
4. Determinar las posiciones de tampn apropiadas.
5. Determinar los tamaos de tampn apropiadas.
6. Inserte los tampones en el horario.

En lo que sigue, estos seis pasos se aplicarn a un proyecto ejemplo ms grande. La

red del proyecto est representado en la Fig. 10.11. La duracin de la actividad se
indica encima de cada nodo de la actividad mientras se dan los recursos necesarios
para tres tipos de recursos renovables por debajo del nodo. Actividades 0 y 12 son
maniques, lo que representa el inicio del proyecto y el final, respectivamente.

Paso 1. Se supone que las duraciones de las actividades representadas en la red ya

son 50% estimaciones de tiempo agresivos (ver Fig. 10.1).
Paso 2. Para construir un programa de proyecto factible de recursos, se necesita
informacin sobre las necesidades de recursos de las diferentes actividades. En el
proyecto, se utilizan tres tipos de recursos, denominados A, B y C, con disponibilidad
de 3, 1 y 2 unidades, respectivamente. Las necesidades de recursos de cada
actividad se representan en la Tabla 10.1. Mediante el uso de una tcnica de
herramientas de software o programacin comerciales discutidos en la Seccin.
7.4.1, la programacin de la figura. 10.12 se puede obtener. En este calendario,
todas las actividades estn programadas ALAP.
Paso 3. En base a la tabla anterior, hay tres opciones para la CC: o bien "1-3-4-5-8",
"1-3-4-5-10-11" o "1-3-9 -6-11 "0,2. Basado en el conocimiento de un jefe de
proyecto del entorno del proyecto (! subjetiva), que puede ser, por ejemplo, lleg a la
conclusin de que la tercera de las tres cadenas de candidatos es el ms restrictivo:
slo hay un enlace de recursos, y los recursos estn ampliamente disponibles en la
empresa, mientras que las precedencias tecnolgicos son estrictas. Adems, las

actividades de la segunda cadena se perciben como ms actividades "normales", que

son ms manejables.
Paso 4. posiciones tampn apropiado se indican en la figura. 10.13, junto con el CC
elegido. se insertarn tres amortiguadores de alimentacin, la primera entre las
actividades 4 y 6, para proteger la CC en la actividad 6 de la variabilidad en la
cadena de alimentacin no crtica que consiste solamente de la actividad de 4 (en lo
sucesivo tambin como FB4-6). Un segundo circuito intermedio de alimentacin
(FB10-11) se inserta antes de la actividad 11, para protegerlo de la variabilidad en la
cadena de alimentacin 4-5-10. Por ltimo, FB8-12 est presente para proteger a la
finalizacin del proyecto de la variabilidad en la cadena de alimentacin 2-7-8. por
supuesto, tambin puede insertar un tampn proyecto, despus de la actividad 12.
tampones de recursos deben ser colocados cuando los recursos son transferidos de
nonCC de CC-actividades. Se deja al lector para determinar la posicin de estos
tampones. Ya que slo se llevarn a cabo los RB como una llamada de atencin, que
no sern consideradas ms adelante en este ejercicio. En situaciones prcticas,
puede ser prudente esperar con la identificacin de estos despachos hasta que se ha
desarrollado el programa de lnea de base tamponada final, ya que se pueden
planear los recursos a ser transferidos de manera diferente en este programa
definitivo.

Paso 5. Con base en estudios de duracin de las actividades similares de proyectos

similares anteriores, la compaa ha estimado que la desviacin estndar - de cada
duracin de la actividad es de aproximadamente 0,4 veces la duracin.
Correspondientes estimaciones de la desviacin estndar para todas las duraciones
de las actividades se proporcionan en la Tabla 10.2. La direccin ha decidido que una
proteccin temporal de dos desviaciones estndar es suficiente para determinar el
tamao del bfer. Por lo tanto, el siguiente tampn sizescanbecalculated: FB4-6 D 1:
6
! Perodos de tiempo choose2; FB8-12 D 2 * C p22 1:62 C 22 D 6: 5! elegir 7;
FB10-11 D 2 * P0: 82 C C 1:22 0:82 D 3: 3! elegir 4. De manera similar, el tamao de
la memoria intermedia de proyecto es igual a PB D 2 * p1: 22 C 22 C C 1:62 1:22
1:22 C D 6: 6
! tomar 7.
Paso 6. Los FBs y PB ahora se pueden insertar en el programa de la lnea de base,
como se muestra en la Fig. 10.14.

10.5 Ejecucin de Proyectos y Gestin de bfer

La construccin de una lnea base del cronograma tamponada tal como se explica en
las secciones anteriores sirve como una herramienta ideal durante la fase de
ejecucin del proyecto para monitorear el desempeo del proyecto y tomar acciones
correctivas cuando sea necesario. Una vez que el proyecto se pone en marcha, la
ejecucin de las actividades del proyecto se debe hacer de acuerdo con la
mentalidad de correcaminos. Como se explic anteriormente, esto implica que los
tiempos de acabado actividad individual no son vistos como hitos o plazos
individuales para garantizar que los primeros acabados de los predecesores de

actividad tiene un efecto inmediato en el inicio de la actividad. Esta mentalidad

tambin implica que durante la ejecucin del proyecto, en contra de sus iniciales en
la programacin de la lnea de base, todas las actividades comienzan lo antes
posible. La clave para reducir el proceso de trabajo en curso en todo el sistema y
otras desventajas de iniciar las actividades de ASAP es controlar el flujo de trabajo en
el sistema: actividades sin predecesores (nondummy), las denominadas actividades
de compuerta, no debe comenzar antes de la hora la hora de inicio, mientras que
nongating actividades, especialmente los de la CC, debe iniciarse tan pronto como
sea posible cuando el trabajo est disponible.
La ejecucin del proyecto est gestionado por el uso de tampones: adems de
proporcionar proteccin contra la variacin estadstica agregada, se supone que los
tampones para actuar como mecanismos de alerta vitales. gestin de memoria
intermedia es la clave para el seguimiento del desempeo del proyecto en CC / BM
(ntese las distintas pero relacionadas funciones esenciales de tampones durante el
desarrollo y ejecucin del proyecto de lnea de base). La CC es la secuencia de
eventos dependientes que evita que el proyecto de ser planificada con una
estimacin de ms corta duracin global. De esta manera, los aspectos ms
destacados de CC donde los recursos adicionales pueden hacer que el proyecto se
completar en un intervalo ms corto. Teniendo en cuenta el objetivo de completar el
proyecto lo ms rpido posible, el CC es la restriccin que impide que el proyecto de
hacer un mayor progreso hacia este objetivo. Al mismo tiempo, los tampones son los
instrumentos que pueden ser utilizados durante la ejecucin del proyecto para
determinar si la duracin total del proyecto en el programa de lnea de base es
todava alcanzable con un grado adecuado de certeza. Mediante la comparacin de
la programacin actual lo antes posible con las posiciones de amortiguamiento en la
lnea de base, el director del proyecto tiene una idea de la cantidad de tampones han
sido utilizados frente a la cantidad de la tramitacin de sus cadenas de alimentacin
se ha completado. Si el progreso del proyecto se encuentra en el inicio de una
cadena y toda la memoria intermedia ya se ha consumido, el proyecto est en
peligro. Si el progreso es al final y sin memoria intermedia se ha consumido, el
proyecto ser probablemente temprano. Este proceso de gestin de memoria
intermedia puede ser formalizado. Mientras que una proporcin predeterminada de la
memoria intermedia restante, todo se supone que vaya bien (la zona OK verde). Si
variacin de la actividad consume tampones por una cierta cantidad, se eleva una
advertencia para determinar lo que hay que hacer si la situacin contina
empeorando (la zona de cuidado de color amarillo). Estas acciones (agilizacin, horas
extraordinarias de trabajo, subcontratacin, etc.) deben ser puestos en vigor si la
situacin se deteriora ms all de un punto crtico (la zona de accin rojo). Figura
10.15 proporciona posibles umbrales de gestin de memoria intermedia.
Obviamente, los valores de umbral para activar acciones varan como una funcin
del proyecto o de la finalizacin camino.
Una de las ventajas de los FBs y toda la CC / BM mtodo es que la necesidad de
volver a programar el proyecto se reduce (que est marcado como la programacin
proactiva en el cap. 1). El calendario en curso se actualiza continuamente, pero el
horario de referencia normalmente se mantiene sin cambios. CC / BM afirma que slo
si el proyecto tiene un gran problema, es decir, el PP es un verdadero problema,
tendr sentido para reprogramar. Tales circunstancias se producen cuando es
imposible restaurar la programacin en curso para la zona de seguridad mediante
acciones de rutina como una respuesta a amortiguar el seguimiento. En ese

momento, se identifica un nuevo CC, y un nuevo programa de lnea de base debe ser
desarrollado que proporciona el director del proyecto con una nueva evaluacin de la
fecha en que l / ella puede anticipar el proyecto se complete con una cantidad
conveniente de certeza. La mayora de las fuentes de CC / BM dicen que ms a
menudo que no, volver a calcular una lnea de base es un recurso final que debe
evitarse siempre que sea posible, para evitar el nerviosismo sistema. Sin embargo,
acontecimientos inciertos durante la ejecucin del proyecto (retrasos de actividad, la
necesidad de insertar nuevas actividades, falta de disponibilidad de los recursos,
retrasos en las entregas por un subcontratista, etc.) pueden cambiar
dramticamente la composicin de las secuencias crticas. Un CC puede cambiar
simplemente como un cuello de botella puede cambiar, y aunque tal vez la duracin
prevista del proyecto no est en peligro inmediato, uno debe seguir centrada en una
cadena de actividades que pueden haber perdido su criticidad. Este tema ha sido
descrita en una serie de documentos de revisin crtica en la que los autores afirman
que CC / BM sufre de simplificacin grave. A propsito de los puntos crticos / CC
principal BM es el tema de la siguiente seccin.

10.6 Una nota crtica

Desde su introduccin en 1997, CC / BM es visto como un importante abrir los ojos a
la gestin y programacin de proyectos dinmica del proyecto. La idea de proteger a
un horario base determinista con el fin de hacer frente a las incertidumbres es sonido
y hace un llamamiento a la gestin (Herroelen y LEU 2001) y es uno de los
fundamentos de la programacin dinmica (vase por ejemplo el tema del cap. 5).
Sin embargo, se mencionan carencias y simplificaciones a travs de varias fuentes
en la literatura, que han dado lugar a una enorme cantidad de extensiones, dos
artculos de investigacin y libros, en la parte superior de la filosofa original CC / BM.
En lo que sigue, los principales puntos de crtica destacan en trabajos de
investigacin escritos por Herroelen y LEU (2001) y Herroelen et al. (2002) se
mencionan brevemente, sin entrar en mucho detalle.

10.6.1 Programacin Objetivo

La filosofa / BM CC asume que el tiempo es el principal objetivo de la programacin,
e ignora otros objetivos de una administracin regular y / o no regulares como se ha
discutido a lo largo Chaps. 7 y 8. En consecuencia, se asume implcitamente que
cada proyecto es un problema de programacin de proyectos con recursos limitados,
donde el objetivo es la programacin de la reduccin al mnimo de tiempo, como se
discute en la Seccin. 7.3.2. Cabe sealar, sin embargo, que un segundo objetivo
importante de programacin se toma en cuenta implcitamente, es decir, la
minimizacin del trabajo en progreso (WIP). Como se mencion anteriormente, esta
programacin objetivo se tiene en cuenta a travs de la utilizacin del enfoque de
programacin como tardo-como-posible, y es similar al objetivo de nivelacin
discutido en la Seccin. 7.3.4. Por otra parte, por las actividades de programacin
segn tardo-como-posible y asumiendo que estas actividades tienen un flujo de caja
negativo (es decir, el costo), el actual objetivo del valor neto de la secta. 7.3.3
Tambin se ha tenido en cuenta. Sin embargo, aparte de los objetivos de tiempo,
nivelacin y el valor neto presente, no hay otros objetivos que podran ser relevantes
en la prctica se toman en cuenta explcitamente. Las investigaciones futuras

deberan centrarse en la influencia de la incorporacin de estos otros objetivos de

programacin sobre la pertinencia y el uso del enfoque de CC / BM.

10.6.2 Programacin de Calidad

Goldratt minimiza el efecto de la utilizacin de algoritmos de planificacin de alta
calidad y establece que el impacto de la incertidumbre es mucho mayor que el
impacto de la utilizacin de mtodos de programacin apropiados. A pesar de que
casi no se puede negar que la incertidumbre es una dimensin fundamental de la
programacin dinmica y con frecuencia tiene un gran efecto sobre el rendimiento
del proyecto, el efecto beneficiario de mtodos de programacin de sonido se debe
poner en la perspectiva correcta. Se ha demostrado extensamente a travs de los
captulos anteriores que la cadena fundamental no slo depende del objetivo de
programacin, sino tambin de la calidad del algoritmo utilizado para construir un
programa factible de recursos. En consecuencia, el uso de mtodos de programacin
de alta calidad no slo es crucial para la calidad del objetivo de la programacin de
proyectos (tiempo), sino que tambin determina qu actividades son crticos y hacen
parte de la cadena crtica. Por otra parte, cuando el tiempo es considerado como el
objetivo principal de programacin, es una eleccin lgica para centrarse en las
mejores tcnicas de programacin que conducen a la realizacin del valor objetivo de
programar mejor optimizado.

10.6.3 Cadena Crtica

El CC / filosofa BM prescribe el uso y la presencia de una cadena nica crtica que
puede ser la mejor mantenida constante a lo largo de todo el ciclo de vida del
proyecto. Sin embargo, se puede verificar fcilmente que en un entorno realista
proyecto, ms de una cadena puede ser crtico y la presencia de cadenas crticos
nicos o mltiples depende de la forma en que el programa de la lnea de base se
construye (programacin de calidad objetiva y programacin). Por otra parte, una
dinmica de resultados de la configuracin en un desplazamiento de la cadena crtica
causada por los cambios en las estimaciones de tiempo de actividad, las relaciones
de precedencia, etc. Los efectos combinados de mltiples cadenas crticos
dinmicos, que adems dependen del objetivo de la programacin y la calidad de los
mtodos utilizados, pone el enfoque de amortiguacin en una perspectiva ms
compleja. El enfoque / BM CC no responda adecuadamente a estas cuestiones.

10.6.4 Dimensionamiento de bfer

tampones de encolado se pueden hacer sobre la base de la longitud de la cadena
crtica (tampn proyecto) o cadenas de alimentacin (alimentacin de tampones)
propuesto inicialmente por Goldratt, o tomando la informacin de riesgo de las
actividades en la (alimentacin o crtico) de la cadena en cuenta. Sin embargo, los
posibles retrasos en las actividades que llevan a amortiguar el consumo tambin
puede ser causada por la falta de disponibilidad de recursos. Aunque el enfoque
original de CC / BM sugiere utilizar tampones de recursos para garantizar la
disponibilidad oportuna de estos recursos, se conjetura que no son una solucin ideal
para resolver los retrasos inesperados. El impacto de los posibles retrasos debidos a

la falta de disponibilidad de recursos depende de la escasez de estos recursos, y por

lo tanto, el conocimiento acerca de la escasez de recursos tambin debe tenerse en
cuenta al dimensionar tampones. Una manera de medir la escasez de recursos se ha
propuesto en la Seccin. 8.3.2.

Gestin 10.6.5 Buffer

El uso de tampones de tiempo para proteger a la fecha lmite del proyecto puede ser
cuestionada en proyectos de gran complejidad, donde el uso eficiente de los recursos
limitados es el principal impulsor de rendimiento progreso del proyecto. Tanto la
insercin de tampones esttica en el calendario de la lnea de base (fase de
programacin) y la penetracin dinmica de tampones durante el avance del
proyecto podra (fase de ejecucin) y, a menudo har que nuevos conflictos de
recursos. La solucin de estos nuevos conflictos de recursos podra resultar en la
necesidad de adaptar el calendario de lnea de base original, dando lugar a cambios
en la cadena (s) crtico y cadenas de alimentacin y en los tamaos de bfer
correspondientes. Aunque esta anomala puede ser considerado como un detalle de
programacin tcnica, no hay reglas de dedo sobre las mejores prcticas para
reparar el programa de lnea de base original se dan.

10.7 Conclusiones
La traduccin de la teora de las restricciones filosofa descrita en "La Meta" a un
entorno de proyecto, tal como se describe en "Cadena Crtica", fue un importante
paso adelante en el desarrollo de la teora de la gestin de proyectos. De hecho,
Goldratt ilustra en su novela la aplicabilidad del enfoque cuello de botella para los
entornos de gestin de proyectos y define la cadena crtica como el cuello de botella
proyecto para enfocar. Al igual que en los buffers de inventario en entornos de
produccin (el objetivo), que introduce el uso de tampones de tiempo para proteger
el cuello de botella (Cadena Crtica) contra la variabilidad.
Un buen nmero de estudios se han centrado en las trampas de la filosofa de la
cadena crtica. En estos estudios, los autores sostienen que la teora CC / BM es un
importante para abrir los ojos. De hecho, el punto de que la interaccin entre las
duraciones de las actividades, las relaciones de precedencia, las necesidades de
recursos y la disponibilidad determina la duracin del proyecto es bien recibida, pero
no es en absoluto una idea nueva (esta idea fue el tema central de caps. 7 y 8). Por
otra parte, la proteccin de un calendario base determinista a travs de la insercin
de tampones (proyecto, la alimentacin y tampones de recursos) es un pragmtico
enfoque, pero a veces un poco demasiado simplista a la gestin de todas las formas
de variabilidad que pudieran surgir en la programacin de proyectos. Diversos
estudios hacen hincapi en la necesidad de algoritmos eficientes para la creacin de
horarios de referencia slidos, mecanismos y mecanismos para la evaluacin
dinmica de la criticidad de las actividades del proyecto de advertencia potentes y
eficaces. Sin embargo, la mayora de los estudios reconocen que el avance de la
gestin del proyecto fue causado por la novela de un hombre que ya afirmaron hace
dos dcadas que la identificacin y se centran en el factor limitante (el cuello de
botella o de la cadena crtica) es primordial para cambiar el comportamiento del
sistema en estudio.