Un informe A3 de resolución de problemas debe mostrar el razonamiento que sustenta un cambio. ¿Qué ocurre ahora? ¿Qué causa la diferencia respecto a la situación deseada? ¿Por qué ayudaría la contramedida propuesta? Completar una página solo resulta útil si esas conexiones tienen sentido.
Utiliza un espacio compartido para analizar el problema y coloca las evidencias junto a los cambios propuestos. Este ejemplo sigue a un equipo de formación cuyas solicitudes vuelven repetidamente del área de programación al equipo que las recibe porque falta información esencial o no está clara.
Empieza por el problema, no por rellenar el formulario
El Lean Enterprise Institute describe el A3 como algo más que una hoja de papel: reúne la situación actual, el análisis, las contramedidas, las responsabilidades y las evidencias de los resultados en un proceso compartido de resolución de problemas.
Imagina un equipo de formación que recibe solicitudes de varios departamentos. El equipo de recepción registra cada solicitud y la pasa al de programación, que asigna un formador y acuerda una fecha. Algunas solicitudes vuelven al primer equipo porque el segundo no sabe si la fecha propuesta está aprobada, a quién se dirige la sesión o quién puede responder a las preguntas.
«Necesitamos un formulario mejor» ya es una solución. Puede ser correcta, pero no describe el problema. Un punto de partida más útil sería: el equipo de programación no puede asignar un formador a algunas solicitudes porque no están claros los destinatarios, el estado de la fecha o la persona que puede decidir, lo que provoca intercambios adicionales entre los equipos.
Acota el análisis a algo que puedas observar: un servicio de formación, el paso de recepción a programación y un periodo definido. «Mejorar la comunicación de toda la organización» no daría al A3 un límite práctico.
Muestra la situación actual con un registro de solicitudes
Dibuja el recorrido existente: llega la solicitud → recepción prepara la información → programación la revisa → se asigna un formador. Añade una flecha de vuelta de programación a recepción y registra por qué se devuelve cada solicitud.
El siguiente registro muestra el nivel de detalle que conviene recoger. Sustituye estas entradas de ejemplo por observaciones del servicio seleccionado antes de elegir una contramedida.
| Solicitud de ejemplo | Qué recibe programación | Motivo de la devolución | Pregunta que investigar |
|---|---|---|---|
| R01 | Hay una fecha, pero no se indica si está aprobada. | No se sabe si se puede reservar un formador. | ¿La fecha estaba confirmada y no se registró, o aún esperaba aprobación? |
| R02 | Se indica «formación de equipo» sin especificar los destinatarios. | No se puede elegir un formador adecuado. | ¿Recepción recibió esa información? ¿Dónde quedó guardada? |
| R03 | La solicitud está completa, pero no identifica a quién puede resolver un conflicto de fechas. | La consulta vuelve a pasar por recepción. | ¿Quién puede decidir? ¿Puede programación contactar directamente con esa persona? |
Cuenta por separado las solicitudes y las ocasiones en que se pide una aclaración. Una solicitud devuelta tres veces equivale a una solicitud afectada y tres devoluciones. Mezclar ambas unidades puede cambiar la magnitud aparente del problema según quién prepare el informe.
Distingue también el tiempo de espera de una respuesta del tiempo dedicado a revisar la solicitud. Que transcurra más tiempo entre equipos no significa necesariamente que la revisión lleve más trabajo. Una información poco clara y una cola de trabajo sobrecargada pueden necesitar contramedidas distintas.
Distingue las causas de las explicaciones que parecen convincentes
El equipo puede concluir enseguida que quienes solicitan la formación no prestan atención o que recepción necesita más capacitación. Son explicaciones demasiado fáciles si todavía no se ha examinado el trabajo. Sigue una solicitud devuelta desde su envío original, pasando por cada copia, mensaje y cambio de equipo.
En R01 hay dos causas posibles. La fecha podría estar aprobada, pero haberse perdido ese dato al copiar la información en un mensaje para programación. También podría no existir aún la aprobación, mientras que un campo de fecha obligatorio invita a introducir un valor provisional. La misma ausencia visible puede tener causas distintas.
| Posible causa | Evidencia que la apoyaría | Cómo cambia la respuesta |
|---|---|---|
| Se pierde información necesaria al pasar la solicitud. | La solicitud original contiene el dato, pero la versión que recibe programación no. | Conservar la información durante el traspaso en lugar de volver a preguntársela al solicitante. |
| La solicitud se pasa antes de tomar una decisión. | La fecha sigue sin aprobarse en el registro original y en las conversaciones. | Hacer visible si la solicitud está lista y si la fecha es provisional; otro campo obligatorio puede no resolverlo. |
| Recepción y programación entienden de forma distinta qué significa «lista». | Ambos equipos siguen sus instrucciones, pero estas exigen información diferente. | Acordar las condiciones del traspaso en vez de culpar a uno de los equipos. |
La guía del Lean Enterprise Institute sobre el pensamiento A3 destaca la investigación y la conexión lógica entre los hechos, el problema y las contramedidas. Aquí importa más observar el paso entre equipos que rellenar cada casilla durante una sola reunión.
Elige una contramedida que responda a la causa
Supongamos que la revisión muestra dos problemas: los equipos aplican criterios distintos para considerar lista una solicitud y no se distinguen las fechas provisionales de las confirmadas. Una contramedida concreta sería definir la información necesaria para programar la formación y señalar explícitamente el estado de la fecha.
Durante la prueba, el traspaso podría incluir los destinatarios, la fecha solicitada con su estado de confirmada o provisional y la persona autorizada para resolver conflictos. Las solicitudes que todavía no estén listas permanecerían claramente identificadas como pendientes de aclaración, en vez de aparecer en la misma cola que el trabajo listo.
Esto no significa rechazar cualquier solicitud incompleta. Algunas conversaciones de planificación empiezan, con razón, antes de fijar una fecha. El cambio debe permitir distinguir una consulta inicial de una solicitud lista para asignar, no obligar a inventar respuestas para poder enviar un formulario.
Compara esa propuesta con sustituir todo el sistema. Un sistema nuevo podría reproducir el mismo criterio ambiguo. Salvo que las evidencias muestren que las herramientas actuales impiden pasar correctamente la solicitud, prueba la regla más clara antes de convertir el cambio de software en el centro del A3.
Concreta la prueba y las medidas de seguimiento
Indica quién mantendrá la regla de traspaso, qué solicitudes entrarán en la prueba, cuándo revisarán los resultados ambos equipos y qué les haría modificarla o detenerla. Mantén los mismos límites del servicio y criterios de recuento que en la situación de partida.
Una medida útil es la proporción de solicitudes devueltas por información ausente o ambigua al pasar de un equipo a otro. Explicita el numerador y el denominador: solicitudes afectadas divididas entre todas las solicitudes enviadas en el grupo y periodo analizados. Registra aparte las devoluciones repetidas y el tiempo transcurrido hasta una decisión de programación.
Observa también el otro lado del traspaso. Si se devuelven menos solicitudes solo porque recepción las retiene indefinidamente, el servicio puede no haber mejorado. Registra la espera en recepción y el trabajo adicional necesario para preparar cada solicitud. No declares el éxito con una sola medida local si el retraso simplemente se ha desplazado.
Deja el apartado de resultados vacío hasta que la prueba aporte observaciones. El A3 puede indicar «prueba propuesta» y mostrar las medidas previstas. Una previsión pertenece al lado de la contramedida propuesta, no a una casilla titulada «resultados».
Organiza el razonamiento del A3 en Boardmix
Coloca a la izquierda del lienzo de Boardmix la situación actual: el recorrido de la solicitud, la flecha de devolución y el registro. En el centro, sitúa el análisis de causas y conecta cada explicación posible con las evidencias que la apoyan o que todavía faltan. A la derecha, coloca la contramedida elegida y el plan de prueba.
En este ejemplo, conecta la falta de claridad sobre la fecha con la distinción propuesta entre confirmada y provisional. Relaciona los criterios contradictorios con la condición de traspaso compartida. No enlaces cada causa con todos los cambios: así dejaría de verse qué propuesta responde a cada problema.
Abre una pizarra de Boardmix y lleva a la conversación ejemplos reales de recepción y programación. Anonimiza los datos de las solicitudes cuando sea necesario e identifica a la persona responsable del A3 sin dar a entender que dirige a todos los equipos implicados.
Si la prueba muestra después que incluso las solicitudes claras esperan porque no hay formadores disponibles, conserva ese hallazgo. Cambia cuál es el siguiente problema que investigar. El A3 debe mostrar por qué el equipo revisó su interpretación, no sostener la explicación inicial a costa de las evidencias.
