> ## Content Index > Fetch the complete content index at: https://www.consultoriaprocesos.com/llms.txt > Use this file to discover other available public pages before exploring further. # ⚙️ Algunos procesos solo funcionaban porque eran incómodos - URL: https://www.consultoriaprocesos.com/algunos-procesos-solo-funcionaban-porque-eran-incomodos/ - Published: 2026-09-09T17:50:25.000Z - Updated: 2026-09-09T17:50:25.000Z - Author: Johan - Tags: Consultoría, Metodología El pensamiento Lean lleva décadas tratando la fricción como desperdicio. Cada paso innecesario, cada espera, cada formulario que alguien rellena dos veces se identifica, se mide y se elimina. En general es lo correcto. Pero hay una excepción que hasta ahora casi no hacía falta pensar, y que la automatización con IA ha vuelto urgente: parte de la fricción del trabajo del conocimiento nunca fue desperdicio. Era un control. Nadie lo diseñó como tal, pero funcionaba como tal. ## **El coste de pedir era el control de calidad de la petición** Escribir un caso de negocio a mano era lento, así que solo lo presentaba quien de verdad creía en la idea. Preparar un análisis de veinte páginas costaba esfuerzo real, y ese esfuerzo era una señal creíble de que alguien pensaba que el tema importaba. Pedirle a un compañero que sacara unos datos gastaba capital social, así que se pedía cuando hacía falta, no por curiosidad. Ninguno de esos filtros aparecía escrito en un procedimiento. Emergieron solos. Y hacían un trabajo que nadie había asignado formalmente a nadie: separar lo que merecía atención de lo que simplemente se le había ocurrido a alguien. El coste de formular la petición era, en la práctica, el control de calidad de la petición. ## **La IA no distingue entre la fricción que estorba y la que sostiene** Una herramienta que reduce el esfuerzo de producir texto, análisis o propuestas lo reduce de forma uniforme. No puede saber cuál de las dos fricciones está eliminando, porque desde fuera las dos se parecen: las dos son incomodidad, las dos consumen tiempo, las dos parecen candidatas obvias a desaparecer. El resultado es previsible una vez lo ves: llega mucho más, todo redactado con fluidez, nada costoso de producir. El volumen sube. La señal no sube con él. Y la organización se queda sin forma de ordenar lo que recibe, porque el mecanismo de ordenación *era* el coste. Es un problema de flujo parecido al que ya vimos con [el chat que rompe la mañana](https://www.consultoriaprocesos.com/el-chat-que-ayuda-y-el-chat-que-rompe-la-manana/): cuando pedir cuesta cero, se pide más, y quien recibe absorbe la diferencia. ## **No es solo falta de capacidad para absorber** Se habla mucho de que las organizaciones no tienen capacidad para absorber tanto cambio, y es verdad. Pero esa lectura se queda a medias. No es solo que la capacidad sea escasa. Es que desapareció el regulador que limitaba cuánto llegaba a la puerta. La capacidad no se encogió tan rápido como creció la demanda. Es la misma mecánica que cuando [un pensamiento suelto se convierte en tu próxima tarea](https://www.consultoriaprocesos.com/cuando-un-pensamiento-suelto-se-convierte-en-tu-proxima-tarea/), solo que ahora el pensamiento suelto llega ya redactado, argumentado y con formato de entregable. ## **La pregunta incómoda antes de automatizar un paso** Antes de eliminar un paso porque resulta lento o molesto, vale la pena comprobar si estaba haciendo algún trabajo que nadie había reconocido: - **¿Qué decisión tomaba alguien gracias a este paso?** Si la respuesta es ninguna, es desperdicio. Si alguien decidía algo, era un control. - **¿Filtraba volumen o solo lo retrasaba?** Retrasar no es filtrar. Filtrar significa que algo no pasaba. - **¿Quién dejará de pensar cuando este paso desaparezca?** Si el esfuerzo obligaba a alguien a ordenar sus ideas, ese trabajo hay que reubicarlo, no borrarlo. - **Si el volumen se multiplica por diez, ¿qué se rompe primero?** Ese punto es tu nuevo cuello de botella, y conviene saberlo antes y no después. ## **Sustituir un filtro accidental por uno diseñado** La respuesta no es mantener procesos lentos a propósito. Sería absurdo, y además no funcionaría: nadie sostiene una incomodidad por decreto. Lo que toca es devolverle un coste a la petición, pero un coste deliberado y útil en lugar de uno accidental. En términos Lean, sustituir un poka-yoke que existía por accidente por uno diseñado a conciencia, y colocarlo en la entrada del proceso: - **Que la petición declare el resultado esperado.** No qué se quiere producir, sino qué decisión o problema resuelve. - **Nombrar responsable antes de aceptar la entrada.** Si nadie la reclama, no entra en la cola. - **Definir qué significa terminado.** Sin criterio de cierre, la petición vuelve una y otra vez. - **Criterios de entrada explícitos.** No todo lo que llega tiene derecho automático a ocupar capacidad. - **Devolver parte del trabajo de pensar a quien pide.** Ese era, precisamente, el trabajo que hacía la fricción antigua. > La fricción que eliminas sin entender qué función cumplía no desaparece. Reaparece más adelante, convertida en volumen que nadie sabe ordenar. Automatizar es casi siempre una buena idea. Pero conviene hacerlo sabiendo qué sostenía la incomodidad que estás quitando, porque no toda molestia es desperdicio y no todo lo fluido es valor. Algunos de tus procesos funcionaban, en parte, porque eran incómodos. Vale la pena decidir con qué los sustituyes antes de que el volumen decida por ti.