XI CONGRESO INTERNACIONAL DE INGENIERIA DE PROYECTOS

LUGO, 26-28 Septiembre, 2007

APLICACIN DE LA CADENA CRTICA AL SECTOR DE LA
CONSTRUCCIN: UN CASO PARTICULAR
Unai Apaolaza Perez de Eulate, Aitor Oyarbide Zubillaga
Abstract
Depending on the kind of the work to be done, each construction project can require very
different levels of complexity and diversity in comparison with other projects belonging to the
same sector. One of the main problems that arise in this context is to get a consistent
management method in order to deal with this environment, taking into account that many of
the required resources must be shared with other building works. The aim of this research is
to analyze the way that one company can adopt the Critical Chain project management
methodology, the specific problems faced and how the problems were progressively
overcame. The main conclusion of the case study is that the method can deal with this
environment in a satisfactory way (both in terms of effectiveness, efficacy and efficiency),
including both single and multi-project management.
Keywords: Critical Chain, project management, multi-project
Resumen
Los diferentes niveles de complejidad y diversidad que, en funcin del tipo de obra, pueden
estar presentes en el sector de la construccin, hacen que desde la ptica de la gestin de
proyectos tenga un inters propio. Una de las principales dificultades radica en la
complejidad de dar con un mtodo de gestin capaz de responder de manera satisfactoria a
la problemtica descrita, en un entorno con recursos limitados y compartidos con otras
obras. El objeto de este estudio es el anlisis de situacin especfica a la que se enfrenta
una empresa del sector de la construccin dedicada a la fabricacin de estructura metlica,
en el proceso de adopcin del mtodo de gestin de proyectos denominado Cadena
Crtica. La principal conclusin que se deriva de esta experiencia es la validez del mtodo
(en trminos de efectividad, eficacia y eficiencia) para un entorno como el citado, tanto en la
vertiente individual de cada proyecto como en el mbito denominado multiproyecto.
Palabras clave: Cadena Crtica, Critical Chain, gestin de proyectos, multiproyecto
1. Introduccin
La gestin de proyectos es una disciplina en la que a pesar del tiempo transcurrido desde la
irrupcin de los mtodos considerados como referentes principales, el PERT y el CPM, y
pese a los esfuerzos que se han dedicado en este sentido, muchos de los problemas
considerados en sus orgenes siguen teniendo la consideracin de crnicos (Jeanette
Cabanis-Brewin 1999;Rand 2000;Steyn 2000). Un entorno multiproyecto puede entenderse
como un sistema en el que un gran porcentaje de la actividad que realiza son proyectos. En
este tipo de entornos los proyectos comparten recursos, lo que significa que existen de facto
una serie de relaciones entre ellos y la problemtica de su gestin resulta muy compleja
(Lockyer 1969), y la toma de decisiones requiere de una visin global tanto de los proyectos
en su conjunto como del estado de las cargas de trabajo en los recursos, pues de al poderse
2233
llegar a dar situaciones como el requerir la priorizacin de uno o varios proyectos en
detrimento de otros (Tobis & Tobis 2003). Esto significa que tales problemas siguen siendo,
por tanto, de actualidad, y pone de manifiesto que los entornos en que operan las empresas
requieren con frecuencia de una gestin diferente, ms completa.
En respuesta a lo anterior, a finales de los aos 90 Eliyahu Goldratt propuso un nuevo
mtodo para gestionar proyectos de manera alternativa a la tradicional, en la lnea de los
conceptos argumentados por l mismo en la Teora de las Limitaciones (Theory of
Constraints, TOC). Esta teora fue desarrollada por l mismo y presentada a principios de
los aos ochenta (Goldratt & Cox 1993). La idea bsica subyacente es que todo sistema
cuenta con al menos un punto que limita su capacidad total, el cuello de botella. La teora
plantea un modelo de gestin global del sistema en base a la aplicacin de una serie de
reglas y tomando como referencia dicho punto, gracias a lo que es posible mejorar de
manera considerable el resultado global, simplificndose la propia gestin. Los cinco pasos
que conforman el proceso de mejora continua de la TOC son los siguientes:
1. Identificar la limitacin del sistema.
2. Explotar la limitacin.
3. Subordinar el resto del sistema a la limitacin.
4. Elevar (Aliviar) la limitacin.
5. En caso de romperse la limitacin, volver al paso 1.
Con el paso del tiempo la teora ha ido desarrollndose y extendindose a otros mbitos,
entre los que destaca el de la gestin de proyectos, cuya versin especfica se llama
Cadena Crtica (Goldratt 2001;Rand 1998) y de la cual hay mltiples referencias que
avalan sus logros y posibilidades (Leach 2005;Newbold 1998;Nokes et al. 2003;Rodrguez
2005)(Goldratt, Nokes, Leach, Newbold, Realization, Prochain, AGI). Los criterios utilizados
son mismos que en el caso de produccin, pero adaptados a los parmetros propios del
entorno de proyectos, donde hay dos escenarios complementarios que deben ser tenidos en
cuenta de manera coherente: el entorno del proyecto nico y el entorno multiproyecto. Esta
necesaria correspondencia implica la superacin de una de las mayores dificultades, y por lo
tanto tambin representa la gran oportunidad de obtener mejoras sustanciales.
1.1 Problemtica de la empresa
El caso de estudio se refiere a una empresa que trabaja en el sector de la construccin,
realizando proyectos que implican diseo, fabricacin y habitualmente montaje de estructura
metlica. La duracin de los proyectos normalmente vara entre 3 y 6 meses, en funcin de
su nivel de complejidad, y el nmero de proyectos en ejecucin de manera simultnea es
como trmino medio de entre 15 y 30. Los proyectos tanto pueden ser gestionados en su
totalidad por la empresa como ser subproyectos integrados en otros proyectos mayores,
siendo lo ms frecuente que haya trabajos de ingeniera y de fabricacin que impliquen
subcontratacin.
Uno de los principales condicionantes es la diversidad de los proyectos que abarca la
empresa, implicando actividades que entraan tipos y niveles de dificultad muy diversos. La
tipologa de los proyectos que componen la cartera tambin supone un factor destacable,
pues puede dar lugar a escenarios muy dispares que requieren ser abordados de diferentes
maneras, y en este sentido el papel de la organizacin interna de la empresa es crucial,
pues el resultado depender de la estrategia que adopte y cmo sea ejecutada. Finalmente,
la gran cantidad de partes implicadas en estos proyectos, especialmente en las grandes
obras, motivan una permanente exposicin a modificaciones y conflictos de intereses entre
partes implicadas, que escapan al control de la empresa. Consecuentemente, la total
2234
eliminacin de la incertidumbre resultara utpica, pero la reduccin de la misma tendra un
impacto tanto ms positivo que revertira en la empresa en trminos de ganancia de
capacidad competitiva.
2. Desarrollo
La introduccin de una nueva filosofa de trabajo en un determinado entorno resulta siempre
incmoda y complicada, pues adems de implicar un cambio, un aprendizaje, suele requerir
un esfuerzo aadido para las personas implicadas. En el caso de la Cadena Crtica esto
puede ser an ms costoso dado el cambio mental que puede llevar asociado, por lo que se
opt por actuar de manera progresiva en lugar de involucrar a todas las personas en una
accin de cambio desde el inicio. De comn acuerdo con la empresa, se decidi realizar un
proyecto piloto con el fin de valorar la validez del mtodo en el entorno particular de la
empresa. Por lo tanto, la implantacin del mtodo en la empresa qued condicionada a la
obtencin de unos resultados satisfactorios desde el punto de vista de la empresa en una
prueba preliminar y que por otro lado, y en caso de decidirse por la adopcin del mtodo,
presumiblemente conllevara un plus de conviccin y apoyo por parte de los participantes en
la prueba piloto en la futura expansin al resto de la empresa.
2.1 Fase I: proyecto piloto
La realizacin de esta primera fase tuvo lugar durante un perodo de dos meses, e implic
aplicar los principios de la Cadena Crtica en una parte de la empresa. Dado que los
resultados de la prueba deberan arrojar luz sobre la decisin de implantar o no el mtodo
en su totalidad, las conclusiones obtenidas deberan ser generalizables al resto de la
empresa. Por lo tanto, esa fraccin del trabajo estara constituida por proyectos a desarrollar
en el perodo contemplado para la prueba y asimismo la carga de trabajo requerida por tales
proyectos debera implicar un porcentaje elevado de la capacidad de los principales
recursos implicados (Ya que en caso contrario, un aparente xito de la accin podra ser
atribuido a un trato de favor hacia estos proyectos a la hora de determinar las prioridades en
la asignacin de recursos).
Con carcter previo a su inicio se establecieron unos criterios de xito para el proyecto
piloto, de manera que el resultado del mismo pudiese determinarse con una mayor
objetividad. Dichos criterios se resumen a continuacin: consecucin de planificaciones
estables y sencillas, conocimiento de la carga de los recursos en cada momento,
conocimiento de las prioridades a la hora de fabricar, definicin clara de las tareas y del lote
de trabajo, y conocimiento del impacto de las replanificaciones.
El primer aspecto a abordar fue la capacitacin de los participantes de cara a funcionar en el
nuevo entorno de trabajo a construir, el cual se regira de acuerdo con las directrices
establecidas por el mtodo. Para garantizar la respuesta por parte de las personas en el
proyecto se organizaron sesiones de media jornada de duracin mediante las que se
transfirieron los conocimientos imprescindibles para comenzar a trabajar en la nueva
dinmica: bases del mtodo para comprender el funcionamiento y los objetivos buscados, y
conceptos especficos para desarrollar las labores correspondientes en particular a cada rol
asociado al mtodo, principalmente interpretacin de la informacin aportada por el sistema
y capacidad para reportar el avance de las actividades propias en el software. Para ello, los
facilitadores realizaron un seguimiento personalizado de las evoluciones de cada una de las
personas implicadas, garantizando un aprendizaje prctico, basado en el uso diario de los
conocimientos y del software y en una asistencia in situ.
Posteriormente se procedi a la construccin del sistema en s, consistente en un
modelizado del mismo y su posterior puesta a disposicin del personal participante mediante
un software especfico. En esta primera fase se prim la rapidez en la construccin puesta
2235
en funcionamiento del sistema por encima de un refinado del mismo, habida cuenta de que
considerando anteriores experiencias con el mismo mtodo se esperaba que fuese
precisamente el uso el que aportara la mayor contribucin a la mejora progresiva del
modelizado. De esta manera y tras un breve periodo de anlisis se dio con las
planificaciones iniciales de los proyectos, construidas de acuerdo con los criterios que el
propio mtodo establece y con las caractersticas especficas de la actividad, y finalmente
validadas por los participantes. Esta aceptacin del modelizado del trabajo dio pie a la
introduccin del mismo en el software, permitiendo de esta manera el inicio de la fase de
ejecucin.
Figura 1: ejemplo de representacin del estado del avance del proyecto
El inicio de la fase de ejecucin con el nuevo sistema permiti vislumbrar desde el principio
una de las virtudes del mismo: en la primera actualizacin de la situacin el diagnstico
determin que el consumo del buffer en uno de los proyectos era de un 80% mientras el
avance del mismo era an nulo. Pero lo ms significativo, ms all de la capacidad de
visualizacin la situacin grficamente y en trminos numricos, fue la ausencia de
sensacin alguna de alarma hasta ese momento, lo que puso de manifiesto la facilidad con
que los plazos pueden transcurrir sin un avance proporcional al mismo y lo que es peor, sin
tener ninguna impresin de que el desfase se est produciendo, lo que es sinnimo de
inexistencia de reaccin. Este hecho inicialmente cre una sensacin de estar realizando las
cosas peor que con el mtodo anterior, dado que lo habitual hasta entonces era que la
sensacin de alarma se produjera en la parte final de los proyectos. Sin embargo,
rpidamente se vi que ello era una virtud: con el fin de controlar la situacin se organiz
una reunin semanal de seguimiento en la que bsicamente se evaluaba la situacin de los
proyectos en cada momento y tomaban las decisiones necesarias para mantenerlos dentro
de lo aceptable en relacin a los objetivos y, dado que desde el inicio de cada proyecto este
contaba con un indicador de la situacin que adverta de desviaciones en cuanto estas se
producan, resultaba ms sencillo tomar medidas correctoras para corregir las situaciones
de desfase. Ms an, se observ que se estaban tomando medidas a uno o incluso dos
meses vista para evitar retrasos que ya se vislumbraban como irrecuperables por va
ordinaria, algo que es tanto ms fcil de hacer cunto antes se detecten las desviaciones y
viceversa.
La dinmica anterior se prolong por un espacio de dos meses ms aproximadamente,
durante los cuales la empresa pudo valorar la aportacin del mtodo a sus intereses, y en
particular su contribucin a la mejora de la gestin de los proyectos y de los recursos bajo
2236
una ptica global. Al proyecto piloto sigui un perodo de reflexin en la empresa en el que
en vista del cumplimiento de los criterios dexito, as como de los resultados vislumbrados,
se tom la decisin de implantar el mtodo con carcter extensivo a toda la empresa.
2.2 Fase II: expansin al resto del sistema
La fase de expansin se plante en su parte inicial de manera muy similar a la expuesta
para el caso del proyecto piloto, de manera que mediante varias sesiones se fue formando
progresivamente al resto del personal implicado y de igual manera se realiz el modelizado
del resto de proyectos de acuerdo con el nuevo sistema, adaptando tambin el modelizado
de la capacidad a la capacidad total del sistema y no slo al conjunto de recursos
contemplados en la parte piloto. Como era de esperar, el hecho de pasar a considerar el
sistema en su totalidad, as como el criterio adquirido por el personal participante en la fase
anterior motiv que hubiese ciertas diferencias con dicha fase, algunas de las cuales
resultaron trascendentales.
Primeramente se realiz un anlisis de los trabajos y recursos que deban ser modelizados y
por motivos de practicidad se concluy que no deba modelizarse el 100%. En el caso de los
proyectos, slo se tuvieron en cuenta aquellos que en la fecha prevista de fin del modelizado
tuviesen una parte importante de trabajo por hacer, ya que lo contrario implicara un trabajo
estril. En el caso de los recursos, por el contrario, el criterio fue el de uso o no del software
para su gestin. As, por ejemplo, no se asign una capacidad a las subcontrataciones
entendiendo que no supondran un problema de capacidad y que en todo caso su gestin se
llevara fuera del sistema, aunque en base a la informacin de ste. Por otro lado, la
naturaleza propia de cada proyecto existente en ese momento requiri de un esfuerzo
adicional a la hora de realizar el modelizado de cada uno de ellos: las planificaciones de
puentes, rascacielos, edificios singulares o gras de carga tienen en comn la necesidad de
estructura metlica, pero la morfologa de cada uno de estos trabajos resulta diferente y por
tanto el nivel de generalizacin es distinto en cada caso. Finalmente, al considerar todos los
recursos del sistema y no slo los implicados en una determinada fase, el modelizado vari
en nmero de unidades pero tambin en tipologa de recursos, y en el caso concreto del
drum incluso se lleg a redefinir la manera en que se represent su capacidad, con el fin
de adaptarla mejor a la situacin real, tal y como ms adelante se detalla.
Esta primera parte permiti que todo el sistema pasara a funcionar de acuerdo con el
mtodo, compartiendo la informacin y tomando criterios de funcionamiento comunes. El
elemento integrador de la parte organizativa con la evolucin real es el software, mediante el
cual se posibilita la disponibilidad de informacin actualizada que permite establecer
prioridades comunes, y que proporciona una visin objetiva de la situacin a todos los
niveles. Pero una vez alcanzada esta visibilidad general de la situacin, el siguiente paso
era la compatibilizacin del nuevo mtodo con la dinmica general de la empresa. En
concreto, existan una serie de reuniones peridicas en que distintos comits analizaban
aspectos concretos (Proyectos, cartera de pedidos, situacin general de determinados
recursos) y con los que el nuevo mtodo deba ser complementario. Realmente la
coherencia general no fue difcil de hallar: bast con determinar qu funcionalidades del
software utilizar, pues por lo dems era capaz de proporcionar de manera rpida y precisa
una informacin muy valiosa para todas estas reuniones, que anteriormente no exista y en
cuyo lugar estaban la experiencia y la intuicin de las personas. La mayor diferencia
respecto a la etapa anterior fue el convencimiento colectivo de la necesidad de algo ms
que dichas reuniones, pues si bien resultaban trascendentales para los intereses de la
empresa, se vi que los perodos entre las mismas (Mensuales) en ocasiones resultaban
excesivos y permitan que se produjeran desviaciones muy difciles de recuperar a posteriori
y que econmicamente resultaban muy costosas. Consecuentemente, se opt por realizar
un seguimiento de la evolucin de las cargas de trabajo de manera que en cuanto se
2237
percibiesen desviaciones significativas los Responsables de Recursos fuesen informados
para poder as actuar de inmediato en caso de considerarlo oportuno.
En situaciones tales como compromisos de entrega en fechas concretas o revisiones de
cliente, ejemplos tpicos de hitos, se observ que se produca una cierta orientacin de la
actividad hacia el cumplimiento de dichas fechas, aunque no siempre con carcter general y
organizado. La causa de ello era que cada hito no afecta de igual manera a todos los
recursos, lo que generaba problemas de interpretacin, coordinacin y conflictos de
intereses. Muchos de los hitos no se establecen considerando la explotacin capacidad
existente, sino en base a intereses de cliente. Desde un punto de vista prctico, puede
afirmarse que se trata de medidas que ste impone con el fin de evitar verse perjudicado por
posibles incumplimientos del proveedor, y por lo tanto alejan al sistema de una forma de
trabajo ms lgica de acuerdo con sus propios parmetros. Es indudable por tanto que la
introduccin de los hitos tiene consecuencias para los proyectos y para el sistema en su
conjunto, lo que recomienda su utilizacin con cautela y de modo justificado. Asumiendo que
este escenario, impuesto por el cliente, no es el ms favorable para la empresa, se opt por
dar un tratamiento diferenciado a cada hito con el convencimiento de que resultara
beneficioso en su conjunto, interpretndolo por tanto como un proyecto individual con
objetivos propios, pero sin olvidar sus vnculos con el proyecto global en el que se encuadra.
La progresiva adaptacin entre la estructura organizativa y el nuevo mtodo propici que el
sistema alcanzase la madurez necesaria como para comenzar con la ltima parte de la
implantacin, consistente en la transferencia de conocimientos avanzados en el mtodo y su
utilizacin, as como en un progresivo alejamiento de los facilitadores respecto al da a da
de la empresa. De esta manera se abordaron dos objetivos: por un lado, la independencia
en el funcionamiento por parte de la empresa, y por otro la adquisicin de los conocimientos
por parte de esta para tomar sus propias decisiones, en el futuro, en el marco de la dinmica
de mejora continua de la TOC. Al igual que en todo el proceso anterior, los facilitadores
adquirieron un especial protagonismo en esta parte, al principio de manera directa e
interactiva en el da a da hasta lograr una efectiva comprensin de los conceptos, y
posteriormente mediante una supervisin que progresivamente se fue disminuyendo en
intensidad.
Como resultado de lo anterior, el personal del rea de fabricacin realiz una reflexin
acerca del modo en que la capacidad del recurso crtico de la empresa, el armado, estaba
modelizado. Ello propici un profundo debate acerca de las ventajas y desventajas del
modelizado inicial y como consecuencia de ello se desarroll un nuevo modelo que
proporcionaba una mayor sencillez de uso y de interpretacin, si bien requera de algo ms
de trabajo y concrecin en la asignacin inicial.
2
1
1
1
1
R1
R2
R3
R4
R5
Capacidad mxima
R
6
(a) (b)
Figura 2: modelizados de la capacidad del recurso crtico. (a) Modelizado inicial de capacidad
agregada. (b) Modelizado final con capacidad distribuida.
2238
Como se observa en la figura 2 (a), donde se muestra el modelizado inicial de la capacidad
del drum, se trata de un recurso agregado. Ello significa que cualquier tarea que requiera de
este recurso se traducira automticamente en carga para este recurso, y mientras no se
superase el mximo, tericamente sera una carga aceptable por el sistema. Sin embargo, el
caso en cuestin tiene la particularidad de que cada trabajo requiere de un til propio, por lo
que la realizacin de trabajos similares en paralelo implicara la necesidad de multiplicar el
nmero de tiles necesarios, lo que consumira una excesiva capacidad y no resultara
factible. En contraposicin con ello, la figura 2 (b) representa la alternativa propuesta por el
propio departamento y que posteriormente se aceptara. En concreto se trata de una
especializacin de los recursos, de manera que los 6 puestos de armado de estructura se
distribuyen en cuatro puestos individuales (Recursos R1, R2, R3 y R4 respectivamente) y
uno doble (R5), destinado ste ltimo a la fabricacin especfica de un producto de
caractersticas repetitivo en su fabricacin, sin llegar a ser estndar. De esta manera se
super el problema expuesto en el modelizado inicial, si bien conllev dos contrapartidas:
ms trabajo a la hora de realizar la asignacin de recursos (Pues al resultar ms especfico
debe tomarse una decisin acerca del recurso en particular que realizar cada trabajo) y
necesidad de gestionar de manera singular aquellos casos excepcionales en que haya una
carga de trabajo insuficiente para el recurso R5. Sin embargo, en opinin de los usuarios
principales del modelizado de capacidad del recurso crtico (Departamento de fabricacin) la
visin proporcionada por este modelizado compensaba con creces los inconvenientes, lo
que motiv su adopcin.
3. Resultados
De manera similar a lo que en otras empresas tradicionales ha sucedido, la organizacin
analizada en este documento ha basado su xito hasta la fecha en su conocimiento del
sector y de la actividad, desde perspectivas bsicamente tcnicas y econmicas. Sin
embargo, los aspectos relacionados con la gestin han estado en un segundo plano, por lo
que no han evolucionado en igual medida a lo largo del tiempo. De esta manera, en los aos
precedentes se ha llegado una situacin en la que ha sido necesario hacer un importante
esfuerzo en este sentido mediante el lanzamiento de sucesivos proyectos relacionados con
diversos mbitos organizacionales.
Por todo lo anterior puede afirmarse que en trminos generales la ms reciente de estas
acciones, la aplicacin del mtodo de la Cadena Crtica, ha supuesto un notable avance en
el mbito de la gestin de proyectos para la empresa. En sntesis la adopcin de este
mtodo ha proporcionado una situacin notablemente ms ventajosa de cara a la gestin
del entorno en el que opera la empresa. El principal logro asociado al proyecto de
implantacin es la consecucin de un sistema global de trabajo capaz de alinear de una
manera efectiva los objetivos globales de la empresa con la realidad diaria del personal, es
decir, la estrategia y la operativa. Las claves para ello son una serie de objetivos parciales
que han sido trabajados de manera individual pero siempre con la visin integral del
sistema, de manera que cada uno de ellos aporta al total algo en particular y de una
determinada manera. Estos resultados parciales se exponen a continuacin:
Desarrollo de un modelizado de la capacidad adecuado a las necesidades del sistema.
Esto en concreto se traduce en una capacidad de identificar de manera permanente y
actualizada el estado de las cargas de los recursos implicados, con especial atencin en
el recurso crtico. Adicionalmente, el nivel de precisin de esta lectura del estado de la
carga de trabajo deba ser suficiente como para poder realizar valoraciones objetivas de
la situacin que permitiese tomar decisiones, y ser a su vez gestionable de manera gil
(Es decir, ser sencillo de interpretar y utilizar).
2239
Concepcin y construccin de una sistemtica gil y eficaz de planificacin y gestin de
la ejecucin de los proyectos, abarcando desde la definicin individual de cada proyecto
hasta la ejecucin de los mismos en el entorno multiproyecto correspondiente. En este
sentido es importante diferenciar entre la parte asociada al mtodo (Es decir, la genrica,
que establece cmo crear y compatibilizar planificaciones de proyectos de acuerdo con
la Cadena Crtica) y la parte especfica de la actividad en s. En lo concerniente a esta
ltima cobra un especial valor la sistemtica de planificacin de cada proyecto a dos
niveles: en una fase inicial a nivel agregado, respondiendo con rapidez a las cuestiones
relacionadas con la disponibilidad de capacidad en fechas concretas, y tras la definicin
de los aspectos ms concretos, a nivel de detalle, traduciendo los valores agregados a
necesidades concretas de capacidad de manera coherente con la capacidad existente.
t
t
Figura 3: esquematizacin de las fases de la planificacin: agregada y de detalle.
Relacionado con lo anterior, el tratamiento de los proyectos en la fase de planificacin en
funcin del nmero de hitos considerados tambin ha permitido cambiar la forma de
trabajar para adaptarla mejor a una realidad que complicaba la gestin de los recursos y
por extensin el manejo del multiproyecto. El paso de considerar el pedido de un cliente
como proyecto en su globalidad a interpretarlo como proyectos diferenciados con
necesidades propias ha implicado importantes cambios en la forma de realizar la
gestin, cambios que han propiciado un mejor uso de la capacidad en todos los sentidos.
En concreto, propicia un mejor uso de los recursos y facilita la toma de decisiones, al
evitar que se reserve una capacidad en momentos concretos sin tener garantas de que
se vayan a utilizar realmente, evitando que otros proyectos se retrasen en vano. Se
orienta as el uso de la capacidad hacia el cumplimiento de las fechas, por encima de
intereses particulares que dificultan el funcionamiento orientado a objetivos globales,
tales como los incrementos de saturacin de recursos con carcter departamental por
encima de otras consideraciones.
Los puntos anteriores posibilitan la consecucin sistema fiable y transparente que
conduce a un aumento de la credibilidad, interna y externamente, de manera que ello
redunda en un reforzamiento de la propia robustez del sistema. El hecho de trabajar
compartiendo la misma informacin y funcionando de acuerdo con criterios claros y
2240
estables facilita la comprensin de los objetivos, globales y locales, as como su
coherencia respectiva. Ello, a su vez, facilita la toma de decisiones y el logro de
consensos respecto a las mismas (Es importante recordar que el sistema de informacin
posibilita que los problemas sean detectados cuando se producen, siendo conocido
adems su impacto potencial sobre el plazo). De esta manera todo el conjunto
considerado trabaja de manera alineada con los intereses globales, si bien cada
miembro lo hace al nivel que le compete.
A priori, el hecho de tratarse de proyectos de carcter singular planteaba una
contrariedad: la imposibilidad de reutilizar de manera sencilla planificaciones anteriores,
teniendo que partir de cero a la hora de planificar cada nuevo proyecto. Sin embargo,
dos aspectos permitieron invertir esta situacin: por un lado, el tipo de planificacin,
basada en dependencias tcnicas asociadas a recursos bajo la ptica de carrera de
relevos amplia el rango de reutilizacin de las planificaciones anteriores. Por otro, la
concsecucin de bloques de unidades bsicas de planificacin (Secuencias bsicas de
tareas mediante cuya integracin mltiple se pueden generar de manera rpida las
planificaciones de detalle) dot al sistema de un mecanismo gil y eficaz para pasar de
la planificacin agregada inicial a la planificacin detallada con coherencia y de manera
no traumtica.
Finalmente, se han identificado varios escenarios de inters debido al impacto que
pueden tener en la operativa. Con relativa frecuencia se presentan situaciones que
trascienden los parmetros de funcionamiento considerados como normales, y cuya
superacin requiere medidas adicionales y/o diferentes. El problema en estas
circunstancias suele ser la capacidad de reaccin, pues el tiempo transcurrido desde que
la situacin es detectada hasta que se toman las medidas correspondientes propicia una
desviacin respecto a la planificacin que resulta muy difcil y costosa de recuperar
despus. La identificacin y anlisis de estos escenarios permite, por tanto, disponer con
carcter previo a las citadas situaciones de criterios y directrices que permiten una
respuesta ms eficaz. Un ejemplo muy representativo de lo anterior es el de la situacin
generada al emprender un proyecto que implique un consumo relativamente elevado de
la capacidad global en un perodo prolongado. En estas condiciones, y al margen de la
problemtica propia del proyecto, el sistema en su conjunto se vuelve especialmente
sensible respecto a la evolucin de este proyecto en particular, pues cualquier
desviacin del mismo en trminos de plazo tiene un fuerte impacto sobre la capacidad
global.
4. Conclusiones
Un anlisis de general de todo lo acaecido a lo largo del proyecto, considerando la situacin
y la problemtica inicial, los objetivos de la empresa con carcter previo a la implantacin,
as como los resultados alcanzados y el conocimiento generado en base a la
experimentacin permite extraer una serie de conclusiones que resultan muy valiosas bajo
diferentes pticas. Por un lado es importante considerar el valor de la experiencia desde la
ptica de la empresa en que se ha desarrollado, es decir, en el mbito especfico de esta
aplicacin en particular. Ms all de lo anterior, tambin resulta de inters la aportacin que
esta experiencia puede realizar desde el punto de vista del mtodo en s, en otras claves
como puede ser la aplicabilidad del mtodo en diferentes entornos o las consecuencias
generalizables que pueden extraerse.
4.1 Conclusiones relacionadas con la aplicacin del mtodo a la empresa:
La principal conclusin que se puede extraer de la experiencia desarrollada es la validez del
mtodo para su utilizacin en la empresa en cuestin. Frente a las dudas iniciales,
2241
fundamentadas en la complejidad del sector, en la dificultad de la propia actividad y en la
incapacidad de las acciones emprendidas en el pasado con el mismo fin, el mtodo ha
demostrado tener capacidad para conducir la empresa en la direccin deseada. En primer
lugar, porque la lgica subyacente en el msmo es coherente con la problemtica de la
actividad y fcilmente integrable con la estructura organizativa ya existente. Pero adems
inmediatamente fue capaz de proporcionar una visin clara de la situacin del sistema
(Bsicamente proporcionando una visin clara y actualizada del estado de los proyectos y
de las cargas de los recursos), permitiendo detectar los problemas de una manera
ponderada y objetiva en cuanto se producan, lo que a su vez, y de cara a la toma de
decisiones orientadas a reconducir la situacin, otorgaba una posicin muy ventajosa en
comparacin con la situacin inicial. Y finalmente, porque todo lo anterior ha conducido a
una nueva concepcin del sistema basada en principios simples, claros y consistentes que
favorecen la comprensin de los objetivos y las decisiones tomadas en cada momento,
redundando en una mayor facilidad de integracin de las personas.
En el plano estructural el mtodo ha permitido identificar carencias que anteriormente no
resultaban evidentes, dando adems orientaciones acerca de la direccin que debe tener la
solucin. As, la estructura de reuniones mensuales existente resultaba bsica para todos
los implicados, pero a menudo era insuficiente desde un punto de vista operativo al ser
inviable un aumento de la frecuencia de reuniones. Las prestaciones derivadas de la nueva
sistemtica de funcionamiento, sin embargo, abrieron una nueva posibilidad compatible y
complementaria con las reuniones ya existentes: la disponibilidad de informacin y la
capacidad de detectar inmediatamente los problemas permiti disear una dinmica de
seguimiento de la situacin que en caso de incurrir en desviaciones significativas informara
inmediatamente a los responsables afectados, brindando la posibilidad de organizar de
manera gil reuniones para el anlisis y toma de decisiones correspondientes.
Los hitos que responden a intereses del cliente y que vayan a ser realmente considerados
como referentes en el plan, alejan al sistema de una forma de trabajo ms lgica en
trminos de capacidad y de acuerdo con sus propios parmetros. Es importante poner en
conocimiento de quienes participan en la definicin de las condiciones del proyecto con el
cliente ya que pueden evitarse hitos innecesarios o negociar las condiciones de stos de
manera que su impacto resulte mnimo y no se convierta en un problema aadido. Por otro
lado, el dar un tratamiento diferenciado a cada hito como un proyecto individual no es algo
desdeable, pues supone de facto una prdida de la visin del estado del proyecto en su
globalidad. Consecuentemente, la ligazn entre los diferentes subproyectos que componen
el proyecto global y el control de su situacin debern ser gestionadas por el jefe de
proyecto. Sin embargo las ventajas asociadas a esta manera de administrar el sistema
justifica este aparente perjuicio, dado resulta beneficioso en su conjunto.
4.2 Conclusiones relacionadas con el mtodo:
Por lo que al mtodo en s respecta, hay varias conclusiones que resultan de especial
inters considerando la problemtica inicial y el escepticismo que rodea a este tipo de
acciones. La primera de ellas es la constatacin de la eficacia del mtodo de cara a operar
en un entorno caracterizado por la realizacin de proyectos singulares de magnitud,
complejidad y duracin considerables, elevada incertidumbre y recursos compartidos, tanto
propios como subcontratados.
Otro aspecto destacable es la rapidez con que se materializa la implantacin, producindose
un cambio de escenario verdaderamente espectacular con resultados visibles desde las
primeras semanas. Este es un argumento muy importante para las empresas, pues la
transformacin del sistema se produce adems sin generar una distorsin importante en el
quehacer diario de las personas, lo que facilita sobremanera la adopcin del mtodo. Este
hecho se fundamenta en la simplicidad de uso del sistema, y en el enfoque de la formacin,
2242
cuya parte ms terica est muy dosificada y que adems se basa principalmente en el
aprendizaje con el uso diario, es decir, haciendo el trabajo que de todas maneras debera
hacerse con muy poca carga adicional, excepto en el caso del facilitador interno, que
lgicamente debe volcarse en la implantacin.
Asimismo, resulta imprescindible destacar que una de las claves del xito del mtodo es el
grado de implicacin de las personas durante la implantacin. Al tratarse de un mtodo que
orienta al sistema en su totalidad en una direccin comn, resulta imprescindible que todas
las partes implicadas trabajen en esa lnea, y con especial rigor al principio, con el fin de
lograr resultados concretos que permitan valorar en su justa medida el potencial beneficio
derivado del funcionamiento asociado a la nueva sistemtica. Lgicamente, la involucracin
y perseverancia de las personas de mayor nivel de responsabilidad juega un papel decisivo
en este sentido, pues su capacidad de estimulacin al resto de implicados es vital en el
sentido de poder proporcionar a la implantacin un impulso definitivo o, por el contrario,
destinarlo a una progresiva situacin de abandono.
En cuanto a la construccin del sistema, y con especial atencin en el modelizado, el
objetivo a conseguir no debe ser el dar con una fiel representacin de toda la realidad. sta
es demasiado compleja, y mientras el nivel de precisin con que es posible definirla no es
absoluto debido a la existencia de variabilidad e incertidumbre motivadas por mltiples
factores de naturaleza impredecible, el esfuerzo necesario definir tal modelo, as como para
mantenerlo actualizado sera imposible de abarcar. El objetivo debe ser la consecucin de
un modelo aproximado con un nivel de precisin suficiente como para poder visualizar y
gestionar el sistema considerado, y una buena parte del conocimiento necesario para dar
con un modelizado apropiado se adquiere precisamente mediante la experiencia en el uso.
5. Lneas futuras de actuacin
Dado que la implantacin es an reciente, su nivel de madurez es todava reducido y debe
ser desarrollado. Las decisiones que en el futuro se vayan tomando determinarn el rumbo
de la empresa, y consecuentemente el ritmo y nivel de desarrollo del mtodo. Por ello, y
considerando adems todo lo observado durante el proyecto de implantacin, es importante
que estas decisiones se tomen de manera coherente con el mtodo y su filosofa, y en este
sentido hay determinadas acciones que merecen ser tenidas en consideracin:
Consolidacin de la nueva organizacin de los proyectos: como se ha mencionado
anteriormente, el nivel de madurez alcanzado por el sistema construido ha permitido su
funcionamiento de acuerdo con los principios del mtodo. Sin embargo, hay diversos
aspectos que an deben ser desarrollados y que dotarn al sistema de mayor potencial
o consistencia. Entre estos cabe destacar la necesidad de una mayor agilidad en el
funcionamiento estructural y la progresiva asuncin de las responsabilidades asociadas
a cada uno de los roles.
Cambio del enfoque comercial: como se ha expuesto en los apartados 2.2, 3 y 4.1, la
problemtica asociada a la introduccin de hitos requeridos por el cliente ha sido motivo
de un anlisis que ha conducido a un cambio en la operativa de los proyectos. El
resultado del mismo ha supuesto una mejora considerable respecto a la situacin
anterior, pues ha reducido en cierta medida las consecuencias del problema. Sin
embargo, la existencia de hitos en s supone un serio condicionante, que, de ser posible,
hay que evitar, y en caso contrario debe ser gestionado de manera que se minimice su
impacto.
Mejora operativa del departamento de fabricacin: el nivel de detalle de la informacin
necesaria para poder gestionar los proyectos de forma eficaz requiere que sea
entendible y utilizable por todos los implicados. Sin embargo, en casos como el del
2243
departamento de fabricacin de la empresa considerada, este nivel de detalle
proporciona una informacin valiosa pero insuficiente para llegar al grado de detalle
necesario para gestionar el trabajo de personas y mquinas a nivel de programacin de
tarea. La conformacin de un medio para desplegar la informacin agregada desde nivel
de proyecto al de programacin, de manera coherente, aportara una mejora operativa
sobre este departamento. La confirmacin de este extremo, no obstante, requiere de un
anlisis en mayor profundidad.
Finalmente, otro aspecto que a futuro debera ser abordado y que est relacionado con
todos los anteriores, es el lanzamiento de la dinmica de mejora continua que subyace
en la propia TOC, de acuerdo con lo expuesto en el apartado 1.1, pues un eventual
incremento de la capacidad del cuello de botella, actualmente ubicado en la fabricacin,
elevara la capacidad global de la empresa.
Referencias
Goldratt, E. M. (2001), Cadena Crtica, Ediciones Daz de Santos, S.A., Madrid.
Goldratt, E. M. & Cox, J. (1993), La Meta: un proceso de mejora contnua, Ediciones Daz
de Santos, S.A., Madrid.
J. Cabanis-Brewin (1999), So... So what??, PM Network, pp. 49-52.
Leach, L.P. (2005), Critical Chain Project Management, 2 edn, Boston.
Lockyer, K. G. (1969), An introduction to critical path analysis, Pitman Publishing, London.
Newbold, R.C. (1998), Project Management in the Fast Lane, CRC Press LLC, Boca Raton
(Florida).
Nokes, S., Major, I., Greenwood, A., & Goodman, M. (2003), The definitive guide to project
management, Financial Times Prentice Hall, Glasgow.
Rand, G.K. (1998), "Book Review: Critical Chain", Journal of the Operational Research
Society, vol. 49, no. 2, p. 181.
Rand, G.K. (2000), "Critical chain: the theory of constraints applied to project management",
International Journal of Project Management, vol. 18, no. 3, pp. 173-177.
Rodrguez, M. (2005), "Gestin de multipoyectos: Cadena Crtica", in Los tres caminos para
conseguir la excelencia en operaciones. Seis Sigma, Lean Manufacturing y TOC, Escuela
de Negocios Caixanova, ed., Trculo Edicins, S.L., pp. 263-288.
Steyn, H. (2000), "An investigation into the fundamentals of the Critical Chain Project
Scheduling", International Journal of Project Management, vol. 20, no. 5, pp. 363-369.
Tobis, I. & Tobis, M. (2003), Gestin de mltiples proyectos, The Mc Graw Hill Companies,
Madrid
Correspondencia (Para ms informacin contacte con):
Unai Apaolaza Perez de Eulate
Mondragon Goi Eskola Politeknikoa, J.M.A. S. Coop. Loramendi 4, 20500 Mondragon, Spain.
Phone: +34 943 794700 ext 229 Fax: +34 943 791536
E-mail: uapaolaza@eps.mondragon.edu
URL: http://www.eps.mondragon.edu
2244