←︎ Volver a la bitácora

Mirar el sistema antes de culpar a una pieza

Cuando un problema se repite, conviene mirar las relaciones que lo producen: información, reglas, capacidad, incentivos y tiempos de respuesta. Pensar en sistemas amplía el diagnóstico sin borrar la responsabilidad individual. El objetivo es intervenir donde pueda cambiar el patrón, no encontrar una explicación que lo justifique todo.

Incorporada el 6 min de lectura

Una pieza funciona dentro de unas relaciones.

Si las entregas siempre llegan tarde, señalar a la última persona de la cadena puede parecer una explicación suficiente. Pero quizá recibe tarde la información, trabaja con prioridades incompatibles o depende de una aprobación que nadie ha previsto. Su conducta importa; el recorrido completo también.

Pensar en sistemas consiste en observar elementos y relaciones a lo largo del tiempo. Pregunta qué información circula, qué decisiones puede tomar cada persona y qué consecuencias vuelven a quienes deciden. Así aparecen posibilidades de mejora que no se ven mirando una tarea aislada.

Esta mirada no absuelve automáticamente a nadie. Una persona puede incumplir un acuerdo y el proceso puede estar mal diseñado al mismo tiempo. Comprender ambas cosas permite responder con más precisión que elegir entre culpar al individuo o culpar a una abstracción.

Un equipo no responde como una máquina predecible.

En un ensayo de febrero de 2024, Iván explora qué es un sistema y distingue situaciones simples, complicadas y complejas. Relaciona esa reflexión con los equipos: las personas reaccionan, aprenden y cambian, por lo que una misma intervención no produce siempre el mismo resultado.[1]

El ensayo nace de un debate y contiene afirmaciones que conviene afinar. Que una respuesta sea difícil de predecir no significa que no existan causas. Tampoco significa que todo sea azar o que observar regularidades resulte inútil. La incertidumbre limita lo que puedes anticipar, no elimina la posibilidad de comprender y aprender.

Usamos como semilla su rechazo a las recetas universales, sin convertir su clasificación en una definición científica cerrada. En particular, un propósito explícito no es una condición que todos los enfoques exijan del mismo modo para hablar de sistemas.

La expansión se centra en una aplicación concreta: antes de repetir una corrección sobre una persona, investigar si las relaciones del trabajo están reproduciendo el problema.

El mapa también es una hipótesis.

Donella Meadows recomienda observar cómo se comporta un sistema a lo largo del tiempo, hacer visibles nuestros modelos y seguir aprendiendo mediante intervenciones pequeñas. También vincula responsabilidad e información sobre las consecuencias de decidir.[2]

En tu proyecto, empieza por hechos: cuándo aparece el retraso, qué sucedió antes y qué cambia después. Una anécdota llamativa puede ocultar que el problema solo ocurre con determinados pedidos o cuando coinciden varias entregas.

Dibuja las relaciones que sospechas. Si ventas promete plazos sin consultar capacidad, producción recibe urgencias; si esas urgencias interrumpen todo, aumentan los retrasos; si ventas no recibe esa información, vuelve a prometer igual. Es una hipótesis de bucle, no una verdad demostrada por dibujar flechas.

Busca qué dato permitiría contrastarla y dónde podéis intervenir. Tal vez hace falta confirmar capacidad antes de comprometer una fecha. Después observa efectos: resolver un atasco local puede desplazarlo a otra parte o añadir un trámite que retrase todo sin mejorar las decisiones.

Mira quién ve las consecuencias.

Imagina un equipo que personaliza camisetas para asociaciones. Es un ejemplo hipotético. Cada comercial acepta encargos urgentes porque quiere cuidar a su cliente. Quien imprime reorganiza la cola continuamente y las entregas normales empiezan a retrasarse.

La primera explicación puede ser que impresión se organiza mal. Al reconstruir varios pedidos, aparece otra posibilidad: nadie tiene una visión compartida de la capacidad y cada urgencia se decide sin ver lo que desplaza. La intención local de ayudar produce un problema colectivo.

El equipo prueba una confirmación sencilla: antes de aceptar una urgencia, consulta disponibilidad y hace visible qué compromiso cambiaría. No se trata de prohibir todas las excepciones. Se trata de decidirlas con sus consecuencias delante.

Durante la prueba revisa tanto puntualidad como tiempo de respuesta comercial. Si todo se bloquea esperando una sola autorización, habrá creado otro cuello de botella. La solución necesita ajustarse; el mapa inicial ayuda a preguntar, pero no sustituye la observación.

Ejemplo de urgencias comerciales que cambian una cola de producción y generan retrasos; intervención y revisión.
MAPA 01 · Mira las relaciones del trabajoAmpliar infografía ↗︎

Amplía el diagnóstico sin diluir la responsabilidad.

Escoge un problema que se repita y describe el patrón con ejemplos concretos. Evita empezar por una etiqueta personal. Sustituye es desorganizado por qué información faltó, qué decisión llegó tarde y qué compromiso no se cumplió.

Pregunta a las personas que participan en distintas partes del trabajo. Pueden estar respondiendo racionalmente a objetivos que chocan entre sí. Escuchar sus condiciones no obliga a aceptar cualquier conducta, pero puede revelar por qué reaparece.

Propón un cambio pequeño en una relación: acceso a información, orden de una confirmación, límite de trabajo o regla de prioridad. Explica qué esperas observar y qué efecto secundario te preocuparía.

Revisa con quienes reciben las consecuencias. Si el cambio ayuda, consolídalo; si no, modifica tu explicación. Un enfoque sistémico sirve cuando mejora la capacidad de actuar juntos y asumir responsabilidades, no cuando vuelve tan complejo el problema que nadie se atreve a tocarlo.

Aprendizajes

  • Las relaciones también producen resultados. Mira información, reglas y dependencias.
  • Complejidad no significa ausencia de causas. Reconoce incertidumbre sin renunciar a investigar.
  • Un mapa es una hipótesis. Contrasta sus relaciones con hechos.
  • Una mejora local puede desplazar el problema. Observa efectos en el conjunto.
  • Comprender no borra responsabilidad. Combina acuerdos personales y cambios de proceso.

Preguntas detonantes

  1. ¿Qué patrón se repite más allá de una persona?
  2. ¿Quién decide sin ver las consecuencias?
  3. ¿Qué información llega tarde o no llega?
  4. ¿Qué cambio pequeño permitiría contrastar nuestra explicación?
  5. ¿Dónde podría aparecer un efecto secundario?

Para seguir aprendiendo

PARA ENTENDER LA BASE

Si repetimos el problema, ¿qué no estamos revisando?

Reconoce un patrón que se repite antes de atribuirlo a una persona.

Leer bitácora →︎
PARA SEGUIR AVANZANDO

Hay problemas que no se resuelven con un plan más detallado

Distingue cómo intervenir cuando el sistema no responde de forma predecible.

Leer bitácora →︎
PARA AMPLIAR LA MIRADA

Cuando el equipo depende demasiado de ti

Examina la dependencia del líder como un patrón de información y decisiones.

Leer bitácora →︎

Cómo se ha elaborado esta bitácora

Esta bitácora parte de los apuntes y reflexiones reales que Iván guardó en su Notion personal durante sus cuatro años en LEINN. Ese archivo se ha organizado en una base de 521 notas de conocimiento. Cada entrada toma un concepto de esa base y lo amplía con referencias, explicaciones e infografías para convertirlo en un recurso de aprendizaje.

Fuentes

  1. Notion personal · Leadership in Complexity

    Definiciones y aplicación a equipos leídas. Se matizan causalidad, predictibilidad y alcance de las definiciones. Original conservado en el archivo personal; no disponible públicamente.

  2. Donella Meadows · Dancing With Systems ↗︎

    Observación del comportamiento, modelos mentales, aprendizaje y responsabilidad; referencia para ampliar la reflexión.

Datos de la entrada
Incorporada el
20 de septiembre de 2026
Última revisión
20 de septiembre de 2026 · Versión 1
Primera lectura recomendada
2.º · segunda mitad · Startup Creation
Cuándo volver
Cuando corregir una pieza no cambia el resultado del conjunto.
Idioma
Español
Apoyo de IA
OpenAI Codex · texto y edición; ImageGen · infografías
Modelo
Familia GPT-6; variante principal no expuesta por el cliente
Estado
Publicada en everleinner.com