Sábado por la mañana, Robert acaba de acompañar a su mujer a su clase de pintura en el centro de la ciudad. Entra en la cafetería que hay junto al estudio del pintor y enseguida ve a Roland sentado en una mesa. Roland le llama y le invita a sentarse con él. Robert pide su «Flat White», lo coge y se une a Roland.

Roland tiene unos treinta años y dirige una empresa tecnológica. Una vez que Robert se ha acomodado, Roland le pregunta:

– Roland: «Cuando nos conocimos hace dos semanas, mencionaste que un proceso en el que todos los recursos tienen la misma capacidad sólo propaga malas noticias. ¿Qué significa eso?».

– Robert: «¿Recuerdas las simulaciones que preparaste? Aunque todos los recursos tengan la misma capacidad, su producción en un momento dado, no es necesariamente la misma», explica Robert.

– Roland: «Lo llamaste variaciones estadísticas».

– Robert: «Exactamente. Así que imaginemos que el primer recurso tiene una producción inferior a la media debido a la fatiga, a una tarea compleja o a la falta de datos de entrada. Entonces otros recursos no pueden compensar, y el bajo rendimiento se transmite a todo el proceso.»

– Roland: «Pero, ¿y si el recurso alcanza una producción superior a la media?

– Robert: «Entonces, basta con que el siguiente recurso tenga una producción inferior o igual a la media para que se pierdan los beneficios de la alta producción del primer recurso. Las buenas noticias sólo pueden propagarse si todos los recursos rinden simultáneamente por encima de la media, lo cual es muy improbable, sobre todo a medida que aumenta el número de recursos.»

– Roland: «Así, un sistema en el que las capacidades de los distintos recursos están equilibradas sufre todas las malas noticias y nunca se beneficia de las buenas».

– Robert: «Exactamente. El resultado es un aumento constante del trabajo en curso. Las tareas entran en el sistema y sólo salen lentamente. Esto lleva a tiempos de procesamiento más largos».

– Roland: «Entiendo. Pero, ¿por qué es mejor tener una restricción, que parece una situación negativa?».

– Robert: «Tener una restricción no es una situación negativa, sino todo lo contrario. Te permite saber dónde tienes que centrarte para gestionar el rendimiento del sistema. Una restricción permite aplicar mecanismos eficaces contra las variaciones de productividad. Simplifica las cosas».

– Roland: «Entonces, ¿una restricción es algo bueno?

– Robert: «Efectivamente, pero sólo si se aplican métodos adecuados para gestionar el trabajo en curso y la restricción. Ahí es donde entra la teoría de las restricciones».

– Roland: «¿Qué pasaría si no se aplicaran esos métodos?

– Robert: «¿Tienes las simulaciones que preparamos?»

Roland saca su ordenador y lo enciende.

– Robert: «Modifica la simulación para simular un proceso en el que el segundo recurso tenga la mitad de capacidad que el primero y el tercero».

Roland cumple y comenta los resultados, mostrando un gráfico a Robert.

– Robert: «El trabajo en curso aumenta rápidamente y parece que nunca dejará de aumentar. El trabajo se acumula frente al recurso número dos, que tiene una capacidad inferior. Seguirá acumulándose hasta que la carga financiera de este trabajo en curso obligue a la empresa a cesar sus operaciones.»

– Roland: «Ha mencionado aplicar los principios de la teoría de las restricciones. ¿Qué son?»

– Robert: «Una restricción es simplemente reconocer la realidad de la situación. Los recursos idénticos son complejos de aplicar y, como hemos visto, ineficaces. Es mucho mejor tener una restricción claramente establecida».

«Como la restricción fija la capacidad máxima del sistema, es necesario no desperdiciarla. Por lo tanto, debemos reservar tareas para que trabaje la restricción. De este modo, nunca se quedará sin trabajo».

– Roland: «¿Cómo se determina el tamaño de esta reserva?

– Robert: «Debe ser suficiente para hacer frente a la carga de trabajo si un recurso anterior a la restricción (por ejemplo, el recurso número uno) no produce correctamente. También debe tener en cuenta el tiempo probable para que estos recursos vuelvan a estar en línea en caso de fallo.»

– Roland: «Esta reserva protege al sistema de las malas noticias procedentes de los recursos que preceden a la restricción. ¿No es así?»

– Robert: «Exactamente. El trabajo en curso también es una mala noticia. Para controlarlo, limitamos la entrada de material a sólo lo necesario para alimentar la restricción y, potencialmente, llenar el nivel de reserva anterior a ella.»

– Roland: «Así, el trabajo en curso se mantiene en un nivel estable. Pero, ¿cómo se estabiliza también el tiempo de producción?».

– Robert: «Está relacionado con la Ley de Little. En estas condiciones, el tiempo de producción es igual al trabajo en curso dividido por la capacidad de la restricción. El trabajo en curso es estable y se mantiene al mínimo. La capacidad de la restricción es estable y se mantiene en su óptimo. Así, el tiempo de producción se estabiliza en el nivel mínimo y se convierte en fiable.»

– Roland: «Pero, ¿qué ocurre si los recursos que están detrás de la restricción sufren una interrupción de la producción?

– Robert: «Nada demasiado espectacular. Estos recursos tienen mucha más capacidad que la restricción, así que en cuanto vuelven a estar en línea, tienen capacidad suficiente para absorber el retraso rápidamente.»

– Roland: «Entiendo cómo funciona en el caso de la producción industrial, pero no veo cómo aplicarlo en mi caso con el desarrollo de aplicaciones».

En ese momento, la mujer de Robert entra en la cafetería y le busca. Él le hace una señal y se levanta. Le dice a Roland: «Quedemos cuando puedas seguir hablando de esto. Llámame para decirme cuándo estás disponible. Que tengas un buen fin de semana». Robert se reúne con su mujer y salen juntos de la habitación.

Didier Varlot

Soy un ingeniero francés. También soy el orgulloso padre de tres hijas a quienes entreno cada vez que acceden a escucharme. Soy un viajero incansable. Trabajé en Francia, Rumania, Reino Unido, Estados Unidos, Brasil, Países Bajos, Sudáfrica, Bélgica, España, Italia y Suiza. He dedicado mi carrera a brindar servicios excepcionales de gestión de operaciones, productos y proyectos. Mis logros incluyen: – Desarrollé una empresa de 3 personas a 1500, de 0 a 50 M€ de ventas anuales y de 1 a 4 sitios de producción. – Recuperé proyectos por 53 M€ evitando más de 500.000€ en penalizaciones a la empresa – Contraté un equipo de jóvenes talentos, los entrené y los ayudé a crecer. – Lideré un programa de investigación y desarrollo de energías renovables. – Lideré equipos multidisciplinarios, multiculturales, remotos y ágiles en más de diez zonas horarias. – Entrené a una importante compañía de seguros para obtener un alto nivel de preparación para la recuperación ante desastres.

La entrada La restricción nos blinda contra las malas noticias se publicó primero en Ingenieria Industrial Online.

La aplicación de los principios de la Teoría de las Restricciones suele dar resultados impresionantes con rapidez. Muchos han oído hablar de este enfoque, pero, por desgracia, sólo unos pocos lo aprovechan y, por tanto, obtienen sus beneficios. No hay instrucciones complicadas que seguir, pero las soluciones son tan sencillas y obvias que da la sensación de estar haciendo trampas. Tuve la oportunidad de descubrir la teoría de la restricción a finales de los 80’s y enseguida tuve ocasión de aplicarla a casos empresariales reales. He aquí una de esas aplicaciones y los beneficios que el equipo obtuvo de ella.

Los hechos descritos en este artículo ocurrieron entre 1999 y 2002. Los nombres de las personas implicadas se han modificado por motivos de privacidad.

A caballo regalado no le mires el colmillo

Alex es director general de la filial rumana de un fabricante internacional de material ferroviario. La fábrica rumana ya tenía una buena experiencia y reputación en la modernización de locomotoras para ferrocarriles y clientes industriales. La empresa matriz acaba de comprar un competidor francés, y da la casualidad de que tenían un proyecto firmado con los ferrocarriles rumanos. Este proyecto, financiado por una institución internacional, es muy visible y esencial para las futuras relaciones de la empresa con los ferrocarriles.

El proyecto ya está en marcha. Se inició hace un año. Sin embargo, la sede central decide que el proyecto se transfiera bajo la autoridad de Alex y su equipo local.

Alex recibe una primera sesión informativa: El proyecto pretende modernizar 100 vagones de pasajeros para hacerlos más cómodos y eficientes. El proyecto tiene algunos requisitos específicos:

• Hay tres tipos de entrenadores: de primera, de segunda y de barra.
• La modernización debe organizarse subcontratando los trabajos a dos empresas rumanas designadas en el contrato.
• El contrato se entregará dentro del plazo de validez del contrato de financiación firmado entre los ferrocarriles y la institución internacional.

Miremos de todos modos dentro de la boca del caballo regalado

Cuando se transfiere un proyecto, el primer paso lógico es establecer una línea de base y determinar si hay que poner en marcha algún plan de recuperación. Como el proyecto se gestionaba desde las oficinas de la empresa recién adquirida, Alex y una selección de miembros de su equipo se desplazan a Francia. Al principio les sorprende lo amistoso que es el antiguo equipo del proyecto. Alex esperaba que le tuvieran en cuenta que les había quitado el proyecto, pero todos parecían encantados de conocerles y transferirles la información.

Al final de la estancia, Alex comprende que lo que había tomado por colaboración parece ahora el alivio de transferir la papa caliente a otra persona. La imagen que Alex tiene ahora del proyecto es bastante oscura.

• El proyecto se vendió con un compromiso de entrega poco realista y puede que finalmente se retrase dos años, prolongándose mucho más allá del plazo de financiación.
• Está por encima del presupuesto en 15 millones de euros, lo que representa alrededor del 30% del presupuesto original.
• Una empresa estadounidense ha comprado una de las empresas rumanas que participaban como subcontratistas en el proyecto y está dispuesta a poner fin a la colaboración.
• El otro subcontratista rumano está prácticamente en quiebra.
• La fase de diseño no ha terminado y llevará varios meses más.
• Los recursos de diseño se destinaron a otros proyectos y cabe esperar más retrasos.
• Aún no se ha encargado ningún componente.
• Pero lo más importante es que nada de esto se comunicó al cliente ni a la entidad financiera.

Hacerse cargo del proyecto

El equipo no tiene elección. Intentar escapar de un contrato financiado por una institución internacional sería un suicidio en este mercado. La empresa podría acabar bloqueada y perder otras oportunidades en las décadas siguientes. Además, el proyecto es uno de los mayores para Rumanía y ya está firmado. Por lo tanto, debe ejecutarse y debe ser un éxito. Y Alex es ahora el responsable de ello.

La primera decisión de Alex es constituir un equipo de proyecto. Serban, «guardián del tiempo», es el gestor del calendario, Constantin es el gestor de calidad, Mihaela es la gestora de compras e Ioana es la interventora. Su segunda decisión es renegociar lo que se pueda con el cliente y la institución internacional. Tiene que salvar el proyecto y necesita desesperadamente algo de margen.

Consigue cierta holgura en la entrega, pero el calendario sigue siendo muy apretado. No puede conseguir ningún cambio en el precio. La institución internacional se mantiene firme en su postura. No tiene más presupuesto para este proyecto. Además, la institución deja claro que no habrá más pagos tras la expiración del programa de financiación, aunque no se entreguen todos los autocares. Así pues, todas las entregas deben producirse imperativamente antes de la nueva fecha de entrega contractual. No es posible ningún retraso.

Los límites de la programación clásica

El equipo del proyecto empieza a trabajar inmediatamente en la planificación detallada. Serban es experto en el camino crítico y la metodología PMBOK y empieza a compilar la planificación en software. Cada modernización de autocar requiere más de 500 componentes nuevos y unos 50 pasos de montaje individuales. Si se multiplica por 100 autocares, la planificación resultante tiene que exponerse en una pared para que sea legible. Se trata de una planificación mucho más complicada que la modernización de una locomotora. La logística entre el almacén de piezas y los dos centros de producción parece una pesadilla.

Alex y el equipo tardan horas en entender cómo funciona el plan. El calendario resultante se ajusta al acuerdo contractual, pero no hay ninguna holgura. ¿Qué probabilidades hay de que un proyecto tan complejo se desarrolle según lo previsto?

A pesar de todo, el equipo se pone manos a la obra:

• Las piezas se piden inmediatamente (al menos las que tienen una definición estabilizada)
• Los primeros autocares se envían a los centros de producción para desmontarlos y reparar el bastidor.
• El equipo presiona al equipo de diseño para que termine el diseño lo antes posible.

El primer incendio

El equipo empuja el mayor número posible de vagones en la producción, tal y como pide el calendario. Pero un vagón de tren mide 23 metros de largo por 3 de ancho y 5 de alto, y pesa tanto que no se puede mover con facilidad. Al cabo de unos días, hay vagones por todas partes y el suelo del taller parece un caos. Los síntomas que aparecen son:

• Los entrenadores están esperando a que trabajen los equipos que tienen exceso de trabajo.
• A otros equipos les falta trabajo y se ponen a trabajar en otros proyectos y terminan por no estar disponibles cuando el entrenador está disponible.
• La falta de piezas bloquea el trabajo mientras las piezas se han comprado y están en stock.

Alex envía un equipo de expedicionarios para ayudar en el piso. La situación empeora inmediatamente:

• Los expedidores se contradicen.
• Las prioridades cambian constantemente.
• Los expedidores están apagando fuegos por todas partes.
• Serban es llamado varias veces al día para arbitrar entre expedidores.
• Incluso Alex es contactado de vez en cuando para arbitrar entre los expedidores, el subcontratista y Serban.

El equipo está aprendiendo que gestionar 100 vagones de pasajeros difiere de la modernización de unas pocas locomotoras, de una en una. Los primeros vagones ya llevan retraso y el equipo está gastando el poco dinero disponible a un ritmo más rápido de lo esperado. Este proyecto ya parece un desastre y puede acabar con la carrera de Alex y su equipo.

En caso de duda, haga las preguntas adecuadas

Alex se reúne con el equipo, y todos están de acuerdo en que si siguen como hasta ahora, este proyecto será un gran fracaso.

Alex recuerda que en el pasado solicitó el apoyo de Jonah para que le ayudara a organizar uno de los proyectos de la empresa. Jonah le introdujo en la Teoría de las Restricciones y le empujó a leer «La Meta», un libro escrito por el Dr. Eli Goldratt. Los métodos ayudaron a Alex a gestionar eficazmente la modernización de las locomotoras con un taller más pequeño y menos personal del que habría utilizado cualquier otra empresa. Jonah y la Teoría de las Restricciones podrían ayudar en esta situación. Alex llama a Jonah, que acepta venir al día siguiente para reunirse con el equipo. Al día siguiente, Alex lleva a Jonah a recorrer el taller para ver la situación. A continuación, se reúnen con el equipo del proyecto en una sala de reuniones. Cuando llega Jonah, el equipo le espera con la esperanza de encontrar una solución mágica a su problema. Jonah se para ante la pared de planificación y mira el plano sin decir nada. Luego, se vuelve hacia el equipo y dice: «Bueno, chicos, ¿cuáles son vuestros mayores dolores en esta situación?». Todos expresan sus frustraciones, hablando unos por encima de otros. Jonah espera a que se calme el ruido e intenta resumir lo que oye. Las principales frustraciones son garantizar que la producción siga el ritmo previsto. Y añade: «Esto sí que parece complejo. Pero hay que encontrar la simplicidad inherente a este proyecto para hacerlo más manejable. Empecemos con algunas preguntas». Alex reconoce la forma de hacer de Jonah. Nunca da una solución, sino que siempre impulsa a la gente a construir soluciones planteando preguntas.

Defina sus productos

Ahí viene la primera pregunta:

«¿Cuáles son sus productos? ¿Qué entregas en este contrato?».

Esta parece sencilla, pero no es fácil ponerse de acuerdo. Todo el mundo está de acuerdo en que hay tres tipos de trenes, vagones: 1ª, 2ª y la barra. Pero algunos sostienen que entregamos trenes (compuestos por varios entrenadores de 1ª, 2ª y barra), mientras que otros piensan que entregan entrenadores individuales.

Jonah pregunta: «¿Cómo utilizarán los vagones los ferrocarriles? ¿Integrarán vagones individuales en los trenes existentes o los utilizarán en trenes modernizados?».

El equipo está de acuerdo en que el cliente probablemente utilizará los vagones como trenes nuevos.

Jonah prosigue: «Esto significa que su proyecto consiste en entregar 10 trenes de 10 vagones cada uno y no 100 vagones. Esto ya debería simplificar el planteamiento para la planificación». Jonah añade: «Debes decidir cómo quieres ver tu contrato».

Alex y los demás miembros del equipo parecen no entenderlo, así que Jonah continúa:

«Pueden ver el proyecto de diferentes maneras:

• Se trata de un proceso de fabricación de trenes compuestos por coches de 2ª, 1ª y barra.
• Se trata de un proceso de fabricación de tres productos diferentes.
• Se trata de un proceso de entrega de 100 entrenadores individuales.
• Un gran proyecto monolítico.

Debes elegir el enfoque con el que te sientas más cómodo y que sea más fácil de representar en un calendario».

De las conversaciones entre los miembros del equipo se desprende claramente que éste no se siente cómodo considerando el contrato como un proyecto monolítico, ya que sería demasiado complejo de gestionar. Dudan entre las demás opciones, aunque más o menos parezcan iguales. Deciden entonces elegir la primera opción. Será un proceso de fabricación de trenes.

A continuación, analice su proceso…

Jonah pregunta: «¿Cuál es la configuración del flujo de su producción?».

Una vez más, la pregunta coge por sorpresa al equipo, que exige algunas aclaraciones.

Jonah explica: «Tu producción puede tener forma de «I», lo que significa que un conjunto de materias primas da un producto al final. En este caso, serían tres líneas de producción paralelas e independientes, una por cada tipo de autocar. Puede tener forma de «V», es decir, que un conjunto de materias primas produzca varios tipos de productos. También puede tener «forma de A». En este caso, varios subcomponentes se integran en un producto único».

El equipo aún no sabe a dónde quiere llegar, pero se debate entre ellos y termina explicando que la forma de la producción es más compleja y no puede resumirse en estos modelos sencillos. Incluye algunas fases comunes al principio (desmontaje, modificación del chasis y pintura), luego cada producto tiene su fase específica de montaje; después, la fase de pruebas es común. Argumentan que las pruebas podrían ser específicas para cada tipo de autocar, pero como se utiliza el mismo banco de pruebas, deciden describirlo como un paso común.

Jonah no parece satisfecho con esta respuesta. Dice: «No estamos discutiendo qué recurso utiliza cada tipo de vagon-tren, sino la forma de su organización de producción».

La primera propuesta viene de Serban: «Tiene forma de A, ya que tenemos que ensamblar tres tipos diferentes de vagones para hacer un tren». Todos parecen estar de acuerdo.

Jonah reacciona: «¿Estás seguro?» Jonah continúa: «Montar un tren significa sólo entregar diez vagones más o menos al mismo tiempo. No implica ningún paso activo».

Serban propone entonces que la producción tiene forma de I, pero Constantin le interrumpe: «Todos los vagones se fabrican a partir de los mismos vagones antiguos que se modifican para adaptarlos a cada tipo, así que nuestra producción tiene forma de V».

… Defina su restricción

Jonah parece satisfecho con la respuesta. Dice: «Mirando la forma de tu proceso de producción, ¿dónde está la restricción, el dictador de flujo?».

Constantin es el primero en reaccionar: «Debería estar en uno de los recursos utilizados en las tres ramas de nuestro proceso de producción. Como los pasos específicos de montaje difieren mucho, la probabilidad de tener tres restricciones distintas en la misma fase de montaje parece baja. Las distintas restricciones deberían retrasar de forma diferente los distintos tipos de autocares. Pero hemos visto que todos los tipos de autocares se ven afectados de forma similar».

Jonah confirma: «Tienes razón. Ahora, ¿qué etapa eliges como la restricción?».

Constantin pregunta: «¿Qué quieres decir con elegir la restricción? Un recurso es la restricción, ¡o no lo es!». Jonah aclara: «Tienes razón. Sin embargo, puede que no sea fácil determinar qué recurso es la verdadera restricción. Puedes acabar teniendo varios candidatos sin poder determinar claramente cuál es la restricción. Por lo tanto, es posible que tengas que seleccionar uno y luego poner en práctica una forma de gestionarlo. Si no se resuelven todos los síntomas, hay que buscar otra restricción. Pero partir por gestionar ya la primera restricción debería haber aclarado la solución, y la verdadera limitación al flujo debería ser más obvia en esa fase».

El equipo mantiene una acalorada discusión. Saben por experiencia que el primer síntoma que hay que buscar es la acumulación de trabajo en proceso frente a la restricción. Sin embargo, el taller está tan abarrotado de autocares y vagones en distintas fases que es imposible determinar el WIP – trabajo en proceso frente a cada recurso. Deciden fijarse en la capacidad teórica de los equipos utilizados para cada etapa. El mejor candidato es el puesto de pintura.

Jonah reacciona: «Puedes empezar con esta hipótesis. Te equivocarás si sigues viendo interrupciones al gestionar la estación de pintura como una restricción, te indicará que la restricción está en otra parte».

Determinar cómo aprovechar y utilizar la restricción

Jonah añade: «Ahora, ¿cómo quieres utilizar la restricción de la forma más eficiente?».

Serban propone tener autocares disponibles para pintar en cuanto la cabina esté disponible. Y para hacer visible este amortiguador (buffer), propone almacenar estos autocares en una zona delante de la cabina. Tras debatirlo, el equipo determina que dos autocares serán suficientes para evitar que la cabina de pintura se quede sin un autocar que pintar.

Jonah dice: «¿Qué deberían hacer para conseguir más visibilidad en el proceso?».

Alex entiende por dónde quiere ir Jonah y propone: «Deberíamos limitar el inventario en proceso para dejar de abarrotar el taller. Podríamos dejar de enviar nuevos vagones a la fábrica e incluso dejar de trabajar en algunos vagones y almacenarlos temporalmente (congelarlos). Esto nos permitiría ver mejor el flujo y comprobar que la restricción está donde suponíamos. Además, deberíamos introducir (liberar a producción) nuevos autocares sólo al ritmo al que se pintan los autocares».

Jonah está de acuerdo: «Esto parece un plan. Si quieres acabar pronto, empieza tarde».

Serban pregunta: «¿No deberíamos usar la cadena crítica?». Serban leyó el libro hace poco y le gustaría tener un proyecto para experimentar con lo que ha leído.

Jonah responde: «No te aconsejo que utilices la cadena crítica. Estás trabajando en un taller subcontratado. La cadena crítica requiere un gran cambio en la gestión de las personas, y puede que allí no tengas suficiente autoridad para imponer estos cambios.»

Mantente ágil y obten retroalimentación (feedback) tan pronto como puedas. No dejes que la inercia te limite

En cuestión de días, se reorganiza la producción. Se organiza una zona cerca de la cabina de pintura para almacenar dos autocares listos para pintar. El equipo deja de enviar nuevos vagones al taller y almacena cerca de la mitad de los vagones que ya están en proceso. Se reintroducirán progresivamente en la producción.

Serban rehace un calendario basado en las decisiones tomadas. Sorprendentemente, permite al equipo cumplir el plazo contractual y obtener una holgura adicional. Así, añade un margen de tiempo al final de la producción de cada autocar para proteger la fecha de entrega. En pocos días, el taller ha cambiado por completo: se trabaja en todos los autocares de la planta, ya no hay llamadas de arbitraje entre expedidores, y la logística incluso hace frente al ritmo de producción. Durante un mes y medio, el equipo no envía nuevos autocares a la fábrica y sólo vuelve a introducir en producción los que ya están allí. El trabajo en proceso disminuye, lo que permite al equipo tener una visión más clara de lo que ocurre en el taller. Todo parece ir sobre ruedas y el equipo se vuelve optimista.

Las restricciones pueden ocultarse

A finales del segundo mes, el director general del subcontratista solicita una reunión urgente con Alex. Le explica que necesita más autocares en producción para evitar interrupciones de la producción y que el trabajo en los nuevos autocares debe iniciarse inmediatamente, ya que tiene capacidad de sobra en el taller de desmontaje. Alex explica que se espera capacidad extra, ya que el desmontaje no es una restricción. Pero el director general no quiere oírlo. Quiere que los nuevos vagones entren en producción inmediatamente y amenaza con informar al cliente de que el equipo de Alex está saboteando el proyecto.

Alex está confuso por tanta energía para exigir autocares adicionales. Llama a Jonah para discutir el asunto. Jonah pregunta: «Me has dicho que están casi en quiebra. Así que tal vez tengan una restricción más profunda y crítica que la industrial y piensen que lanzando el trabajo sobre nuevos vagones pueden resolver su problema. Me ha dicho que reciben un anticipo cada vez que introducen un nuevo autocar en la producción. ¿Quizá su problema no sea industrial, sino financiero?». Al día siguiente, Alex visita la fábrica y se dirige al despacho del director general. Pregunta directamente si tienen un problema financiero. Tras algunas vacilaciones, el director general dice que no tiene efectivo para pagar a sus empleados este mes.

Durante los dos días siguientes, Alex y el director general renegocian su contrato y sustituyen el pago inicial y el pago a la entrega por un pago mensual regular y un pago menor a la entrega. De este modo, no hay necesidad de poner más autocares en producción y el proveedor puede cumplir sus obligaciones financieras.

Restricción incorrecta. La siguiente, por favor

Tres meses después de reorganizar la producción, los autocares se amontonan visiblemente frente a las pruebas eléctricas al final de la cadena de producción. Resulta evidente que la hipótesis de que la cabina de pintura era la restricción estaba equivocada. La zona de pruebas eléctricas es en realidad donde está la verdadera restricción. Durante la siguiente llamada con Jonah, Alex comenta esta nueva situación y le pregunta: «¿Reorganizamos de nuevo toda la producción y gestionamos las pruebas eléctricas como la restricción?». Jonah responde «Tienes dos soluciones posibles:

• Puedes ceñirte a la realidad y gestionar las pruebas eléctricas como restricción. Sin embargo, la capacidad de esta restricción está muy cerca de la zona de pintura, ya que el trabajo en proceso no ha crecido demasiado. Siempre es complicado gestionar dos restricciones candidatas que tienen capacidades cercanas.
• Puedes ceñirte a tu plan y asegurarte de que la cabina de pintura sea la restricción elevando la capacidad de las pruebas eléctricas. Puede ser más fácil añadir un segundo turno al banco de pruebas que añadir capacidades a la pintura, ya que hay tiempos incompresibles como el curado».

Tras discutirlo con el equipo del proyecto y el subcontratista, se organiza un segundo turno de pruebas eléctricas, y el trabajo en proceso de esa operación se reduce a cero.

Restricción por inanición

Durante una de sus visitas, Alex ve que la cabina de pintura está vacía y que no hay ningún autocar esperando a ser pintado en la zona dedicada a ello. Llama a Serban y le pide que vaya a la planta de trabajo. Intentan entender por qué no hay trabajo que hacer y descubren que, debido a las bajas temperaturas, algunos trabajos de soldadura se han retrasado y los autocares correspondientes no están listos para pintar. Esto les hace comprender que necesitan controlar mejor lo que ocurre en los pasos anteriores a la restricción. Deciden añadir un colchón de tiempo en el calendario para tener en cuenta las variaciones debidas a la diferencia de tiempo de las reparaciones entre los vagones. Este amortiguador de tiempo se inspira en el amortiguador de alimentación de la metodología de la cadena crítica y se divide en tres zonas: verde, amarilla y roja. El color del amortiguador se muestra en un panel fijado al vagón. Si el amortiguador está verde, no ocurre nada especial. Si se vuelve amarillo, los expedidores lo vigilan pero no toman medidas para no sembrar el caos en el calendario. Si el amortiguador se pone rojo, los expedidores entran en acción, empujan el autocar lo más rápido posible y pueden tomar todas las medidas necesarias para que el autocar avance. Por ejemplo, pueden utilizar ventiladores calefactores para calentar la zona a soldar y evitar retrasos debidos a las bajas temperaturas.

Tras dos semanas de este funcionamiento, los autocares llegan frente a la zona de pintura con suficiente antelación para evitar que la cabina permanezca parada.

¿Dónde está la simplicidad inherente?

En ese momento, estamos gestionando 100 amortiguadores de alimentación y 100 amortiguadores de proyecto de autocares. Esto lleva mucho tiempo, y la mayoría de las veces, el amortiguador de alimentación reacciona como el amortiguador del proyecto. Alex y Serban explican sus dificultades a Jonah, que pregunta: «¿El amortiguador del fin del autocar de segunda proviene a una exigencia o problema del cliente?». Serban explica que no, pero que se debe a intentar proteger la fecha de entrega en el calendario. Las fechas contractuales de entrega se organizan por composición del tren. Un tren consta de un número determinado de vagones de 1ª clase, de 2ª clase y un vagón bar.

Jonah reacciona: «¿Así que eliminaron parte de la flexibilidad del calendario fijando fechas de entrega estrictas para cada vagón en lugar de fijar una fecha de entrega para cada composición de tren?».

Alex y Serban deciden cambiar el amortiguador de un ajuste por vagón a uno solo por tren, y el número de amortiguadores finales se divide por 10. La gestión resulta más sencilla y el calendario recupera cierta flexibilidad.

Amortiguador de costos

Las cuestiones de entrega y producción mantienen la atención de la dirección alejada de los asuntos financieros. Sin embargo, al mismo tiempo, la situación de los costos evoluciona en la dirección correcta. Gracias a las negociaciones y a la racionalización del proyecto y del proceso, el equipo consigue recuperar el presupuesto del proyecto y anula el riesgo inicial del 30% por encima del presupuesto. Pero a mitad de la producción, empieza a aparecer un aumento de los costos que puede hacer que el proyecto vuelva a superar el presupuesto.

Serban propone utilizar EVM (Earned Value Management). Por desgracia, esta potente herramienta también es muy compleja de poner en marcha y de seguir. Así que el equipo desiste antes de empezar. Alex e Ioana intentan establecer algo tan sencillo como el amortiguador de tiempo y deciden experimentar con un amortiguador de costos. Crean una hoja de cálculo para controlar todos los costos. Tanto el valor comprometido como el valor real en efectivo se controlan y se representan gráficamente. El colchón equivale al margen de beneficio del proyecto y se divide en las tres zonas habituales. Por desgracia, la penetración del amortiguador ya es roja. Por tanto, la herramienta no es útil.

Más que ayudar, estresa. Cuando le hablan a Jonah de esta iniciativa, él responde: «Podría haber sido útil si se hubiera implantado al principio del proyecto, pero ahora es más una distracción para la dirección que un beneficio. Yo no me centraría en esto de momento, sino que seguiría muy atento a cada gasto hasta el final del proyecto.»

Los resultados

Dos años después, el equipo celebra la entrega del último autocar dentro del plazo contractual y se reúne para resumir lo ocurrido y lo aprendido.

El resultado superó con creces las expectativas:

• Todos los autocares se entregaron dentro del plazo revisado y no se pagó ninguna penalización por retraso en la entrega;
• La calidad de los autocares era satisfactoria;
• El costo del proyecto superó ligeramente las previsiones, pero estábamos lejos del desastre que auguraba la auditoría de situación inicial.

El equipo también elabora una lista de lecciones aprendidas que Alex repasa concienzudamente cada vez que se enfrenta a dificultades en un proyecto.

• Al plantear preguntas en lugar de ofrecer una solución preconcebida, Jonah permitió que el equipo aceptara más rápidamente las soluciones que estaban elaborando, lo que les permitió aplicarlas con mayor rapidez y eficacia al tener que superar menos resistencias.
• El equipo no utilizó una receta típica de la Teoría de las Restricciones, sino una solución mixta que utilizaba un tambor-amortiguador-cuerda y una cadena crítica con un toque de árboles lógicos. Hizo comprender al equipo que las herramientas de la Teoría de las Restricciones no están grabadas en piedra, sino que son una base sobre la que debe construirse una solución a medida.
• A la larga, algunas metodologías resultan demasiado complicadas de aplicar. Así que tomar prestadas algunas ideas es un excelente primer paso hacia una mejor gestión.
• El uso de amortiguadores para medir la desviación es una herramienta muy eficaz y fácil de aplicar. Permite centrarse en lo que repercute en el resultado y evitar reaccionar de forma exagerada ante los acontecimientos.
• Los amortiguadores de costos y de efectivo fueron adiciones prometedoras, pero llegaron demasiado tarde para ser útiles.
• Al poner en marcha un proyecto, el equipo de proyecto debe controlar inmediatamente las desviaciones y no dudar en buscar orientación en caso de duda. No deben dejar que el ego sea la limitación.
• La gente debe pensar más allá de la receta y plantearse las preguntas necesarias. Los Cinco Porqués es una herramienta que a menudo se pasa por alto porque se considera demasiado simple, pero es una de las más poderosas.
• Los problemas a los que puede enfrentarse el proyecto no siempre están relacionados con su ejecución. De vez en cuando, puede verse afectado por condiciones externas. La necesidad de liquidez del subcontratista no estaba relacionada con el proyecto, pero podría haber anulado las ventajas de reorganizar el proceso si no hubiera salido a la luz antes de que fuera demasiado tarde.
• No hay nada peor que retrasar la toma de decisiones por culpa de la indecisión; no dejes que la inercia se convierta en un obstáculo. Una vez dado este primer paso, el segundo es mucho más fácil y, sin darte cuenta, ya estás corriendo.

Didier Varlot

Soy un ingeniero francés. También soy el orgulloso padre de tres hijas a quienes entreno cada vez que acceden a escucharme. Soy un viajero incansable. Trabajé en Francia, Rumania, Reino Unido, Estados Unidos, Brasil, Países Bajos, Sudáfrica, Bélgica, España, Italia y Suiza. He dedicado mi carrera a brindar servicios excepcionales de gestión de operaciones, productos y proyectos. Mis logros incluyen: – Desarrollé una empresa de 3 personas a 1500, de 0 a 50 M€ de ventas anuales y de 1 a 4 sitios de producción. – Recuperé proyectos por 53 M€ evitando más de 500.000€ en penalizaciones a la empresa – Contraté un equipo de jóvenes talentos, los entrené y los ayudé a crecer. – Lideré un programa de investigación y desarrollo de energías renovables. – Lideré equipos multidisciplinarios, multiculturales, remotos y ágiles en más de diez zonas horarias. – Entrené a una importante compañía de seguros para obtener un alto nivel de preparación para la recuperación ante desastres.

La entrada Romper la cadena del fracaso: Utilización de TOC para recuperar proyectos que fracasan se publicó primero en Ingenieria Industrial Online.

Para entender de qué se trata el método de Ruta Crítica, y cómo funciona como un algoritmo de redes, podemos dirigirnos a: Método de la Ruta Crítica (CPM). De acuerdo al objetivo de este artículo, basta con mencionar que la Ruta Crítica es una herramienta que soporta el análisis, la planificación, y la programación de proyectos. Que básicamente, nos ayuda a determinar cuáles de las actividades que componen un proyecto, son críticos con relación en su efecto sobre el tiempo total del proyecto.

El objetivo de este artículo es el de, mediante herramientas tecnológicas, abordar un caso básico de CPM, para desarrollar el método utilizando un lenguaje de programación, en este caso Python, que nos permita, automatizar los cálculos y así obtener las actividades críticas del proyecto, la duración del mismo y un diagrama de Gantt.

En el desarrollo de este ejercicio emplearemos:

Para evaluar los resultados obtenidos a través del tratamiento de un problema técnicamente formulado y abordado, utilizaremos un caso descrito en el libro Investigación de Operaciones (9na edición), de Hamdy A. Taha (University of Arkansas, Fayetteville), (Ejemplo 6.5-1):

Caso de aplicación

Un editor firmó un contrato con un autor para publicar un libro de texto. El autor somete a consideración una copia impresa de un archivo de computadora del manuscrito. Las actividades (simplificadas) asociadas con la producción del libro de texto se resumen en la siguiente tabla.

La tarea será determinar la Ruta Crítica (Actividades críticas) y la duración estimada del proyecto.

Paso 1: Crear el entorno de trabajo en Colaboratory

Lo primero que vamos a hacer consiste en crear un entorno de trabajo en Google Colaboratory, así que vayamos allá: Abrir cuaderno nuevo.

Verán que tienen un lienzo para programar el modelo, así que en este cuaderno podemos ir generando las líneas de código que explicaremos en los pasos siguientes.

Paso 2: Importar las librerías necesarias

Respecto a las librerías, en la introducción del artículo hicimos una descripción de la funcionalidad de cada una, veamos como importarlas en nuestro entorno:

#Importar las librerías necesarias
!pip install criticalpath
from criticalpath import Node
import datetime
import pandas as pd
import matplotlib.pyplot as plt
from matplotlib.patches import Patch
import numpy as np

De esta manera, tenemos todo lo necesario para empezar a desarrollar nuestro código.

Paso 3: Ingresar los datos del modelo

Básicamente los datos del modelo corresponden a las tareas, su duración y las relaciones de dependencia que rigen la secuencia del proyecto.

El siguiente fragmento permite ingresar estos datos al modelo:

#Ingresar los datos del modelo (Tareas y dependencias)

#Crear el proyecto "p"
p = Node('proyecto')

tareas = [("A", {"duracion": 3}), 
          ("B", {"duracion": 2}), 
          ("C", {"duracion": 4}), 
          ("D", {"duracion": 3}), 
          ("E", {"duracion": 2}), 
          ("F", {"duracion": 4}), 
          ("G", {"duracion": 2}), 
          ("H", {"duracion": 1}), 
          ("I", {"duracion": 2}), 
          ("J", {"duracion": 4})]

dependencias = [("A", "E"), 
                ("B", "E"), 
                ("E", "F"),
                ("F", "G"), 
                ("G", "I"), 
                ("I", "J"),
                ("C", "J"), 
                ("H", "I"), 
                ("D", "H")]

# Cargar al proyecto las tareas y sus duraciones
for i in tareas:
    p.add(Node(i[0], duration=i[1]["duracion"]))

# Cargar al proyecto sus dependencias (secuencias)
for j in dependencias:
    p.link(j[0],j[1])

# Actualizar el proyecto:
p.update_all()

El anterior fragmento nos permite cargar todos los datos necesarios para conocer la Ruta Crítica del modelo. Veamos cómo obtenerla:

#Obtener la Ruta Crítica del modelo
p.get_critical_path()

Al ejecutar esta instrucción tenemos la siguiente salida:

De la misma manera, podemos obtener la duración estimada del proyecto:

#Obtener la duración del proyecto
p.duration

Al ejecutar esta instrucción tenemos la siguiente salida:

Así entonces, de esta manera muy sencilla tenemos las actividades que componen la Ruta Crítica y la duración del proyecto de acuerdo a CPM (17 semanas). Podríamos finalizar el modelo hasta acá, sin embargo, queremos obtener el diagrama de Gantt del proyecto, y para eso es necesario obtener algunas variables adicionales.

Paso 4: Obtener las variables de inicio y finalización

Ya que el problema planteado no establece fechas de inicio y finalización, podemos, mediante Python, utilizar una fecha de inicio artificial, por ejemplo: Hoy. ¿Con qué objetivo hacemos esto? Los diagramas de Gantt requieren de una línea de tiempo y es preciso establecer estas variables. Estableceremos fechas de inicio, de finalización y un status para cada actividad del proyecto.

En este caso puntual, ya que la duración de cada actividad se nos da en semanas, multiplicaremos el valor de la duración por 7:

#Obtener las variables de inicio y finalización
ruta_critica = [str(n) for n in p.get_critical_path()]

proj_fecha_inicio = datetime.date.today()

proj_calendario = pd.DataFrame([dict(Tarea = key, 
                                   Inicio = datetime.date.today(), 
                                   Fin = datetime.date.today() + datetime.timedelta(val['duracion']*7), 
                                   Status = 'Actividad Normal')
                              for key, val in dict(tareas).items()])

for key, val in dict(tareas).items():
    dep = [d for d in dependencias if d[1] == key]
    prev_tareas = [t[0] for t in dep]
    if prev_tareas:
        prev_fin = proj_calendario[proj_calendario.Tarea.isin(prev_tareas)]['Fin'].max()
        proj_calendario.loc[proj_calendario.Tarea == key, 'Inicio'] = prev_fin
        proj_calendario.loc[proj_calendario.Tarea == key, 'Fin'] = prev_fin + datetime.timedelta(val['duracion']*7)
        
proj_calendario.loc[proj_calendario.Tarea.isin(ruta_critica), 'Status'] = 'Ruta Crítica'
        
display(proj_calendario)

Al ejecutar este fragmento de código, tendremos:

Podemos apreciar cómo tenemos las fechas estimadas de inicio de cada actividad y su correspondiente fecha de finalización (teniendo en cuenta que la duración de las actividades está dada en semanas). También tenemos un status relacionado con la naturaleza de cada actividad: Crítica o Normal.

Y tenemos fechas de inicio y finalización, lo siguiente será calcular cuántos días pasan entre el inicio del proyecto y el inicio y finalización de cada actividad:

# Número de días desde que el proyecto inicia hasta que la tarea inicia
proj_calendario['dias_inicio'] = (proj_calendario.Inicio-proj_fecha_inicio).dt.days
# Número de días desde que el proyecto inicia hasta que la tarea finaliza
proj_calendario['dias_fin'] = (proj_calendario.Fin-proj_fecha_inicio).dt.days
# Días entre el inicio y el fin de cada tarea
proj_calendario['dias_inicio_fin'] = proj_calendario.dias_fin - proj_calendario.dias_inicio

display(proj_calendario)

Al ejecutar este fragmento de código, tendremos:

Paso 5: Obtener el diagrama de Gantt (Graficar)

El siguiente paso consiste en graficar de acuerdo al diagrama de Gantt, ls actividades del proyecto. El eje x estará dado en días.

#Graficar las actividades en un diagrama de Gantt
fig, ax = plt.subplots(1, figsize=(16,6))
ax.barh(proj_calendario.Tarea, proj_calendario.dias_inicio_fin, left=proj_calendario.dias_inicio)
plt.show()

Al ejecutar el fragmento tendremos:

Paso 6: Mejorar el diagrama de Gantt

Una vez obtenido el diagrama podemos realizar modificaciones sobre el mismo, por ejemplo: dar un color específico a las actividades de la ruta crítica, anexar leyendas, entre otros. Vamos a resaltar con rojo las actividades críticas, y a anexar alguna leyenda de actividades:

# Dar color rojo a las columnas de actividades críticas
def color(row):
    c_dict = {'Ruta Crítica':'#E64646', 'Actividad Normal':'#4F81BE'}
    return c_dict[row['Status']]
proj_calendario['color'] = proj_calendario.apply(color, axis=1)
fig, ax = plt.subplots(1, figsize=(16,6))
ax.barh(proj_calendario.Tarea, proj_calendario.dias_inicio_fin, left=proj_calendario.dias_inicio, color=proj_calendario.color)

#Anexar leyendas
c_dict = {'Ruta crítica':'#E64646', 'Actividad normal':'#4F81BE'}
leyenda = [Patch(facecolor=c_dict[i], label=i)  for i in c_dict]
plt.legend(handles=leyenda)

plt.show()

Al ejecutar el fragmento tendremos:

Ahora tenemos un modelo capaz de obtener las actividades críticas de un proyecto, determinar su duración de acuerdo al algoritmo CPM y graficar las actividades mediante un diagrama de Gantt.

También es posible incorporar una variable de «estado de terminación» de cada actividad, para así observar el avance del proyecto.

El código completo de este desarrollo lo puedes encontrar en nuestro cuaderno: Método de la Ruta Crítica (CPM) mediante Python.

La entrada Método de la Ruta Crítica mediante Python (CPM) se publicó primero en Ingenieria Industrial Online.

El algoritmo PERT se desarrolla mediante intervalos probabilísticos, considerando tiempos optimistas, probables y pesimistas, lo cual lo diferencia del método CPM que supone tiempos determinísticos.

Conceptos básicos para diagramar actividades con redes

La entrada PERT – Técnica de evaluación y revisión de proyectos se publicó primero en Ingenieria Industrial Online.