La solicitud parecía razonable. Una aplicación desarrollada para estandarizar un proceso ya estaba en producción, funcionando como se había diseñado. Entonces llegó el pedido: ¿podrían agregar una nueva opción que separe el proceso en dos pasos y permita que dos personas lo operen en lugar de una?
La razón era concreta: una de las personas involucradas no sabía operar el sistema.
Técnicamente, era implementable. Pero aceptarla habría sido un error, no por la complejidad de desarrollo, sino porque la solicitud no era realmente un problema de sistema. Era un problema humano disfrazado de problema técnico.
Cuando algo no funciona en la intersección entre una persona y un sistema, hay exactamente tres diagnósticos posibles: el sistema tiene un problema de diseño, el proceso fue mal concebido, o hay una brecha de capacidad en quien lo opera. Son categorías distintas y tienen respuestas distintas.
El error más común, y el más costoso, es saltarse el diagnóstico y responder directamente con una solución. En este caso, la solución propuesta asumía implícitamente que el problema era el sistema. Pero el sistema funcionaba. El proceso estaba estandarizado. Lo que faltaba era que una persona aprendiera a operar lo que ya existía.
Rediseñar el proceso para evitar ese aprendizaje no resuelve el problema. Lo institucionaliza.
En la década del 70, el psicólogo organizacional Chris Argyris identificó un patrón que llamó "rutinas defensivas": comportamientos que las organizaciones adoptan para protegerse del conflicto o la incomodidad a corto plazo, pero que sistemáticamente bloquean el aprendizaje y la mejora.
Las rutinas defensivas no se perciben como evasión. Se perciben como pragmatismo. "Hagámoslo funcionar de la forma en que la gente puede operarlo" suena razonable. Incluso empático. Pero lo que en realidad está ocurriendo es que la organización está eligiendo pagar un costo permanente, un proceso más lento, más fragmentado, con el doble de personas, para evitar el costo transitorio de una conversación difícil.
"Cada workaround que se convierte en proceso oficial es una decisión de nunca resolver el problema que lo originó."
Cuando una organización acepta rediseñar un sistema para acomodar una brecha de competencia, incurre simultáneamente en tres costos que rara vez aparecen en ningún análisis.
El primero es el costo de eficiencia permanente. Un proceso que requería una persona ahora requiere dos. Ese diferencial no es un gasto de implementación, es un gasto recurrente, todos los días, hasta que el proceso se rediseñe de nuevo. La brecha de competencia que costaba cerrar una vez, ahora cuesta indefinidamente.
El segundo es el costo de señal organizacional. Cuando la organización acepta complejificar un proceso para evitar capacitar a alguien, establece un precedente: las brechas de habilidad tienen solución técnica. La próxima persona que no sepa operar algo tiene razones fundadas para pedir lo mismo. La excepción se convierte en política implícita.
El tercero, y el más silencioso, es el cierre permanente de la brecha. Mientras el workaround existe, no hay presión para aprender. La persona que no sabía operar el sistema seguirá sin saberlo, solo que ahora el sistema se adapta a ella. La brecha de competencia no desaparece: queda congelada en el diseño del proceso.
Gana paz a corto plazo. Evita la incomodidad de decirle a alguien que necesita capacitarse, o de reconocer que el rol y la persona no están bien alineados. Evita el tiempo y costo de la formación. Evita la conversación.
Y pierde, de forma silenciosa y acumulativa, la capacidad de operar con eficiencia, la coherencia de sus estándares, y la posibilidad de que esa persona, y las que vengan después, desarrollen las competencias que el sistema moderno requiere.
En ingeniería de software existe el concepto de deuda técnica: el costo acumulado de tomar atajos en el código que eventualmente hay que pagar con intereses. Las organizaciones acumulan algo análogo cuando evitan las conversaciones difíciles sobre capacidad: deuda de competencia. No aparece en ningún balance. Pero se paga igual.
Ante la solicitud de separar el proceso en dos para que una persona pudiera operar solo una parte, la respuesta correcta no era técnica. Era diagnóstica.
¿El sistema tiene un problema de usabilidad que dificulta genuinamente su operación? Entonces hay que mejorarlo. ¿El proceso fue mal diseñado y la complejidad es intrínseca? Entonces hay que rediseñarlo. ¿El sistema funciona y el proceso es correcto, pero la persona no tiene la habilidad para operarlo? Entonces hay que capacitarla, o evaluar si el rol está bien asignado.
Esas son conversaciones distintas. Y la única que no está disponible como respuesta válida es agregar complejidad al sistema para no tener ninguna de las tres.
Modernizar una organización no es solo implementar nuevas herramientas. Es exigir que las personas crezcan con ellas. Cuando priorizamos la comodidad del cambio por sobre el cambio mismo, no estamos modernizando, estamos construyendo sistemas más sofisticados para preservar los mismos límites de siempre.
¿Quieres aplicar estas ideas en tu organización? Conversemos sobre cómo hacerlo.
Agendar sesión gratuitaUna perspectiva por semana. Sin ruido, sin ventas. Solo ideas accionables sobre estrategia, datos y procesos.
Sin spam. Puedes darte de baja cuando quieras.