Mapear el sistema antes de cambiarlo: guía práctica

Para mapear un sistema antes de cambiarlo, elige un resultado que importe a las personas a las que va dirigido el cambio y dibuja todo lo que hoy produce ese resultado: las personas y unidades implicadas, lo que circula entre ellas, las reglas que las gobiernan y los bucles que mantienen estable la situación actual. Un buen mapa lleva de dos a cuatro semanas, se construye con las personas que forman parte del sistema y no sobre ellas, y termina con una lista breve de lugares donde un cambio tiene probabilidades de mantenerse. Sin él, una transformación suele cambiar la parte del sistema más fácil de ver y luego contempla cómo el resto del sistema la deshace en silencio.

Por qué el mapa va primero

La mayoría de los planes de transformación se dibujan sobre un organigrama. El organigrama muestra quién reporta a quién. No muestra cómo se mueve realmente el trabajo, dónde una solicitud espera tres semanas ni qué regla informal sigue todo el mundo porque saltársela una vez causó problemas. Eso es lo que decide si un cambio sobrevive.

El pensamiento sistémico tiene una larga tradición en esto. La quinta disciplina (1990), de Peter Senge, popularizó la idea de que las organizaciones se comportan según su estructura, no según sus intenciones, y el ensayo de Donella Meadows Leverage Points: Places to Intervene in a System (1999) sostenía que los puntos donde instintivamente se empuja, como presupuestos, impuestos y normas, suelen ser los más débiles para actuar.

Este artículo es el complemento práctico de La transformación fracasa a la puerta del cliente, que explica por qué el cambio tiene que notarlo el cliente para contar. Mapear es la forma de descubrir qué se interpone hoy entre tu organización y esa experiencia.

Paso 1: Elegir el resultado, no el departamento

Empieza por un resultado descrito desde fuera: «una pequeña empresa obtiene una licencia de actividad», «un paciente recibe el alta y sabe qué hacer después», «un proveedor cobra a tiempo». Evita empezar por una unidad («mapear el departamento de licencias»), porque el resultado casi siempre atraviesa tres o cuatro unidades y dos partes externas.

Escribe el resultado en una frase y acuerda dos límites: dónde empieza el sistema (el primer momento en que alguien necesita algo) y dónde termina (el momento en que lo tiene, o se rinde). Todo lo que, dentro de esos límites, da forma al resultado va en el mapa.

Paso 2: Enumerar los actores y luego situarlos

Haz primero un mapa de partes interesadas, porque es rápido y pone nombres en la pared. Incluye:

• Las personas a las que va dirigido el resultado, divididas en los dos o tres grupos que lo viven de forma distinta.
• Todas las unidades internas que tocan una solicitud, incluidas las que solo aprueban o revisan.
• Las partes externas: reguladores, proveedores, entidades socias, bancos, plataformas.
• Los actores silenciosos: el buzón compartido, el sistema heredado, el comité que se reúne una vez al mes. Trata un sistema o una reunión como actor si el trabajo espera por él.

Después pasa a un mapa de sistema y sitúa a los actores en una misma superficie. Cuando varias organizaciones comparten el resultado, un mapa de ecosistema es mejor lienzo, porque muestra el valor que se intercambia entre entidades en lugar de los pasos dentro de una sola.

Paso 3: Dibujar los flujos

Conecta a los actores con flechas y etiqueta cada flecha con lo que circula: información, dinero, documentos, aprobaciones, personas, datos. Conviene marcar por separado, con colores distintos, cuatro tipos de flujo:

1. Flujos de trabajo. La solicitud, el expediente o el caso según avanza.
2. Flujos de información. Quién le dice qué a quién, y con cuánto retraso.
3. Flujos de dinero y recursos. Presupuestos, tasas, tiempo del personal.
4. Flujos de autoridad. Quién puede decir sí, quién puede decir no, a quién hay que consultar.

Cuando el flujo es una secuencia dentro de un solo equipo, un diagrama de flujo del proceso lo recoge mejor que las flechas de un gran mapa. Cuando implica a la vez la experiencia del cliente y el back office, un service blueprint muestra ambas capas.

No dibujes los flujos solo a partir de documentos. Recorre tú mismo el trayecto. Un service safari, en el que el equipo vive el servicio como lo haría un cliente, revela con frecuencia pasos que el proceso oficial no menciona.

Paso 4: Marcar las reglas y los bucles

Es el paso que la mayoría de los equipos se salta, y es donde está la información útil.

Reglas. Junto a cada actor y cada flujo, escribe las reglas que condicionan el comportamiento: políticas escritas, objetivos de rendimiento, umbrales de aprobación y las reglas no escritas («nadie firma antes de que lo haya visto el director»). Pregunta directamente: «¿Qué te metería en un lío aquí?». Las respuestas son las reglas reales.

Bucles. Busca cadenas que se retroalimentan. Una habitual: aumentan las quejas, así que se añade un paso de revisión, así que la tramitación se ralentiza, así que las quejas aumentan aún más. Otra: una unidad se mide por su rapidez, así que rechaza enseguida los expedientes incompletos, así que los clientes los vuelven a presentar, así que el volumen crece, así que la unidad parece desbordada y pide más personal. Dibújalos como círculos cerrados. Un bucle que mantiene estable la situación actual es la razón por la que los intentos de cambio anteriores se desvanecieron.

Aplica los cinco porqués a cualquier retraso o punto de fallo para rastrearlo hasta la regla o el bucle que hay detrás.

Paso 5: Encontrar dónde habrá resistencia y dónde el cambio se mantendrá

Ahora lee el mapa en su conjunto. Ayudan tres preguntas:

• ¿Dónde espera el trabajo? Los puntos de espera suelen estar en los flujos de autoridad, no en los de trabajo.
• ¿Qué regla, si cambiara, modificaría varios flujos a la vez? Esa es una candidata a punto de apalancamiento.
• ¿Quién se beneficia de la situación actual? No como villanos. La mayor parte de la resistencia viene de personas cuyos objetivos, carga de trabajo o estatus dependen del diseño actual.

Para cada lugar candidato, haz un rápido análisis de campo de fuerzas (la herramienta de Kurt Lewin): enumera las fuerzas que impulsarán el cambio y las que lo frenarán. Elige los dos o tres lugares donde las fuerzas impulsoras son reales y las restrictivas pueden abordarse. Serán los puntos de partida de la hoja de ruta, que se trata en Una hoja de ruta de transformación que los equipos hacen suya.

Paso 6: Validar el mapa con las personas que aparecen en él

Antes de que nadie decida nada, lleva el mapa a las personas que aparecen en él, en grupos pequeños, y pregunta: «¿Qué está mal o qué falta?». Espera correcciones. Cada corrección convierte a esas personas en coautoras del diagnóstico en lugar de en su objeto. Un mapa que el personal de primera línea reconoce es el argumento más sólido que un equipo de transformación puede llevar a una reunión de dirección.

Ejemplo ilustrativo

Ilustrativo. Un ayuntamiento de tamaño medio del norte de Europa quería reducir a la mitad el plazo de aprobación de obras menores. El plan original era un nuevo portal en línea. El equipo mapeó primero el sistema, partiendo del resultado «un propietario obtiene permiso para construir una ampliación».

El mapa mostró once actores, entre ellos dos agencias externas y una comisión de urbanismo mensual. El flujo de trabajo parecía razonable; el de autoridad, no. Cualquier solicitud que afectara a una calle protegida iba a la comisión, fuera cual fuera su tamaño, y la comisión se reunía una vez al mes. Detrás había un bucle. Las quejas por una ampliación polémica habían llevado en su día a una norma según la cual «todos los casos patrimoniales van a comisión», lo que lo ralentizaba todo, lo que hacía que más solicitantes llamaran a los concejales, lo que mantenía nerviosa a la comisión y la norma en vigor.

El portal habría agilizado la presentación sin cambiar nada de la espera. En su lugar, el ayuntamiento delegó los casos patrimoniales pequeños en técnicos sénior con criterios claros, reservó la comisión para los grandes y solo entonces construyó el formulario en línea. El portal se puso en marcha en un sistema capaz de aprovecharlo.

Qué hacer y qué evitar

Qué hacer

• Partir de un resultado que el cliente reconocería.
• Incluir a las partes externas y a los actores no humanos, como sistemas y comités.
• Escribir las reglas no escritas. Preguntar qué mete a la gente en líos.
• Dibujar los bucles como círculos para que nadie los confunda con líneas rectas.
• Llevar el mapa a las personas que aparecen en él antes de actuar.

Qué evitar

• Mapear solo a partir de documentos de políticas y manuales de procesos.
• Mapear un departamento cuando el resultado atraviesa cinco.
• Buscar la exhaustividad. Un mapa está terminado cuando cambia una decisión, no cuando están dibujadas todas las cajas.
• Presentar el mapa como una conclusión sobre personas en lugar de sobre estructura.
• Dejar que el mapeo se convierta en el proyecto. De dos a cuatro semanas suelen bastar para un resultado.

Preguntas frecuentes

¿Qué diferencia hay entre un mapa de sistema y un mapa de procesos? Un mapa de procesos muestra los pasos por los que pasa una unidad de trabajo, normalmente dentro de un equipo. Un mapa de sistema muestra todos los actores, flujos, reglas y bucles que, juntos, producen un resultado, incluidos los que están fuera de tu organización. Usa un mapa de procesos para hacer zoom en una parte del mapa de sistema.

¿Qué nivel de detalle debe tener un mapa de sistema? El suficiente para mostrar dónde espera el trabajo y por qué. Si una caja o una flecha no cambiaría dónde decides actuar, déjala fuera. La mayoría de los mapas útiles caben en una pared.

¿Quién debe estar en la sala al mapear un sistema? Personas que hacen el trabajo en cada etapa, al menos una persona que vive el resultado como cliente, alguien que conozca las reglas (políticas, jurídico o finanzas) y quien vaya a patrocinar el cambio. Mantén el grupo central entre seis y diez personas y valida después con otras.

Por dónde seguir

Empieza con las guías del mapa de sistema y del mapa de partes interesadas, haz zoom con un service blueprint y pon a prueba los puntos elegidos con un análisis de campo de fuerzas. Si tu último programa no mapeó nada y aun así produjo un grueso informe, Por qué los programas de transformación producen informes y nadie cambia su forma de trabajar explica el patrón.