«¿Desarrollamos o compramos el sistema de reservas?» parece una sola decisión. En realidad, el servicio reúne elementos distintos: la experiencia del cliente, las reglas de planificación, los datos del calendario, las notificaciones y la infraestructura. Tratarlo todo como un único componente puede llevar al equipo a desarrollar demasiado o a comprar algo que no admite precisamente lo que hace útil al servicio.
Un mapa de Wardley separa esos componentes y los sitúa en su contexto. Este ejemplo utiliza un servicio ficticio de reparación de equipos para explorar dónde conviene experimentar, dónde comparar productos disponibles y qué falta por saber antes de elegir.
Interpreta bien los dos ejes
Wardley Mapping, creado por Simon Wardley, relaciona las necesidades de un usuario con las capacidades que las sostienen. La dimensión vertical representa la cadena de valor y la visibilidad de sus componentes para el usuario. La horizontal representa su evolución, con las etapas habituales Génesis, A medida, Producto y Recurso estandarizado (Commodity). La guía del entorno de Learn Wardley Mapping explica cómo esas posiciones y relaciones de dependencia forman el mapa.
La evolución no es un calendario de entregas. Mover un componente hacia la derecha no significa que el equipo vaya a terminarlo el próximo mes. Tampoco una posición baja en el eje vertical implica poca importancia: un fallo de infraestructura puede impedir que funcione todo el servicio.
Este mapa también se diferencia de un mapa estratégico organizado en torno a objetivos (guía en inglés). Aquí se examina cómo las capacidades del servicio se relacionan con las necesidades del usuario y hasta qué punto están consolidadas en el entorno correspondiente.
Empieza por la necesidad del cliente
El servicio del ejemplo organiza visitas para reparar equipos de cocinas profesionales. El usuario es la persona responsable de un restaurante que necesita un técnico adecuado en un horario viable. Su necesidad inmediata no es «usar nuestra plataforma de planificación», sino concertar una visita que pueda resolver la avería.
Escribe esa necesidad cerca de la parte superior del tablero. Debajo, enumera lo que debe estar disponible: una experiencia de reserva, información sobre el equipo y la avería, una forma de asignar el trabajo a un técnico capacitado, citas disponibles y una confirmación que el cliente entienda.
Después pregunta de qué dependen esas capacidades. La disponibilidad de citas necesita información de calendarios. Asignar un trabajo exige datos sobre los tipos de equipos y las competencias de los técnicos. La confirmación necesita un servicio de notificaciones. El servicio digital también requiere infraestructura informática, aunque los clientes no interactúen normalmente con ella.
Dibuja una conexión solo cuando una capacidad necesite otra. Que dos componentes pertenezcan al mismo departamento no basta. Si el equipo empieza a debatir cada base de datos y cada API, vuelve a la decisión que se está estudiando: ¿qué partes del servicio de reservas conviene desarrollar o contratar?
Sitúa los componentes con evidencias, no por familiaridad
Para este ejemplo, supongamos que el equipo ha encontrado varios productos de planificación de citas consolidados, pero todavía está experimentando con una forma de asignar las reparaciones de averías poco habituales a técnicos adecuados. Son supuestos de un caso didáctico, no una evaluación del mercado ni de proveedores reales.
| Componente | Posición ilustrativa | Motivo | Evidencias que necesitaría el equipo real |
|---|---|---|---|
| Enfoque experimental para asignar técnicos según la avería | Génesis | La propuesta es novedosa y su utilidad aún no está clara | Alternativas existentes y pruebas de que el enfoque funciona |
| Recorrido de reserva adaptado a reparaciones | A medida | El ejemplo exige una secuencia específica para trabajos poco habituales | Tareas observadas de los clientes y comparación con flujos disponibles |
| Planificación de citas | Producto | El caso presupone productos consolidados con funciones reconocibles | Capacidades actuales, limitaciones y requisitos de integración |
| Notificaciones al cliente | Producto | El caso presupone un servicio configurable que cubre la necesidad básica | Comportamiento de entrega, accesibilidad, encaje operativo y condiciones del proveedor |
| Capacidad informática básica | Recurso o servicio estandarizado | Se trata como una capacidad de apoyo estandarizada | Necesidades del servicio, oferta disponible y restricciones de uso |
Sitúa el recorrido de reserva relativamente arriba, porque está próximo a la experiencia del cliente. Coloca debajo las capacidades de apoyo y conecta las dependencias. No conviertas las filas de la tabla en cinco puntos aislados: las relaciones son lo que permite concretar la conversación sobre qué desarrollar o contratar.
«Lo hemos desarrollado nosotros» no demuestra que algo pertenezca a la etapa A medida. Un equipo puede mantener su propia implementación de una capacidad disponible ampliamente como producto o servicio estandarizado. Del mismo modo, contratar un trabajo especializado no convierte esa capacidad en un producto estándar.
Si el equipo no está de acuerdo sobre una posición, anota los distintos motivos. Quizá haya que dividir «motor de reservas» en asignación ordinaria de citas y gestión de averías poco habituales para entender el desacuerdo. Una etiqueta demasiado amplia puede ocultar componentes con características muy diferentes.
Replantea la decisión de desarrollar o comprar
La propuesta inicial era desarrollar todo el sistema de reservas. El mapa sugiere investigar algo más concreto: ¿puede el equipo contratar la planificación ordinaria de citas y conservar margen para desarrollar la experiencia específica de reparación y probar el enfoque de asignación menos conocido?
Es una pregunta que hay que comprobar, no una recomendación automática. Un producto de planificación podría imponer una secuencia rígida, pedir información que el cliente no puede aportar o dificultar los cambios en una capacidad esencial. La posición del componente no elimina la necesidad de examinar su encaje, costes de operación, contratos, requisitos de seguridad y esfuerzo de sustitución.
El relato de Simon Wardley sobre uno de sus primeros mapas muestra el valor de examinar componentes en distintas etapas de evolución, en lugar de tratar un sistema empresarial como un bloque indivisible. El servicio de reparaciones puede aplicar esa forma de observar sin adoptar las conclusiones de aquel caso histórico.
Compara dos opciones concretas
La opción A consiste en desarrollar conjuntamente el recorrido de reserva, la planificación y las notificaciones. El equipo controlaría esas interacciones, pero también tendría que mantener varias capacidades que quizá ya existan en el mercado.
La opción B consiste en crear una capa limitada de interacción con el cliente sobre un producto de planificación. Puede reducir lo que el equipo debe mantener, siempre que ese producto admita las reglas de citas necesarias y facilite la información que requiere la experiencia.
Prueba la opción B con una reserva difícil, no solo con una demostración cómoda. Utiliza un restaurante con una avería incierta, un técnico que solo atiende ciertos equipos y una cita que podría cambiar cuando llegue más información. Si el componente contratado no permite ese recorrido, determina si el problema es de configuración, falta de una interfaz o incompatibilidad de fondo.
Dibuja el mapa del servicio en Boardmix
Abre Boardmix y crea una pizarra en blanco. Dibuja un eje horizontal llamado Evolución y divídelo en Génesis, A medida, Producto y Recurso estandarizado. Añade un eje vertical con la etiqueta «Visibilidad para el usuario», con la mayor visibilidad arriba.
- Coloca «Responsable del restaurante» sobre la necesidad «Concertar una reparación adecuada». Mantén visible ese punto de referencia al añadir capacidades.
- Añade «Recorrido de reserva de reparación» debajo de la necesidad. Conéctalo con «Asignación de técnicos» y «Planificación de citas».
- Sitúa los cinco componentes del ejemplo en sus posiciones provisionales. Pon etiquetas breves junto a los puntos para que el diagrama no dependa del color.
- Conecta el recorrido de reserva con las notificaciones, porque confirmar la cita forma parte de esa experiencia. Sitúa la dependencia de capacidad informática más abajo.
- Añade junto a la asignación de técnicos una nota: «Enfoque experimental: comparar alternativas existentes». Coloca las dos opciones de contratación fuera del mapa para que no parezcan otras capacidades.
Separa la situación actual de las propuestas. Si quieres explorar la contratación de un sistema de planificación, duplica la zona pertinente y marca la segunda versión como opción. Mover un punto en el mapa original sin explicarlo puede hacer que una propuesta parezca una realidad existente.
Identifica qué decisiones requieren más información
El mapa no calcula cuál es el mejor proveedor, no determina el retorno de la inversión ni indica cuándo una capacidad pasará a estar disponible como recurso estandarizado. Evita añadir coordenadas precisas o fechas previstas solo para dar al dibujo una apariencia analítica. Una posición aproximada con un motivo claro es más útil que un decimal sin fundamento.
Para el servicio de reparaciones, la pregunta inmediata es si puede separar la planificación ordinaria de la lógica de averías poco habituales sin perjudicar la experiencia del cliente. Una pequeña prueba de integración puede responder a parte de la pregunta; observar a los clientes, a otra. El mapa ayuda a entender por qué ambas investigaciones están relacionadas.
Si el producto de planificación encaja, el equipo puede dedicar más esfuerzo a la parte del recorrido que sigue siendo incierta. Si no encaja, el mapa permite identificar qué dependencia requiere atención, en lugar de reducir el debate a «comprar no funcionó, así que hay que desarrollarlo todo».
