G02 - Cómo conducir un Gemba

Qué es y qué no es

Tres preguntas guían todo el Gemba:

1. Propósito: ¿qué necesita el cliente del proceso y qué problema le resuelve este proceso?
2. Proceso: ¿cómo funciona de verdad, paso a paso?
3. Personas: ¿quienes lo ejecutan pueden hacerlo bien, detectar problemas y mejorarlo?

Por qué ir al Gemba

Entre cómo creemos que funciona un proceso y cómo funciona en realidad hay una brecha casi inevitable. Lo que llega a quien decide está filtrado: indicadores, reportes, manuales, lo que alguien cuenta en una junta. Cada filtro simplifica y omite. Ir al Gemba es la forma más directa de cerrar esa brecha.

• Para ver la realidad, no la versión documentada. En la práctica la gente crea atajos: un Excel paralelo, un correo que "siempre hay que mandar", una validación que se hace de memoria. Ahí están los riesgos, los retrasos y el conocimiento que se pierde.
• Para encontrar la causa, no solo el síntoma. Un indicador dice que algo va mal, pero no por qué.
• Para ver el desperdicio. Quien vive el proceso ya no lo percibe; quien lo dirige no lo ve porque no está ahí.
• Para decidir con hechos. Las mejoras diseñadas sobre supuestos fallan al implementarse porque no consideran las excepciones reales.
• Para involucrar a quienes hacen el trabajo. Observar y preguntar con curiosidad genuina genera confianza y reduce la resistencia al cambio.

El Gemba sirve para que las decisiones y las mejoras se basen en lo que realmente ocurre, no en lo que suponemos que ocurre.

¿No basta con preguntar a los usuarios?

Los usuarios son indispensables, y el Gemba no los reemplaza: el Gemba es ir con ellos. La diferencia está entre preguntarles cómo trabajan y verlos trabajar.

• Mucho de lo que saben es tácito. Al explicar el proceso lo resumen y se saltan pasos que para ellos son obvios.
• La costumbre vuelve invisible el desperdicio. Lo que lleva años haciéndose "así se hace".
• Tienden a describir el proceso oficial. Cuentan cómo debería hacerse, no cómo lo hacen.
• Ven su parte, no el flujo completo. Los problemas más grandes suelen estar en las transiciones entre áreas.
• Suelen traer soluciones, no problemas. "Necesito un botón que haga tal cosa" esconde una necesidad que puede resolverse mejor.

Los usuarios aportan lo que nadie más puede: el porqué de lo que hacen, las excepciones que conocen, las restricciones que viven y, sobre todo, la validación de las soluciones. Ver El usuario como actor del proceso.

La entrevista te da la versión que el usuario puede contar; el Gemba te da además la que no sabe que está contando.

Qué identifica el Product Manager

En todo Gemba, el Product Manager identifica los cinco elementos del proceso: proceso, política, procedimiento, control y rol. Ver Elementos del proceso.

El proceso en siete pasos

1. Preparar

• Delimitar el proceso. Qué lo dispara y qué resultado entrega. Ejemplo: empieza cuando el proveedor entrega sus documentos y termina cuando queda activo para facturar.
• Identificar al cliente del proceso. Quién recibe el resultado: un cliente, un proveedor o un área.
• Elegir la unidad de trabajo que vas a seguir. Un expediente, una solicitud, una orden, una incidencia.
• Avisar al dueño del proceso y al equipo, con el propósito claro: "venimos a aprender cómo funciona el proceso, no a evaluar a nadie".
• Reunir lo documentado: políticas, procedimientos, controles y manuales del proceso. No para seguirlos, sino para compararlos después con lo que se observe.
• Pedir los datos que ya existen (registros del sistema, bitácoras, reportes) para contrastarlos después con lo observado.

2. Seguir una unidad de trabajo

Camina el proceso como lo vive el expediente, no como lo describe el organigrama. Pasa por cada área, cada sistema, cada bandeja.

• Sigue varias unidades, no una sola. Una unidad muestra el camino feliz; varias muestran las excepciones.
• Observa a distintas personas haciendo el mismo trabajo, incluida alguien que acaba de llegar. Las diferencias muestran dónde falta un estándar; la persona nueva muestra dónde el proceso no está claro. Ver Trabajo estandarizado.
• Observa en días distintos, incluidos los picos normales del proceso, como los cierres de quincena.
• Observa sin interrumpir. Pregunta mientras la persona trabaja, sin detenerla. Si hace falta más, agenda un momento aparte.

3. Registrar lo que se ve

Por cada paso, registra:

4. Preguntar por qué

Cuando veas una espera, un retrabajo o un paso raro, pregunta por qué a quien hace el trabajo. Repite la pregunta hasta llegar a la causa, no al síntoma. Ver 5 porqués.

• Pregunta al proceso, no a la persona: "¿por qué regresa este expediente?", no "¿por qué lo regresaste?".
• No propongas soluciones todavía. Si propones, la gente deja de contarte cómo funciona y empieza a discutir tu idea.

5. Modelar el estado actual

Con lo registrado, arma el mapa de flujo de valor del estado actual:

• Tiempo total: desde que se dispara el proceso hasta que entrega el resultado.
• Tiempo de trabajo: la suma de los tiempos de trabajo de todos los pasos.
• Relación entre ambos: qué parte del tiempo total es trabajo real. En procesos de oficina suele ser muy baja.
• Completo y correcto acumulado: qué porcentaje de unidades recorre todo el proceso sin regresar.

Modela también en BPMN lo observado: quién hace cada paso, en qué orden, con qué decisiones y excepciones. El mapa de flujo de valor muestra el tiempo y el desperdicio; el BPMN muestra la lógica. Juntos forman el mapa del estado actual.

6. Clasificar cada paso

Aquí se descubre el valor. Nadie lo define de antemano: sale de lo que viste. Clasifica cada paso:

Para nombrar el tipo de desperdicio, usa G03 - Los 8 desperdicios en procesos administrativos.

7. Validar y acordar

1. Valida con quien ejecuta el proceso. Muéstrale el mapa y pregunta: "¿así pasa?". Si no se reconoce, regresa al paso 2. Esta es la compuerta C1, al cerrar la etapa 3.
2. Acuerda con el dueño del proceso qué es valor, qué es soporte y qué es desperdicio. Ese acuerdo es la entrada a la etapa 4.

Del Gemba a la solución

El Gemba no termina en el mapa. Es la base de todo lo que el Product Manager decide después.

Por qué importa para quien diseña soluciones tecnológicas:

• El mayor riesgo no es técnico: es construir bien algo que no resuelve el problema correcto.
• "Necesitamos un sistema que haga X" ya es una solución. En el Gemba aparece la necesidad real, las excepciones y los pasos que nadie mencionó. Los criterios de aceptación salen de ahí.
• Una unidad agéntica enfrenta los casos reales: excepciones, datos incompletos, decisiones de criterio. Si no se observaron, no se diseñaron, y el agente falla justo ahí.
• La tecnología es la forma más duradera de trabajo estandarizado, siempre que antes se haya entendido cuál es el estándar.
• La adopción depende de esto. Si el usuario ve que entendiste su trabajo, adopta la solución. Si se la impusieron desde un escritorio, la rodea y vuelven los Excel paralelos.
• Después de implementar, observar cómo se usa realmente la herramienta es la retroalimentación más honesta.

El Gemba convierte a quien implementa de alguien que construye lo que le piden en alguien que resuelve el problema que realmente existe.

Qué se entrega

Con esto se obtiene la línea base del indicador que después usará la Ficha de hipótesis de valor.

Reglas de conducta

Errores comunes

Ejemplo (ilustrativo)

Preguntas de reflexión

Criterio de cierre de las etapas 2 y 3

• Proceso delimitado: disparador, resultado y cliente.
• Varias unidades de trabajo seguidas, en días distintos.
• Proceso, políticas, procedimiento, controles y roles identificados.
• Tiempos de trabajo, esperas, volúmenes y completo y correcto registrados por paso.
• Cada paso de soporte necesario ligado a una política con origen conocido.
• Mapa de estado actual validado por quien ejecuta el proceso.
• Pasos clasificados en valor, soporte y desperdicio.
• Clasificación acordada con el dueño del proceso.

Referencias

• Lean Enterprise Institute: Gemba Walk y Gemba.
• AllAboutLean: Taiichi Ohno's Chalk Circle.
• Lean Enterprise Institute: Keep It Simple: Value-Stream Mapping at the Gemba.
• Object Management Group: BPMN 2.0, también norma ISO/IEC 19510.
• Edmondson, A. The Fearless Organization, Wiley, 2018: seguridad psicológica.

Relacionado

• Definición del rol
• Reporte de Gemba
• G03 - Los 8 desperdicios en procesos administrativos
• Módulo 2 - Ir al Gemba
• Módulo 3 - Mapear el estado actual

Ruta de lectura (2 de 9): ← G01 - Metodología de transformación de procesos · índice · G03 - Los 8 desperdicios en procesos administrativos →