Como comenté en el artículo anterior, el tema de los problemas complejos da para mucho, así que he decidido escribir un par de artículos más. Con estos artículos, más la serie de introducción a los sistemas complejos, deberíamos tener herramientas más que suficientes para enfrentarnos a los retos de este mundo cada vez más complejo.
Y si bien es importante conocer qué estrategias usar (o evitar) para enfrentarnos a problemas complejos, casi más importante es saber cómo evitar crear problemas complejos.
Índice
Introducción
Problemas difíciles vs. complejos
Optimización
Optimización local
Soluciones cercanas de optimización
¿Cómo evitarlo?
Optimizar problemas locales
¿Cómo evitarlo?
Optimización global
¿Cómo evitarlo?
Resumen
Introducción
Algo que solemos hacer y que genera, o facilita, la aparición de problemas en sistemas complejos es optimizar.
Optimización: La optimización se refiere al proceso de mejora continua de un sistema, un problema o una solución con el objetivo de obtener los mejores resultados posibles. Este proceso implica normalmente la maximización de ciertos factores deseables (como la eficiencia, la rentabilidad, la velocidad, etc.) y la minimización de otros menos deseables (como los costos, el tiempo, los errores, etc.).
La optimización puede ser un procedimiento sumamente efectivo para tratar con sistemas lineales y predecibles, pero como veremos a lo largo de este artículo, en el ámbito de los sistemas complejos puede llegar a provocar efectos contraproducentes e incluso perjudiciales.
«Primera regla del club de los sistemas complejos: huye de la tentación de optimizar»
Nadie.
Vale, me lo acabo de inventar, pero si trabajas con sistemas complejos, deberías tener esto en cuenta.
Problemas difíciles vs. complejos
Antes de pasar a explicar qué tipos de optimizaciones hay, qué peligros tiene cada una y qué podemos hacer para evitar caer en la trampa, me gustaría resaltar otra diferencia entre un problema difícil (hard) y uno complejo.
Difícil: Un problema fijo con múltiples soluciones que dependen de nuestras decisiones.
Complejo: Un problema dinámico que va cambiando en función de las acciones de otros.
Un ejemplo de problema difícil sería el famoso «problema del viajante». Imagina que tienes que ir a 5 ciudades y quieres encontrar la ruta más corta. El problema es que eso requeriría elegir entre 12 posibles rutas.
Eso no es mucho y una persona podría resolverlo en un tiempo razonable. Pero en cuanto añadimos más ciudades el número de posibilidades aumenta exponencialmente. Por ejemplo, para 10 ciudades ya serían 181.440 rutas diferentes y para 30 ciudades hay más de 4x10^30 rutas posibles.
Es un problema que requiere mucho tiempo y capacidad de cómputo, pero el problema en sí es fijo, no cambia. El número de ciudades, su localización, las conexiones entre ellas y el objetivo final permanecen fijos. Lo que sí cambia es la solución del siguiente paso en función de la decisión que hayamos tomado previamente.
Es decir, en función de la ciudad que elijamos visitar primero, habrá un conjunto disponible de rutas diferentes de si hubiéramos empezado por otra. Así que nuestras decisiones en cada paso, determinan nuestros posibles siguientes pasos.
En cambio, en un problema complejo, las interdependencias e interacciones entre los componentes del sistema harán que el problema en sí mismo vaya cambiando y que tengamos que ir adaptando la solución a dichos cambios.
Veámoslo con un ejemplo. Pongamos que ese viajante es Willy Fog (o el original Phileas Fogg) y que en vez de recorrer 5 ciudades concretas, lo que quiere es dar la vuelta al mundo en el menor tiempo posible. Para ello, usará muchos medios de transporte diferente: tren, bus, avión, barco y lo que haga falta.
En tiempos de Willy Fog (allá por 1870), las opciones eran más limitadas, pero supongamos que es su bisnieto y vive en el presente. Esto le facilitaría mucho la tarea de dar la vuelta al mundo (muchas más opciones), pero debido a la complejidad de los sistemas de transporte actuales (interdependencia entre compañías, itinerarios, horarios, etc.) debería tener mucho más cuidado con las optimizaciones.
Es decir, si decide al milímetro cada paso del viaje, se verá en una situación frágil en la que cualquier retraso puede causar una cadena de retrasos, cancelaciones y nuevos problemas que pueden elevar muchísimo la demora.
Cualquiera que haya enlazado varios vuelos para ir a algún sitio sabrá (a veces a las malas, como en mi caso), que si no dejas tiempo suficiente entre un vuelo y otro, cualquier mínimo retraso te puede hacer perder vuelos y mucho tiempo. Ahora multiplica esto por más vuelos conectados entre distintos países y compañías, barcos, trenes y otros medios de transporte.
Aquí ya podemos empezar a ver esas diferencias entre los problemas en los que la siguiente solución depende de tus decisiones anteriores y aquellos en los que dependes de las acciones de otros (retrasos, aduanas muy lentas, atascos, fallos técnicos, robos, cambios en compañías o aeropuertos, etc.).
Entre otros, en el primer caso, la optimización es posible y deseable, mientras que en el segundo caso un exceso de optimización puede ocasionar el efecto contrario.
Optimización
Cuando hablamos de la optimización de un sistema, o de la solución a un problema, podríamos hablar de dos tipos: local y global.
Vamos a hablar primero de la optimización local, porque es una de las primeras trampas en las que caemos.
Optimización local
Aquí podríamos hablar también de dos casos:
Soluciones cercanas de optimización
Optimizar problemas locales
Lo siento, pero no he encontrado una forma mejor de nombrarlas o diferenciarlas. Ambas serían «optimizaciones locales», pero en el primer caso se refiere más a lo que en matemáticas o ciencias de la computación llaman «local optimum», mientras que el segundo tiene más que ver con poner el foco en los problemas de una parte del sistema.
Vamos a verlas más en detalle.
Soluciones cercanas de optimización
Aunque no tiene por qué ser siempre así, podríamos ver este caso como una optimización temprana. Antes de tiempo.
Si recuerdas, en el artículo anterior hablaba de la exploración y la explotación. Primero exploramos, buscando posibles soluciones, para luego explotar (usar) la mejor solución.
Con problemas simples (un problema fijo con una única solución fija), exploramos hasta encontrar su solución y listo, a explotarla.
Pero en problemas complicados, difíciles o complejos, suele haber varias soluciones. Unas mejores que otras. Si nos paramos en la primera buena solución que encontremos, es muy posible que nos perdamos la mejor solución de todas. O, simplemente, alguna mejor que esa primera que encontramos.
Eso es a lo que se llama «local optima».
Una forma de verlo es imaginarte que vas por el campo y quieres encontrar la cima más alta. Si solo hay un pico grande, la solución es fácil. Empiezas a subir hasta que llegues al punto más alto.
En cambio, si estás en una cordillera, no es tan sencillo. Si empiezas a subir, puede que llegues a lo más alto de un pico, pero no tiene por qué ser al más alto. Es la solución local a tu situación actual (es tu pico cercano más alto), pero no es la solución global (el pico más alto de la cordillera).
Para encontrar el pico más alto de todos, necesitarás no solo subir, sino bajar e ir en otras direcciones, hasta encontrar el pico más alto y luego subirlo. Es decir, explorarás (cambiar de direcciones, bajar, caminar en llano) y explotarás (subir) varias veces hasta encontrar la mejor solución.
Ahora imagínate que hiciste lo de subir a lo más alto del primer pico. Ahora tienes dos problemas:
No es la solución óptima (hay picos más altos y puede que no veas lo que querías ver).
Para cambiar de solución tienes que bajar una montaña muy grande.
Esta es una de las razones por las que tratar de optimizar demasiado pronto en ingeniería se considera una mala idea. Optimizar la solución errónea puede salir muy caro.
Y lo mismo aplica a intervenciones o políticas en organizaciones, criterios a la hora de invertir.
Esto es válido tanto para problemas complicados como complejos, con la diferencia de que el resultado de una optimización local suele ser irrelevante en el caso de los sistemas complejos.
Si un problema complicado es como una cordillera con múltiples soluciones, un problema complejo es como una cordillera que «baila».
No es un problema fijo. Es decir, sería más similar a una cordillera en la que los picos van continuamente cambiando de altura y posición. Esto hace que cualquier optimización sea superflua, ya que mientras explotas alegremente tu solución, el problema ya habrá cambiado y estás trabajando en la dirección equivocada.
En ingeniería, como comenté antes, optimizar una solución demasiado pronto suele ser un problema, pero hay veces que no se trata del tiempo, sino de la información disponible.
Por ejemplo, cuando un equipo de desarrollo no tiene información sobre el impacto de sus cambios en el usuario final, es muy común desarrollar, o mejorar, características que nunca serán usadas. Esto ocasiona una pérdida de tiempo del equipo, de dinero de la empresa y de satisfacción por parte del cliente.
Si cada persona (o grupo) se fija nada más en tus tareas, sus objetivos y su información local, corre el riesgo de trabajar duro en la dirección equivocada, sin saberlo.
Eso puede funcionar bien en problemas fijos y bien acotados. Cada agente hace su tarea bien y el proyecto sale bien. Pero en entornos complejos, es necesario que cada agente pueda ver la «foto global», que tenga información rápida del impacto de sus acciones y debe ser capaz de reaccionar en consecuencia.
Esto no solo ocurre en ingeniería o en empresas. También podemos verlo en medicina, el entrenamiento y, muchas otras áreas.
Por ejemplo, es muy común que si tienes un dolor de rodilla, vayas a un especialista en la rodilla que te examine todos los tejidos de la rodilla, pero no te mira la cadera, el pie, cómo te mueves con fatiga muscular, nivel de estrés, alimentación, etc. Al final, está usando información local, cuando en un sistema tan interconectado como el cuerpo humano, nada pasa de forma aislada.
Otro ejemplo de usar información local, o temprana, serían las pruebas de imagen para dolores crónicos de espalda. Cuando se encuentra el más mínimo problema en una prueba de imagen (una protusión o una hernia en un disco vertebral, por ejemplo), no se suele mirar mucho más lejos y asociar el dolor con ese hallazgo.
Curiosamente, la evidencia científica dice que es normal que a partir de los 30 años se vean este tipo de hallazgos en personas que no sufren ningún tipo de dolor en la espalda. Y que no tiene por qué existir una relación entre estos y el dolor que se sufre. Puede haber muchas otras causas que ni siquiera se miran por habernos parado en la primera pista del posible problema.
Optimizar problemas locales
Otro caso de optimización local es cuando queremos optimizar una parte del sistema o promovemos que cada componente optimice su forma de actuar.
Esto ocurre mucho en organizaciones, donde, debido a los incentivos de la misma, su cultura u otras razones, cada departamento se preocupa de hacerlo lo mejor posible, sin tener en cuenta cómo afecta al resto de la organización.
La teoría es que si cada departamento lo hace lo mejor posible, la organización lo hará lo mejor posible, pero esto no es solo poco realista, sino que no tiene en cuenta la interacciones entre los agentes del sistema (tanto los departamentos como las personas individuales), o agentes externos.
Es decir, ignora los principios básicos de los sistemas complejos.
Esto ocurre mucho cuando usamos estrategias reduccionistas (de las que hablé en el artículo anterior) para «mejorar» un sistema complejo.
Por ejemplo, tratar de mejorar una parte del cuerpo, un departamento en una empresa, un proceso en una organización, etc. de forma aislada, sin tener en cuenta el resto del sistema.
A veces, ni siguiera tiene que ser una parte física, puede ser un comportamiento, cualidad o capacidad. Un ejemplo de esto sería tratar de mejorar muy rápido la fuerza (muscular), sin tener en cuenta la distinta velocidad de adaptación de otras partes importantes como los tendones.
Es muy común en ciertos deportes trabajar la fuerza y la explosividad antes de que el resto del sistema esté preparado para soportar esos esfuerzos. Esta optimización de una parte respecto a otra crea desequilibrios que ponen al sistema en un estado más frágil y es común que aparezcan lesiones.
Lo mismo ocurre si trabajamos de forma aislada los músculos grandes, encargados de mover las extremidades (y que se ven bien en el espejo), de forma aislada. Esos músculos, cuando nos movemos normalmente, no funcionan solos. Requieren otros músculos más pequeños para estabilizar las articulaciones, así como la participación de los tejidos conectivos (fascia, tendones y ligamentos), la propiocepción, el equilibrio, la coordinación del sistema nervioso, etc.
Al final, estamos creando una eficiencia local ficticia, que normalmente no aporta los beneficios globales que buscamos. Esto puede crear desequilibrios que el resto del sistema puede no soportar.
Si no, mira cuánta gente es capaz de tirar de su peso en una máquina, pero no es capaz de hacer una dominada. Siendo (aparentemente) el mismo movimiento. En cambio, cualquier persona que haga una dominada puede tirar de su peso en una máquina.
En empresas es muy común ver que la velocidad de «producción» es muy diferente entre departamentos, lo que crea «cuellos de botella» y retrasos de los resultados globales. A lo mejor, el departamento de ventas vende y crea expectativas en clientes que los departamentos que producen el producto no son capaces de cumplir.
O, quizás, se produce más de lo que se puede vender, generando un exceso de inventario y pérdidas.
En una empresa de desarrollo de software, puede que el equipo de desarrollo genere cambios a un ritmo que el equipo que despliega y mantiene el producto no puede mantener. Esto puede crear una sobrecarga en este último, haciendo que tarde aún más y que los cambios tarden más en llegar al producto final.
O, peor aún, que se salten pruebas y pasos de seguridad, para poder mantener el ritmo, y se entregue un producto de menor calidad o inseguro.
Debido a los incentivos individuales y por departamentos, este tipo de problemas es muy común en las empresas. Cada departamento suele encargarse de su parte, sin tener en cuenta el resto de la «cadena de valor». Es decir, se centran en el objetivo local, sin tener en cuenta el objetivo global.
Se centran en el objetivo local, sin tener en cuenta el objetivo global.
¿Cómo evitarlo?
Aumentar la visibilidad de los resultados globales
Rotaciones temporales (para aumentar entendimiento del resto del sistema y empatía con otros agentes)
Tener un feedback directo del impacto de las acciones locales en el objetivo global
Crear incentivos que fortalezcan el objetivo global frente al rendimiento individual o local
Inyectar diversidad cada cierto tiempo
Añadiendo o cambiando agentes
Cambiando incentivos
Crear procedimientos para cuestionar, o revisar, las soluciones de forma periódica
Evitar incentivos que promuevan la productividad constante y la máxima eficiencia individual
Evitar promover el «estar ocupados» (solamente explotar)
Crear incentivos que promuevan la exploración
«Cuando la única herramienta que tienes es un martillo, todo problema comienza a parecerse a un clavo»
En muchos casos, se puede ver esta famosa frase como una optimización local, ya que te quedas en la primera solución que tienes, sin buscar otras. Esto sucede mucho cuando en un grupo, o una persona, existe poca diversidad de herramientas, estrategias, formas de pensar y puntos de vista.
Esto nos da una pista, la diversidad es clave para evitar caer en esta trampa. Como vimos en el artículo sobre la diversidad, no siempre más diversidad será mejor. Por ejemplo, un grupo menos diverso puede estar más enfocado y ser más productivo que uno muy diverso. Mientras que si hay más diversidad, habrá más posibilidades de innovación y de salir de esta «local optima».
Por lo tanto, lo que seguramente querremos es inyectar algo de diversidad cada cierto tiempo, para asegurarnos de que no nos «dormimos en los laureles» y seguimos trabajando en una solución, que ya no es óptima.
Esta diversidad se puede añadir mediante nuevos agentes, cambios en los incentivos, o procedimientos que promuevan las soluciones alternativas cada cierto tiempo.
Los sistemas tienden a la homogeneidad, así que, por mucha diversidad inicial que haya, con el tiempo, se irá perdiendo.
Hay empresas que promueven que sus empleados roten por varios equipos, eso les permite tener una visión más amplia de la empresa, aprender de gente diferente y añadir diversidad allá donde van.
Alguna empresa de software hace que sus programadores pasen un tiempo en soporte al cliente, para que conozcan de primera mano cómo impacta su trabajo a dichos clientes. Les puedo asegurar que esto le abre los ojos a muchos ingenieros y hacen que entiendan mejor su trabajo y el valor que aportan.
En general, evitar quedarnos con la primera solución y buscar continuamente nuevas soluciones (aunque creamos que hemos «solucionado» el problema) es fundamental cuando trabajamos con sistemas complejos. Así como tratar de buscar el impacto global de cualquier intervención que hagamos, no quedarnos en el impacto local.
Y, a ser posible, crear incentivos que promuevan la exploración cada cierto tiempo. Esto será necesario porque nos olvidaremos, nos volveremos cómodos y necesitamos que nuestras soluciones sean tan dinámicas como los problemas.
Optimización global
En un sistema complejo, la principal fuente de incertidumbre es la interacción entre agentes o componentes. Por esta razón, tratar de optimizar el sistema ajustando al máximo la eficiencia en dichas interacciones suele ser una muy mala idea.
Lo veíamos con Willy Fog. Tratar de ajustar las conexiones entre medios de transporte para ahorrar tiempo, dinero o energía, da como resultado un sistema altamente frágil ante cambios en cualquier punto de la cadena. Un retraso, un atasco, una huelga, un robo, una revuelta en un país inestable... cualquier cosa puede ocurrir y hasta la más mínima ocasionaría un retraso en cadena que destruiría el plan original.
Podemos ver lo mismo en el tráfico. Si cada coche va muy pegado al siguiente, para «optimizar» y usar menos tiempo y espacio, cualquier frenazo o, incluso, disminución de la velocidad, causará atascos o accidentes.
También podemos verlo en proyectos. Si ajustamos mucho el tiempo entre que una tarea pasa de un estado a otro, o de un departamento a otro, cualquier variación producirá retrasos en cadena. Lo mismo ocurre con el presupuesto.
Por ejemplo, ajustar tanto el presupuesto para organizar un evento que lo gastas todo, no es muy buena idea. Habrá imprevistos (problemas con proveedores, multas, horas extra, cambios en vuelos o estancias de invitados, etc.) y necesitarás un «colchón» que te permita poder reaccionar y adaptarte a ellos.
¿Cómo evitarlo?
Creo que en el caso de la optimización global se ve más claramente qué produce el problema y cómo evitarlo. Básicamente, lo que tenemos que hacer es evitar una optimización excesiva en los procesos de comunicación entre los distintos componentes.
Debemos dejar cierta holgura (slack) que haga de amortiguación (buffer) en caso de imprevistos.
Cuánta holgura dependerá del caso y el sistema, pero, en general, dejar entre un 10% y un 20% de holgura es recomendable en la mayoría de los casos.
Los fanáticos de la eficiencia se echarán las manos a la cabeza porque eso puede suponer dejar un 20% del tiempo de un equipo sin planificar. A muchos gerentes o jefes de proyecto les pone nerviosos pensar que hay gente que no es productiva el 100% del tiempo. Pero es precisamente esto lo que produce la mayor parte de fracasos en proyectos y planificaciones.
Siempre aparecerán tareas inesperadas o habrá que lidiar con errores e imprevistos. Si todo nuestro tiempo está ya organizado, tendremos que robar parte de ese tiempo ya planificado para «apagar fuegos». Nuestro equipo estará en modo reactivo constantemente y nuestra planificación se retrasará cada vez más.
Si somos entrenadores, podríamos estar tentados a diseñar estrategias y tácticas al milímetro, pensando que conocemos todos los posibles factores. Algo realmente imposible cuando tratamos con personas (sistemas muy complejos) interactuando unas con otras en el gran sistema complejo que es un partido.
Lo mismo podría decirse de las tácticas militares.
«Planeo mucho mis batallas, aunque nunca me salen como las planeé.»
Napoleón Bonaparte
Otro ejemplo sería tratar de hacer la técnica perfecta para cualquier movimiento. Un robot puede repetir un movimiento mil veces de la misma forma, un ser humano no. Debido a que somos un sistema complejo y por todo lo que explicaba en el artículo de la autoorganización, nunca repetiremos dos veces el mismo movimiento. Lo cual es bueno.
De hecho, en el artículo comentaba como esa variabilidad nos permite adaptarnos mejor a los cambios en el entorno, la tarea y otros agentes. Pretender hacer una técnica perfecta, repitiendo ciertos movimientos siempre de la misma forma, reduce esa variabilidad, esa holgura que crea el sistema, volviéndolo frágil ante cambios.
Imagen del estudio de Nikolai Bernstein donde descubre (en 1923) que, a diferencia de los novatos, los maestros herreros nunca repetían el mismo movimiento. Tenían más éxito dando con el martillo en el mismo punto con movimientos más variados (distintas partes del cuerpo autoorganizándose en función de la situación).
En resumen, queremos dejar cierto espacio para la autoorganización en el sistema, para que sea flexible y capaz de reaccionar ante pequeños cambios y perturbaciones sin causar un gran impacto en el sistema.
Y recuerda, esta holgura o espacio puede ser tiempo, pero también espacio físico, energía, presupuesto, etc. Básicamente, esta holgura se puede aplicar a cualquier recurso que estés considerando optimizar.
Resumen
Optimizar y ser eficientes es algo que buscan muchas empresas y personas en múltiples ámbitos. En entornos lineales, delimitados y predecibles, es posible ajustar mucho los procesos y las partes para conseguir esa optimización. Pero en sistemas complejos, optimizar demasiado puede ocasionar muchos problemas.
En general, en los sistemas complejos, la optimización de las soluciones no suele ser tan relevante como en otro tipo de sistemas, ya que el problema cambia constantemente. Así que la solución también debe hacerlo.
La optimización excesiva genera muchos problemas en sistemas complejos, así que haremos bien en evitar optimizar muy pronto y buscar constantemente nuevas soluciones.
Además, las interacciones entre los agentes o componentes del sistema son un punto crítico que debemos cuidar. Son la mayor fuente de incertidumbre, así que nos vendrá bien añadir cierta holgura a dichas conexiones. Dejar cierto espacio para la variabilidad y la autoorganización.
Espero que las ideas principales hayan quedado claras. He tratado de poner ejemplos variados para que se pueda ver cómo aplica en distintos ámbitos. Te invito a que trates de aplicar dichos conceptos a aquellas áreas que mejor conozcas.
Fascinating article Juanje!
I really like that it’s well written with a story telling and multiple examples to make it thus very complex (pun intended:)) to explain topic clear and simple as possible.
I’m fascinated with going against the instinct to control and leave buffer while injecting diversity from time to time and how to apply that to multiple fields.
Looking forward to your next article!
P.S it was worth translating it to English to make it broadly available .