🧰 Cien proyectos de mejora no son un sistema de gestión
Se puede cerrar cien proyectos excelentes y no tener arquitectura de procesos, propiedad extremo a extremo ni gobernanza. Por qué la caja de herramientas no es la disciplina.
Una organización puede cerrar cien proyectos de mejora, con sus análisis de causa raíz, sus mapas y sus ahorros calculados, y seguir sin gestionar por procesos.
No es una provocación. Es lo que se ve cuando miras un poco más allá de la carpeta de proyectos: no hay arquitectura de procesos, nadie responde del flujo completo, los indicadores son funcionales, y las mejoras se evaporan a los pocos meses de cerrar el proyecto. Todo eso puede convivir perfectamente con una función de mejora continua impecable.
Dos preguntas distintas
La confusión viene de que ambas disciplinas hablan de procesos, pero no hacen la misma pregunta.
La mejora pregunta cómo hacer que este proceso funcione mejor. La gestión por procesos tiene que preguntar antes otras cosas: por qué existe este proceso, qué resultado le pertenece, quién responde de él, cómo debería comportarse y cómo lo gobernamos con el tiempo.
Son preguntas de naturaleza diferente. La primera se responde con un proyecto. Las segundas no se responden nunca del todo: se gestionan.
Si la gestión por procesos solo aparece cuando hay un problema que resolver, lo que tienes es mejora continua. Que está muy bien, pero no es lo mismo.
El catálogo de técnicas no es la disciplina
Hay una segunda confusión, más extendida y más cómoda: presentar la caja de herramientas como si fuera la disciplina.
Mapear procesos, dibujar un SIPOC, modelar en notación estándar, hacer un análisis de causa raíz, aplicar herramientas Lean, llevar un ciclo de mejora estructurado. Todo eso son capacidades. Son necesarias y muchas veces excelentes. Pero ninguna de ellas, ni todas juntas, constituyen un sistema de gestión.
Un mapa describe cómo se hace algo. No dice quién responde del resultado, ni con qué indicador, ni qué pasa cuando el rendimiento se sale de rango, ni quién decide si ese proceso debería seguir existiendo.
| LA TÉCNICA APORTA | LA GESTIÓN POR PROCESOS DEBE AÑADIR |
|---|---|
| Un mapa de cómo funciona hoy | Una arquitectura: qué procesos existen, cuáles crean valor y cómo se relacionan |
| Un análisis de causa raíz de un problema | Un criterio de cuándo hace falta mejorar y cuándo no |
| Un proyecto con sus ahorros | Un resultado extremo a extremo del que alguien responde de forma permanente |
| Indicadores del tramo intervenido | Medición del flujo completo, conectada con la estrategia |
| Una solución implantada | Gobernanza: quién decide, con qué frecuencia se revisa y cómo se sostiene |
| Una mejora puntual | Capacidad de evolucionar el proceso cuando cambie el contexto |
La columna de la izquierda se puede certificar en un curso. La de la derecha solo existe si la organización decide dotarse de ella.
Por qué la confusión resulta cómoda
Merece la pena mirar esto sin cinismo, porque hay razones de peso para que las organizaciones prefieran la columna izquierda.
- Un proyecto tiene principio y fin. La gestión no termina nunca, y eso es mucho más difícil de presentar en un comité.
- Un proyecto produce una cifra de ahorro. La gobernanza produce ausencia de problemas, que es exactamente lo que nadie percibe.
- Un proyecto no obliga a tocar el organigrama. Nombrar dueños de proceso sí toca poder, y eso siempre cuesta más.
- La formación en herramientas se compra. La disciplina de gestión hay que construirla dentro, y no hay proveedor que la entregue llave en mano.
Así que se hace lo que se puede hacer sin abrir el melón. Y se hace bien. El problema no es la mejora continua: es tomarla por lo que no es.
El desperdicio que genera la confusión
Aquí aparece una ironía incómoda: una función de mejora sin sistema de gestión detrás acaba generando sus propios desperdicios.
| DESPERDICIO | CÓMO SE MANIFIESTA |
|---|---|
| Retrabajo | Se vuelve a analizar un proceso que ya se analizó hace dos años, porque nadie guardó la decisión ni el criterio |
| Sobreproducción | Proyectos que se lanzan porque toca cumplir el plan de mejora, no porque el proceso lo necesite |
| Inventario | Mejoras implantadas y nunca adoptadas, acumuladas en documentos que ya nadie abre |
| Sobreproceso | Mapas detalladísimos de procesos que nadie usa para decidir nada |
| Espera | Problemas de flujo que esperan meses a un comité porque ningún rol tiene autoridad para resolverlos |
| Talento no utilizado | Gente formada en técnicas potentes, empleada en producir entregables que no cambian cómo se gestiona |
Es el patrón clásico: operaciones impecables sobre un proceso que nadie gobierna. Mucha actividad, poca diferencia.
Qué mide la madurez de verdad
Si el número de proyectos no sirve como medida, ¿qué sirve? Cinco preguntas bastan para situarse, y ninguna se responde con una certificación.
- ¿Existe una lista acordada de los procesos que crean valor, o cada área tiene su propia versión?
- ¿Cada uno de esos procesos tiene un responsable con nombre, que responde del resultado extremo a extremo?
- ¿Hay indicadores de flujo completo, o solo indicadores por función?
- ¿Hay un ritmo de revisión establecido, o el proceso solo se mira cuando estalla?
- ¿Qué pasó con las tres últimas mejoras implantadas? ¿Siguen vivas, y alguien lo comprueba?
La última es la más reveladora. Sostener no es una fase final del proyecto: es una función de gestión que tiene que existir cuando el proyecto ya no está.
La lectura poka-yoke
Shingo insistía en que un buen dispositivo no pide a nadie que se esfuerce más ni que recuerde mejor. Aplicado a esto, la diferencia entre mejora y gestión se ve con nitidez.
Una mejora que depende de que la gente se acuerde de aplicarla es una norma. Una mejora que sigue viva porque el sistema la revisa, la mide y tiene a alguien que responde de ella es gestión. La primera se degrada en silencio; la segunda avisa cuando se desvía.
Por eso la pregunta útil al cerrar un proyecto no es cuánto hemos ahorrado, sino otra: ¿qué mecanismo hará visible que esto deja de funcionar, y quién lo va a ver?
No es una jerarquía, es una diferencia
Nada de esto quita valor a la mejora continua. Hacen falta las dos cosas, y la mayoría de las organizaciones que conozco son mucho mejores en la primera que en la segunda.
Pero conviene no llamarlas igual. Resolver problemas muy bien y gestionar por procesos son capacidades distintas, y confundirlas tiene un efecto concreto: la organización cree que está construyendo un sistema cuando en realidad está acumulando intervenciones.
Y las intervenciones, por buenas que sean, no se gobiernan solas.
Para seguir leyendo
Esto continúa la idea de Tu sistema de gestión ya existe, solo que nadie lo diseñó y de Lo que se pregunta en la reunión es tu sistema de gestión. Sobre el vacío de propiedad extremo a extremo, Todos los pasos tienen dueño; el proceso no tiene ninguno.
