No toda fricción es un problema

Hay algo profundamente atractivo en una operación sin fricción.

Una solicitud que antes necesitaba tres correos ahora se resuelve en apenas unos segundos. Un dato deja de copiarse manualmente entre varios sistemas. Una aprobación burocrática desaparece. Una decisión puede tomarse más cerca del lugar donde ocurre el trabajo, sin esperar a que alguien varios niveles arriba encuentre el tiempo para revisarla.

Es difícil discutir contra eso. Y, en muchos casos, no hay nada que discutir.

Las organizaciones acumulan una cantidad absurda de resistencia que nadie diseñó deliberadamente; se ve en información duplicada, pasos que sobrevivieron a la razón que los creó, esperas provocadas por responsabilidades ambiguas o controles que ya no controlan nada. Remover esa fricción no necesita una defensa sofisticada. Es el trabajo que debería hacerse.

El problema aparece poco después, cuando la experiencia de haber eliminado desperdicio produce una conclusión más amplia de lo que esa experiencia autoriza: que cualquier resistencia es una señal de mal diseño.

Entonces empezamos a mirar los sistemas de una manera peligrosamente sencilla. Contamos pasos. Medimos tiempos. Localizamos aprobaciones. Buscamos intervención humana. Todo aquello que interrumpe el flujo ahora parece sospechoso.

Y muchas veces lo es.

Pero no lo es siempre.

La velocidad de un flujo no es por sí sola una medida suficiente de la calidad del sistema que lo contiene.

Una operación puede hacerse más rápida y, al mismo tiempo, perder una separación de responsabilidades, un límite de autoridad o una oportunidad necesaria de deliberación. El tiempo sí mejora. El sistema no necesariamente.

Ahí empieza la parte incómoda.

Dos aprobaciones que parecen iguales

Una transferencia financiera necesita una segunda aprobación antes de ejecutarse.

Desde afuera, el diagnóstico parece inmediato: hay dos personas haciendo lo que una podría hacer. La segunda intervención añade espera. Si desaparece, la transferencia ocurre antes.

Ahora cambiemos apenas la arquitectura.

En una organización, esa segunda persona no posee una autoridad distinta, no recibe información que el primer actor no tenga y rara vez modifica la decisión. El paso sigue ahí porque el flujo fue diseñado de esa manera años atrás y nadie ha tenido una razón suficientemente fuerte para cuestionarlo.

La espera, en cambio, nunca es abstracta. Alguien la paga.

El equipo que necesita mover el dinero espera. Una operación urgente requiere mensajes adicionales, una llamada, un recordatorio. Si el aprobador está fuera, el trabajo se acumula. Decenas de pequeñas interrupciones pueden concentrarse alrededor de una persona que, en términos sistémicos, ya no añade nada que explique el costo.

La organización está pagando por una resistencia cuya función ya no puede explicar con claridad.

En otra organización, la pantalla puede verse exactamente igual. Una persona inicia la transferencia y otra la aprueba.

Aquí, sin embargo, ambas acciones representan autoridades diferentes. Quien prepara el movimiento puede disponer la operación, pero no comprometer unilateralmente el capital. La segunda intervención separa iniciación de autorización y establece una frontera real de autoridad.

También cuesta tiempo. El solicitante también espera. No hay que romantizar esa demora solo porque podamos describir el control con palabras elegantes.

La diferencia es que esta organización sí puede explicar qué riesgo intenta contener al aceptar ese costo.

Eso todavía no resuelve el diseño. Tal vez el umbral sea demasiado bajo. Tal vez una revisión humana siga interviniendo en operaciones cuyo riesgo podría resolverse con permisos mejor definidos. Tal vez el control sea correcto y la forma de ejercerlo sea torpe.

Una restricción puede cumplir una función real y estar mal diseñada.

Lo importante es otra cosa: la presencia de una aprobación, por sí sola, no permite saber si estamos mirando burocracia residual o arquitectura deliberada.

La superficie engaña.

La resistencia también puede hacer trabajo

Algunas decisiones necesitan espacio entre intención y ejecución.

No porque esperar sea una virtud, sino porque ciertas acciones merecen una oportunidad adicional de ser examinadas antes de convertirse en hechos. Ante acciones difíciles de revertir, una pausa puede cumplir una función de diseño y no simplemente añadir demora.

En otros casos, la resistencia hace visible una frontera de autoridad. El sistema necesita distinguir entre quien puede preparar una acción, quien puede aprobarla y quien puede ejecutarla. Concentrar esos movimientos puede ser rápido y, aun así, producir una arquitectura que nadie querría descubrir después de un error.

También importa qué tan difícil es volver atrás.

En El peso de la firma, al seguir el momento en que una decisión empieza a tratarse como vinculante, el costo de reversión aparecía como una propiedad importante del cierre. Aquí el mismo problema aparece desde otra dirección: cuando deshacer una acción es costoso, resulta mucho menos razonable tratar toda resistencia previa como desperdicio.

Eso no convierte la reversibilidad en una fórmula.

Hay decisiones fáciles de revertir que siguen necesitando límites por privacidad, autoridad o acumulación de riesgo. Y hay decisiones importantes que pueden ocurrir con poca intervención humana porque el sistema ya contiene permisos precisos, límites explícitos y mecanismos sólidos para detectar y corregir desviaciones.

El interés no está en acumular controles.

Está en entender por qué una determinada acción encuentra resistencia antes de ejecutarse y qué ocurriría si dejara de encontrarla.

Ese matiz parece pequeño hasta que se intenta eliminar fricción a escala.

Tener una función no basta

Aquí el argumento podría volverse demasiado cómodo.

Bastaría con encontrar una función para cada control y asumir que el tiempo terminó legitimándolo, como si la costumbre fuera evidencia.

Pero las organizaciones están llenas de cosas que cumplen exactamente la función para la que fueron diseñadas y que, aun así, merecen desaparecer.

Una restricción puede preservar autoridad. Eso no demuestra que esa autoridad deba permanecer donde está.

Puede reducir el riesgo de un nivel directivo y multiplicar, al mismo tiempo, pequeñas interrupciones para decenas de personas en la operación. Puede ofrecer tranquilidad a quien controla mientras distribuye su costo entre quienes tienen menos capacidad de cuestionarlo.

Ese costo importa.

Quien impone una fricción y quien la soporta no suelen ser la misma persona.

Por eso preguntar qué función cumple un control es apenas el comienzo. También necesitamos entender bajo qué autoridad se impone, quién absorbe su carga y si esa carga sigue siendo proporcional a aquello que intenta proteger.

Ni siquiera la incapacidad de explicar una restricción nos autoriza a eliminarla de inmediato.

A veces estamos viendo una reliquia. Otras veces encontramos conocimiento tácito que nunca fue documentado, una responsabilidad válida que quedó mal representada o una precaución cuya lógica sobrevivió mejor que su explicación.

La falta de claridad es una razón para revisar. No es todavía un veredicto.

Pero conservar también necesita un argumento.

Una regla no se vuelve necesaria porque lleve diez años ahí. Una aprobación no adquiere legitimidad porque alguna vez respondió a un riesgo. Una revisión humana no merece permanencia automática porque el sistema anterior dependiera de ella.

Si la misma función puede preservarse con permisos más precisos, mejor información o una arquitectura que imponga menos carga sobre quienes ejecutan el trabajo, la restricción debería cambiar.

La fricción tiene que justificar su lugar.

No una sola vez, cuando alguien diseñó el proceso, sino mientras siga imponiendo un costo sobre el sistema.

Esa exigencia funciona en las dos direcciones. Remover una resistencia implica saber qué desaparece con ella. Conservarla exige seguir siendo capaces de explicar qué protege y por qué el precio que impone todavía merece pagarse.

Cuando eliminar se vuelve más fácil

La automatización vuelve esta discusión especialmente relevante por una razón concreta: hoy es mucho más barato modificar las resistencias visibles de una operación.

Una espera puede reemplazarse por una regla. Una verificación manual puede convertirse en una validación automática. Una aprobación puede desaparecer porque permisos, condiciones y límites ya permiten resolver la decisión de otra manera.

Eso es progreso cuando el diseño preserva lo que necesitaba preservar.

El problema aparece cuando medimos primero aquello que la automatización hace fácil medir.

Una métrica de tiempo registra la demora. No dice por qué existe.

El número de intervenciones muestra cuántas personas tocaron una operación. No indica, por sí mismo, si estamos viendo duplicación innecesaria o una separación intencional de funciones.

Una reducción de clics puede mejorar la experiencia sin decir nada sobre la distribución de autoridad que quedó debajo.

Cuando la unidad de análisis es demasiado local, una espera accidental y una deliberación necesaria pueden parecer exactamente el mismo problema.

Y entonces una intervención técnicamente impecable puede producir un resultado extraño: eliminar exactamente aquello que el proyecto fue contratado para eliminar, mostrar mejores métricas y dejar detrás un sistema menos capaz de gobernar ciertas decisiones.

No hay ninguna razón para responder a ese riesgo preservando trabajo manual.

Ese sería el error inverso.

Una buena arquitectura puede ofrecer más control con menos fricción. Puede reemplazar una cola de aprobaciones con permisos mejor delimitados. Puede convertir una revisión tardía en una condición que el sistema comprueba antes de que la acción exista. Puede hacer que una decisión que antes necesitaba supervisión constante se vuelva segura para resolver localmente.

Ahí la reducción de fricción no elimina la función. La rediseña.

Y esa diferencia cambia por completo lo que significa optimizar.

Lo fácil no siempre es lo que debe ocurrir

La mayor parte de la fricción accidental merece poca nostalgia.

Si un dato puede dejar de copiarse dos veces, que deje de copiarse. Si una decisión pertenece claramente a un equipo, no debería recorrer una jerarquía en busca de una aprobación ceremonial. Si un control ya no contiene ningún riesgo identificable, su antigüedad no merece protección.

Pero tampoco deberíamos convertir la ausencia de resistencia en una propiedad moral de los buenos sistemas.

Una organización madura necesita saber qué acciones pueden resolverse sin preguntar, dónde termina la autoridad de cada actor y en qué puntos una decisión debe encontrar suficiente resistencia como para que sus consecuencias sean comprendidas antes de ejecutarse.

Nada de eso queda resuelto para siempre.

El riesgo cambia. La tecnología cambia. Las responsabilidades se mueven. Una restricción que alguna vez protegió algo importante puede quedarse instalada mucho después de que esa necesidad desaparezca. La fricción deliberada tampoco puede convertirse en mobiliario permanente.

Por eso diseñar también exige revisar continuamente aquello que hemos decidido hacer difícil.

No para convertirlo en fácil por principio, sino para saber si todavía existe una razón suficientemente buena para que siga siendo difícil.

Diseñar un sistema no consiste en hacer todo fácil. Consiste en decidir con suficiente precisión qué debe poder ocurrir con facilidad y qué no debería ocurrir sin suficiente razón.