Hay momentos en los que un sistema (una empresa, un software, un protocolo administrativo…) empieza a comportarse como esa lavadora redonda que tenía tu mamá por allá en los noventa: mucho ruido, gasta mucha energía, da vueltas innecesarias y, con suerte, termina haciendo bien su trabajo. A veces, un sistema sigue operativo, pero nadie sabe cómo ni por qué.

En mi casa, por ejemplo, hay una luz que solo funciona si enciendes otra primero. La regla carece de lógica, pero la seguimos sin pensar. Así operan demasiados procesos laborales.

Cumple su función con una complejidad exagerada. Rara vez es accidental. A menudo indica que algo esencial dejó de funcionar correctamente.

Mi modelo actual para entender este fenómeno plantea que, a partir de cierto umbral, la complejidad añadida a un sistema deja de ser una mejora y pasa a ocultar una falla fundamental. Pareciera que cada paso nuevo se justifica de forma aislada, pero el efecto acumulativo sugiere que el sistema cruzó una línea invisible.

Desde ese punto, cada capa adicional de burocracia o cada nueva función de software aporta un valor marginal negativo. Podríamos estar observando una manifestación de rendimientos decrecientes tan severa que el propio acto de «mejorar» el sistema lo vuelve funcionalmente peor, más opaco y más costoso en términos de energía para quienes deben operarlo.

Se cruzó un límite; seguir sumando capas impide mejoras reales. Puede llevar a que el sistema funcione, pero sea cada vez menos claro, menos manejable y más molesto para los usuarios.

Todo sigue operativo bajo una lógica incomprensible. Y cada tarea simple se vuelve una cadena de pasos sin valor.

Esto ocurre con frecuencia en procesos que alguna vez fueron eficientes. Un software interno, por ejemplo, puede empezar ágil y sencillo y, con los años, volverse lento y engorroso.

Pienso en un caso real: en un antiguo trabajo, el sistema para subir visitas regulatorias tardaba quince minutos en abrir y otros quince en guardar cambios. Como el sistema sigue dando algún resultado, nadie se detiene a pensar si otro enfoque más simple lo haría mejor.

La complejidad innecesaria rara vez nace de la improvisación; suele venir de gente competente intentando solucionar problemas concretos con medidas puntuales. Surge de soluciones específicas que nunca se revisan; con los años se acumulan y terminan volviendo el sistema torpe y poco eficiente.

Estos sistemas operan como una red de tuberías improvisada. Faltó un plano maestro; hubo generaciones de técnicos añadiendo codos, válvulas y derivaciones para resolver fugas inmediatas. La red se mantiene sellada, pero la presión cae dramáticamente en cada giro innecesario. 

Lo notable es que nadie se atreve a enderezar el trazado porque ya forma parte de la infraestructura crítica, aunque el caudal final sea un hilo comparado con la energía inyectada al inicio. Lo que queda es una calcificación de decisiones pasadas que estrangula el flujo, muy lejos de cualquier diseño eficiente.

En varias ciudades medievales existían instituciones que funcionaban más como un software imposible de cerrar que como mecanismos útiles. Los gremios podían seguir cobrando cuotas aunque ya no fabricaran nada y los tribunales repetían ceremonias que habían perdido todo sentido. A nivel conceptual era pura inercia, pero a nivel práctico mantenía el orden lo suficiente para que la vida continuara. 

Es como un sistema operativo en “modo compatibilidad”, donde el miedo a apagarlo pesa más que la función original. Tiene lógica, porque la caída de una institución absurda puede ser más costoso que su supervivencia como reliquia. La tradición, vista desde este ángulo, equivale históricamente a nunca reiniciar la computadora por miedo a que no arranque.

Algo similar ocurre con la llamada Valla de Chesterton. Antes de derribar una estructura absurda, muchos prefieren detenerse a pensar en un posible propósito oculto. La calle estrecha de una ciudad antigua puede parecer inútil hasta que alguien recuerda que fue diseñada para frenar caballería enemiga o proteger del viento invernal. Aunque la razón original carezca de sentido hoy, la mera posibilidad de que lo tuviera produce parálisis. El temor a consecuencias imprevistas basta para mantener en pie burocracias enteras. El sistema sobrevive porque el costo de su ineficiencia es conocido, mientras que el costo de eliminarlo es un misterio que nadie se arriesga a descubrir.

Cuando eso ocurre por años, aparece una criatura especial: el “sistema zombi administrativo”. Camina, firma papeles, notifica por correo… pero su lógica murió hace tiempo.

Si nadie depura lo inservible, esas soluciones se acumulan. Se transforman en una mezcla de excepciones, validaciones, permisos y reglas que solo unos pocos entienden bien.

Es como ir a la notaría: sacas un número para esperar que un señor timbre un papel que certifica que estás vivo. Nadie sabe por qué el timbre da fe, pero sin el timbre, no existes. Pasa igual con los formularios del Estado: cada campo obedece a una norma, una ley, una necesidad. Pero al final, el documento es tan enredado que ni quienes lo diseñaron logran explicarlo con claridad.

Aquí vale la pena aplicar un principio de ingeniería inversa antes de la demolición. Más que por respeto intelectual, se trata de evitar cortar el cable rojo equivocado. Un formulario de veinte páginas puede parecer un monumento a la torpeza, pero cada apartado suele tener su origen en un problema real. Una casilla sobre el tipo de tinta tal vez surgió tras un escándalo de falsificaciones en los años ochenta, y una sección redundante puede haber sido añadida por demandas de accesibilidad en los dos mil. El sistema informático que procesa todo esto quizá siga en COBOL porque migrar décadas de datos sería más arriesgado que mantener el dinosaurio. Lo que parece ineptitud es, en muchos casos, una colección de cicatrices institucionales. El conjunto es un equilibrio frágil mantenido a fuerza de remiendos.

Pero cuidado con la justificación histórica. Explicar el origen del tumor no lo hace menos nocivo. Saber que la casilla de «tipo de tinta» tiene historia ayuda al análisis, pero no valida que el operario pierda tiempo hoy.

Eso complica todo: los ciudadanos perdemos tiempo, los funcionarios también y un trámite simple se convierte en semanas de espera.

Cuando un sistema se mantiene con parches acumulados, se pierden tiempo y recursos de forma silenciosa.

Una empresa que obliga a sus equipos a dedicar horas a procesos torpes paga sueldos para que la gente haga clics inútiles. Ese costo nunca queda reflejado en los reportes, pero se filtra en retrasos, en clientes que abandonan y en personas cansadas de repetir tareas que no aportan nada.

La magnitud real de ese costo se entiende mejor cuantificándolo. Supongamos un reporte semanal de “avances” que nadie lee. Un equipo de diez personas dedica una hora a la semana a redactarlo. Son diez horas semanales. Al cabo de un año, 520 horas. Eso equivale a trece semanas de trabajo a tiempo completo de una persona. En la práctica, la organización paga un trimestre entero de salario y beneficios para producir un archivo que termina olvidado en una carpeta digital. La ineficiencia pasa de ser un fastidio a una hemorragia de tiempo y energía humana.

La teoría de juegos lo describe con claridad: equilibrios de baja energía. Son puntos donde todos pierden tiempo, pero moverse hacia algo mejor exige un riesgo que nadie quiere asumir.

Los sistemas bancarios antiguos (Mainframes) son un ejemplo clásico. Procesan millones de transacciones críticas sobre código que casi nadie vivo sabe editar con seguridad. Mover una sola línea podría matar la operación del día, así que todos prefieren seguir jugando con cuidado, aunque el resultado sea lento y costoso de mantener. Es un diseño imposible de elegir desde cero, pero sobrevive porque se castiga más al que intenta arreglarlo (y falla) que al que lo deja seguir operando a duras penas. A largo plazo, este equilibrio se percibe como estabilidad, aunque su único logro sea desperdiciar recursos de manera organizada.

Hay otro efecto más sutil: a medida que los procesos se complican, la gente pierde margen de acción, una rigidez que termina afectando su capacidad operativa.

Lo que antes era una decisión directa ahora requiere permisos, formularios, aprobaciones. Eso consume tiempo y energía y deja la sensación de que cualquier iniciativa es un problema.

En ese contexto, tomar la iniciativa pasa de ser una ventaja a ser un cacho.

En informática, hay un término para esto: deuda técnica. Son decisiones que en su momento sirvieron, pero con el tiempo se vuelven obstáculos. Mientras más se acumulan, más difícil es cambiarlas.

Con el tiempo, las conexiones entre partes se vuelven tan complejas que se pierde el hilo. Lo mismo ocurre en instituciones, equipos, incluso en relaciones laborales. La falta de revisión a tiempo puede terminar bloqueando el funcionamiento por completo.

Estos fenómenos actúan en conjunto y forman un mecanismo que se retroalimenta. La sospecha de que existe una posible Valla de Chesterton genera cautela frente a cualquier cambio. Esa cautela es el terreno fértil donde prosperan sesgos como el statu quo, el costo hundido y la aversión a la ambigüedad. Al mismo tiempo, cada parche puntual añadido en nombre de la prudencia queda legitimado, y con el paso de los años produce la masa crítica de lo que llamamos deuda técnica. Lo que parece una serie de decisiones menores termina cristalizando en un sistema completo, un organismo burocrático nacido de la suma acumulada de miedos, sesgos y soluciones defensivas.

Un buen ejemplo de cómo los sistemas pueden volverse comedia involuntaria es un formulario que pide “rellenar en letra de molde” y acto seguido exige “firma con pluma estilográfica”. Dos órdenes incompatibles en una sola hoja, un error tan evidente que se integra al diseño. El trámite sobrevive porque todo el mundo juega el mismo juego tácito: presentar el documento, fingir que la contradicción no existe y confiar en que el funcionario decida cuándo aplicar una regla y cuándo ignorarla. Es un mecanismo funcional solo porque nadie lo sigue en serio, convirtiéndose en una especie de videojuego con errores aceptados por la comunidad. La ironía está en que el formulario fracasa como norma legal y triunfa como ritual compartido, una broma contada en voz baja bajo una fachada solemne.

La psicología humana pesa más que la lógica institucional en la supervivencia de estos sistemas. En una reunión para discutir la modernización de un proceso, se pueden observar sesgos cognitivos en acción. El gerente que invoca la tradición refleja el sesgo de statu quo. El empleado a punto de jubilarse que recuerda todo el esfuerzo invertido exhibe la falacia del costo hundido. El equipo rechaza un nuevo sistema por desconocimiento antes que por calidad, revelando la aversión a la ambigüedad. La suma de estos sesgos individuales produce una inercia colectiva que perpetúa lo absurdo, incluso cuando todos saben que algo debería cambiar.

Muchas veces se evita el cambio porque implica admitir que algo sobrevivió por pura inercia. Nadie quiere señalar que veinte años de formularios eran innecesarios. Además, las organizaciones tienden a valorar la estabilidad por encima de la claridad.

Si algo funciona, aunque sea a tropiezos, se defiende como tradición. Esa mezcla de miedo al error y apego a lo viejo normaliza lo absurdo con gran facilidad.

Esto también se conecta con el concepto de rendimientos decrecientes. Llega un punto en que agregar más esfuerzo o recursos deja de mejorar nada y solo vuelve las cosas más difíciles. Ese punto es difícil de ver. Cada nuevo paso parece justificable: se agrega una medida para evitar errores, una herramienta para mejorar o un comité para tomar mejores decisiones.

No basta con que algo funcione. Importa también cómo funciona.

Un sistema que produce resultados, pero agota a quienes lo usan, interrumpe la comunicación o exige un esfuerzo desproporcionado para tareas mínimas, sigue funcionando solo por falta de revisión (carece de salud operativa). Sin cuestionamientos, seguirá creciendo en la dirección equivocada.

Curiosamente, a veces la solución es una pausa, antes que añadir más tecnología. Un momento para simplificar y volver a lo esencial. Preguntarse qué problema se intentaba resolver en primer lugar y si las herramientas actuales lo siguen haciendo bien.

Para transformar este diagnóstico en acción, es útil clasificar la complejidad que enfrentamos. Primero está la Complejidad de Resguardo, nacida de normas legales o de seguridad (ISO, regulaciones); esta debe mantenerse, pero digitalizarse para reducir la carga. Segundo, la Complejidad Legada, soluciones a problemas extintos (el «fantasma del 94») que deben eliminarse de inmediato. Y tercero, la Complejidad de Control, fruto del miedo a que el equipo decida; esta se resuelve simplificando los flujos de aprobación y delegando.

Esto rara vez se ve como urgente, pero evitar esa revisión nos lleva a estructuras tan enredadas que se vuelven irreparables.

En educación, esto es especialmente claro. Se crean planes, rúbricas, evaluaciones, plataformas, calendarios, indicadores, retroalimentaciones y escalas. Todo con la intención de mejorar la calidad. Basta mirar el uso del tiempo en ciertas reuniones para notar que el foco se desplazó de la enseñanza a la administración. Y eso debería hacernos pensar.

La complejidad es inevitable en áreas como la medicina, la justicia o la ingeniería. Pero incluso allí, cuando los procesos básicos se traban, algo dejó de estar bien calibrado. Lo razonable sería hacer pausas periódicas y eliminar lo inservible. La idea es conservar lo útil y simplificar lo demás, evitando partir de cero.

Lo curioso es que cuanto más incomprensible es un proceso, más prestigio acumula dentro de la institución. Lo que debería ser eliminado se transforma en tótem de continuidad, como si la dificultad misma probara su legitimidad. Así, un trámite absurdo puede volverse intocable por representar estabilidad en un entorno cambiante. El efecto es paradójico: el sistema sobrevive por el miedo a desenchufarlo y no por su utilidad real. Con el tiempo, la normalización del absurdo se convierte en la verdadera innovación. Evoluciona la habilidad colectiva de habituarse al proceso, hasta que la contradicción deja de percibirse y se instala como la definición misma de normalidad.

Al final, protegemos la red obstruida que heredamos, confundiéndola con infraestructura crítica.

Quizá parte de esta ineficiencia sea permanente. En sistemas donde cooperan miles o millones de personas, siempre habrá resistencia operativa, retrasos y reglas absurdas contrarias al sentido común. Son el costo de coordinar escalas enormes. Pero el verdadero reto, lejos de buscar una pureza teórica imposible, está en identificar el momento exacto en que la resistencia deja de ser un costo operativo tolerable y pasa a detener el motor.