Al inicio de esta semana planteamos una pregunta:
¿Su proceso funciona o las personas aprendieron a sortearlo?
La pregunta parece sencilla. Pero existe una diferencia importante entre percibir que las personas crean atajos y comprender por qué lo hacen.
Puede existir un procedimiento. El flujo puede estar documentado. Las responsabilidades pueden estar definidas. Las personas pueden haber recibido formación.
Y, aun así, en la operación real, el trabajo puede seguir caminos distintos de los previstos.
Ante eso, una conclusión aparece con facilidad:
“Las personas no siguen el proceso.”
Tal vez.
Pero eso describe lo que estamos viendo. No necesariamente explica lo que está ocurriendo.
No toda desviación comienza en la ejecución
Hay situaciones en las que el proceso es adecuado, pero las personas no recibieron el conocimiento, los recursos o la preparación suficientes para ejecutarlo.
Hay otras en las que se puso a disposición una herramienta, pero no se desarrolló la capacidad necesaria para utilizarla.
Hay situaciones en las que continúan prevaleciendo hábitos anteriores.
Y también existen aquellas en las que el problema comenzó antes de todo eso:
el propio proceso fue diseñado sin comprender suficientemente la realidad en la que tendría que funcionar.
Esa posibilidad cambia la investigación.
En lugar de preguntar solamente:
“¿Por qué las personas no están siguiendo el proceso?”
tal vez sea necesario preguntar:
“¿El proceso que les estamos pidiendo que sigan tiene sentido en las condiciones reales en las que se realiza el trabajo?”
Esto no es una defensa de la improvisación. Tampoco significa que toda resistencia sea legítima o que la forma actual de trabajar deba conservarse.
Significa reconocer algo elemental:
un proceso puede tener sentido en el diagrama de flujo y no tenerlo en el entorno donde realmente debe funcionar.
Cuando una buena idea se encuentra con una operación que no conoce
Imagine una operación de campo distribuida geográficamente.
Un determinado equipo necesita una intervención después de que ocurra una condición específica. Alguien analiza la necesidad y define quién será responsable de la actividad.
Técnicamente, la decisión parece coherente. Existe una necesidad de mantenimiento. Existe un profesional asociado a ese tipo de instalación. Se le asigna la actividad.
Sobre el papel, problema resuelto.
Pero existe una información que el diseño no incorporó suficientemente:
¿dónde están esas personas en relación con el lugar donde debe realizarse la intervención?
En determinadas situaciones, el profesional definido por el procedimiento podría tener que recorrer una distancia considerable únicamente para realizar esa actividad.
Mientras tanto, equipos de atención de emergencias ya circulan por el territorio y podrían incorporar la tarea a su propia rutina operativa.
La necesidad seguía siendo correcta. La actividad seguía siendo necesaria. El problema estaba en la arquitectura elegida para ejecutarla.
Cuando la orientación llegó a la operación, quienes conocían la realidad de campo cuestionaron el diseño.
No porque no quisieran ejecutar el trabajo, sino porque conocían una condición que no había estado suficientemente representada en la decisión.
Este tipo de situación revela una trampa de gestión:
podemos intentar formar a las personas para ejecutar perfectamente un proceso que debería haber sido cuestionado antes de comenzar la formación.
Más formación no eliminaría el desplazamiento innecesario. Más presión por el cumplimiento tampoco.
Un indicador de cumplimiento podría incluso demostrar que la actividad se estaba realizando, mientras los recursos siguieran consumiéndose de manera inadecuada.
El trabajo real contiene información que el procedimiento no contiene
Comprender el AS-IS no debería significar simplemente localizar el procedimiento vigente y convertirlo en un diagrama de flujo.
El proceso formal indica cómo debería realizarse el trabajo. El trabajo real muestra cómo ocurre efectivamente.
Entre ambos pueden existir atajos, excepciones, controles paralelos, hojas de cálculo auxiliares, decisiones informales, conocimiento tácito, restricciones tecnológicas, limitaciones geográficas, dependencias entre áreas y adaptaciones incorporadas con el tiempo.
Algunas de esas prácticas son desperdicios. Otras son respuestas inteligentes a problemas que el diseño formal nunca resolvió. Algunas pueden ser ambas cosas al mismo tiempo.
Observar el trabajo real no significa aceptarlo sin cuestionamiento.
Significa convertirlo en evidencia para comprender el sistema antes de rediseñarlo.
Stakeholder no es quien recibe el diagrama para aprobarlo
Una organización puede creer que involucró a los stakeholders porque presentó el proceso ya terminado a diferentes áreas y pidió su validación.
Pero validar un diseño después de que sus principales decisiones ya fueron tomadas es diferente de participar en la comprensión del problema.
En este contexto, stakeholder no es únicamente quien ejecuta una actividad.
Incluye a quien suministra entradas, ejecuta, recibe las salidas, toma decisiones, responde por los sistemas, conoce restricciones de seguridad, calidad, regulación o tecnología, se ve afectado por las consecuencias o posee conocimiento relevante sobre cómo funciona realmente el proceso.
Esto no significa reunir a decenas de personas para decidir cada flecha de un diagrama.
Significa garantizar que las perspectivas necesarias estén representadas mientras todavía pueden modificar el diseño.
El conocimiento organizacional suele estar distribuido.
Quien ejecuta conoce detalles que la gestión puede no ver. Quien recibe la salida percibe problemas que quien ejecuta quizá no perciba. Tecnología conoce las limitaciones de los sistemas. El liderazgo conoce objetivos y restricciones del negocio. El cliente experimenta consecuencias que ninguna de esas áreas observa por completo.
Ninguna perspectiva, de forma aislada, representa necesariamente todo el proceso.
Un proceso puede existir durante años y seguir siendo inadecuado
También existe el problema opuesto al proceso recién diseñado: el proceso antiguo.
Aquel que existe desde hace tanto tiempo que su propia longevidad empieza a funcionar como argumento de legitimidad.
“Siempre se ha hecho así.”
En una operación de cobros con muchos años de funcionamiento ya existían procedimientos, responsabilidades y una forma establecida de ejecutar las actividades.
El proceso existía. Pero no funcionaba satisfactoriamente.
Uno de los cambios realizados fue aparentemente sencillo:
reunir a los stakeholders relevantes alrededor del mismo proceso.
Primero, comprender cómo se realizaba realmente el trabajo: el AS-IS.
Después, confrontar perspectivas, interfaces, problemas y brechas.
¿Qué hacía un área? ¿Qué esperaba recibir la siguiente? ¿Dónde estaban las ambigüedades? ¿Qué responsabilidades no estaban claras? ¿Qué partes del procedimiento no correspondían con la ejecución? ¿Qué conocimiento estaba distribuido entre diferentes personas y áreas?
Solo después de esa comprensión se construyó el TO-BE.
El nuevo diseño fue discutido, validado, formalizado y entonces puesto en práctica.
La diferencia no estaba simplemente en tener un mejor diagrama de flujo.
El proceso pasó a incorporar conocimiento que antes estaba disperso entre sus stakeholders.
Escuchar a la operación no significa diseñar el proceso exactamente como se trabaja hoy
Si diseñar un proceso únicamente desde la visión de quienes están lejos de la ejecución es arriesgado, hacer el movimiento contrario también puede serlo.
Quienes ejecutan el trabajo pueden haber incorporado prácticas innecesarias, repetir controles cuya razón original ya no existe, mantener etapas porque “siempre se ha hecho así”, crear atajos que resuelven un problema local y generan consecuencias en otra parte del proceso o no ver restricciones y objetivos fuera de su actividad.
Por eso:
escuchar a quien ejecuta no significa convertir el AS-IS en TO-BE.
Significa no construir el TO-BE ignorando aquello que solo el trabajo real puede revelar.
El objetivo no es elegir entre “la teoría” y “la operación”.
Es poner en diálogo el conocimiento técnico, los objetivos organizacionales y la realidad operativa.
Y entonces llegamos a la formación
Después de diseñar el proceso todavía queda otra distancia por recorrer.
Una organización puede construir un proceso adecuado y fracasar en la implantación.
Puede comunicar mal, formar de manera insuficiente, no proporcionar recursos, no preparar a los líderes o no desarrollar autonomía para gestionar excepciones.
O simplemente presentar el procedimiento y considerar que la capacidad ya está instalada.
Esa fue precisamente la provocación de nuestra publicación anterior:
una herramienta disponible no equivale a capacidad instalada.
El mismo razonamiento vale para los procesos.
Proceso diseñado no equivale a proceso ejecutable.
Proceso publicado no equivale a proceso incorporado.
Formación realizada no equivale a capacidad instalada.
Por eso, cuando encontramos distancia entre procedimiento y ejecución, al menos tres hipótesis deben permanecer abiertas:
el proceso puede ser inadecuado;
la capacidad necesaria para ejecutarlo puede no haberse desarrollado;
o ambas cosas pueden estar ocurriendo al mismo tiempo.
Elegir un diagnóstico antes de investigar es precisamente el tipo de simplificación que genera nuevas intervenciones sobre causas equivocadas.
Y la automatización hace que este cuidado sea aún más importante
El martes discutimos otra consecuencia de esta misma cuestión:
¿Automatizar el proceso o automatizar el problema?
La automatización y la inteligencia artificial amplían enormemente lo que podemos transferir a la tecnología.
Pero la velocidad no sustituye a la comprensión.
Si automatizamos un flujo alejado del trabajo real, podemos eliminar precisamente la flexibilidad informal que permitía a las personas compensar sus fragilidades.
El proceso sigue siendo inadecuado. Solo que ahora puede reproducir esas fragilidades con mayor velocidad, consistencia y escala.
Por eso sigue siendo tan importante la pregunta anterior a la automatización:
¿comprendemos suficientemente bien aquello que estamos a punto de acelerar?
Tal vez la adhesión comience antes de la formación
Existe una tendencia a tratar la adhesión como una cuestión posterior al diseño.
Primero construimos el proceso. Después formamos. Entonces exigimos cumplimiento.
Pero parte de la adhesión puede comenzar mucho antes.
Comienza cuando vemos el trabajo tal como realmente ocurre. Cuando comprendemos las perspectivas que intervienen en ese sistema. Cuando confrontamos procedimiento y realidad. Cuando distinguimos adaptación necesaria de desperdicio incorporado. Cuando las personas que poseen conocimiento relevante pueden influir en el diseño antes de que este ya esté decidido.
Eso no elimina la resistencia, el conflicto ni la necesidad de decisión gerencial. Y ciertamente no convierte cada proceso en un consenso.
Participación no significa que todos decidan todo.
Significa que pueden tomarse mejores decisiones cuando el conocimiento necesario llega a la decisión antes de que esta sea tomada.
Del trabajo real a la capacidad organizacional
Tal vez sea precisamente aquí donde Personas y Procesos dejan de ser asuntos separados.
Los procesos organizan la ejecución. Las personas poseen una parte relevante del conocimiento necesario para ejecutarlos y mejorarlos. La tecnología puede ampliar la capacidad. Los productos y servicios reciben los efectos de esa combinación. Y la Rentabilidad termina absorbiendo aquello que funciona — y aquello que no funciona.
En Power 4P, los 6Es ayudan a organizar esta investigación sin presumir de antemano dónde está el problema.
VER el trabajo real.
ENTENDER stakeholders, restricciones, conocimiento, interfaces y excepciones.
ELEGIR un diseño coherente con el resultado que necesitamos producir.
EJECUTAR y desarrollar la capacidad necesaria para hacerlo realidad.
EVIDENCIAR si el nuevo proceso realmente mejoró el sistema.
EVOLUCIONAR incorporando aquello que la propia ejecución continúa enseñándonos.
El punto no es defender que todo proceso deba ser rediseñado, ni concluir que toda desviación demuestra un error de diseño.
Se trata de evitar la conclusión cómoda de que el problema está en las personas simplemente porque es en ellas donde conseguimos verlo.
Antes de exigir adhesión, tal vez exista una pregunta anterior:
¿Quienes diseñaron el proceso conocían el trabajo real?
Porque cuando la respuesta es no, aquello que llamamos resistencia puede ser simplemente el lugar donde la realidad finalmente encontró una manera de responder al diagrama de flujo.