G01 - Metodología de transformación de procesos
Metodología de transformación de procesos
Alcance
Método general para entender, limpiar, rediseñar y automatizar cualquier proceso: administrativo, comercial, de servicio, financiero, de TI o de planta. El Product Manager lo aplica en cada iniciativa, pero cualquier persona que mejore un proceso puede usarlo. Es agnóstica: no depende de una empresa ni de una industria. Los ejemplos vienen de distintos tipos de proceso.
La idea en una frase
El Gemba alimenta el análisis, el mapa lo hace visible, la hipótesis lo compromete, el estándar lo vuelve repetible y la tecnología lo hace escalable. Si se invierte el orden y se empieza por la tecnología, se automatiza el problema en lugar de resolverlo.
Un concepto antes de empezar: el cliente
En esta metodología "cliente" siempre lleva apellido:
- Cliente externo: fuera de la empresa; recibe el producto o servicio final y normalmente paga por él.
- Cliente interno: área o persona de la empresa que recibe el trabajo de otra.
- Cliente del proceso: quien recibe la salida del proceso analizado; puede ser interno o externo.
Todo proceso sirve, al final, a un cliente externo. El valor se juzga desde él.
Tres enfoques que se combinan
No todo proceso necesita lo mismo. Hay tres formas de intervenirlo, de la más radical a la más gradual:
| Enfoque | Qué hace | Cuándo usarlo | Ritmo | Riesgo principal |
|---|---|---|---|---|
| Reingeniería (BPR) | Reinventa el proceso desde cero | El proceso actual ya no sirve al cliente | Rápido y radical | Alto: cambia estructura, roles y sistemas a la vez |
| Gestión de procesos (BPM) | Ordena, estandariza y da visibilidad | El proceso funciona pero nadie lo controla ni lo mide | Constante | Burocratizar: medir todo y no mejorar nada |
| Mejora continua (Kaizen) | Ajusta y optimiza lo que existe | El proceso es funcional pero mejorable | Lento y progresivo | Pulir un proceso que debió rediseñarse |
Una analogía: la reingeniería cambia el vehículo, la gestión le instala el tablero de sensores y la mejora continua afina el motor. La analogía viene de la lámina 3 de la presentación de reingeniería.
Los tres se complementan. La reingeniería construye la arquitectura; Lean es el motor diario que optimiza y sostiene el flujo. Qué enfoque toca se decide en la etapa 4, con evidencia, no al inicio. Ver Decidir el nivel de intervención.
Los 6 pasos de la reingeniería dentro de las 9 etapas
La presentación Reingeniería de procesos (BPR) (en Adjuntos) propone un motor de 6 pasos con el valor para el cliente al centro. Todos caben en este ciclo:
| Paso de la presentación | Etapa del ciclo |
|---|---|
| 1. Levantar el estado actual (AS-IS) | 2 y 3: Gemba y mapa |
| 2. Identificar fricciones y desperdicios | 4: analizar |
| 3. Definir el valor desde el cliente | 1 y 4: cliente y valor |
| 4. Rediseñar el proceso (TO-BE) | 5: rediseñar |
| 5. Estandarizar a prueba de errores | 5 (estándar mínimo) y 9 (estándar definitivo) |
| 6. Ejecutar y controlar | 8 y 9: construir, validar y sostener |
Lo que el ciclo agrega: comprender el negocio antes de mapear, una hipótesis de valor medible antes de diseñar y el diseño de la solución tecnológica con IA y unidades agénticas. La presentación lista 7 desperdicios; este método usa 8 (agrega el talento no aprovechado). Sus cifras ("10x", "de 15 días a 30 minutos") son ilustrativas y no tienen fuente: no las uses como dato.
Reingeniería alrededor de la tecnología
La definición clásica de BPR habla de reconstruir el proceso "en torno a la tecnología". En este método se reconstruye en torno al cliente del proceso y al valor. La tecnología habilita el diseño; no lo dicta.
El ciclo en 9 etapas
| Etapa | Pregunta | Salida principal |
|---|---|---|
| 1. Comprender el negocio | ¿Por qué este proceso y cómo funciona esta parte del negocio? | Contexto del área, Ficha SIPOC, Mapa de involucrados |
| 2. Gemba | ¿Qué pasa realmente? | Reporte de Gemba |
| 3. Mapear el estado actual | ¿Cómo funciona hoy y cuánto tarda? | Mapa AS-IS con línea base |
| 4. Analizar | ¿Qué falla, por qué y cuánto cuesta? | Análisis de valor y desperdicio, Planteamiento del problema, nivel de intervención |
| 5. Rediseñar | ¿Cómo debería funcionar? | Mapa TO-BE y estándar mínimo |
| 6. Hipótesis de valor | ¿Qué vamos a lograr y cómo lo sabremos? | Ficha de hipótesis de valor |
| 7. Diseño de la solución | ¿Cuál es la mejor forma, nueva o conocida, de mover el indicador? | Diseño de solución, Backlog |
| 8. Construcción orquestada | ¿Se construye lo que mueve el indicador? | Solución aceptada |
| 9. Validar y sostener | ¿Funcionó? ¿Cómo no retrocedemos? | Reporte de validación, Estándar de trabajo |
Las compuertas del ciclo, y quién las confirma:
Etapa 1. Comprender el negocio
Propósito: llegar al Gemba hablando el idioma del área, sabiendo por qué se interviene este proceso y qué buscar.
Pasos:
- Justificar el proceso. ¿Por qué este y no otro? Se selecciona por impacto, no por quién pide más fuerte.
- Aprender el lenguaje y el contexto. Términos del área, cómo gana o pierde dinero, sus indicadores, políticas, contratos, sistemas y documentos existentes.
- Ubicar y delimitar el proceso. Dónde vive en la arquitectura de procesos (categoría, grupo, proceso) y cuál es su disparador, inicio, fin y cliente. Se resume en un SIPOC.
- Identificar involucrados. Quién gana, quién pierde y quién decide con el cambio.
- Anotar un supuesto de valor. Qué creemos que el cliente del proceso necesita. El Gemba lo confirma o lo corrige.
Criterios para seleccionar un proceso:
| Criterio | Pregunta |
|---|---|
| Servicio | ¿Afecta lo que recibe el cliente final o un área interna clave? |
| Costo | ¿Cuántas horas-persona, retrabajos o pérdidas genera? |
| Tiempo | ¿Cuánto tarda de punta a punta y cuánto espera el cliente? |
| Riesgo | ¿Qué pasa si falla: multas, pérdida de clientes, errores de dinero? |
| Volumen | ¿Cuántas veces ocurre al día, a la semana o al mes? |
Quién prioriza
Elegir entre iniciativas es una decisión de portafolio de la dirección. El Product Manager aporta la justificación con estos criterios.
Proceso general
En una distribuidora, "compras" es demasiado amplio. El proceso delimitado es "de la requisición aprobada a la orden de compra enviada al proveedor". El cliente del proceso es el almacén que necesita el material.
Comprender no es diseñar
Esta etapa se mide en días, no en semanas. Si al terminarla ya hay una solución en mente, se está saltando el Gemba.
Etapa 2. Gemba
Propósito: ver el proceso real, no la versión documentada. Ver G02 - Cómo conducir un Gemba.
Pasos:
- Recorrer el proceso donde ocurre con quien lo ejecuta (Gemba walk).
- Seguir unidades de trabajo de punta a punta: una solicitud, un pedido, un expediente, una pieza.
- Identificar pasos y actividades, incluidos los que no están en ningún manual: el Excel paralelo, el correo que "siempre se manda", la validación de memoria.
- Registrar tiempos, esperas, retrabajos y excepciones.
- Comparar cómo lo hacen distintas personas. Las diferencias muestran dónde falta un estándar.
Se aplican Las 3 Gen: estar en el lugar real, ver la cosa real y medir los hechos reales (Genchi genbutsu).
Proceso general
En una mesa de ayuda de TI, el Gemba es la bandeja de tickets, la llamada, el chat y la consola de administración. Seguir diez tickets completos dice más que el tablero de tiempos promedio.
Etapa 3. Mapear el estado actual
Principio: no se puede optimizar lo que no se puede ver.
Pasos:
- Modelar el estado actual (AS-IS) con dos flujos:
- Flujo de trabajo: la transformación física o digital (la pieza que avanza, el expediente que se completa).
- Flujo de información: lo que dispara y coordina el trabajo (pedidos, pronósticos, correos, avisos).
- Medir tiempos de ciclo de cada paso y las esperas entre pasos.
- Fijar la línea base: tiempo total, tiempo de trabajo, volumen, throughput (cuánto sale terminado por día o semana) y errores.
Se usan dos herramientas que se complementan:
| Herramienta | Responde | Muestra |
|---|---|---|
| VSM | ¿Dónde se pierde el tiempo? | Flujo completo con tiempos, esperas e inventarios |
| BPMN AS-IS | ¿Cómo funciona exactamente? | Quién hace cada actividad, qué decide, qué sistemas usa, dónde están los traspasos |
Un dato que casi siempre sorprende: la eficiencia del flujo.
Eficiencia del flujo = tiempo que agrega valor ÷ tiempo total
Un proceso que tarda cinco días con dos horas de trabajo real tiene una eficiencia menor al 2%. El resto es espera.
Etapa 4. Analizar
Propósito: encontrar qué falla, por qué y cuánto cuesta. Después, decidir qué tan profundo se interviene.
Pasos:
- Clasificar cada paso en valor, soporte necesario o desperdicio.
- Marcar desperdicios y cuellos de botella sobre el mapa. El cuello de botella fija el throughput de todo el proceso: el desperdicio que está ahí es el que más cuesta.
- Buscar la causa raíz con 5 porqués e Ishikawa.
- Priorizar con Pareto: pocas causas explican la mayoría de los problemas.
- Cuantificar el impacto: horas, dinero, errores o clientes afectados.
- Decidir el nivel de intervención.
Los 8 desperdicios en cualquier proceso
| Desperdicio | Definición general | En planta | En oficina o digital | En el desarrollo de sistemas |
|---|---|---|---|---|
| Sobreproducción | Producir más o antes de lo que se necesita | Piezas fabricadas sin pedido | Reportes que nadie lee, información "por si acaso" | Funcionalidades que nadie pidió o que nadie usa |
| Espera | Trabajo detenido porque falta algo | Máquina parada por falta de material | Solicitud en una bandeja esperando aprobación | Esperar aprobaciones, ambientes, respuestas del negocio o revisiones |
| Transporte | Mover algo sin transformarlo | Material que va y viene entre almacenes | Datos que pasan de un sistema a otro por Excel o correo | Requisitos que pasan por muchas manos antes de llegar a quien construye |
| Sobreprocesamiento | Hacer más de lo que el cliente valora | Acabados que nadie pidió | Capturar dos veces, validaciones redundantes, firmas de más | Documentación que nadie lee, sobreingeniería, aprobaciones de más |
| Inventario | Trabajo acumulado que inmoviliza recursos | Material en exceso | Pendientes acumulados, expedientes incompletos | Trabajo a medio terminar: requisitos sin construir, código sin liberar |
| Movimiento | Desplazamientos o búsquedas innecesarias de las personas | Caminar por herramientas | Buscar información en varios sistemas o carpetas | Cambiar de tarea todo el tiempo; buscar información en varios lugares |
| Defectos | Errores que obligan a rehacer | Piezas rechazadas | Rechazos, correcciones, conciliaciones | Errores que llegan a producción; retrabajo por requisitos mal entendidos |
| Talento no aprovechado | Capacidades de las personas sin usar | Operadores sin voz en la mejora | Personas capacitadas haciendo tareas mecánicas | Personas técnicas haciendo a mano pruebas o liberaciones que se pueden automatizar, o excluidas de entender el problema |
Ver G03 - Los 8 desperdicios en procesos administrativos. La columna de desarrollo de sistemas se basa en Poppendieck, M. y T. Lean Software Development (2003).
Decidir el nivel de intervención
Con el análisis en la mano se elige el enfoque. Queda registrado y se confirma en la compuerta C2.
| Si se observa… | Nivel | Qué implica en la etapa 5 |
|---|---|---|
| El proceso ya no sirve al cliente; hay muchos traspasos y reglas obsoletas; las mejoras anteriores no movieron el indicador | Reingeniería | Diseñar desde cero, en torno al cliente |
| Funciona, pero cada quien lo hace distinto, no hay dueño ni indicadores | Gestión | Ordenar, estandarizar, nombrar dueño y medir |
| Funciona y es estable; los problemas son puntuales | Mejora continua | Ajustar pasos concretos |
El nivel no se decide por gusto
Pedir reingeniería porque "suena más ambicioso" o mejora continua porque "es menos riesgoso" sin evidencia es decidir desde el escritorio. El nivel sale del análisis.
Etapa 5. Rediseñar
Propósito: diseñar el estado futuro (TO-BE) antes de pensar en tecnología.
El orden es estricto: eliminar → simplificar → estandarizar. Cómo se aplica depende del nivel:
- Reingeniería: hoja en blanco. Se pregunta qué resultado necesita el cliente y cuál es el camino más corto para dárselo. Para idear se asume cero restricciones; la viabilidad se revisa en la etapa 7.
- Gestión: se conserva la estructura; se eliminan variaciones, se define el estándar y se instalan indicadores.
- Mejora continua: se atacan las causas priorizadas, una por una.
Principios de flujo
Material de apoyo
La presentación Sistema pull y takt time (en Adjuntos) explica estos principios en 13 láminas: push contra pull, takt time, heijunka, kanban, pull en servicios y un plan de acción. La cifra de la lámina 11 (una póliza que pasa de 15 días a 30 minutos) es ilustrativa y no tiene fuente; no la uses como dato.
| Principio | Qué es | En oficina o digital | En el desarrollo de sistemas |
|---|---|---|---|
| Pull en lugar de push | Producir según la demanda real, no según pronósticos | No generar reportes o expedientes hasta que alguien los necesita | Construir solo lo que el backlog priorizado pide; no adelantar funcionalidades "por si acaso" |
| Just in time | Lo necesario, en la cantidad necesaria, cuando se necesita | La información llega al paso siguiente justo cuando la usa | Detallar cada requisito justo antes de construirlo, no meses antes |
| Kanban | Señales visuales que autorizan trabajar solo cuando el paso siguiente lo pide | Tablero con límite de trabajo en curso por columna | Tablero de desarrollo con límite de trabajo en curso en análisis, construcción, pruebas y liberación |
| Takt time | El ritmo al que hay que producir para igualar la demanda | 420 minutos disponibles ÷ 60 solicitudes diarias = una solicitud cada 7 minutos | Si el negocio pide 10 cambios pequeños por semana, el equipo debe cerrar uno cada medio día |
| Heijunka | Nivelar la carga para que el volumen no llegue en picos | Repartir la carga del corte de mes a lo largo de las semanas | Mezclar cada semana cambios grandes y pequeños en lugar de juntar todo antes de una liberación |
| Flujo continuo | Que el trabajo avance sin detenerse ni acumularse | Menos lotes, menos aprobaciones en serie | Entregas pequeñas y frecuentes, con pruebas automáticas, en lugar de grandes liberaciones |
| Menos traspasos | Cada cambio de manos es una espera y un riesgo de error | Una persona o un sistema resuelve de punta a punta | El mismo equipo entiende el problema, construye y prueba; menos pases entre áreas |
Prevenir el error: poka-yoke
El poka-yoke hace que el error sea imposible o que se detecte al instante. Hay tres tipos:
| Tipo | En planta | En oficina o digital | En el desarrollo de sistemas |
|---|---|---|---|
| Diseño | Conectores que solo entran en una posición | Campo que no acepta un formato inválido; lista cerrada en lugar de texto libre | Validaciones en la base de datos y en la interfaz que impiden guardar datos inválidos |
| Procedimiento | Secuencia obligatoria de montaje | Lista de verificación que bloquea el avance si falta algo | La liberación no avanza si fallan las pruebas automáticas o falta la revisión |
| Detección | Alarma que detiene la línea ante una anomalía | Alerta que detiene el flujo cuando un dato no cuadra | Monitoreo que avisa al instante cuando algo falla en producción |
Ordenar el entorno: 5S
Las 5S ordenan el lugar de trabajo, físico o digital:
| S | Significa | En planta | En oficina o digital | En el desarrollo de sistemas |
|---|---|---|---|---|
| Seiri | Clasificar: separar lo necesario de lo inútil | Retirar herramientas que no se usan | Depurar carpetas, reportes y accesos que nadie usa | Eliminar código, reportes, ramas y funcionalidades sin uso |
| Seiton | Ordenar: un lugar para cada cosa | Tablero de herramientas | Estructura de carpetas y nombres estándar | Estructura de proyecto, nombres y repositorios estándar |
| Seiso | Limpiar e inspeccionar | Limpieza diaria como inspección | Revisar bandejas y datos incompletos cada día | Revisar a diario errores, alertas y deuda técnica |
| Seiketsu | Estandarizar las tres primeras | Reglas visibles | Plantillas y convenciones documentadas | Convenciones de código y plantillas documentadas |
| Shitsuke | Disciplina: sostener | Auditorías periódicas | Revisión mensual del orden digital | Revisiones periódicas de la calidad del código |
Salida: VSM futuro, BPMN TO-BE y un estándar mínimo. El estándar definitivo se escribe en la etapa 9, cuando la solución ya se validó.
Muchas iniciativas terminan aquí
Si el rediseño resuelve el problema sin construir nada, la iniciativa pasa por la hipótesis (etapa 6) y salta a la validación (etapa 9).
Etapa 6. Hipótesis de valor
Propósito: comprometer un resultado medible antes de invertir en construir. Ver Hipótesis de valor y G05 - Cómo redactar una hipótesis de valor.
Si eliminamos [desperdicio] y construimos [solución], el indicador [X] pasará de [línea base] a [meta] en [plazo], medido con [fuente de datos].
Etapa 7. Diseño de la solución
Propósito: innovar. Generar varias soluciones posibles, elegir la más simple que mueve el indicador, probarla de forma rápida y eficiente y definir cómo encaja.
Idear y seleccionar alternativas
Esta es la etapa donde el rol innova. Antes de decidir con qué se resuelve cada actividad:
- Generar al menos tres alternativas de distinta naturaleza: sin tecnología, con lo que ya existe y con tecnología nueva. Técnicas: ¿Cómo podríamos…?, SCAMPER y mirar otras industrias.
- Buscar dónde entran la IA y las unidades agénticas: actividades donde una persona lee, clasifica, redacta, busca, revisa o decide con criterio. Definir su nivel de autonomía.
- Consultar el radar tecnológico para saber qué tan lista está cada tecnología.
- Seleccionar con la matriz de alternativas: impacto en el indicador, valor para el usuario, viabilidad, esfuerzo, riesgo y aprendizaje.
- Prototipar antes de construir: papel, maqueta, Mago de Oz, prueba de concepto o piloto, con tiempo fijo.
- Documentar la decisión: elegida, descartadas y por qué.
Guía completa: G06 - Cómo diseñar e innovar la solución.
Evaluar capacidades
| Capacidad | Qué se revisa |
|---|---|
| Sistemas | Qué existe, qué se integra, dónde viven los datos, restricciones de seguridad. Ver G07 - Cómo validar el encaje arquitectónico |
| Datos | Si los datos necesarios existen, son confiables y se pueden medir |
| Estructura | Qué áreas cambian, qué traspasos desaparecen, quién es el dueño del proceso |
| Roles | Qué hace cada persona en el estado futuro y qué necesita aprender |
Criterio de automatización
Cada actividad del BPMN TO-BE se resuelve con lo más simple que funcione:
| Tipo de actividad | Se resuelve con |
|---|---|
| No agrega valor | Nada. Debió eliminarse en la etapa 5 |
| Regla clara y estable dentro de un sistema | Regla de negocio o validación en el sistema |
| Datos que deben pasar entre sistemas | Integración entre sistemas |
| Repetitiva, con reglas claras, entre sistemas sin integración | RPA |
| Requiere criterio, texto libre o tiene mucha variabilidad | IA o unidad agéntica, siempre con humano en el ciclo |
| Anticipar un problema a partir de patrones | Analítica predictiva |
| Capturar el estado de algo físico en tiempo real | Sensores (IoT) |
| Tarea física repetitiva, pesada o de precisión | Robot o cobot trabajando junto a las personas |
| Juicio con responsabilidad legal o trato delicado con el cliente | Persona, con apoyo de información |
Proceso general
En cuentas por pagar, cruzar la factura contra la orden de compra es una regla clara: va al sistema. Interpretar una nota de crédito con texto libre es criterio: puede ir a un agente, y una persona revisa antes de aplicar el ajuste.
Ejemplo ilustrativo: seguros
En la conciliación de descuentos por nómina, cruzar el archivo del empleador contra la cartera es una regla clara: va al sistema. Interpretar un oficio con texto libre es criterio: puede ir a un agente de IA, y una persona revisa antes de aplicar el ajuste.
Ejemplo ilustrativo: manufactura
En la estación de atornillado, detener la unidad si el torque sale del rango de 45 a 50 N·m es una regla clara: va al controlador de la herramienta. Juzgar si un rayón en la pintura es aceptable es criterio: puede ir a un agente de IA con visión por computadora, y un inspector revisa antes de mandar la unidad a retrabajo.
Ejemplo ilustrativo: retail
En devoluciones de comercio electrónico, validar que el pedido esté dentro del plazo de devolución es una regla clara: va al sistema. Interpretar el comentario libre del cliente sobre por qué devuelve es criterio: puede ir a un agente de IA, y una persona revisa antes de aplicar el reembolso.
El diseño se evalúa en tres dimensiones: valor, usuario y viabilidad. Ver Tres dimensiones del diseño.
Etapa 8. Construcción orquestada
Propósito: construir en ciclos cortos y aceptar solo lo que mueve el indicador. Ver G08 - El Product Manager como Product Owner.
Cada ciclo sigue el PDCA:
| Paso | Qué se hace |
|---|---|
| Planear | Tomar la causa raíz (etapa 4) y la meta (etapa 6); definir qué se prueba en este ciclo |
| Hacer | Construir y probar en un piloto acotado |
| Verificar | Medir el resultado contra el indicador |
| Actuar | Si funciona, estandarizar y escalar. Si no, ajustar y reiniciar el ciclo |
Piloto antes de escalar
Un piloto en un tipo de trámite, una sucursal o un turno cuesta poco y enseña mucho. Escalar sin piloto es apostar.
Etapa 9. Validar y sostener
Propósito: comprobar que el valor se cumplió y que el proceso no retrocede.
Pasos:
- Volver al Gemba para ver el uso real de la solución.
- Medir contra la línea base de la etapa 3 y la meta de la etapa 6.
- Decidir: escalar, ajustar o retirar.
- Escribir el estándar definitivo con el dueño del proceso y capacitar.
- Sostener: auditorías periódicas (la quinta S) e indicadores a la vista.
- Incorporar mejoras de los usuarios como Kaizen.
Pensamiento A3
El A3 resume una iniciativa completa en una sola hoja. Obliga a pensar con claridad y a comunicar sin presentaciones largas. Plantilla: Reporte A3.
| Bloque del A3 | Sale de la etapa |
|---|---|
| Contexto: por qué este proceso | 1 |
| Estado actual con datos | 2 y 3 |
| Análisis de causa raíz | 4 |
| Meta: la hipótesis | 6 |
| Estado futuro y contramedidas | 5 y 7 |
| Plan de implementación | 7 y 8 |
| Seguimiento y resultado | 9 |
Gestión del cambio
Rediseñar un proceso cambia cómo trabajan las personas. Sin gestión del cambio, el proceso nuevo convive con el viejo o lo pierde. Se usa el modelo de tres momentos de Lewin:
| Momento | Qué se hace | Etapas |
|---|---|---|
| Descongelar | Crear urgencia con evidencia del Gemba y datos; romper la inercia; comunicar la visión; involucrar a quien gana y a quien pierde | 1–4 |
| Cambiar | Diseñar con los usuarios; capacitar; ejecutar pilotos; atender la resistencia | 5–8 |
| Recongelar | Estándar, 5S, nuevos indicadores, dueño del proceso; anclar la nueva forma de trabajar | 9 |
La gestión del cambio no es la última fase
Muchos modelos la ponen al final, al implementar. Para entonces ya es tarde: la resistencia se forma cuando la gente siente que otros deciden sobre su trabajo. Empieza en la etapa 1, con el Mapa de involucrados, y es una capa que recorre todo el ciclo, como Design Thinking.
Quien lidera el cambio no solo rediseña procesos: modela comportamientos y quita barreras para que el equipo pueda trabajar distinto.
Fuentes
- Process Transformation Playbook (presentación de referencia, en Adjuntos). Se excluyeron sus cifras ilustrativas sin fuente.
- Hammer, M. y Champy, J. Reengineering the Corporation (1993): origen de la reingeniería.
- Reingeniería de procesos (BPR): guía ejecutiva (presentación de referencia, en Adjuntos): cuándo aplicar reingeniería y sus 6 pasos.
- Sistema pull y takt time (presentación de referencia, en Adjuntos): pull, takt time, heijunka y kanban.
- Arquitectura de procesos: del catálogo al flujo (presentación de referencia, en Adjuntos): APQC PCF y BPMN.
- Rother, M. y Shook, J. Learning to See (Lean Enterprise Institute, 1999): mapa de flujo de valor.
- Lewin, K. (1947): modelo de cambio en tres momentos.
- Lean Enterprise Institute: Lean Lexicon.
Relacionado
- Definición del rol
- G02 - Cómo conducir un Gemba
- G04 - Design Thinking para el Product Manager
- G08 - El Product Manager como Product Owner
- MOC Product Manager
Ruta de lectura (1 de 9): ← Módulo 0 - Fundamentos de procesos · índice · G02 - Cómo conducir un Gemba →