La transformación digital es un problema de diseño de servicios, no de tecnología

La transformación digital sale mal cuando se dirige como un programa tecnológico: elegir una plataforma, pasar los formularios a internet, contar los sistemas lanzados. El cliente sigue encontrándose con los mismos traspasos, los mismos documentos y la misma espera, solo que ahora en una pantalla. Trátala, en cambio, como un problema de diseño de servicios. Rediseña lo que la persona intenta conseguir, de principio a fin, en el frontstage y en el backstage, y solo entonces decide qué tiene que hacer la tecnología.

La creencia, expuesta con justicia

La creencia es esta: nuestros servicios son lentos porque nuestros sistemas son antiguos. Sustituye los sistemas, pon los servicios en internet y la experiencia mejorará por sí sola.

No es una creencia absurda. Los sistemas antiguos ralentizan las cosas. El papel se pierde. Muchos servicios son realmente mejores en línea, y algunos solo pueden escalar así. Además, el gasto en tecnología es fácil de planificar, aprobar y reportar. Tiene proveedores, hitos y una fecha de lanzamiento. Un equipo directivo puede ver cómo ocurre.

Así que el instinto de empezar por la tecnología es comprensible. El problema es lo que deja fuera.

Por qué falla en la práctica

Digitaliza el proceso, no el resultado

El primer movimiento de la mayoría de los programas es tomar el formulario existente y ponerlo en internet. Cada campo, cada adjunto, cada paso de firma sobrevive al cambio. El cliente que antes hacía cola en una ventanilla ahora sube los mismos siete documentos a un portal y después espera a que los mismos tres departamentos aprueben uno tras otro. El servicio es digital. No es mejor.

Los servicios atraviesan departamentos; los programas no

Un cliente vive un único servicio: «renovar mi licencia», «abrir una cuenta», «matricular a mi hijo en el colegio». Dentro de la organización, ese servicio pasa por varios departamentos, cada uno con su propio sistema, presupuesto y objetivos. Los programas tecnológicos suelen delimitarse departamento por departamento, así que se moderniza cada parte y las juntas entre ellas, donde vive la mayor parte del retraso, se quedan como estaban.

Melvin Conway observó en 1968 que las organizaciones tienden a producir diseños que reflejan sus propias estructuras de comunicación. Los servicios digitales le dan la razón a diario. Si tres departamentos no se hablan entre sí, el portal tendrá tres secciones que tampoco se hablan.

Nadie diseña el backstage

La pantalla que ve el cliente es el frontstage. Detrás están las personas, las normas, las aprobaciones y los sistemas que realmente producen el resultado. G. Lynn Shostack describió por primera vez el service blueprint en 1982 y lo llevó a un amplio público empresarial en un artículo de 1984 en la Harvard Business Review, precisamente para hacer visible esta parte oculta. La mayoría de los programas de transformación diseñan el frontstage con detalle y dejan el backstage como estaba. El resultado es una app pulida encima de un proceso que todavía necesita la firma en papel de un responsable.

El éxito se mide como entrega, no como cambio

«Sistemas lanzados», «servicios en línea» y «porcentaje digitalizado» son medidas de actividad. Pueden subir todas mientras el tiempo para obtener un resultado, el número de contactos repetidos y la tasa de abandono siguen planos. Cuando el cuadro de mando premia los lanzamientos, los equipos lanzan. (Cómo medir lo correcto se explica en Medir la transformación por resultados, no por actividad).

Qué funciona en su lugar

Trata el servicio, no el sistema, como la unidad de la transformación. En la práctica, eso significa cinco hábitos.

1. Nombra el resultado que quiere la persona. No «presentar la solicitud», sino «poder abrir mi tienda». Escríbelo con las palabras del cliente. Esto fija los límites del trabajo, y casi siempre son más amplios que un departamento.
2. Mapea el servicio completo tal como funciona hoy. Usa un mapa de experiencia para verlo desde el lado del cliente y después un service blueprint para ver el backstage: quién toca el expediente, qué comprueba, a qué espera. Recorre tú mismo el servicio; no lo mapees a partir del manual de procedimientos.
3. Cuestiona cada paso antes de digitalizarlo. Para cada documento, aprobación y campo, pregunta: ¿por qué está aquí, quién lo usa y qué pasa si lo quitamos? Los cambios de normas y de procesos suelen ser las mejoras más baratas y más grandes, y no cuestan ni una línea de código.
4. Prueba el nuevo servicio antes de construir el sistema. Haz funcionar a mano el recorrido rediseñado durante unas semanas con un grupo pequeño, un test concierge, o pon una interfaz sencilla encima de personas que hacen el trabajo manualmente, una prueba del Mago de Oz. Aprendes lo que la tecnología tiene que hacer de verdad, que suele ser menos de lo que decía la especificación.
5. Dale a una sola persona el servicio completo. Nombra a un responsable del servicio con autoridad sobre los departamentos implicados y mide el servicio por lo que obtiene el cliente: tiempo hasta el resultado, pasos, contactos repetidos, abandonos.

La tecnología pasa entonces a ser lo que debería: la forma de prestar a escala el servicio rediseñado, no el rediseño en sí.

Un ejemplo

Ilustrativo. El ayuntamiento de una ciudad europea mediana puso en marcha un programa de tres años para «llevar a internet las licencias de actividad». El nuevo portal se lanzó a tiempo. Las solicitudes seguían tardando más o menos las mismas semanas, y las llamadas al centro de atención aumentaron, porque los solicitantes no sabían cuál de los cuatro departamentos tenía su expediente.

Se pidió a un pequeño equipo que lo revisara. Hicieron el blueprint de un solo recorrido, el de la dueña de una cafetería que solicitaba la apertura, y encontraron once traspasos entre urbanismo, salud ambiental, seguridad contra incendios y licencias, cada uno esperando a que terminara el anterior. Tres de los documentos que se pedían ya los tenía otro departamento. Dos aprobaciones eran secuenciales solo por costumbre.

Hicieron un piloto manual en un distrito: un técnico responsable de cada solicitud de principio a fin, los departamentos revisando en paralelo y los documentos duplicados eliminados. El portal se mantuvo, pero su función cambió: ahora mostraba al solicitante un único responsable y un único estado. El piloto le dijo al ayuntamiento exactamente qué integraciones merecía la pena construir y cuáles no hacían ninguna falta.

Qué hacer y qué evitar

Haz esto

• Empieza por un servicio de gran volumen, no por toda la organización.
• Lleva a la sala a las personas que prestan el servicio, no solo a quienes lo gestionan.
• Haz el blueprint del backstage antes de escribir ningún requisito técnico.
• Trata las normas y los procedimientos como material de diseño, no como restricciones fijas.
• Prueba el nuevo recorrido a mano antes de comprometerte a construir.

Evita esto

• Pasar a internet un formulario en papel campo por campo.
• Delimitar el trabajo por departamento o por sistema.
• Reportar los «servicios digitalizados» como un éxito.
• Dejar que la forma del producto del proveedor decida cómo funciona el servicio.
• Encargar el rediseño solo a IT, o solo a diseño de servicios. Necesita a los dos, con el responsable de negocio al frente.

Preguntas frecuentes

¿El diseño de servicios es solo experiencia de cliente con otro nombre? No. El trabajo de experiencia de cliente suele centrarse en lo que el cliente ve y siente. El diseño de servicios abarca eso y también el backstage: el personal, las normas, los sistemas y los traspasos que producen la experiencia. En una transformación, el backstage es donde tiene que ocurrir la mayor parte del cambio. Si estás eligiendo entre los dos mapas, consulta ¿Customer journey map o service blueprint?

¿Seguimos necesitando una hoja de ruta tecnológica? Sí, pero debe seguir al rediseño del servicio, no dirigirlo. Una vez que sabes cómo debería funcionar el servicio, la hoja de ruta describe lo que tienen que hacer los sistemas para sostenerlo. Muchas organizaciones descubren que la lista se acorta.

¿Por dónde empezamos si hay que arreglarlo todo? Elige el servicio con más volumen y más quejas, mapéalo de principio a fin y arregla primero las juntas entre departamentos. Un servicio bien hecho enseña a la organización más que diez a medias. Antes de redibujar nada, ayuda mapear el sistema antes de cambiarlo.

Por dónde seguir

Este artículo forma parte del artículo principal de la sección, La transformación fracasa en la puerta del cliente. Para el trabajo práctico, empieza por el service blueprint y el mapa de experiencia, usa un mapa de sistema para ver qué departamentos y normas dan forma al servicio y una matriz de puntos de contacto para ver cada canal que atraviesa el cliente.