Acoplados a cómo eran las cosas

Trabajé en un proyecto de comercio empresarial para una gran multinacional. Un gran ERP, muchos procesos internos, muchas personas con mucho tiempo en la empresa. Y un cambio en una regla de descuento que, visto desde el código, parecía unas pocas condiciones y una prueba.

Así recorrió la empresa ese cambio.

Nos alineábamos con la dirección. Finanzas pedía ajustes. Revisábamos, volvíamos a la dirección, recibíamos aprobación y volvíamos a Finanzas. Entonces alguien recordaba que otra área debía verlo y esa área encontraba una restricción, a menudo en el ERP, que devolvía la propuesta al inicio. Más reuniones, más trabajo repetido, la misma sensación siempre: ya hemos estado aquí.

Lo curioso es que nadie en ese ciclo hacía nada malo. Cada paso tenía sentido por separado. El problema era el ciclo, y tenía dos mitades: una en la organización y otra en el software.

La capacidad de cambiar es una competencia de la empresa

Los mercados cambian. La tecnología cambia y, últimamente, más rápido que la mayoría de los ciclos de planificación. Una empresa que vendía mediante distribuidores decide abrir un canal B2B de comercio electrónico. Otra, que hacía todo en el ERP, necesita exponer precios, existencias y pedidos a un nuevo frente digital. Nada de eso es exótico. Es la presión normal sobre cualquier gran negocio.

Lo que determina si saldrá bien no es solo el presupuesto o el talento. Es si la empresa aún puede cambiar. He llegado a considerarlo una competencia como cualquier otra. Puedes tenerla, puedes perderla y normalmente solo notas que la perdiste cuando la necesitas.

En mi experiencia, las grandes empresas la pierden en dos lugares al mismo tiempo.

Cómo un sistema queda enyesado

El primer lugar es la arquitectura.

Piensa en digitalizar una operación centrada en el ERP para vender B2B por internet. En un sistema sano, es un nuevo canal: habla con precios, clientes, existencias y pedidos mediante contratos, y esas capacidades hablan con el ERP mediante una integración.

En un sistema rígido, esas capacidades no están separadas. Con los años, funciones que deberían vivir aparte, en sus propios servicios o al menos módulos, se fueron apilando. La lógica de descuentos conoce las reglas de crédito del cliente. Las reglas de crédito leen directamente tablas del ERP. El checkout presupone un flujo de pedidos específico, que presupone una rutina de existencias específica. Cada capa se apoya en la de abajo.

Nadie lo diseña a propósito. Se acumula, un atajo razonable cada vez, hasta que las capas ya no se pueden separar. Entonces un cambio que debería tocar una cosa toca seis.

Ese es el coste arquitectónico de la rigidez y por eso insisto en el bajo acoplamiento. No porque las cajas separadas queden más bonitas en un diagrama, sino porque el acoplamiento determina cuánto del sistema arrastra una decisión de negocio. Una regla de descuento debería ser una decisión de precios. Si cambiarla exige negociar con el flujo de pedidos, la rutina de existencias y las entrañas del ERP, la arquitectura convirtió una decisión comercial en una excavación.

El bajo acoplamiento también tiene un coste, y no voy a fingir lo contrario. Los contratos deben diseñarse y mantenerse. Las integraciones necesitan responsables. Algunas cosas se duplican a propósito. Es más lento el primer día. Compensa cuando el mercado pide algo que el diseño original nunca imaginó y, en mi experiencia, ese día siempre llega.

La otra mitad del ciclo

El segundo lugar donde la empresa pierde la capacidad de cambiar está en las personas.

En una gran empresa, muchas personas pasaron años, a veces décadas, trabajando con las mismas reglas, sistemas y caminos de aprobación. Esa experiencia es real y valiosa. También pesa.

Lo que vi repetidamente fue resistencia a cambiar la forma de trabajar. Propuestas que parecían resueltas volvían para otra discusión. A veces parecía que el proyecto sufría un boicot silencioso.

No creo que la mayor parte fuera deliberada. Mi lectura honesta es que a menudo era inconsciente: personas protegiendo la forma de trabajar que conocían, la que siempre les había funcionado. Básicamente, inercia.

Es fácil frustrarse con eso. Es más útil entenderlo. Un sistema rígido y una organización rígida se alimentan mutuamente. Cuando el software no puede cambiar sin gran riesgo, las personas aprenden a decir que no, a menudo con razón. Cuando dicen que no durante mucho tiempo, nadie invierte en facilitar los cambios del software. El yeso se engrosa por ambos lados.

Forzar desde fuera no funciona

La reacción natural al llegar como parte de un equipo externo es presionar. Tienes el mandato, el plan y el apoyo de la dirección. A veces la dirección puede simplemente decidir y eso mueve las cosas. Pero presionar desde fuera tiene un efecto previsible: las personas empiezan a rechazar el propio proyecto. Cuanto más fuerzas, más trata la organización el cambio como algo impuesto. En mi experiencia, es una de las formas más seguras de que un proyecto no avance.

Vale la pena pensar por qué. Un cambio impuesto desde fuera pide a las personas abandonar lo que conocen a cambio de algo que no ayudaron a construir, propuesto por quienes no saben cómo funciona realmente la empresa. Así planteada, la resistencia tiene sentido.

Lo que funcionó: cambiar de dentro hacia fuera

Lo que marcó la diferencia en aquel proyecto fue encontrar personas dentro de la empresa dispuestas a cambiar y acercarlas al trabajo.

Quiero ser específico, porque es fácil malinterpretarlo: no eran necesariamente las personas más nuevas. Algunas de las más importantes llevaban allí muchos años. Conocían los flujos internos, quién decidía qué, qué precedentes existían y por qué una propuesta prosperaría o no. La diferencia no era la edad ni la antigüedad. Era la disposición. Estaban abiertas a hacer las cosas de otra forma y conocían la empresa lo suficiente para hacerlo posible.

Buscamos a esas personas, ganamos su confianza y les dimos un papel real en el trabajo. Explicaban por qué algo no se aprobaría tal como lo habíamos escrito y qué sí. Decían quién debía estar en una conversación antes de que ocurriera, no después. Recordaban que algo parecido ya se había aprobado: una especie de jurisprudencia interna, sin abogados. Con su apoyo pudimos avanzar en cambios más importantes e innovar dentro de una estructura que se resistía.

No fue una victoria limpia. Algunas propuestas se aplazaron o descartaron. En algunos puntos aceptamos soluciones que sabíamos que podrían encontrar límites después e intentamos construirlas para que pudieran evolucionar. Una elección pragmática sigue teniendo un coste real, y dejar espacio para cambiarla después no hace gratuito el cambio. Solo lo hace posible.

También tuve que aprender algo menos cómodo: necesitaba a esas personas más de lo que ellas me necesitaban. Yo era responsable de la parte técnica, pero no entendía la empresa. Ellas sí.

Lo que me llevo

Dos cosas, que son la misma lección vista desde dos lados.

En el software: protege el bajo acoplamiento. Separa las capacidades de negocio, pon contratos entre ellas y no dejes que el ERP, ni ningún sistema único, se convierta en el lugar donde viven todas las reglas. El objetivo no es la elegancia. Es mantener a la empresa capaz de responder al próximo cambio del mercado, canal o tecnología sin excavar.

En la organización: no intentes imponer el cambio desde fuera. Encuentra a las personas de dentro que conocen los flujos y quieren avanzar, apóyalas y construye el cambio con ellas. Es más lento al principio. Es la única versión que he visto perdurar de verdad.

Un sistema que no cambia y una empresa que no cambia suelen venir juntos. Hay que trabajar en ambos, y el segundo empieza por las personas.