El procedimiento que nadie podía comentar: por qué el feedback instantáneo cambia todo
Durante años, proponer un cambio a un procedimiento significaba encontrar primero a la persona responsable, escribirle un correo, esperar una reunión, y.
Durante años, proponer un cambio a un procedimiento significaba encontrar primero a la persona responsable, escribirle un correo, esperar una reunión, y confiar en que alguien, en algún momento, actualizara el documento. La idea podía ser buena, incluso obvia para quien la tenía en el momento de usar el procedimiento. Pero el sistema no estaba diseñado para recibirla ahí, en ese momento.
Un enlace que cambia el punto de partida
Hace poco llegué a una idea simple: dar acceso de revisor (Reviewer) a un documento de procedimiento, de forma que cualquier persona que lo use pueda comentar o proponer un cambio directamente sobre el texto, con seguimiento de cambios, sin pasar antes por un correo, una reunión o un ticket. Antes de esto, proponer una mejora implicaba iniciar todo un proceso paralelo solo para poder proponer el proceso principal.
Por qué importa el momento, no solo el canal
No es lo mismo poder comentar un procedimiento en algún momento futuro que poder hacerlo en el instante en que la fricción aparece. El coste de una idea no es escribirla: el coste de una idea es todo lo que ocurre antes de poder escribirla. Cuantos más pasos separan el momento de detectar algo mejorable del momento de registrarlo, menos ideas llegan a registrarse.
Una idea que espera una semana para ser escrita ya no es la misma idea. Pierde matices, pierde urgencia, y a veces se pierde del todo.
Lo que cambia cuando el sistema permite comentar de inmediato
- Colaboración más rica: quien ejecuta el proceso participa directamente en mejorarlo, no solo lo sigue.
- Trazabilidad real: cada comentario y cada cambio propuesto queda registrado en el propio documento, no disperso entre correos y chats.
- Menos sobreprocesamiento: desaparece la ronda de pasos previos que solo servían para "proponer proponer" un cambio.
El sistema, no la buena voluntad de las personas, es quien determina si una mejora llega a tiempo o se pierde en el camino.
Poka-yoke aplicado: de la buena intención al sistema
Dar acceso de revisor a un procedimiento es, en el fondo, un poka-yoke de proceso: no depende de que alguien recuerde proponer una mejora por el canal correcto, en el momento correcto. El propio sistema lo permite, en el lugar y el instante donde la mejora surge.
| Concepto | Término (Shingo) | Aplicación en este caso |
|---|---|---|
| Inspección en la fuente | Source Inspection | El comentario se hace en el mismo documento, en el momento en que se detecta la necesidad de cambio, no después. |
| Autoinspección | Self-Inspection | Quien usa el procedimiento identifica y registra la mejora por sí mismo, sin depender de un tercero para iniciarla. |
| Método de control | Control Method | El sistema deja constancia inmediata del cambio propuesto (seguimiento de cambios), en lugar de solo advertir que existe una sugerencia pendiente. |
El desperdicio detrás del proceso anterior: sobreprocesamiento
El proceso que existía antes de este cambio —correo, reunión, ticket, y solo entonces una actualización— es un ejemplo claro de sobreprocesamiento (Overprocessing): pasos añadidos que no aportan valor a la mejora en sí, sino que existen solo para iniciar el proceso de mejorarla. Cuantos más pasos separan una idea de su registro, menos ideas sobreviven el trayecto.
| Waste (Muda) | COPQ (Coste de la No Calidad) |
|---|---|
| Sobreprocesamiento (Overprocessing) | Horas de correos y reuniones consumidas solo para iniciar una propuesta de cambio, además del coste de oportunidad de las mejoras que nunca llegan a proponerse por la fricción del propio proceso. |
Si te preguntas dónde en tu organización una buena idea sigue esperando turno solo para poder proponerse, hablemos. Contacto.
