Hay un patrón que aparece seguido cuando uno se sienta a mirar los números de una empresa que está creciendo: el proceso no falla en cualquier lado. Falla siempre en el mismo punto. Entre producción y ventas. Entre la fábrica y las sucursales. Entre el que cotiza y el que ejecuta. Entre el que recibe el pedido y el que lo despacha.
Y casi siempre se lee como un problema de personas. “Con logística no nos entendemos.” “El de compras no avisa.” La conversación se va a las actitudes, se hace una reunión, se promete mejor comunicación, y tres meses después el proceso se vuelve a cortar exactamente en la misma junta.
Me puse a buscar si había literatura sobre esto y terminé en un paper de 1968 que no habla de empresas ni de procesos, sino de software. Igual describe el fenómeno mejor que casi todo lo que se escribe hoy sobre gestión.
Lo que dijo Conway en 1968
Melvin Conway escribió un artículo llamado How Do Committees Invent? Lo mandó a la Harvard Business Review y se lo rechazaron; lo publicó Datamation en abril de 1968. Su tesis, en una línea:
“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.”
Cualquier organización que diseña un sistema va a producir, inevitablemente, un diseño cuya estructura es una copia de su estructura de comunicación.
El razonamiento es simple y por eso incomoda: para que las partes de algo encajen, las personas que las hacen tienen que hablar entre sí. Donde no hay conversación, hay una costura. Y la costura queda en el producto.
Hay una segunda frase de Conway, menos citada, que es la que a mí me resultó más útil:
“Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist.”
Dada cierta organización, hay una clase entera de soluciones que esa organización no puede alcanzar, porque los caminos de comunicación que harían falta no existen. No es que salen mal: no llegan a existir como opción. Eso reencuadra el problema. Si tu proceso se rompe siempre en la misma junta, probablemente no estés frente a un problema de actitud sino frente a un límite de diseño.
Qué se verificó cuarenta años después
Durante décadas esto fue una observación ingeniosa sin evidencia dura. En 2012, Alan MacCormack, Carliss Baldwin y John Rusnak publicaron en Research Policy un test de lo que la literatura llama la mirroring hypothesis: la idea de que el producto espeja a la organización que lo construye.
El diseño del estudio es lo interesante. Compararon pares de productos que hacían exactamente lo mismo, pero construidos por organizaciones de forma opuesta: por un lado empresas comerciales, con equipos acoplados y coubicados; por el otro, comunidades de software libre, con participantes dispersos y débilmente acoplados. Misma función, estructuras organizativas distintas.
El resultado fue consistente en todos los pares: el producto hecho por la organización débilmente acoplada resultó significativamente más modular. Y la diferencia no fue marginal — midieron hasta un factor de ocho en la propensión de un cambio de diseño a propagarse de un componente a otro.
Traducido: en una de esas organizaciones, tocar una pieza obligaba a tocar ocho veces más cosas que en la otra. El costo de cambiar algo estaba determinado por cómo estaba organizada la gente, no por qué producto estaban haciendo.
Esta evidencia es sobre software. Extrapolarla a una distribuidora, una fábrica o una cadena de sucursales es una analogía mía, no un hallazgo del paper. Me parece una analogía sólida —un proceso operativo también es un sistema con componentes e interfaces— pero es una analogía, y prefiero decirlo antes de apoyar un consejo sobre ella.
Por qué en una PyME pega más fuerte
Una corporación puede tapar una costura mal diseñada. Contrata un coordinador, arma un comité, agrega una capa. Le sale caro, pero puede.
Una empresa de cuarenta personas no tiene esa capa, y entonces paga cada costura en efectivo: en días, en retrabajo, en mercadería quieta esperando que alguien decida.
Los datos de la CEPAL dan una dimensión de la brecha en la región. Las mipymes son cerca del 99% de las empresas de América Latina y emplean al 67% de los trabajadores. Pero la distancia de productividad con las empresas grandes es enorme: las grandes llegan a 33 veces la productividad de las microempresas y hasta 6 veces la de las pequeñas. En los países de la OCDE ese mismo múltiplo va de 1,3 a 2,4 veces.
Esa brecha no se explica solo por tecnología o escala. Buena parte es capacidad de coordinación: el costo de que la información cruce de un área a la otra sin perderse.
Dónde aparece esto en los números
Lo que me interesa del asunto es que no se queda en teoría organizacional. Una costura mal diseñada tiene una firma contable, y suele estar repartida en lugares donde nadie la suma:
- Días de ciclo. El tiempo entre que entra un pedido y sale la entrega. Si se mide por etapa, casi siempre hay una en la que el trabajo espera mucho más de lo que se procesa. Esa espera es la junta.
- Retrabajo. Rehacer lo que ya estaba hecho. Las estimaciones de la American Society for Quality —de industria, no académicas— ubican el costo de la mala calidad entre el 15% y el 20% de las ventas en muchas manufactureras, con un rango informado de 5% a 35% según la complejidad del producto.
- Capital de trabajo inmovilizado. Stock intermedio que se acumula justo antes de un traspaso entre áreas. En la práctica es plata financiando una falta de coordinación.
- Cotizaciones que se caen en el traspaso. Se cotiza en un lado, se ejecuta en otro, y lo que se pierde entre medio nunca entra a ningún reporte.
Ninguna de estas cifras aparece como línea en un balance. Todas se pueden estimar con datos que la empresa ya tiene.
La maniobra inversa
Si la estructura de comunicación determina el resultado, entonces la relación se puede usar al revés: diseñar deliberadamente la comunicación para obtener el proceso que uno quiere. En la industria del software a eso lo llaman inverse Conway maneuver, y es el eje del libro Team Topologies de Matthew Skelton y Manuel Pais.
Para una PyME, lo realista no es rediseñar el organigrama. Es más chico y más barato:
- Encontrar la junta cara. Medir días de ciclo por etapa y ver dónde el trabajo espera en vez de moverse.
- Mirar quién habla con quién ahí. No el organigrama formal: quién efectivamente levanta el teléfono cuando algo se traba.
- Cerrar el circuito antes de agregar gente. Conway también advirtió que sumar personas a un problema de coordinación suele empeorarlo: “la mayor causa común detrás de muchos sistemas mal diseñados ha sido la disponibilidad de una organización de diseño necesitada de trabajo”.
Lo que no haría: convertir esto en un proyecto de reestructuración. La versión útil es una junta por vez, medida antes y después.
La pregunta
Si tuviera que quedarme con una sola cosa de todo esto, es que conviene invertir el orden de la pregunta. En vez de “¿quién falló?”, preguntar “¿dónde está la junta más cara de mi proceso, y cuánto me cuesta por mes?”.
Es una pregunta que se puede responder con números. Y a diferencia de la otra, tiene arreglo.