La transformación fracasa en la puerta del cliente: cómo diseñar un cambio que la gente sienta

La transformación tiene éxito cuando cambian dos cosas en un día de trabajo cualquiera: cómo hacen su trabajo las personas de primera línea y lo que vive el cliente en el momento en que trata contigo. La mayoría de los programas cambian la estructura, los sistemas y la presentación, y se detienen antes de llegar a esos dos lugares. La solución es diseñar el cambio desde el momento del cliente hacia atrás, mapear el sistema que produce ese momento y dejar que los equipos que hacen el trabajo sean dueños de la hoja de ruta y de las medidas.

Este es el artículo de referencia de nuestra serie sobre Transformación. Recorre el tema completo y enlaza con los artículos que profundizan en cada parte.

Por qué la transformación se detiene antes de llegar a nadie

Imagina un programa típico. Se aprueba un nuevo modelo operativo. Se rebautizan los departamentos. Se compra y se configura una plataforma. Los cuadros de mando se ponen en verde. Dieciocho meses después, un cliente llama con el mismo problema que tenía antes, le pasan entre los mismos tres equipos y espera el mismo número de días. La empleada que atiende el teléfono sigue usando un apaño porque el nuevo sistema no resuelve los casos que ve cada semana.

Nada en esa historia es un fallo de esfuerzo. Es un fallo de hacia dónde se dirigió el esfuerzo. Los programas suelen diseñarse de arriba abajo: estrategia, estructura, tecnología, procesos, personas. El cliente aparece al final, como un objetivo de satisfacción. Cuando el cambio llega a la primera línea, se ha traducido tantas veces que nadie sabe decir qué debería sentirse distinto el martes por la mañana.

Hay tres patrones que aparecen una y otra vez:

• El cambio se organiza por departamentos, pero el cliente se mueve entre departamentos. Cada unidad mejora su propia parte. Los traspasos entre ellas, donde está la mayor parte del dolor, no son de nadie.
• Se mide la actividad en lugar del resultado. Se cuentan las sesiones de formación impartidas, los sistemas lanzados y las políticas publicadas. Si un solo cliente espera menos, no.
• A las personas que hacen el trabajo se les informa, no se les implica. Reciben el nuevo proceso en una sesión informativa. Saben exactamente por qué no funcionará en los casos difíciles, y nadie les preguntó.

Analizamos a fondo el segundo y el tercer patrón en por qué los programas de transformación producen informes y nadie cambia su forma de trabajar.

Las cuatro capas de una transformación que la gente siente

Ayuda pensar la transformación como cuatro capas, de fuera hacia dentro. El cambio tiene que diseñarse en las cuatro, y con la atención en ese orden.

1. Lo que siente el cliente. Los momentos en que un cliente, un ciudadano o un empleado se encuentra con tu servicio: el formulario, la llamada, la ventanilla, el mensaje, la espera. Es la única capa que vive alguien de fuera de la organización.
2. Cómo trabaja la gente. Las acciones de frontstage y de backstage que producen cada momento: quién hace qué, con qué información, en qué secuencia y con cuánto margen de decisión.
3. El sistema que hay debajo. Políticas, normas de aprobación, sistemas informáticos, datos, incentivos, presupuestos y líneas jerárquicas. Esta capa decide lo que la gente puede y está autorizada a hacer.
4. Cómo se dirige el cambio. La hoja de ruta, la asignación de responsabilidades, la gobernanza y las medidas que guían el programa durante meses y años.

La mayoría de los programas empiezan en la capa cuatro y gastan su energía en la capa tres. La capa del cliente se trata como un resultado que llegará solo. Rara vez llega, porque nadie ha diseñado el vínculo entre una nueva política y un momento distinto en la ventanilla.

El trabajo de experiencia de cliente empieza por el extremo opuesto. Si tu organización todavía está construyendo ese hábito, lee centrarse en el cliente es una práctica, no un eslogan: por dónde empezar junto con este artículo. La transformación es donde esa práctica tiene que escalar a toda la organización.

Cómo diseñar un cambio que la gente sienta: siete pasos

Estos pasos sirven tanto para la transformación organizacional como para la digital. No sustituyen a la gestión de programas. Son lo que pones dentro de ella para que aterrice.

1. Elige recorridos, no departamentos

Elige de tres a cinco recorridos de cliente que sean los más importantes para el propósito de la organización y que atraviesen varias unidades: «obtener un permiso», «presentar una reclamación», «incorporarse como nuevo empleado», «cambiar un plan de pagos». Organiza la primera ola de la transformación en torno a esos recorridos. Cada recorrido recibe un pequeño equipo multifuncional con un responsable con nombre que tiene autoridad para cambiar las cosas por encima de las fronteras entre departamentos.

Elige recorridos sobre los que ya oyes quejas repetidas, con mucha demanda o en los que está en juego un objetivo estratégico. Evita empezar por el recorrido políticamente más seguro; enseña a la organización que la transformación es cosmética.

2. Ve a ver antes de diseñar nada

Antes de cualquier taller, el equipo del recorrido vive el servicio como lo haría un cliente y observa cómo se presta. Un service safari hace que los miembros del equipo recorran el camino ellos mismos. La observación contextual consiste en sentarse con el personal de primera línea mientras trabaja y anotar cada apaño, hoja de cálculo y llamada telefónica que el proceso oficial no menciona.

Este paso cambia lo que cree el programa. Los directivos descubren con frecuencia que el proceso que aprobaron no es el proceso que funciona.

3. Mapea la experiencia y el trabajo que hay detrás

Dibuja el recorrido actual con un mapa de experiencia: etapas, acciones, pensamientos, emociones y puntos de dolor desde el lado del cliente. Después dibuja debajo el service blueprint, la herramienta que G. Lynn Shostack presentó en los años ochenta, que muestra las acciones de frontstage, las de backstage y los procesos de soporte, separados por la línea de visibilidad.

El blueprint es donde la transformación se vuelve concreta. Puedes señalar el traspaso exacto en el que un expediente espera cuatro días, o el paso en el que el personal vuelve a introducir datos porque dos sistemas no se hablan. Si no sabes cuál de los dos mapas necesitas primero, consulta customer journey map o service blueprint.

4. Mapea el sistema antes de cambiarlo

El blueprint muestra el trabajo. No muestra por qué el trabajo es como es. Para eso necesitas un mapa de sistema de las normas, los incentivos, los flujos de datos y las decisiones que mantienen el patrón actual, y un mapa de partes interesadas de quién gana, quién pierde y quién tiene que dar el visto bueno.

Añade un análisis de campo de fuerzas, la herramienta de Kurt Lewin para enumerar las fuerzas que empujan a favor y en contra de un cambio. A menudo revela que la fuerza de resistencia más poderosa es una sola norma de aprobación o un indicador de reporte, no la resistencia de las personas. La guía completa está en mapear el sistema antes de cambiarlo.

5. Diseña a la vez los nuevos momentos y el nuevo trabajo

Ahora diseña el recorrido futuro: qué momentos cambian, qué debería sentir el cliente en cada uno y qué hará de forma distinta cada persona por debajo de la línea de visibilidad. Diseña la capa uno y la capa dos en la misma sesión, con el personal de primera línea en la sala. Una nueva promesa al cliente sin una nueva forma de trabajar detrás es un eslogan.

Prueba los nuevos momentos antes de construir nada. Un role play de la nueva conversación en ventanilla, hecho con personal real y unos pocos clientes reales, saca a la luz en una tarde huecos que un desarrollo de sistemas sacaría a la luz en seis meses. Para toda la gama de pruebas baratas, consulta probar una experiencia antes de construirla.

6. Construye una hoja de ruta que sea de los equipos

Convierte los cambios diseñados en una hoja de ruta organizada por recorrido y por resultado, no por versiones del sistema. Cada elemento indica qué momento mejora, qué equipo es responsable y qué se retirará cuando llegue. Usa una matriz RACI para las decisiones entre departamentos, de modo que los traspasos tengan responsable.

La clave es la pertenencia. Una hoja de ruta escrita por una oficina de programa y entregada a los equipos es un calendario. Una hoja de ruta que han escrito los equipos de recorrido, y que revisan cada trimestre, es un compromiso. Cómo organizarlo se explica en dirigir una hoja de ruta de transformación que sea de los equipos.

7. Mide lo que siente la gente y retira lo que ya no necesita

Construye un árbol de KPI que conecte el objetivo estratégico con los resultados del recorrido (tiempo de resolución, contactos repetidos, casos resueltos a la primera, esfuerzo) y, más abajo, con las medidas operativas que los equipos pueden mover. Reporta esas medidas, no el número de talleres ni de puestas en marcha. El método está en medir la transformación por resultados, no por actividad.

Después, mantén una lista de cosas que dejar de hacer. Cada proceso nuevo debería apagar un formulario, un informe, una aprobación o un sistema antiguo. Una transformación que solo añade es la forma en que las organizaciones acaban con la forma nueva y la antigua funcionando en paralelo, y con el personal haciendo las dos.

Dónde encaja la transformación digital

La transformación digital es la versión más común de este problema, y la más cara cuando sale mal. Una plataforma nueva reproduce el proceso antiguo en una pantalla, o impone un proceso que la primera línea no puede usar, y el cliente ve una interfaz más bonita sobre el mismo retraso.

Trata cada iniciativa digital como un rediseño del servicio que, además, implica tecnología. Parte del recorrido y del blueprint, decide qué momentos y traspasos deberían cambiar y solo entonces especifica el sistema. El argumento completo está en la transformación digital es un problema de diseño de servicios.

Si necesitas saber hasta qué punto está preparada la organización para este tipo de trabajo, una evaluación de madurez en innovación te da un punto de partida. Si la propia agenda de transformación no está clara, empieza por construir una estrategia de innovación en unos pocos talleres.

Ejemplo ilustrativo: el nuevo sistema de facturación de una empresa de suministros

Ilustrativo. Una empresa regional de aguas de un país europeo mediano lleva dos años con un programa de transformación. La pieza central es una nueva plataforma de facturación y atención al cliente. Se ha puesto en marcha según lo previsto. Las quejas por las facturas no han bajado y los tiempos de atención de llamadas han subido.

El director del programa pide un enfoque distinto para un recorrido: «mi factura parece incorrecta». Se forma un equipo de seis personas: dos asesores del call center, un analista de facturación, un técnico de campo, un product owner de IT y una responsable de atención al cliente como responsable del recorrido.

Pasan una semana haciendo un service safari y sentados junto a los asesores. Descubren que los asesores no pueden ver el historial de lecturas del contador en la nueva plataforma, así que abren un ticket a facturación por cada consulta. Facturación trabaja los tickets por lotes. Al cliente se le promete una llamada en cinco días y a menudo recibe una carta en su lugar.

El blueprint muestra tres traspasos en los que los casos esperan. El mapa de sistema muestra por qué: una norma de protección de datos se había interpretado de forma que restringía los datos de los contadores al equipo de facturación, y el propio objetivo de facturación contaba tickets cerrados, no consultas resueltas en el primer contacto.

El equipo diseña un nuevo momento: el asesor explica la factura en la primera llamada. Detrás, los asesores obtienen acceso de solo lectura al historial del contador, acordado con el delegado de protección de datos, y un guion breve para las tres causas más frecuentes. Lo ensayan en un role play con diez clientes voluntarios antes de cambiar ninguna configuración. El objetivo de facturación pasa a las consultas resueltas a la primera. La carta de devolución de llamada entra en la lista de cosas que dejar de hacer.

El elemento de la hoja de ruta es responsabilidad del equipo del call center, no de IT. La medida que se reporta al consejo es el porcentaje de consultas sobre facturas resueltas en el primer contacto, con seguimiento mensual.

Qué hacer y qué evitar

Haz esto

• Empieza con un número pequeño de recorridos que crucen departamentos y da a cada uno un único responsable con autoridad real.
• Incluye al personal de primera línea en cada sesión de diseño, no solo en la sesión informativa posterior.
• Observa el trabajo antes de rediseñarlo. El proceso oficial y el real rara vez coinciden.
• Mapea normas, incentivos y flujos de datos; suele ser ahí donde se bloquea el cambio.
• Prueba los nuevos momentos con role play o un piloto manual antes de configurar sistemas.
• Haz un premortem de cada elemento de la hoja de ruta: imagina que ha fracasado dentro de un año y enumera por qué.
• Retira algo cada vez que lances algo.
• Haz una retrospectiva con cada equipo de recorrido cada trimestre y cambia la hoja de ruta en función de ella.

Evita esto

• No midas el éxito por las puestas en marcha, las horas de formación o el número de procesos documentados.
• No rediseñes primero el organigrama esperando que la experiencia de cliente venga detrás.
• No dejes que la oficina de programa escriba sola la hoja de ruta.
• No digitalices un proceso que no has mirado; automatizarás la espera.
• No lleves el trabajo de experiencia de cliente como una línea aparte junto a la transformación. Es la prueba de la transformación para saber si algo ha cambiado.
• No anuncies una nueva promesa al cliente antes de que haya cambiado el trabajo que hay detrás.

Preguntas frecuentes

¿Por qué fracasan la mayoría de las transformaciones? Rara vez por falta de esfuerzo o de dinero. Fracasan porque el cambio se diseña y se mide a nivel de estructura y sistemas, y nunca se diseña hasta llegar a los momentos concretos que viven los clientes y el personal. Los traspasos entre departamentos, donde se concentran la mayor parte de los retrasos y la frustración, no son de nadie, así que siguen igual.

¿Qué diferencia hay entre transformación y gestión del cambio? La gestión del cambio suele consistir en ayudar a la gente a adoptar un cambio que ya se ha decidido. La transformación, bien hecha, implica a esas personas en decidir qué cambia desde el principio. Los métodos de este artículo lo hacen posible: el personal ayuda a observar, mapear, diseñar y probar la nueva forma de trabajar, así que la adopción no es un problema aparte que resolver más tarde.

¿Cómo se sabe si una transformación está funcionando? Mira al cliente y a la primera línea, no al programa. ¿Los recorridos son más rápidos o más fáciles según medidas que los clientes reconocerían? ¿Bajan los contactos repetidos? ¿Ha dejado el personal de usar apaños? ¿Se ha apagado algo antiguo? Si la respuesta a las cuatro preguntas es no, el programa está ocupado, no funcionando.

Por dónde seguir

Empieza por un recorrido. Usa un service safari para verlo como lo ve un cliente, un service blueprint para ver el trabajo que hay detrás, un mapa de sistema para ver qué lo mantiene en su sitio y un árbol de KPI para decidir cómo sabrás que ha cambiado. Las 75 guías de métodos están en la biblioteca de guías.