A veces pienso que tener ingresos estables, vínculos confiables, habilidades que sirven y una rutina más o menos ordenada ya debería bastar. Que con eso uno debería estar tranquilo. Pero con el tiempo me di cuenta de que estar tranquilo no significa estar protegido, y esa diferencia no se nota mientras todo siga como siempre. Solo aparece cuando algo te interrumpe.

Y en esa misma línea, creo que también confundimos continuidad con solidez. Como si el solo hecho de que algo se repita sin problemas fuera prueba de que está bien armado. Pero a veces lo único que demuestra es que nadie lo ha puesto a prueba todavía.

Con el tiempo, muchas estructuras que parecen estables solo reflejan que nadie ha cuestionado su base. Lo fácil de mantener se confunde con lo robusto y la rutina va ocultando los puntos ciegos.

Hasta que una se cae. Y no cae sola.

Me pasó hace años, cuando trabajaba en una planta de alimentos bastante eficiente. Todo iba demasiado rápido, estaba automatizado y bien coordinado. Pero el funcionamiento entero dependía de una sola válvula que controlaba la presión de una tolva clave. Era una pieza más, pero sin ella no había forma de seguir. Nadie le prestaba atención y nunca había dado problemas.

Cuando llamé a mantenimiento me dijeron: «Esa válvula nunca se cambia porque nunca falla».

Pero un martes, se trabó y hasta ahí llegamos.

En ese punto entendí de la peor forma que la válvula no fallaba porque a nadie la molestaba (no fallaba porque fuera confiable). O quizás sí fallaba y el sistema se adaptaba sin que lo notáramos. O peor: tal vez su prestigio como pieza invulnerable dependía justo de que colapsara en el peor momento, para que por fin le prestáramos la atención debida.

La producción se detuvo por tres días porque no existía un repuesto. No había modo de operar sin esa pieza.

Por cierto, más tarde supe que esto tiene un nombre elegante en gestión: Theory of Constraints. La idea es simple, casi obvia, pero todos la olvidan. En cualquier sistema hay algo que, sin saberlo, determina la velocidad y el rendimiento de todo lo demás. Esa válvula era el cuello de botella perfecto, invisible hasta el día que decidió recordarnos su existencia. Según ese enfoque, uno debería buscar esa restricción, entenderla, reforzarla y solo después pensar en mejorar el resto. Nosotros hicimos todo al revés: optimizamos cada parte sin mirar el punto que podía arruinarlas todas.

Recuerdo que conversábamos con otros colegas por qué nadie lo había previsto. La respuesta era simple: mientras funcionaba, nadie quería meterse.

Recuerdo que un técnico alguna vez dijo que esa válvula «estaba bendecida» y lo dijo en serio. Como si hubiera una superstición tácita: si la tocamos, se rompe. Así que mejor ni mirarla. Esa mezcla de respeto y miedo disfrazada de racionalidad es una forma bien rara de fragilidad. Y lo peor es que se instala como costumbre: nadie la cuestiona, solo se repite.

Y ahí me di cuenta de algo que no estaba en ningún manual. La superstición del técnico sobre la válvula “bendecida” probablemente ocultaba algo más terrenal. Tendemos a pensar que la fragilidad es un error de diseño que todos quieren arreglar. En realidad, la fragilidad puede ser un recurso valioso. Para la planta, que solo una persona entendiera esa válvula era un riesgo catastrófico. Para esa persona, era la mejor póliza de seguro laboral imaginable. Convertirse en el único punto de falla es una estrategia de poder sorprendentemente efectiva. El conocimiento tácito funciona como capital. Mientras permanezca en una sola cabeza, esa cabeza se vuelve indispensable y define las reglas.

Y cuando eso pasa, el sistema deja de ser técnico y empieza a ser político. Una válvula rota espera a que la repares, pero un cuello de botella humano se las arregla para no ser reemplazado. Cada intento de documentar su tarea o capacitar a otro se lee como una amenaza. Surgen explicaciones razonables, casi elegantes: “es demasiado complejo de explicar”, “el reemplazo lo hará mal”, “esto se hace por experiencia, no por manual”. Al final, el sistema protege su punto más débil porque ese punto aprendió a protegerse solo.

En teoría, los tres cambios que hicimos después (mapear dependencias, crear redundancias, desacoplar) parecían una respuesta perfecta. En la práctica, solo arreglamos la superficie. El problema no era la ingeniería, eran los incentivos. Seguíamos premiando al que guardaba el conocimiento y castigando al que lo compartía. Nadie tenía motivos para volverse prescindible. Con el tiempo entendí que un sistema se vuelve realmente robusto cuando la gente no teme enseñar lo que sabe. Cuando ser reemplazable deja de ser una amenaza y empieza a ser una señal de confianza.

Y eso cambió mi forma de ver todo. Desde entonces aprendí que algo puede operar sin inconvenientes durante mucho tiempo y, aún así, estar mal armado. Un sistema que depende de un único componente esencial es vulnerable. Y muchas veces esa debilidad no se nota. Queda oculta detrás de la costumbre, el ritmo de trabajo o la eficiencia diaria.

A veces solo una persona maneja cierta herramienta, o un cliente representa la mayoría de los ingresos, o una función entera depende de un software que nadie más puede tocar. Mientras todo siga igual, parece que no hay problema.

Parece, pero no aguanta.

Y eso es poco probable que sea sostenido en el tiempo.

Las personas se enferman. Los sistemas fallan. Los clientes se van. Y no hace falta pensar en escenarios extremos para aceptar esto. Basta con asumir que todo lo que involucra a personas o herramientas puede fallar alguna vez.

Y este es un problema técnico.

Una organización incapaz de adaptarse ante un error no es débil por accidente. Lo es principalmente por cómo fue construida.

A menudo, esa construcción sigue una lógica bastante clara: hacer más con menos. Menos personas, menos niveles de revisión, menos margen de error. Y mientras nada falle, parece que todo encaja. Pero cuando falla, no hay cómo sostenerlo.

Cuando las cosas funcionan y fluyen bien nadie quiere cambiar nada. Y es precisamente ahí donde la eficiencia mal entendida se vuelve adictiva porque “evita preguntas”.

En ese punto entendí otra cosa. Lo que en ingeniería llaman redundancia no es lujo, es precaución. Tener un plan B no es ineficiencia, es fiabilidad. Durante años, el ideal fue eliminar duplicaciones y excesos, hasta que un día descubrimos que habíamos eliminado también la posibilidad de respirar. La redundancia es esa red invisible que solo se nota cuando falta. En nuestra planta se tradujo en un repuesto extra y en más gente capacitada para cambiarlo, pero el principio vale igual para cualquier equipo. Lo curioso es que la cultura del ahorro suele borrar justo aquello que mantiene viva la operación.

Y eso tiene un costo que precisamente nadie ve. A veces es un componente, otras veces es una persona o también una regla que todos siguen pero nadie recuerda por qué. A veces todo funciona solo porque alguien —o algo— está absorbiendo el peso sin decir nada. Y mientras nadie lo diga en voz alta, nadie se hace cargo.

No hay que imaginar un desastre. Solo aceptar que todo en algún momento puede fallar.

Y aquí justo nace la paradoja. Hay un punto en el que la obsesión por evitar la fragilidad termina fabricando otro tipo de debilidad. Cuando cada decisión necesita duplicación, revisión cruzada o respaldo inmediato, el sistema se vuelve incapaz de moverse con soltura.

La prevención se transforma en trámite. El miedo a fallar puede inmovilizar tanto como la falla misma. He presenciado algunos proyectos que nunca arrancaron porque todo debía estar garantizado de antemano, incluso lo improbable. Se quebraron por una especie de pánico estructural que los dejó sin margen para poder improvisar. A veces el problema es diseñar una máquina tan protegida que ya no sabe moverse (y no necesariamente depender de una pieza).

A partir de ese momento, dejé de pensar solo en eficiencia y empecé a pensar en distribución de dependencia. La idea no es duplicar todo ni hacer todo más lento. Es evitar que una falla específica tenga el poder de frenar el sistema entero.

Y cuanto más lo pensaba, más claro se volvía. Lo que realmente confunde es la ilusión del mantenimiento. Esa sensación de que algo es fuerte solo porque sigue funcionando.

Igual que una puerta que siempre abre fácil y nadie revisa, los sistemas tienden a confundir duración con resistencia. Cada día sin fallas refuerza la creencia de que nada puede romperse. Es un sesgo colectivo: cuanto más tiempo pasa sin problemas, menos ganas hay de mirar debajo.

Aunque a veces me pregunto si no nos pasamos de vuelta. En el intento de protegernos de errores, a veces armamos sistemas tan enredados que ya nadie sabe cómo funcionan. Y ahí ya no fallan por frágiles, fallan porque nadie se atreve a tocarlos.

Ahí fue cuando decidimos hacer tres cambios concretos:

Primero, revisamos todo lo que no tenía reemplazo. Después del problema con la válvula, armamos un mapa con las dependencias que no estaban anotadas en ninguna parte. Salieron cosas del día a día: como que solo una persona sabía cómo reiniciar el sistema si se cortaba, o que un proveedor mandaba productos sin orden de compra porque ya lo hacíamos así hace años. Eran cosas que funcionaban, siempre y cuando nadie faltara.

Segundo, armamos algunas redundancias. No todo se puede duplicar, pero hay cosas que sí. En nuestro caso fue tener otra válvula de repuesto y capacitar a más personas para cambiarla. En otros lados puede ser algo distinto: turnarse roles, dejar procesos escritos, compartir tareas clave. En fiabilidad organizacional, eso se llama redundancia: no por exceso, sino por precaución. Es lo que permite que el sistema respire sin ahogarse ante un imprevisto.

Tercero, cambiamos parte del diseño para que los errores no se propagaran. Cada parte de la línea podía pararse sin afectar a las otras. Como los tableros eléctricos segmentados: si se sobrecarga un tramo, no se apaga todo. Ese tipo de separación en ingeniería se llama acoplamiento débil. Es una forma de evitar que una falla se propague.

Y lo curioso es que ese acoplamiento débil tiene su equivalente en operaciones. Se llama desacoplamiento, y no tiene que ver con cables ni motores, tiene que ver con dejar espacio entre los eventos.

En las cadenas de producción o en los proyectos, significa crear buffers que detengan el efecto dominó. Un error puede ocurrir, pero no arrastra a los demás. Es la diferencia entre tener una línea continua que se apaga entera y una red modular que puede aislar el daño. Es la clase de diseño que nadie nota hasta que salva el día.

Meses después de implementar todo eso, falló el transformador. Teníamos protocolos, backups, piezas de repuesto. Pero nadie supo cómo detener la línea en modo seguro. El rediseño había sido perfecto. El uso real, no tanto. A veces los nuevos sistemas también fallan porque nadie quiere tocarlos hasta que fallan. Es el mismo patrón, solo que disfrazado de otra cosa.

Y si uno busca un paralelo fuera del trabajo, hay un ejemplo natural que encaja demasiado bien en esto: en ciertos ecosistemas tropicales la vegetación parece inagotable, pero depende de una capa mínima de nutrientes en el suelo. Mientras nada interrumpe el ciclo, todo florece. Una sequía prolongada basta para que el suelo se agote y el bosque se vuelva frágil de golpe.

En organizaciones ocurre algo parecido. La apariencia de estabilidad puede esconder una estructura sostenida por pocas conexiones críticas. No se nota hasta que se corta una y el conjunto entero pierde su capacidad de regenerarse. Lo más llamativo es que el colapso llega como una lentitud progresiva y no de golpe. Un sistema deja de responder, pero todos creen que sigue vivo porque todavía se mueve.

Un sistema que depende de que todo salga bien para operar no es confiable. Es frágil.

Si lo piensas bien, hay sistemas que ni siquiera toleran el error y mucho menos aprenden de él. Taleb usa la palabra “antifrágil” para describir sistemas que no solo aguantan el caos, también crecen con él. No Aprovechan los errores y no los bloquean. Pero eso solo pasa cuando el error tiene espacio para ocurrir sin destruirlo todo.

Todavía se arman proyectos que dependen de una sola persona o de un único punto de decisión. A muchas veces nadie cuestiona eso porque cambiarlo es un lío y mientras funcione, se deja tal como está. Pero ese tipo de dependencia se acumula y nadie la ve hasta que estalla.

A veces lo tenemos claro. Sabemos que estamos dependiendo demasiado de algo o de alguien. Pero igual seguimos, porque meterse ahí desordena todo. Y mientras no pase nada, es fácil dejarlo para después.

Hasta que ocurre. Y arreglarlo sale mucho más caro que haberlo prevenido.

Desde entonces, trato de dejar siempre un pequeño margen. Porque si alguien quiere liderar un proyecto, eso no se resuelve con más motivación y frases bonitas, ahí se quiere pensar en estructuras que puedan soportar estos imprevistos.

Y no es algo que me haya pasado solo a mí. Lo he visto repetirse en muchos equipos, en distintos lugares y momentos. Todo funciona mientras haya una persona que lo sostiene. A veces es alguien con experiencia, a veces quien tomó las decisiones desde el principio. Y durante un tiempo, todo parece andar sin problemas. Hasta que esa persona no está, y nadie más sabe si avanzar o esperar.

No siempre es falta de delegación. Muchas veces es que el flujo completo fue armado para depender de un solo punto. Y cuando eso pasa, cualquier imprevisto deja todo en pausa. Por eso, en los proyectos que realmente funcionan, las decisiones clave no dependen de una sola persona, y las reglas permiten que otros puedan seguir sin quedarse paralizados.

No hace falta imaginar escenarios extremos. Basta con aceptar que en algún momento alguien va a faltar. Y el sistema tiene que seguir funcionando igual.

Hay una pregunta que ayuda a verlo rápido: “¿Qué pasa si esto falla?” Cuando la única respuesta es “esto no puede fallar”, es porque nadie ha pensado qué hacer si pasa.

No se trata de duplicarlo todo. El punto es que el error no tenga poder de desarmarlo todo. Y eso no se arregla con explicaciones. Requiere rediseñar el trabajo desde cómo se reparten las decisiones.

El entusiasmo sirve para empezar. Pero si todo depende de eso, no dura mucho. Lo he visto muchas veces: equipos bien intencionados que se vienen abajo porque nadie pensó cómo sostenerlos cuando la energía inicial se apaga. Liderar no es solo motivar, también es construir una estructura que aguante incluso cuando el ánimo no está.

Una buena estructura no llama la atención cuando todo fluye. Pero cuando algo se rompe, sostiene sin desarmar. El objetivo es saber dónde está lo frágil y no eliminarlo. Cuando deja de estar escondido ya no es una amenaza y se vuelve parte del diseño.

DIAGNÓSTICO Y SOLUCIÓN METODOLÓGICA

El caso que presenté en la primera parte identifica correctamente la fragilidad del sistema. Pero me detuve solamente en la observación filosófica y política.

Un análisis de más riguroso Gestión de Operaciones (OM) aplica un conjunto de herramientas sistemáticas para diseccionar y resolver este fallo de forma rigurosa.

A continuación, se desglosa el «caso de la válvula» utilizando tres pilares metodológicos de OM.

2.1. Más allá del cuello de Botella: aplicación completa de la teoría de restbricciones (TOC)

En el ensayo identifico la válvula como un «cuello de botella», lo cual es el Paso 1 (Identificar) de la Teoría de Restricciones (TOC). Pero la gestión real comienza después de la identificación. La planta falló por no aplicar los siguientes cuatro pasos que detallaré a continuación:

1. Explotar la restricción: ¿Estaba la válvula operando a su máxima capacidad? Antes de fallar, ¿recibía el mantenimiento adecuado, la limpieza correcta, la presión operativa óptima? Explotar significa obtener lo máximo de la restricción sin gastar dinero (ej. optimizando su ciclo de trabajo actual).
2. Subordinar todo lo demás: ¿Había otros procesos (no-restricciones) que funcionaban a un ritmo que sobrecargaba o desgastaba innecesariamente la válvula? El sistema debió ajustarse para operar al ritmo que la válvula (la restricción) permitía, protegiéndola.
3. Elevar la restricción: Este es el paso donde se gasta dinero. Solo después de explotar y subordinar, se justifica la «elevación». Esto es exactamente lo que la planta hizo reactivamente: comprar un repuesto, capacitar a más gente. Una gestión proactiva lo habría presupuestado antes del fallo.
4. Repetir (volver al Paso 1): Si la válvula se eleva (ej. se instala una válvula duplicada o de mayor capacidad), deja de ser la restricción. La restricción se moverá a otra parte (quizás el empaquetado, o la tolva de recepción).

En el ensayo use «TOC» como etiqueta para un problema, no como el proceso metodológico que es.

2.2. De la contingencia (reactiva) a la prevención (proactiva)

La parada de tres días se debió a la falta de un repuesto (un fallo de contingencia). En el ensayo propuse la redundancia (tener un repuesto) como solución.

En gestión de operaciones, la redundancia es la última línea de defensa, es costosa (capital inmovilizado en inventario) y reactiva. La primera pregunta operativa no es «¿Tenemos un repuesto?», la pregunta es «¿Por qué falló la válvula?».

Aquí es donde falló el mantenimiento productivo total (TPM):

• Mantenimiento preventivo (MP): ¿Cuál era el tiempo medio entre fallos (MTBF) de la válvula? Un plan de MP habría programado revisiones, lubricaciones o reemplazos antes de que se cumpliera su vida útil esperada, independientemente de si «parecía» funcionar bien. La frase «nunca se cambia porque nunca falla» es la antítesis del MP.
• Mantenimiento Predictivo (PdM): Incluso sin saber el MTBF, se podrían usar técnicas de PdM (como análisis de vibración, termografía o ultrasonido) para detectar micro-fisuras, sobrecalentamiento o fricción antes de que el fallo se volviera catastrófico.

El método más potente para evitar esto es el FMEA (Análisis de modo y efecto de falla). Es un ejercicio sistemático donde el equipo de ingeniería y operaciones habría analizado la válvula y calculado su NPR (número de prioridad de riesgo).

NPR = Severidad x Ocurrencia x Detección

• Severidad: ¿Qué tan grave es el fallo? En este caso, 10 (detiene toda la operación).
• Ocurrencia: ¿Qué tan probable es que falle? El equipo creía que era bajo (ej. 2), pero sin datos de MTBF, era una suposición.
• Detección: ¿Qué tan probable es que detectemos el fallo antes de que ocurra? El ensayo es claro: «Nadie le prestaba atención». La Detección era 10 (imposible de detectar).

Incluso con una ocurrencia baja (2), el NPR sería 10 x 2 x 10 = 200. Un NPR tan alto, impulsado por la Severidad y la (no) Detección, habría forzado un plan de mitigación. La «superstición» del técnico se combate con el cálculo del NPR.

2.3. Sistematizando el «problema humano»: gestión del conocimiento tácito

En el ensayo identiqué el paso de un fallo técnico a uno «político»: el técnico que usa su conocimiento tácito como «póliza de seguro laboral».

Si lo llevamos netamente a la gestión de operaciones, esto no es una reflexión sociológica; es un fallo catastrófico en la estandarización y la gestión del conocimiento.

La «confianza» es un resultado y no un insumo. La respuesta operativa no es pedirle al técnico que «confíe», es implementar sistemas que hagan irrelevante su acaparamiento de conocimiento:

1. Trabajo estándar (POE): El conocimiento tácito («se hace por experiencia, no por manual») debe convertirse en conocimiento explícito. Se debe documentar exactamente cómo se mantiene, repara y reinicia esa válvula, con diagramas, torques específicos y pasos claros (un procedimiento operativo estándar o POE).
2. Capacitación cruzada (cross-training): Una vez que existe el POE, la organización capacitó y certificó a múltiples personas (3 personas de mantenimiento y 2 operadores de línea) para realizar esa tarea crítica.
3. Matriz de Habilidades (Skills Matrix): Esta es la herramienta visual que previene el riesgo. Es una tabla simple: en un eje están las tareas críticas (ej. «Cambiar Válvula Tolva-A») y en el otro los empleados. Se usan símbolos para indicar quién está «En Entrenamiento», «Certificado» o «Experto/Instructor». Un vistazo a la matriz habría mostrado una sola persona «Experta» para la válvula, exponiendo visualmente el riesgo mucho antes del fallo.

El problema de los «incentivos» se resuelve cuando el incentivo deja de ser «ser indispensable» y pasa a ser «ser capaz de certificar a otros», moviendo al técnico de un rol de guardián a uno de instructor.

PARTE 3: LECCIONES APLICABLES (REFORMULACIÓN OPERATIVA)

 

1. Revisar lo que funciona. Tecnicamente esto es Institucionalizar el FMEA. Aplicar trimestralmente un Análisis de Modo y Efecto de Falla a los 5 procesos más críticos de la cadena de valor, enfocándose en modos de falla con alta Severidad o baja Detección.
2. No sobre-optimizar. Es decir, cuantificar y proteger los Buffers. Mantener inventario de reserva (stock de seguridad) o capacidad ociosa planificada (buffers de capacidad) no es ineficiencia; es el costo calculado de la fiabilidad. Definir el tamaño del buffer en función del riesgo (NPR) y el costo del tiempo de inactividad (Downtime Cost).
3. La fragilidad puede ser un incentivo. Auditar la Matriz de Habilidades. Mapear visualmente las habilidades críticas vs. el personal certificado. Cualquier tarea crítica con un solo punto de falla humano (una sola persona certificada) es una no conformidad que requiere un plan de acción inmediato (Capacitación Cruzada).
4. Documentar es descentralizar. Implementar y auditar el Trabajo Estándar (POE). El conocimiento tácito debe convertirse en Procedimientos Operativos Estándar. La documentación no es un archivo muerto; debe ser utilizada activamente para la capacitación y auditada regularmente (ej. mediante auditorías escalonadas) para asegurar su cumplimiento.
5. Cambiar incentivos, no solo procesos. Vincular los incentivos a la transferencia de conocimiento. Modificar la evaluación de desempeño para que el personal «experto» sea recompensado por el número de colegas que ha capacitado y certificado exitosamente (transición de «héroe» a «instructor»).
6. Redundancia mínima obligatoria.  Establecer una política de «Partes Críticas». Definir qué componentes son SPOF (Single Point of Failure) y mantener un stock de seguridad mínimo obligatorio (basado en el MTBF y el tiempo de entrega del proveedor) para esos ítems, independientemente de los ciclos de optimización de inventario (JIT).
7. Evitar el pánico estructural. Desarrollar y simular Planes de Contingencia. Un plan robusto no solo «existe», sino que se practica (ej. simulacros de parada de emergencia, «disaster recovery drills»). El pánico se reduce con la memoria muscular desarrollada en la práctica del fallo.
8. Prohibido decir “esto no puede fallar”. Asignar Planes de Control a NPRs Altos. Toda vez que un NPR supera un umbral predefinido (ej. 150), es obligatorio asignarle un «Plan de Control» (ej. Mantenimiento Preventivo, Poka-Yoke, Cross-Training) y un responsable de su ejecución.
9. Eliminar dependencias personales. Estandarizar la gestión de proveedores. Un proveedor que envía material sin orden de compra (como en el ejemplo) es un riesgo. Todos los flujos de materiales y datos deben adherirse a procesos estándar (ej. POs, ASN, Facturación), eliminando «acuerdos personales» que no pueden ser auditados o transferidos.
10. OHacer visible la fragilidad. Implementar Gestión Visual (Visual Management). Usar herramientas como la Matriz de Habilidades, tableros Andon (que indican el estado de la línea), y gráficos de control de procesos (SPC) para que cualquier desviación del estándar o punto de riesgo sea inmediatamente obvio para todo el equipo, en lugar de estar oculto en una hoja de cálculo o en la cabeza de un técnico.