Una empresa no es más que una unidad de sistemas simples dentro de otros más complejos. Un negocio es un proceso repetitivo que crea riqueza. Lo demás son entretenimientos ¿Me aceptas la premisa?

Un buen empresario debe saber construir sistemas complejos pero antes deberá aprender que los complejos surjen de los simples.

Un negocio es un proceso repetitivo que crea riqueza. Lo demás son entretenimientos. ¿Me aceptas la premisa?

Te propongo el siguiente ejercicio para el año que viene. Partiendo de la nada, tienes que construir un cohete que llegue a la Luna. ¿Verdad que saldrá un churro? ¡Toma y a mí! Ahora podríamos intentarlo con un nuevo programa de IA, con una nueva vacuna contra la COVID o con cualquier nuevo producto o servicio que queramos vender. En todos los casos volveremos a fracasar. Quería decir aprender… ¿Y por qué nos cuesta tanto construir sistemas complejos partiendo de cero? Pues porque los sistemas diseñados a partir de la nada nunca funcionarán porque no han soportado las pruebas de realidad que necesariamente validan su sentido. Si quieres construir un sistema que realmente funcione, antes empieza por uno simple. Por el principio.

John Gall fue un médico y escritor estadounidense conocido por su libro «Systemantics: How Systems Work and Especially How They Fail«, publicado en 1975. En este libro, Gall presenta una serie de observaciones sobre cómo funcionan los sistemas complejos y por qué a menudo fallan. En esencia, esta ley sugiere que los sistemas complejos tienden a evolucionar desde sistemas más simples que eran funcionales. Sin embargo, tratar de diseñar directamente un sistema complejo desde cero te llevará al fracaso, y en lugar de intentar parchearlo,  es siempre más efectivo reemplazarlo por uno nuevo que sea más simple y funcional.

Un sistema complejo que funciona es aquel que surge invariablemente de otro más simple que ya funcionaba. La proposición contraria también es verdadera y nos dice que un sistema complejo diseñado de la nada nunca va a poder funcionar por el mero hecho de que antes debe haber otro más simple que lo soporte.

SEgundo principo y tan o más interesante aún: Un sistema que no funciona, nunca funcionará parcheándolo sino que debe ser reemplazado por otro rediseñado.

Cuando entiendes bien este principio, tu vida cambia.

Un par de ejemplos de meteduras de pata personales que he sufrido en mi carrera y que ilustran bien la «Ley de los Sistemas Complejos» de John Gall:

Ejemplo 1: Sistema de comunicación en una oficina pequeña: Supongamos que, en una pequeña oficina, los empleados se comunican de manera efectiva usando notas pegadas en un tablero. Los típicos post it de colores que usamos en cualquier pizarra de Kanban -nota 1-. Este sistema simple funciona bien porque todos pueden ver las notas y estar al tanto de la información relevante. Llega un día y a mí se me ocurre introducir un sistema de software más complejo para gestionar la comunicación. Este nuevo sistema lleva tiempo implementarlo y capacitar a los empleados para usarlo, y al final, resulta difícil de entender y usar en comparación con el tablero de anuncios original. A pesar de los esfuerzos por mejorar la comunicación, el nuevo sistema termina siendo arrinconado al ser menos práctico y visual que el sistema simple original de notas en la pizarra.

Otro ejemplo que me pasó con uno de mis clientes de una clínica dental:  Imagina una clínica pequeña en la que los pacientes llegan, se registran manualmente y luego se colocan en una lista de espera visible para los dentistas. Este proceso es simple y directo. Sin embargo, con la intención de modernizar y mejorar la administración, decidimos implementar un sistema informático completo para el seguimiento de pacientes, citas y registros médicos mucho más moderno y visual. A medida que se introduce el nuevo sistema, los problemas de compatibilidad, los fallos técnicos y la curva de aprendizaje resultan ser mayores de lo esperado. La complejidad del nuevo sistema causa retrasos en la atención y confusión entre el personal. En última instancia, el sistema informático resulta ser menos efectivo que el sistema manual original, a pesar de la intención de mejorar la calidad de la atención médica.

En los dos ejemplos cometí el mismo error, incorporar sistemas más complejos sisn testearlos en lugar de confiar en sistemas más simples y funcionales resulta en problemas y dificultades.

La lección que nos traslada la Ley de Gall es que en lugar de construir un producto desde la nada, es mucho más inteligente hacerlo partiendo de un prototipo, lo que hoy llamamos Producto Mínimo Viable (PMV) -nota 2-. Parace una perogrullada, pero casi nunca lo hacemos. Debemos crear prototipos simples y usar la repetición en entornos reales hasta conseguir crear “un producto o servicio de valor”.

Aplica el principio de Gall a todo: a tu organigrama, al diseño de productos, a tus campañas de marketing, a l forma en la que contratas a tu personal, a su formación de, a tu educación financiera o a tu receta a de cocina favorita, … Al principio debemos crear prototipos SIMPLES y usar la repetición en entornos reales hasta conseguir crear “un producto o servicio de valor”. Antes de correr, hay que gatear y luego caminar, dicen sensatamente nuestros mayores.

¿A que mola esto de Gall?

[1] Una pizarra Kanban es una herramienta visual cuya representación puede ser física o digital de un flujo de trabajo o proceso que ayuda a visualizar y gestionar las tareas o elementos ¡Te la recomiendo!

[2] El concepto de «Producto Mínimo Viable» (en inglés, Minimum Viable Product o MVP) se atribuye a Eric Ries, un empresario, autor y consultor en desarrollo de negocios y tecnología. Eric Ries es conocido por popularizar y promover los principios del desarrollo ágil y la metodología Lean Startup, que se centra en la creación y gestión eficiente de nuevas empresas y productos.