Hay un momento específico en la historia de casi todo proceso organizacional bien diseñado. Ocurre generalmente entre dos y seis semanas después de su implementación. Es el momento en que el proceso — elegante en el papel, coherente en la lógica, consensuado en el taller — comienza a deformarse silenciosamente.
Nadie toma la decisión de abandonarlo. No hay una reunión donde se vote en su contra. Simplemente, poco a poco, la gente encuentra atajos. Las excepciones se vuelven regla. Los pasos incómodos se saltan. Y lo que era un proceso se convierte en una intención documentada que nadie sigue.
La respuesta organizacional habitual: más capacitación, más control, más versiones del mismo documento con más detalle. La respuesta que realmente funciona es más difícil: entender por qué los procesos fallan de manera sistémica, no individual.
La mayoría de los procesos organizacionales se diseñan bajo un supuesto implícito que nadie nombra pero que está presente en cada diagrama de flujo, cada checklist, cada manual de procedimientos: el supuesto de que la organización es un sistema complicado, no complejo.
La distinción importa. Un sistema complicado tiene muchas partes, pero su comportamiento es predecible si se entienden las relaciones entre ellas. Un avión es complicado. Una receta de tres páginas es complicada. Dado suficiente expertise, su comportamiento puede ser modelado con precisión.
Un sistema complejo tiene partes que interactúan de maneras no lineales, que se adaptan entre sí, y cuyo comportamiento emergente no puede predecirse completamente desde el diseño de sus componentes. Una organización de veinte personas es compleja. Un equipo de ventas es complejo. Una empresa que está creciendo es compleja.
Cuando se diseña un proceso para un sistema complejo como si fuera complicado, el resultado es siempre el mismo: el proceso funciona bien en condiciones ideales y falla sistemáticamente cuando la realidad se desvía de esas condiciones. Lo cual ocurre, por definición, todo el tiempo.
Norbert Wiener, el matemático que fundó la cibernética en los años cuarenta, demostró algo que las organizaciones todavía no han terminado de asimilar: los sistemas que se sostienen en el tiempo no son los que tienen las reglas más precisas. Son los que tienen los mejores mecanismos de retroalimentación.
Un termostato no mantiene la temperatura de una habitación porque tenga una instrucción muy detallada de cuánto calor producir. La mantiene porque tiene un sensor que mide la diferencia entre la temperatura actual y la deseada, y ajusta su comportamiento en respuesta a esa diferencia.
Los procesos organizacionales que sobreviven al contacto con la realidad tienen algo análogo: un mecanismo que detecta cuando el proceso se desvía de su propósito, y la capacidad de ajustarse en respuesta.
Los que fallan son los que solo tienen la instrucción inicial, sin el sensor.
El proceso fue diseñado para el flujo ideal, no para las excepciones reales.
En todo proceso operacional, las excepciones no son anomalías — son parte del sistema. Un proceso de atención al cliente que solo define qué hacer cuando todo sale bien es un proceso que cubre quizás el cuarenta por ciento de las situaciones reales. El sesenta por ciento restante — el cliente que tiene un problema no contemplado, el proveedor que entrega tarde, el sistema que falla — queda sin respuesta formal. Y ante la ausencia de respuesta formal, cada persona improvisa. Las improvisaciones se consolidan. El proceso original queda obsoleto.
El proceso no tiene dueño, tiene aprobadores.
Hay una diferencia crítica entre aprobar un proceso y ser responsable de que funcione. Los aprobadores participan en el diseño y la validación. Los dueños observan cómo opera en el tiempo, reciben la señal cuando algo no funciona, y tienen la autoridad y el mandato de ajustarlo. Cuando un proceso tiene muchos aprobadores y ningún dueño real, nadie detecta la deformación porque nadie está mirando sistemáticamente.
El proceso mide outputs, no comportamientos.
Si el único indicador de un proceso es su resultado final — la venta cerrada, el proyecto entregado, el cliente satisfecho — no hay manera de saber si el proceso está siendo seguido o si el resultado llegó a pesar de que no lo fue. Medir solo outputs es como evaluar la salud de una persona solo por su peso: una métrica que puede estar bien aunque el sistema subyacente esté deteriorándose.
Existe una paradoja en el diseño de procesos que los líderes más orientados al control tienden a experimentar con más frecuencia. Cuanto más detallado y prescriptivo es un proceso, más frágil se vuelve ante variaciones no anticipadas. Y cuanto más frágil, más tentación hay de agregar más detalle y más prescripción.
El resultado es un ciclo que produce procesos cada vez más extensos y cada vez menos seguidos.
La alternativa no es eliminar la estructura. Es diseñar estructura que pueda adaptarse. En términos prácticos, esto significa definir con precisión el propósito del proceso y los criterios de evaluación de ese propósito, ser más flexible en los medios — los pasos específicos — que en los fines, y construir puntos de revisión periódica donde el proceso mismo pueda ser cuestionado y ajustado por quienes lo ejecutan.
Un proceso que no puede ser cuestionado por quien lo ejecuta no es un sistema de trabajo. Es una declaración de intenciones con fecha de vencimiento.
El cibernetista W. Ross Ashby formuló en 1958 lo que llamó la ley de variedad requerida: para controlar un sistema complejo, el mecanismo de control debe tener al menos tanta variedad — capacidad de respuesta a estados distintos — como el sistema que controla.
Traducido al lenguaje de los procesos: si tu operación enfrenta cien tipos de situaciones distintas, un proceso de diez pasos no puede cubrirlas adecuadamente. No porque los diez pasos estén mal diseñados, sino porque la variedad del proceso es estructuralmente insuficiente para la variedad del sistema que debe regular.
La implicación práctica es que parte del diseño de cualquier proceso debe incluir explícitamente la distribución de criterio a quienes lo ejecutan. No solo las reglas para los casos previstos, sino el marco de valores y prioridades que permite a las personas tomar buenas decisiones en los casos no previstos.
Esto requiere un tipo de confianza organizacional que muchos líderes encuentran incómoda. Pero es matemáticamente necesaria. La alternativa — intentar prever y prescribir todas las variaciones posibles — produce el ciclo de fragilidad descrito antes.
Un proceso diseñado para un sistema complejo no se parece a un manual de procedimientos. Se parece más a una constitución: define los principios y los límites, establece los mecanismos de ajuste, y distribuye la autoridad de interpretación a quienes están más cerca de la realidad operacional.
Concretamente, esto implica tres cambios en la práctica de diseño:
Primero, documentar el propósito del proceso con tanta precisión como los pasos — para que cuando los pasos fallen, haya un norte que oriente la adaptación.
Segundo, diseñar la revisión como parte del proceso mismo, no como una actividad separada. Un proceso que no se revisa periódicamente no es un sistema vivo — es un documento.
Tercero, tratar los desvíos como información, no como fracasos. Cada vez que alguien se sale del proceso para resolver una situación real, eso es una señal sobre los límites del diseño. Las organizaciones que aprenden de esas señales tienen procesos que mejoran. Las que los tratan como indisciplina tienen procesos que mueren.
El proceso perfecto no es el que nadie puede romper. Es el que se repara a sí mismo.
¿Quieres aplicar estas ideas en tu organización? Conversemos sobre cómo hacerlo.
Agendar sesión gratuita